Tim's Blog

The Current Slowness

The current zeitgeist for web development involves a complex, Single Page Application (SPA) which requires loading Javascript. The Javascript code then makes another network request for the content of the "current page". While this content is loading, you might get a blank "skeleton" page with some loading indicator. After all of this, you hopefully see the page content. This is just considering the front-end.

1. Load HTML
2. Parse HTML
3. Load Javascript
4. Parse Javascript
5. Show Loader
6. Load Data
7. Parse Data
8. Render Page

No wonder websites take forever to load! You have to wait for the Javascript code running the page to load and parse, then you have to wait for another network request for the actual content. This seems like (an in many ways is) a huge step backwards from the early web.

How We Got Here

Early websites are simple hand-written html files. When you load a website, your web browser fetches the html, it is parsed, and the site is loaded.

1. Load HTML
2. Parse HTML
3. Render Page

Websites have become more advanced since the days of simple html files on a web server. Most websites now have server-side code and data storage. So many websites generate html with code to have dynamic content, and be more interactive.

At first, websites that have a lot of interactivity, games, or video, require web browser plugins, such as Java Applets, Shockwave, and Flash. These plugins then pull data from a server.

When Javascript becomes more powerful, and can make its own network requests, games, web mail clients, and other "Web Apps" arise. These replace the functionality from the old plugins with browser-native functionality. This leads to the ill-defined schism between websites and web applications.

Web Apps lead to Javascript page rendering, where the server sends HTML, which loads Javascript, which loads data, finally rendering that data as HTML for the browser.

Problems with Javascript Rendering

Javascript is not ideal for rendering HTML in the browser for several reasons:

• Delayed Rendering - It takes longer to load and parse Javascript to render HTML than to just render HTML in the first place
• Flakiness / Error Handling - Javascript is a tricky language to make robust. Using Javascript to render HTML makes that lack of robustness a lot more obvious.
• Client Slowdown - Javascript renders on the user's computer, and complex code can lead to a notable increase in lag on a computer

Improving performance

It is certainly possible to have a website that loads quickly, yet has the interactive qualities that is associated with heavy Javascript.

The best solution is a mix of server and client rendering. On initial page load, the server renders the HTML. The Javascript is parsed and loaded, and adds the functionality to the existing HTML. New views can be loaded and rendered via Javascript.

The solution is fairly obvious. So why aren't websites built this way?