https://www.ireadthisweek.com/author/ireadthisweekWhat ireadthisweek read about this weekhttps://www.ireadthisweek.com/author/ireadthisweek/post/2022/12/31https://www.ireadthisweek.com/author/ireadthisweek/post/2022/12/31# New Feature - Email to Blog Post Now when you send an email to your special email address and start the subject with “blog: “ or “title: “ a title will be prepended to your blog post and it will become a midweek blog post. After the email is sent the blog post will be immediately published and sent to your subscribers via email in a newsletter format. The word “blog: “ or “title: “ including colon and optional space will be removed and everything that comes after it will be the title of your blog post. So if the subject line of your email is “blog: Here are Seven Great ways to Write Better” then the title will be “Here are Seven Great ways to Write Better” and the body of the email will be the body of your blog post. It will then be published and sent out immediately to your subscribers. This won’t be recorded in your weekly post and that will continue on as normal, accumulating emails and auto publishing once a week. https://www.ireadthisweek.com/author/ireadthisweek/post/2022/02/14https://www.ireadthisweek.com/author/ireadthisweek/post/2022/02/14# ​​The Raw Speed of the Web When you optimize for speed over everything else the web can get pretty fast. The trick is in 2022 to manage or pay attention to everything that your page has in it. Everything that the server sends to the browser can be measured. We’ll be taking a look at this page:  In order to send this page to the browser a request was made. Then the browser received it’s response from the server, in this case it was an HTML page.  This HTML page told us to download these additional elements, namely these images and css from the same site and a couple of images from other sites  Some of the images and css were downloaded in parallel which saved time.  For some sites literally every item has to show up before anything can be rendered. But for this page the rendering happens as soon as the HTML is loaded, so while the browser times how many milliseconds it takes to finish loading our reader can start reading as soon as text shows up on the screen. For human perception most anything that happens below [13ms is perceived as instantaneous](https://caseguard.com/articles/how-many-frames-per-second-can-the-human-eye-see/). But anything that happens below 100ms is “almost instantaneous” and that’s our target for webpages, almost instantaneous. So how fast does this page load? The browser reports this page loads in around 127ms (milliseconds) and the total time is 140ms. So I tried checking the time with a stopwatch but my hand reaction time wasn’t fast enough, I was reacting in around 390ms, but I could perceive that it did take some amount of time. Thankfully I had a high speed camera via my smartphone, I could record a high speed video and count how many frames it took in between pressing enter and the rendering to finish. The video frame rate is 240fps (frames per second) and the number of frames it took to display is approximately 83. So this means the page took around 346ms to display, my reaction time was pretty close but the eye (and brain) is actually faster than the hand. Right before enter is pressed  Right after enter is pressed  The first visual indicator appears in the toolbar The browser starts painting  The browser asks the display to continue painting  The site first starts appearing  The text is dim, this may be the browser rendering a different color of text because the background is white  The site is finally rendered  ## Interpretation of Results One hundred milliseconds is the goal, we might not reach the goal and that’s ok as well. In reaching for the goal we might be able to substantially improve the user experience. There are several things outside of our control such as internet speed and device speed. There are actually more things outside our control than inside. As we can see from the above analysis. Not only is internet speed variable but it depends how the interconnection from server to client is handled. Also there are a very wide range of devices that can access the web, many of which can introduce slowdown themselves. So let’s focus on the things we can control. How long it takes to process a request from receiving it, to sending it down the wire. Once we do send it down the wire we have the ability to measure how much data is sent. Let’s focus on processing speed on the server first. When we get a request we should take careful note of where the response actually comes in and how long it takes till we start doing something with it. I Read This Week uses an nginx reverse proxy and Go on the server and I was surprised at how quickly the response goes from server to nginx to Go to `gin`’s middleware and finally to my route definition. It didn’t take nearly as long as I thought. Originally I was reading the article off the database. But after adding a cache layer I could return the request as quickly as possible. The next thing we can optimize is what comes down the wire. This requires us to determine exactly what the webpage or webapp does. If it’s a blog or news site where the primary information that the person requesting will be textual, then it makes the most sense to encode it as HTML and send it down, it doesn’t get much faster. If it’s an app then the smallest thing that can possibly be displayed should come over first to show the user at least something is happening. The rest of the app will be ready in a few seconds and both the user and us expect the user to use the app for a few minutes. Sometimes the flow of a single page app can be “faked” using a website with multiple pages and if attention is paid to all of the above the speed can be just as performant across the board. As long as the user’s perception is kept in mind. So in essence the main point, which has been a long winded way of getting to the title of this post, is how it is possible to achieve “The Raw Speed of the Web.” ## Conclusion The goal is to determine what exactly the app needs to do. In I Read This Weeks’s case it’s to take signups and show blog posts. That’s great because raw web was made to do stuff like this. One issue that comes up is state. Where will the state be stored because when a user signs up we have more than one question. In a single page app state can be stored in JavaScript and synced up to a server via a REST API that sends JSON back and forth. In our case however, the state is stored the same way, in a database, but each page transition only asks one question for each page. What we might miss out on is a slick animation that transitions from one question to the next but in the context of raw speed it’s actually quicker to the end user to do a full server hop because there’s no animation to slow us down. In the case of displaying a post the only thing that has to come down the wire is the actual post with HTML and text. The one thing I haven’t talked about so far is images. Yes, we should optimize images. The issue with images is the larger in millimeters the image is the longer it will take to load. The image should be large enough to display in size to get the point across and just enough resolution to look good. Reduce the size on disk to just enough, but no more. If needed a link can be provided on the image to a higher quality image and perhaps this should be a common practice. Will the web get faster? The web only needs to be as fast as the person looking at the page. We don’t need to get up to the theoretical speed limit of light if the person on the other end is a human with perception times that can only perceive a page up to a certain limit. Once we go faster we are in the range of video speed and then the same rules apply. If you enjoyed this post consider subscribing to the author, [Abe Massry](https://www.ireadthisweek.com/author/abemassry/previous)https://www.ireadthisweek.com/author/ireadthisweek/post/2021/12/13https://www.ireadthisweek.com/author/ireadthisweek/post/2021/12/13# I built this blogging platform for HN readers  **I Read This Week** was built for HN readers. Based on articles you’ve all been posting about blogging, the content of those articles, and the HN comments; this site was built for you. ### Uses no JavaScript There is no javascript on this entire site except for one page by necessity. ### Send email to create and append posts Have a thought? Want to compose your entire post in an email? Found a webpage that you’d like to share or talk about? Send yourself an email to a personalized @ireadthisweek.com email address and it will show up as your next post. If you send yourself an email more than one time in the week all of the emails get appended to, for one post with all of your content for the week. You actually don’t even have to interact with the site at all past the initial signup, you can continue sending yourself emails. ### All posts in markdown Write markdown in email or in the `textarea` for this week’s upcoming post. ### Auto publishes At the beginning of the week (on Monday morning) a new post is automatically published with the previous week’s content and any subscribers get the blog post in an email right to their inbox. ### Custom domains Bring your custom domain, set your A and AAAA records and get a TLS cert provided by LetsEncrypt. ### Send newsletter to subscribers, optional text only emails. Subscribers subscribe directly to you and get the same content on your blog to their inbox, they are subscribing to support you, and have the option of HTML emails or plain text emails. ### Includes an RSS feed Every blog account gets an RSS feed ### Analytics See how many people are reading your posts with custom built, yet very simple, non-javascript analytics on your profile page after you sign in. ### Small but sustainable fee Subscribers pay $5 a month to subscribe to you. You get $4.45. Stripe, our payment processor takes $0.45. We collect a small $0.10 fee (2%) each month from subscribers to maintain the service. ### Export your posts. Download a copy of all your data at anytime ### Save your subscriber list If a subscriber agrees to share their email address with you, you get to keep it. You can then save it and reach out to them individually, or make your own newsletter, even though we wouldn't want to see you go, we want to give you the freedom of choosing to stay. ### Small team open to feedback. Have an idea for a feature? Let us know and we’ll start working on it. This post was written by [Abe Massry](https://www.ireadthisweek.com/author/abemassry/previous) consider subscribing for more content like this.https://www.ireadthisweek.com/author/ireadthisweek/post/2021/09/27https://www.ireadthisweek.com/author/ireadthisweek/post/2021/09/27# This site was built without JavaScript Actually the title isn’t 100% truthful, there is JavaScript on only one page, maybe you’ll find it 😁.  Building a site using no JavaScript at all is surprisingly difficult, some things you’d like to do are surprisingly difficult. Take form validation for example, sometimes you’d like to do front-end form validation as well as back-end form validation. It turns out there are now HTML5 form validation options built into browsers that browsers have natively implemented. So you can get some dynamic behavior without using JavaScript. ## Form Validation Here’s what Google Chrome looks like when it renders:  Here’s what the code looks like: ``` <input class="u-full-width" type="email" name="email" value="username@example.com" id="email"> ``` Specifically the `type="email"` is what makes this appear as an email validation form. This is something implemented in the browser so there’s less chance of us [mere mortals](https://www.ex-parrot.com/pdw/Mail-RFC822-Address.html) getting email validation wrong. But what happens if we *do* want something arbitrary, less complex than email but some simple rules? It turns out that browsers have also implemented arbitrary form validation via regex matching. Here’s what it looks like:  Here’s what the code looks like: ``` <input class="u-full-width" pattern="[a-zA-Z0-9_]{4,15}" title="Letters, numbers, _ (underscore), less than 16 characters, more than 3" type="text" name="twitter" value="abemassry" id="twitter"> ``` This time the `pattern` is what gets checked and inside the double quotes you can put a regex string. The `title` tells you what the pattern is in English (or insert language of choice) and is displayed in the native tooltip. ## Sign Up Flow The next part where JavaScript comes in handy is a sign up form, usually if there are many fields. In order to reduce the [cognitive overhead](https://en.wikipedia.org/wiki/Cognitive_load) of many fields in a signup form only one question was asked at a time. This actually turned out to be much simpler to step through because there was only one item on the screen in focus at a single time. The other benefit to this was each submission allows the user (prospective author) to essentially save their place in filling out the signup form and when they return they are at the exact spot they left off. There are only 4 questions though so it’s very easy to step through and sign up. Sometimes you might find a better way by making an arbitrary constraint and it seems to be beneficial in this case. ## Retro In retrospect and retro style; JavaScript isn’t all bad, it’s used in tons of places, on the web, on the server, in microcontrollers. I really like JavaScript actually, but I wanted to see if it was possible to build a site without using it at all. In this context, a blogging and newsletter site, it is definitely beneficial because the primary response coming from the server is all text. However, some apps and websites would not be possible at all without JavaScript and I’ve written sites like this one, sites with minimal JavaScript, and sites that are JavaScript Single Page Apps (SPAs). So basically the entire range. The final takeaway from this post is use the right tool for the job. This post was written by [Abe Massry](https://www.ireadthisweek.com/author/abemassry/previous) consider subscribing for more content like this. https://www.ireadthisweek.com/author/ireadthisweek/post/2021/08/15https://www.ireadthisweek.com/author/ireadthisweek/post/2021/08/15# I Read This Week - Blog