I think it seems logical on paper. I tried it, and it feels perceptually way worse. It also think it's objectively slower.
When you go from HTML page to HTML page without JS, the browser starts from scratch on every page. The user gets a big flash, then the browser has to redraw the page from scratch. It's actually a lot of work often.
If the browser expected pages to be similar, and added optimizations to reuse existing content, essentially doing internal SPA work, that would be a different story. To my knowledge, the browser does no such optimization, and brute-forces renders every URL from scratch.
You can actually try for yourself on the website I linked. Chrome devtools > disable Javascript. It's a pretty good experience still since I optimized everything. However, you see all sorts of things flicker and move around. It's not the smoothest experience. And If you have worse Internet, it gets worse and worse as you see more of the tear-down > built-up on every click. With the SPA experience, if you have bad internet, you can still scroll around and use the page, as you wait for the update to arrive.
Of course, you're totally right that static HTML works pretty good when the website is already simple and fast. My point was that with 4KB-uncompressed / 140LoC, I can get the smoothest experience. And I unlock options later on like having loading spinners for example.
My general point was that you can do simple client-side rendering in 140 LoC. You keep a simple backend-served website, and add a little polish this way to have a smooth experience.
I find it very cool to have polished app-like experience, while having a simple backend to serve. I like the low-tech, few moving pieces, yet I get options for great UX if I want.
I got charmed by this path with LiveView and Hotwire back in the day. I'm thankful that people continue to push this approach. It's wonderful
Static pages is basically always faster. The web browser is very, very quick at rendering HTML. Executing JavaScript is much slower. But, the real benefit of static sites is caching. You can cache on the edge and have remarkably fast load times.
For the flickering or flashing, you can just stick a couple lines of CSS for view transitions and boom, done. I understand the flashing looks less professional or fast, but it’s not actually.
> I don't really see any user defined input that would change the output.
I feel like the distinction between static websites and SPAs has been lost in the last decade, despite it being in the name _single page application_.
The point of SPAs is not "it's more interactive than a static website is", but "I don't need to fetch the new page and wait it to load as I navigate". You can have any custom behavior just by adding JavaScript. That's something we have from 30+ years.
"applications" don't interrupt the user as you navigate, and we tried to replicate that on the browser, by having history and render JavaScript controlled.
Honestly there are times when using the View Transition API makes sense, but the context here is a dinky brochure site. The weight of scripting does as much damage to first load as it saves on subsequent loads. Browsers are good enough at managing this stuff themselves.
I regularly take my copy of one of the volumes of Knuth's TAOCP off the shelf.
The stuff in those books will never get old, and I often find myself searching for some algorithm or concept that I know I've skimmed over in the past, but no web-searches or LLMs can give me an answer on.
I think it may be due to the lack of open, digital copies of TAOCP available for pillage, as well as the fact that the books don't target a particular language.
As others on this thread have commented, you haven't specified a license. Don't jump on the first thing you think of. Consider the various OSS licenses and decide which one suits you best.
Google play store is only full of trash if you go hunting for trash. I'd like to see the actual stats of people affected by play store malware vs malware available on the play store.
I'm not saying it's not a problem, but I am saying it's not a problem that has caused any problems with any Android user I've ever met.
I am not talking about the malware, I am talking about the apps that are bloated with advertisements or try really hard to push a subscription upon you. Lots of "free" apps try to push you into a subscription once installed.
You're correct. You've just paid it on every app store purchase, and every in app purchase. That's because Apple, despite trying, have failed to completely lock in the payment infrastructure.
I consider almost everyone really wants to earn more money, more easily.
I do not see any indication that Apple wants to get involved in adjudicating payment disputes for physical goods and services. That is high cost, high liability, low margin work. They seem to be perfectly happy letting the existing banks (aka card issuers) handle that, and getting a 0.15% cut for allowing their credit cards to use Apple Pay.
Apple has restricted themselves to being the payment infrastructure for only digital goods, and I assume that is because that is the cheaper, more scalable option.
As a side note, in the US, the proportion of sellers willing to eat the credit card fees has gone down every year, and seemingly at an accelerating pace. I have winnowed down my credit card usage to retail goods/restaurants/travel, because almost everyone else wants payment via ACH/Debit/Zelle/other option that avoids credit card fees, so I would be surprised if Apple would ever want to enter this market, given that even the 2% credit card fee transactions are not able to compete.
It's really fast, and seems fine, but is it just static pages? If not, why not. That's the question most front end devs don't ask themselves enough.
reply