I started working on the web in 1994 and I’ve been privy to the evolution and complication of the web and its component technologies.
We’ve improved considerably from those days to where the web is now. We have hundreds, if not thousands, of projects that we can learn from but that’s not the answer.
Frank Chimero’s Everything Easy is Hard Again presents the view of someone who left the web design business and returned a few years later to find out how much more complex the web had become and how much more we do for the sake of doing it.
It’s from this viewpoint that messages like this worry me.
“Can we agree that, in 2018, human-readable “View Source” is a constraint the web can discard? I benefitted from “View Source” too, but today we have an embarrassment of resources and open source examples I would have killed for as a kid.”— Tom Dale
Jonathan Snook and Christian Heilmann present interesting positions on the issue of having text-based renditions of our content in addition to what’s interpreted by the browser to provide the output on-screen.
Snook writes towards the end of his post:
The sites some build may be simple static sites, befitting of a simple View Source. The sites some build may be compiled and bundled and requiring tools that allow us to dig deeper. Just because you don’t need those tools doesn’t mean that somebody doesn’t need those tools.
Chris Heilmann makes three points that I think are interesting to look at:
Except for a few purist web sites out there, what you see in your current device isn’t the code of the web site.
Code sent to the web is often minimized and bundled. Developer tools give you options to pretty-print those and thus make them much more understandable.
DevTools in all modern browsers work hard in letting you see what the code you’re viewing really look like and give you a human-readable version of the code, within the limitations of the tool used to create the minimized scripts and bundles:
- Looking at the code generated by Webpack you get more lines of Webpack code than bundled code, it’s difficult to figure out which bundle contains the script.
Of course, it is great that there is no barrier to entry if you want to know how something works. But the forgiving nature of HTML and CSS can also lead to problems.
I agree that HTML can cause problems but it’s on us as developers, as standards organizations and as people who teach about the web that it got to where it is. Some developers embraced the tag soup markup (a defensive measure to make sure that the web still worked in modern browsers) and produced markup that would never validate as HTML in any strict validator… and we claimed it was OK and we moved on. As a result, web browsers must be forgiving because developers took the shortest path to a result rather than taking the correct path to the solution.
We need to put the best examples front and center so that people who copy and paste code will find semantic correct HTML rather than tag soup garbage.
But there are more fundamental questions than whether we should have view source for our web content or whether view source is a constraint to current web development.
The entry barrier
But now with all the minimization and bundling of our code it has become very hard, if not outright impossible, to do that kinds of “learn by doing” because there is no easy way to identify mangled variables or figure out how many Webpackk generated bundles we need to keep to make sure that the code works.
Another of Tom’s quotes in the same Twitter thread makes me wonder if I’m missing something. The tweet in question:
I'll go a step further: insistence on human-readable formats on the web is a pretty intense display of Western privilege. Binary formats are important for reaching people with slower devices and capped data plans. I'll happily sacrifice my own nostalgia to achieve that goal. — Tom Dale
I don’t think that a binary format will change the way we address transfer and weight of our web content, if nothing else, we’ll be throwing the same volume of material in a binary format, thus removing any advantage that the binary format offers.
It’s not just the network time that’ll kill your app’s startup performance, but the time spent parsing and evaluating your script, during which time the browser becomes completely unresponsive.
See this presentation from Alex Rusell to get a better understanding of the challenges of the mobile web. It’s from 2016 but the underlying principles have not changed.
The following figures show how much stuff measured by the median number of requests and size in kilobytes have grown in a 3-year period from 2016 to March 2019 (data taken from the HTTP Archive’s state of the web report).
I think that to solve the performance problem we’ve created, we have to become more restrictive of what we can and cannot do on the web. We can start with enforcing best practices for any one of the many performance patterns available… RAIL and PRPL offer actionable goals for you to pursue but actually meeting the performance goals is up to you.
Tools like Performance Budget Calculator, Performance Budget Builder and Browser Calories can help in building the budget once we figure out what a budget is and decide that we want to use one for our project.
Smashing magazine publishes an annual front-end performance checklist. The 2019 edition provides sensible and actionable steps for you to follow if you want to improve performance on your site or app.
Once we have the budget we need to enforce it. Webpack has a plugin that will warn (or error out) if you go over a pre-defined bundle size and Pinterest has created an ESLint rule that disallows importing from certain packages.
How we address these performance requirements and how seriously we enforce them is up to us. But I see no other way to really to get out of this bloated mess we’ve turned our web applications into.