In Defense of the Modern Web

I think it's a shame that frontend web developers have thrown themselves behind the SPA paradigm so hard that the notion of a JavaScript ecosystem that doesn't try to do pull _everything_ into its own domain is unimaginable. I'd love to see more mindshare go towards building libraries that are drop-in/"just add water" progressive enhancements for static sites.

[edit: minor grammar correction]

How many sites actually do this? And how much additional bandwidth (and battery life for mobile devices) does doing this consume?

> We can provide better visual feedback that loading is taking place and a transition is about to occur. And we don't need to load the entire contents of the page — often, we can make do with a small bit of JSON because we already have the JavaScript for the page.

In my experience sites that do this are almost universally slower and less responsive than sites that just use normal links. Maybe that's just confirmation bias and I just don't notice it as much on sites that do it well, but a particularly egregious example of this is Reddit's current mobile site vs their old i.reddit.com mobile site (which I use exclusively (despite it missing a number of newer features and having a lot of minor bugs the newer site doesn't) because it's way way faster).

You probably don't need your js framework, your 10k npm dependencies, or your complex mix of server and client side rendering. Not every website needs an api and clients to consume it, and not everything needs to be an app.

The web is a success because it is simple, accessible, fast, and nobody cares how the server makes the html they are reading. Let's keep it that way.

- The developers want to prove themselves with a new technology

- The site owner wants to make money, so adds are required

- The website needs to "verify identity" to cut down on fraud, so invasive trackers are added

- The finance team wants to cut down on infrastructure costs, so they want less done on the servers

- The user wants to do what they came for done, but may be frustrated by how the site slows down the browser

This tug-of-war is a lot of what leads to slow, resource-intensive, privacy-invading websites.

Native’s much more likely to be ok.

Chief problems are: web interface design tends to be much worse than native (even if they look nice on a screenshot), UI latency is bad and gets worse the more JS you throw at it, there’s more likely to be unhelpful functionality the developer’s accidentally created (selecting the text on a “button” rather then clicking it), and they’re more likely to have weird state-related fragility.

No, it's not. It's easy and you can do all that without an SPA framework. If you can't see this in about 5 seconds, you shouldn't be lecturing other about how to design websites.

Preloading hovered links can be done with a standalone library. AJAX can be done with another a standalone library. Removing extra crap from your page to facilitate faster AJAX can be done with a custom request header and a couple if-else statements on the server side. Best of all, this stuff can be added after you have a working website.

What? The solution to making a website fast is to crunch analytics (presumably on the client and in JS, all of which has to be loaded beforehand for this to work) and then try to predict what the user is going to do on the website, anticipate it, and start loading, even when it might go waste?

Wastage of network bandwidth aside, Speculative Execution destroyed the chip performance in the last two years and opened up a whole lot of scary security holes, some of which may never be fully patched without performance hits. And the bright idea is to do that in the browser?

The author isn't just a React apologist, but also seems to want javascript everywhere.

So much of this debate - sever side rendering, etc. - has to do with the inefficiency of DOM. Mobile and desktop UI toolkits aren't DOM for a reason. They do application UI and have application concerns, meanwhile JS is sitting in this weird Frankenstein ducktaped documents-and-apps markup world. An ecosystem that has to support a million (often competing) things, but all slowly, and with decades of legacy we can't break.

It's going to be interesting change of landscape when we have isomorphic Rust/Wasm delivering truly native web apps that don't render on top of the 30 years of DOM kludge.

The Rust community is just getting started and hasn't had a long time at this, but there's already some really impressive UI work being done in the browser with Rust/Wasm [1]. Once Rust frontend frameworks begin to arrive, it'll be a whole new ballgame. It's so damned fast.

[1] http://makepad.nl/

Many SPA developers rapidly move from project to project. Every once in a while, they learn yet another JS framework, and then hop between jobs to use that.

They never look back. They never truly need to take responsibility for a tech choice.

Try to hire an Angular 1 developer to work on 300K lines of code today. You can't. No skilled front-end developer would take on such a job with options to work on hotter tech.

Any SPA choice you make today will be completely obsolete in 3-5 years. 3-5 years, or even 10 years or more, is a normal life cycle for a serious web property. And not just obsolete, you'd have the hardest time getting the tool chain to still work at all.

The original developers don't care, they using tech N+5 now, somewhere else. They'll be very vocal how N+5 is vastly better than anything else, and really the only option for "the modern web".

It seems that page transitions really are the main reason given for using JavaScript-everything for sites and simple applications that otherwise could have been built with some fast loading HTML and a couple of POST forms.

In native apps, I'm a sucker for pretty transition animations, and I'd love to see those on the web.

But, every website I've ever seen with those types of fancy transitions for large pieces of content (as opposed to little on-page microinteractions) also feels slow, clunky, and heavy. As such, I've come to associate such transitions with slow, clunky and heavy web pages.

I'm not really a web developer, so feel free to tell me if everything that follows is stupid: It seems unlikely that our "current trajectory" can ever resolve this problem. Instead, we'd need an underlying technological shift in how browsers work.

Most large transitions are basically browser hacks—albeit ones we've used so frequently, and for such a long time, that they've come to be officially supported and accepted. To make them more usable, they'd probably need to work alongside the browser in some manner.

And JavaScript has laid claim to that throne which was once primarily contested by enterprise Java and .Net.

The modern web delivers some of that, but only accidentally. The modern web is all about delivering potential malware to me and expecting me to run megabytes and gigabytes of this code, all in order to … display pictures and text, something the browser has been capable of for over twenty years.

This is like saying a lightbulb turning on quickly is jarring. It's the expected, immediate behavior. If every lightbulb I used turned on with different durations and easing functions or flashed colors at me, or loaded a flashing placeholder while the lightbulb loaded, that would be jarring.

A browser that implemented a few semantic tags (including <img> and <video>), fonts, colors, and flexbox would be useful, secure, fast (even on slow devices/connections), and far easier to implement than the behemoths we have now.

Let the application web keep evolving, but specify a well-defined subset for sites that don't need all the features.

SPA as the status quo is a myth. It's a Fermi paradox. Where are they? Almost nothing of any importance is an SPA. You'd think that if they have such superior experience, they lead to superior business metrics, thus they are everywhere. Asides from true app-like experiences like Gmail, Spotify, the like, they're nowhere to be found. Not in places of significance. It's 2020 and Amazon continues to be old school page refreshes. Last time I checked they're doing quite OK. Even big parts of Facebook, the poster child of complex interactivity, continues to do full page refreshes in big parts of the experience.

Instead, SPAs are a startup default, not a web default. Big difference. And the way most are implemented, they don't live up to their potential benefits, instead deliver UX that is even worse than static:

- breaking back buttons - breaking scrollbars - rendering things that aren't interactive

These things don't have to occur, they can be solved in an SPA, but they do occur a lot in the wild. This matters. We live in the real world.

As somebody else here already mentioned, the article takes a completely wrong approach. It assumes some binary choice or outcome. The original point instead was that the web is not a single thing. It's a huge thing where different stacks are to be used for different use cases. This point is largely ignored, instead it is implied that SPAs should simply solve such use cases better, whilst continuing to be a default.

On the particular point of SPA links being typically faster/smarter: there's about 500 drop-in solutions to speed up static links. Which are usually not needed, because the point of such links being bad is overstated and lacks any user evidence. See my earlier remark on virtually all major websites using plain old links. They wouldn't if it was so bad.

Finally, a huge part lacking in this discussion is the accessibility of web development itself. The SPA web is an engineers web, it requires advanced programming skills, infrastructure, increasingly complex tools chains, and so on. If this was to be a true default (luckily it isn't), it would lock out the vast majority of people wanting to contribute to the web.

It's sad to see this sub culture of hardcore engineers with Macbook Pros thinking they own or represent the web or web development.

According to this article we should accept:

- Heavy sites that take a long time to load initially.

- Are sluggish and unresponsive when not on this year's flagship phone.

- Will probably break if the user leaves a tab open for too long.

Because:

- There's an opportunity to shave a fraction of a second off of your page load times if you want to utilize predictive analytics or extensive preloading to ensure the content request is already loaded in cache.

The modern web is just layers upon layers of hacks and it's ugly and slow.

I would recommend to anyone who disagrees to install the NoScript Add-on and run with it for 6 months. I did so and here's some things I've observed...

When I enabled NoScript:

- Most sites do not work without some Javascript that's been used to address Page reflow. They have a global display:none attribute that's removed after the entire page has loaded. All this discussion about page load times or responsiveness is BS when sites are hiding their site from you until it completely loads to avoid reflow.

- Most sites rely heavily on Javascript to do basic formatting that's trivial in CSS.

- Most sites use Webfonts loaded via Javascript

When I disabled NoScript:

- My Phone went from 60% battery at the end of the day to <20%.

- The Web is slow again.

- User hostile behavior like pop overs, auto-play video, and other garbage.

I used to think it was an oversimplification to divide the web into Documents and Applications. I thought it was more accurate to say it was a continuum, and using two different techniques was a sign that we still had not figured it out. After all, a blog post about programming might have an interactive example. An article about retirement might embed a calculator. If you try to categorize a site or even just a page as Document or Application, it gets fuzzy. But if you look at a page and just try to categorize it section by section, as Document or Application, it's easier. (Hence, Web Components make more sense to me.)

So anyway, most people spend some time surfing the web --- by that I mean visiting Documents. Clicking links from search results, to articles, to more articles. If you aren't using an adblocker, I can't imagine how you don't end up throwing your laptop against the wall. I ended up just turning off JavaScript for most sites, and the web looks more like how I think it should look. Every once in a while these people will post a rant, and it will resonate with most people.

But then an Application Developer will read it after a long day and say, hey, wait are you saying I should write my Application (like GMail) in jQuery? To be honest, Applications don't bother me the way overscripted Documents do. I almost expect them to be kind of slow. After all, even some Desktop Applications still have loading screens. So I don't mind so much if you're using React or whatever for your Application or even for that calculator embedded in the article about savings.

But for Documents --- like articles, blog posts, company home pages --- well, one thing I agree with SPA developers is that there could be less server-side rendering. These kinds of sites could often be compiled ahead of time into static HTML. Server-side rendering is better than SPA for these kinds of sites, but static sites are better than server side. I mean, who enjoys getting "Error connecting to MySQL database"? (Okay, that's rare.) I'm intrigued by the old-new JAM Stack :)

It's not a perfect parallel, but this reminds me of systems like Qt Designer, or Apple's Interface Builder/Storyboard, or Android's XML layout system. Those systems all essentially give you an "initial render" made with one technology (XML files created in some sort of visual GUI-builder program) and "subsequent interactions" made with another (C++/Swift/Java code).

My take is, however, that the web as we know it is going to be split in apps and websites.

Sites is stuff that works fine with an 'old classy' request->response method, stuff like blogs, newssites, wikis, information sites, simple booking sites etc. You can make a great living just doing that. Probably most content available on the web will fit in this category. However I think Wordpress and similar frameworks / libraries will continue to dominate this field.

Apps is stuff where you practically need a SPA, where there is no choice. Things like music players, photo editors, file managers, chat applications etc.

Old mom n pop shops will still be around and never need a SPA, but a lot of applications being ported to the web do need it. If you do old style websites, there is nothing wrong with that and it still works fine for a lot of stuff. But if offline capability is a requirement (as an example), it is very hard to make a compelling case without making a SPA.

I like both, I find the old style apps to be a lot quicker to develop but the SPA, PWA style app gives the user a much native feel which is important for a lot of apps.

Speaking of which...

> I'm not aware of any other platform where you're expected to write the logic for your initial render using a different set of technologies than the logic for subsequent interactions.

I'm not aware of the backend, the server side of many mobile application being written in kotlin (or java) or swift.

In fact, it's common for the server and the client to be written in different technologies.

Yes, I know that's not exactly what he means and in a native application, the application is in charge of the initial render. But he's criticizing APIs and I don't see how this statement can be possible without APIs unless he expects the backend to be in the same technology. Which, again, is not unusual for it not to be so.

Or we can say, they are implementations on how to achieve the same thing. The difference is performance.

SPA tech is a good thing for web sites that have little appy parts (like checkout processes, or maps). I'm not saying for the entire website, but just little focused parts. Can you imagine going back to (the old) Yahoo Maps now that Google Maps exists?

Are SPAs good for entire websites (like the new reddit?) Personally I like the new reddit over old reddit. But this is where your users are highly relevant. If you don't listen and choose SPA for millions of users of the public, you will probably get Feedback. You might be lucky and only 10% hate it, but it might explode in your face if that's a key 10% that encompasses influencers.