HN Reader

I wonder why the article doesn't mention utilizing the browser cache for your static CSS and JS assets instead of introducing a service worker as first measure.

Few years ago I built a shopping site MPA this way and the page transitions were almost not noticable.

> I like to argue that some of the most productive days of the web were the PHP and JQuery spaghetti days

I've wondered if going back to that paradigm would be more productive or not than using React et al.

Plenty of big sites like Amazon or Steam still are made this way. Not exactly PHP + jQuery but rendering HTML on the server and sprinkling some JS on top of it.

Has anyone gone back to working like that?

Can someone explain what the service worker strategy accomplishes that plain old http Cache headers don't? It saves a (almost zero weight) network roundtrip, but feels like it's re-inventing the entire wheel for that small (I think) optimization? Am I missing something?

Full title is "You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths"

Omission of trailing part changes the meaning and makes it clickbaity.

The most dangerous thing in programming is developer boredom with a dash of hubris and ignorance of the past.

> The myth that you can’t build interactive web apps except as single page app

You can do it, but you might paint yourself into a corner. For example, your manager might at some point say: please load X, while Y is animating; that will not work if the entire page is reloading. A SPA will give you more control and will also reduce the probability of having to rework entire parts of the code.

Even preceding the tech stack decision, many devs err when they misunderstand what they are writing. GMail, Google Sheets, Google Docs, etc. are apps, if you don't need that level of interactivity, it's probably just a crud app (AirBnB, Craigslist, ecommerce, etc.) and you'd be fine with more a mostly server-side framework.

My feeling nowadays (i.e. since around a decade maybe) is that there is a lot of technical complexity going on which should imho be either an internal part of the browser itself, or should not be used that widely.

It's probably all good for something... But I would love to just make my web app out of what the browser itself can do, without a tech stack as high as a skyscraper for me to handle.

I know, this way the ecosystem can develop more rapidly (compared to waiting for improvements in the official web standards), and it's also fun to play with toys, and everyone can raise his/her value by learning more and more of these tools.

On the other hand, the web was imho in a better shape before all that began. From user perspective and from developer perspective.

I could be wrong... I'm not primarily a web developer at all...

The HN headline is more combative than the actual headline:

You Can't Build Interactive Web Apps Except as Single Page Applications... And Other Myths

This is an essay contributed by Tony Alaribe, based on his talk at BigSkyDevCon this past year, discussing techniques to make a non-SPA based web application feel fast and slick. He mentioned some techniques that were new to me and I thought it was the best talk at the conference.

People treat SPA and MPA as oposing teams, one is the right way and the other is garbage. But this is not how it must be seen.

What we have is the natural way to do things with web stack (the way it's is mean to be used), and the "hacky way" (the way that let us do what we want to do, even when the web stack doesn't support it yet).

SPA is the hacky way today, but before it we had CGI, Java applets, Flash... And the web purists were always very vocal against the hacky way.

But the hacky way is what pushs the envelope of what the natural way can do. Every feature cited in the article that makes an MPA competitive with an SPA today only exists because of SPAs.

I'm on the side of preferencially use the web the way it's meant to use whenever it's possible, but I love to see what can be done when we are a little hacky, and it's awesome to see the web stack adapting to do these things in a less hacky way.

To me it seems that if you have decent cache control headers, then SSR can be decent even without very specific optimizations.

When choosing a tech stack, normally I’d also look for which one rots the slowest. Writing a SPA will typically mean that in the case of the libraries/frameworks there becoming untenable, at least you have an API that you can use when writing a new client.

I have this PrimeFaces/JSF project at work - it’s unpleasant to work with and feels brittle (especially when you have to update components, in addition to nested table row updates being pretty difficult). I’ve also helped migrate an AngularJS project to Vue, the former was less pleasant to use than the latter but the migration itself was also unpleasant, especially when you wanted to get close to 1:1 the functionality. I like how Angular feels more batteries included than the other options, but I’ve seen some overabstracted codebases. React seems like it has the largest ecosystem but the codebases seem to rot pretty quickly (lots of separate libraries for the typical project, lots of updates, things sometimes break). The likes of Laravel and Rails let you be pretty productive but also have pretty tight coupling to the rest of the codebase, same as with PrimeFaces/JSF. I’ve also seen attempts at putting as much logic in the DB as possible and using the back end as more or less only the view layer, it was blazing fast but debugging was a nightmare.

Honestly, just pick whatever technology you think will make the people working with the project in 5 years the least miserable. For me, often that is something for a SPA, a RESTful web API, some boring back end technology that connects to a relational database (sometimes SQLite, sometimes PostgreSQL, sometimes MariaDB; hopefully not Oracle). Whatever you do, try not to end up in circumstances where you can only run a front end with Node.js 10 or where you can't update your Spring or ASP.NET version due to there being breaking changes in your coupled front end technology.

I have some "internal" web apps that I use for myself, and while I do use Remix which is a framework that allows me to use React, I just use SSR and HTML default form controls as interpreted by the browsers, minimal client side processing and almost no styling. I love it so much compared to the "modern" cruft. It's responsive by default because I don't really style it. It has a high signal to noise ratio.

I wouldn't change it for the world, but I've been told multiple times I'm very much in the minority.

The final spaghetti point really takes the wind out of this article's sails. A lot of it is good information, but too many parts make me think "That's a stretch."

I dream of the day that we are finally free of the iron grip the web browser has on the minds of those that would create the future of technology.

The only reason to use spa as far as I am concerned is that’s the way the industry was going 10 years ago… so the community and controls etc… were / are for spas.. any other reason to me was just chasing new tech.

I made the switch and the community it stronger than ever for vuejs and react

Just do it all in WebAssembly.

WebAssembly is pretty great. Here's an example: https://bandysc.github.io/AvaloniaVisualBasic6/

This kind of stuff misses the entire point of frameworks like react or rails for that matter

There might be some technical advantages you can argue but there’s an undeniable economic advantage to not needing to make a bunch of disparate choices and wire things up in a way that you hope will not bit you in the ass later.

Do I have to point out that "you can do X without Y" is never an interesting nor insightful statement? No shit! so? Does that mean you should do X without Y?

I am no frontend-guy, so I don't understand why in the age of node.js web-servers this ditchonomy exists between server-side and client side (SPA). Can't you initialise/pre-render most of your your stuff on the server, serialise it and push it through the client, which then acts as an SPA already initialised and then updates itself on its own. After all, both are JS? Why is the decision not more flexible where to run code, depending on latency, compute intensity etc. Maybe someone can enlighten me, as this is often left out, probably because it is obvious to someone working with these technologies.

Ok but what's the benefit? Yes, if you really want to, you can carve your validation logic in half, write two different kinds of JavaScript and CSS, so that you can change screens in two technically different ways. But the only thing it will accomplish is making your app harder to maintain, and probably slower to boot.