What upsets and concerns me the most is when I see poorly developed SPA on really important sites. For example, government service application websites. If reddit or nytimes has a bloated, intermittently failing SPA site, that's an annoyance. When it's a form to apply for unemployment, ACA health care, DMV, or other critical services, it's a critical failure. Especially since these services are most often used by exactly the population most impacted by bloated SPA (they tend to have slow or unreliable internet and slow computers, maybe even a cheap android phone is all they have).

Such sites should be using minimal or no JS. These aren't meant to be pretty interactive sites, they need to be solid bulletproof sites so people can get critical services. And I haven't even mentioned how SPA sites often lack any accessibility features (which is so much easier to implement if sticking to standard HTML+CSS and no/minimal JS).

Yeah what's weird is that there's is an entire generation of developers who think of SPA as the default.

They think that server side is slower because you have to send down more data, or you have to wait for the server to generate HTML.

Quite the contrary, it's slower to send down 1 MB or 10 MB of JavaScript to render a page, than to simply send down a 100 KB HTML page. Even if you need some JS also, browsers know how to render concurrently with downloads, as long as you provide enough HTML.

Rendering HTML on a server side Intel/AMD/whatever CPU is way faster than rendering it on a mobile device (and probably more efficient too).

Even if it weren't faster and more efficient, it would save battery power on the client.

And there is a ton of latency on the client side these days, ignoring network issues. There are ways of using the DOM that are expensive, and a lot of apps and frameworks seem to tickle those pathological cases. These 20-year-old browser codebases don't seem to be great workloads for even modern Android or iPhone devices.

---

edit: To be fair, I think what's driving this is that many sites have mobile apps and web apps now, and mobile apps are prioritized because they have more permissions on the device. (This is obvious when you look at what happened to Reddit, etc.)

It's indeed a more consistent architecture to do state management all on the client. Doing a mix of state on the server and state on the client is a recipe for confusion -- now you have to synchronize it.

Still there are plenty of apps that are website-only, like the government sites people are talking about. Those people appear to be copying the slow architecture of the dual mobile+web clients and getting a result that's worse.

Take away React, Vue, Angular, or similar away from most current front end developers and there is panic. When I say panic I mean full insanity panic like abandoning the profession or completely going postal.

——

A simple checklist to provide superior front end applications:

* Don’t use this. You (general hypothetical you) probably don’t realize how easily you can live without it only because you have never tried. Doing so will dramatically shrink and untangle your spaghetti code.

* Don’t use addEventListener for assigning events. That method was added around the time of ES5 to minimize disruption so that marketers could add a bunch of advertising, spyware, and metric nonsense everywhere more easily without asking permission from developers. That method complicated code management, is potentially point of memory leaks, and performs more slowly.

* Don’t use querySelectors. They are a crutch popularized by the sizzle utility of jQuery. These are super epic slow and limit the creative expression of your developers because there is so much they can’t do compared to other means of accessing the DOM.

I now add ESLint rules to my code to automate enforcement of that tiny checklist.

I think a bit of context about `this` is important.

Using `this` in a callback -- where you expect your caller to provide your local binding -- is straight-up bad juju. Pass arguments instead.

Using `this` in an object instance to namespace is just fine. The entire point of having an object is that you get these nice encapsulated namespaces which can send messages to each other.

One suggestion, and a related ask: rather than just saying "Don't do FOO", provide alternatives as well; e.g., "Don't use `addEventListener`, use `superFooBarBazzer`".

Bonus points awarded for runnable examples. :)

Perhaps my biggest gripe about the entire Javascript ecosystem is finding libraries that provide documentation that looks like this:

    // See how easy my library is to use!
    myLibrary.doTheThing(fooBar, bazBang);

40k loc. I wrote an ESLint rule to error on this in both statements and expressions.