Yeah, it is perfectly possible to build javascript heavy websites without making them unusable until all is downloaded and processed...

I'm rebuilding a site for a client and using a bunch of dynamic imports, if you don't touch a video route, you'll not download the videojs bundle at all, I set a performance baseline for the site to be interactive and anything that makes it go over the baseline needs a good reason to be there.

I really don't think this is an optimal solution. This makes every page load slowly, instead of just the first page. Waiting to do work doesn't make the work any quicker.

Not really, most of the bundles are pretty small, in the 30/40Kb range gzipped, even smaller with brotli, the problem is when the user has to wait 5s to start using the site, waiting half a second to load the first page is ok, waiting a quarter second to open other page is also ok.

It isn't purely about speed, it is about perception, a very slow first page load is way more annoying that a couple half or quarter second loads distributed over a long interaction, after the js is cached all is nearly instantaneous, but you don't have to wait a while to start using the site in your first visit.

If you want you can also wait for the first page to download completely and them import the remaining js while the user is on the first page, but I didn't tried to see how well it works.

It depends on the use case. For something like a web storefront, this is probably true. For a web application where I spend a long time doing work, I'd rather have a bit of a wait upfront followed by snappy responses on all the other pages. Even a half-second load time can be frustrating when I'm in the middle of a task.

The last two years have had a dramatic shift away from SPA and toward JAMstack, which is more or less pre-rendered SPA. The result is not only faster than SPA, but faster than the 2008-2016 status quo of server-scripted Wordpress and Drupal sites.

I blew off JAMstack as another dumb catchphrase (well, it is a dumb catchphrase), but then inherited a Gatsby site this past spring. It absolutely knocked my socks off. The future is bright.

From what I can see JAMstack is just model (api) view (markup) controller (java-script) for web browsers. But it needs a new name because MVC is lame. While PSA treated the browser as a thick client with a very slow disk accessed over the network. And static HTML treats it as a thin client (like X-windows).

There hasn't been a new idea in computing since the 70s. The only thing we've done is mutate a square peg into a round one and back again. Each time patting ourselves on the back for the sheer brilliance of the move.

I've been spending close to a day trying to figure out how to respond to this statement. It's like you're saying, "From what I can see, the 2020 Volkswagen Golf is just another flightless bird, but it needs a new name because calling it a duck doesn't sound fancy."

It's not a design pattern, and the element of it that uses one (React) usually implements Flux, not MVC.

As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.

>I've been spending close to a day trying to figure out how to respond to this statement. It's like you're saying [...]

No, it's like I'm saying: Software development is fad driven and shallow. The details change but those details are unimportant and ultimately pointless. Bad metaphors are exactly the type of shallow thinking I'm talking about.

A GUI is not a car, a duck, or a fish. It is a UI. That the web is being used as an interactive GUI is a travesty. Without knowing the history of why it was invented in the first place - extremely high latency and low bandwidth of the 90s internet - you will never understand why mutating it to a full GUI is a terrible idea. And why we should have used any of the dozen well engineered technologies that are not hypertext based but work with the internet (low latency high bandwidth) we have today.

It's gotten to the point where an X server in an Amazon data center and a VNC client on a phone is more responsive than facebook, twitter and reddit on mobile.

>As for "no new ideas in computing since the 70s," are you actually proposing that we go back to building websites like we did in the seventies? Um, sure. Brilliant.

Yes, using TeX would be an infinite improvement over the mess we have today. Imagine having one language for everything in a site, instead of the three (five? with markdown and js frameworks) you need today.

That is what happens when you hire react devs to build your static website.

SPAs are a cancer. There. I said it.

What's wrong with accessing resources in a RESTful way?

A page refresh? At this point, a page refresh is so much more bearable than a 2300ms SPA download and hang ups.

As an added bonus, you can bookmark resources. Back button works!

Most SPA frameworks work fine with the back button and bookmarks--they'll either use the URL fragment (#) or the history API. I'm sure there are lots of developers who don't bother to turn on that functionality, but that's not an inherent flaw with SPAs.

(For the record, I don't think that every app that is an SPA should be, but I do think that they have a place.)

If left unoptimized, JavaScript can delay your pages when they try to load in users’ browsers. When a browser tries to display a webpage, it has to stop and fully load any JavaScript files it encounters first.

Yes. And while I will continue to defend it in case of interactive dashboards, webapps and status screens if you are not writing on of those, you shouldn't be using javascript. If we want to fix the internet, browsers should ask the user for permission for each cookie and javascript should be disabled by default.

Yes you're right, but keep in mind that with SPA, only the first loading is slower, then you don't need to reload again when changing pages.

Try to open 10 actual html websites. Now try to open 10 SPA. Tell me which feels slower. SPA slowness is not exclusively from all the third party JS and CSS loads. A lot of it is just innate to being an application instead of a document.

Assuming there are repeat visitors. Someone sent you a link to an article. You don't care which website the article is on, you just want to read it and close it without exploring whatever else the website had to offer. So you download a several-megabyte JS bundle to be able to read several kilobytes worth of text. By the time you encounter another link to that particular website, your cache of its assets would be long gone.

Not necessarily true. I've seen many SPA apps where the API calls that get made when you navigate between pages are slow too. So subsequent pages are slow also in addition to the first page.

This isn't even a hard technical constraint. With async javascript "module" loading, and stuff like the new federated webpack stuff, you can have a lot functionality loaded in on-demand.

That won't always work out or be necessary though.. For an app like Lucidchart or something, I can deal with DL'ing updates every now and then. I spend most of the time in the running app.

In theory. In practice most SPAs are slow at first load and slow when changing pages then crash when too much data is requested.

Beyond that, unless your users are a captive audience (have to use your software for their job) you should probably be optimizing for a positive first impression.

Cold caches are common for users.

> The last 5 years there has been a dramatic shift away from HTML web pages to javascript web applications on sites that have absolutely no need to be an application.

SPAs are a lot easier to keep secure though, so if you don't want your private data leaked then they're a much better option.

Any and all scripts that are loaded at any point in the SPA stay for the duration of the visit. 3rd party scripts are a big risk and not being able to unload JS scripts and associated in-mem/in-page symbols etc. is a timebomb waiting to explode.

How are SPAs any easier to keep secure?

There's a very clear separation between the front end and the back end, which makes it easy to write tests that allow-list only the specific data that's supposed to be getting returned.