I hope at some point the original pattern is re-discovered and made popular again because it would make things so much snappier:
1. Initial GET request from user's browser against index and maybe favicon.
2. Server provides static/dynamic HTML document w/ optional JS, all based upon any session state. In rare cases, JS is required for functionality (camera, microphone, etc.), but usually is just to enhance the UX around the document.
3. User clicks something. This POSTs the form to the server. The server takes the form elements, handles the request, and then as part of the same context returns the updated state as a new HTML document in the POST response body.
4. That's it. The web browser, if it is standards compliant, will then render the resulting response as the current document and the process repeats.
All of this can happen in a single round trip. Latency is NOT a viable argument against using form submissions. I don't think suffering window navigation events is a valid one either. At some point, that SPA will need to talk to the mothership. The longer it's been disconnected, the more likely it's gonna have a bad time.
The web only has to be hard if you want to make it hard. Arguments against this approach always sound resume-driven more than customer-driven. I bet you would find some incredibly shocking statistics regarding the % of developers who are currently even aware of this path.
There's an exceptional beauty in a simple and lightweight website that is just a load and done. I've started doing more with Phoenix and Alpine for the little bits of client-side functionality required, and have been very pleased with it. The most interesting part though, is that users have also been very pleased. They can't explain why in technical terms, but they know it feels better.
I recently had a discussion with some "web developers" that just... couldn't understand how a web application could interact with the server without JavaScript and a REST API. They had never heard of traditional web forms! They didn't even know that was an option.
That blew my mind.
PS: Look into https://htmx.org/
This is exactly the kind of complexity and bloat the GP wishes we can get rid of so that we can return to simpler web applications with forms that do a simple POST and get the updated web page in response.
I have a single php file with a textarea. It creates pages or updates them. The textarea only displays the article. Everything above and below is removed and added again. When publishing it adds the article to the index.html archive-2025.html and tagname.html pages. I haven't bothered automating removal. If it ever happens I'll do it by hand.
The search engine is a bit odd, it is a 26x26 list of raw files named aa.html ab.html each bit in those refers to an article. If you type foobar it loads fo oo ob ba and ar.html then performs and AND on the files. What html's remain are loaded and searched for foobar.
I should really store everything in a db in stead. (Just for searching)
Edit: near zero maintenance over two decades. One instance where the host upgraded php and the editor stopped working but the website worked just fine so it doesn't really count.
I'm not understanding how you are achieving the css transitions between what look like new page loads under the hood...Can you elaborate on how that works?
Instead of a single page app (SPA), you can almost picture the connections between all these little .html pages as some sort of web.
Even ... widely.
> My first impulse was to have a list of posts you can filter with JavaScript.
> But the more I built it, the more complicated it got. Each “list” of posts needed a slightly different set of data. And each one had a different sort order. What I thought was going to be “stick a bunch of <li>s in the DOM, and show hide some based on the current filter” turned into lots of data-x attributes, per-list sorting logic, etc. I realized quickly this wasn’t a trivial, progressively-enhanced feature. I didn’t want to write a bunch of client-side JavaScript for what would take me seconds to write on “the server” (my static site generator).
This is pretty trivial to implement in any framework.
Generally speaking, I find most of the "You don't need Javascript and frontend frameworks, just write static HTML!" posts reflect the skillsets of their authors. Me, I never really did any site-generation or server-side rendering stuff, so writing everything in VueJS + JavaScript is the easy way.
In the current landscape doing things "the hard way" in plain JS is often simpler than with React. You will give up reactivity, testability, declarative rendering, and the ability to hire any passersby, in exchange for not having to deal with a rube goldberg contraption of hooks, dependency tracking, query caches and state management, with a complex build system. Terrible idea for a team. For a bunch of tabs in your blog? Probably worth the trade.
That said, the problems he describes would occur with React/Vue as well since they are a result of mixing a statically generated site with client-side rendering logic. It would not, in fact, be trivial without changing the server.
> Me, I never really did any site-generation or server-side rendering stuff
> I find [...] reflect the skillsets of their authors
now I'm unsure if this is satire...
This is something SPAs are doing as well, though in the case of, say Google Web Search (last I used it directly, which is months if not years ago). Namely, when I begin typing a search the currently-displayed content blanks out.
Why is this annoying?
Because often what I'm typing is being prompted by that content, and if I can't continue to view it as I'm typing my search I lose that context and my train of thought.
So: embed your search directly in every page on your website, rather than having it be a separate page. It's fine for the results page to redirect elsewhere, and if the search mechanics need that page to function, so be it (that's what form submissions are all about).
But other than that, I like the implementation, after realising that it was the blogpage and site themselves which were the demonstration. (I'm ... slow like that sometimes.)
I've used them extensively when working on https://stack.lol
Try and navigate through pages, or change the language, and you'll get these neat effects "for free".
Frameworks like AstroJS also help a lot as they facilitate using view transitions.
The page layout is broken in Firefox 136.0.1 but okay in Chrome 134.0.6998.89 =(. I don't have time to debug what CSS feature might be causing this problem.
I prefer a seamless experience of seeing the next page immediately without a "white flash" first. For instance, if I am looking at a GitHub project page and I click the "Issues" button, in a fraction of a second the page changes to the Issues page without any intermediate disappearance or partial page load.
In most cases, I find transition effects like fading, sliding, etc. to be an annoyance that adds unnecessary delay and visual distraction.
I just enhanced a bit the implementation so that it flickers ...less.
Still looking for ways for this static implementation with view transitions to 100% persist the dark mode during transitions.
Edit: Fixed. Using a tiny bit of script[1] from the Astro documentation.
[1]: https://docs.astro.build/en/guides/view-transitions/#astrobe...
Tapping one of the items in the list causes mayhem.
Going ‘back’ causes stuff to flicker all over the screen.
Kudos to you for reporting it so nicely.
Naturally I used that as an excuse to implement a framework for tracking the output of numerical experiments along with any generated assets and output and configuration details in a SQLite database. Then wrote a generator that pulls everything out of the database and builds a static HTML site.
Anyway I implemented a system of tags for grouping similar experiments. It's less polished and sophisticated than this, but it was quick to implement and feels suitably lightweight.
I'm realizing now that the SQLite database was a misstep, mainly for adding notes and metadata. So I'm planning to just use the filesystem instead so that one's raw experiment runs can be versioned as plaintext files (at the moment, just the static site is versioned)
But for now I need to get around to actually doing the experiments :(
I’ve been using both Hotwire and HTMX recently.
The swapping in of different html is making a come back.
PHP got it right by embedding itself within "HTML" documents. React also got it right by inventing JSX. There's Go templ too. They all said "HTML deserves first class support".
Why can't this DX also be available for other general purpose PLs? I want my Python language server to detect that this or that string is HTML, and provide features accordingly. I don't want to keep bouncing between .py and .html files. Is this achievable?
PEP 750 (still a proposal) adds "t-strings" Python. They're a simple extension of f-strings that give developers access to the static and interpolated parts of the string before they get combined into a final string. They're Python's answer to JavaScript template literals.
This allows writing code like:
user_name = current_user.user_name # something user-supplied and potentially unsafe
foo: HTMLElement = html(t"<div>{user_name}</div>") # wouldn't be safe with f-strings
If PEP 750 does get accepted, eventually one hopes the community will introduce formatting, type checking, and LSP smarts for common kinds of t-strings, like HTML and maybe SQL, etc.
(similar to template literals in JS)
You can also do something similar using f-strings, at the risk of content injection attacks.
We may have had a future without javascript ever running on a server.
I'm finding it interesting that most of the top HN submissions (by popularity) matching "single page app" are critical, not positive. First 15 follow, all but 5 are negative:
- You probably don't need a single-page app (https://journal.plausible.io/you-probably-dont-need-a-single...) 816 points | 6 years ago | 499 comments
- A single-page app is almost always worse than a multi-page app (https://www.gregnavis.com/articles/the-architecture-no-one-n...) 289 points | 6 years ago | 145 comments
- The myth that you can’t build interactive web apps except as single page app (https://htmx.org/essays/you-cant/) 262 points | 4 months ago | 143 comments
- Building a single-page app with Htmx (https://jakelazaroff.com/words/building-a-single-page-app-wi...) 252 points | 5 months ago | 143 comments
- AWS Lambda as a back end for a single-page app (http://lg.io/2015/05/16/the-future-is-now-and-its-using-aws-...) 229 points | 10 years ago | 73 comments
- Create your own dysfunctional single-page app (https://tinnedfruit.com/articles/create-your-own-dysfunction...) 208 points | 6 years ago | 138 comments
- The Single-Page-App Morality Play (https://www.baldurbjarnason.com/2021/single-page-app-moralit...) 207 points | 3 years ago | 131 comments
- Todos: a Backbone.js example Single-Page-App (with LocalStorage)(http://documentcloud.github.com/backbone/examples/todos/inde...) 169 points | 14 years ago | 28 comments
- Your single-page app is now a polyfill (https://itnext.io/your-single-page-app-is-now-a-polyfill-788...) 164 points | 4 years ago | 158 comments
- Why I hate your Single Page App (https://medium.freecodecamp.org/why-i-hate-your-single-page-...) 107 points | 8 years ago | 120 comments
- Building a single page app with Backbone.js, underscore.js and jQuery (http://andyet.net/blog/2010/oct/29/building-a-single-page-ap...) 103 points | 14 years ago | 19 comments
- Why I hate your Single Page App (2016)(https://www.freecodecamp.org/news/why-i-hate-your-single-pag...) 37 points | 11 months ago | 34 comments
- Sonny – Fast single page app engine (https://github.com/felixmaier/sonnyJS) 36 points | 10 years ago | 25 comments
- You probably don't need a single page app (https://plausible.io/blog/you-probably-dont-need-a-single-pa...) 31 points | 6 years ago | 24 comments
- Ask HN: What are the common pitfalls/problems of Single Page App's? 13 points | 9 years ago | 18 comments
The very first technology for building “SPAs” was Java Applets. Corel released a web-based office suite already in 1997, and it was practically an applet for each app.
This was replaced by Flash because Macromedia did an incredible job of getting Flash Player preinstalled on every desktop computer. If you wanted to deliver a rich and seamless app-like web experience in 1999-2004, you used Flash. (It was mostly very primitive as a dev environment, but did a great job at vector motion graphics and video.)
The original progenitors of present-day SPAs are Microsoft Outlook for Web and Google Maps. Outlook invented the ubiquitous XmlHttpRequest object, and Google Maps became so popular that it coined “AJAX.”
Following these examples, people started building DOM-based JavaScript apps that loaded data asynchronously and built up views entirely in code. And that’s when they became modern SPAs.
(There was also Silverlight and some other technologies that vied for the rich web app crown, but JS/DOM carried the day especially when iPhone happened and wouldn’t support anything else.)
One of the first AJAX apps I recall was the original Gmail. That was a revolution in what the browser could do, followed fairly shortly by others (notably Google Earth which launched about the same time).
SPAs simply to deliver relatively static content however seem ... a poor fit. I'll note that HN itself is LLML.
Which leaves my original question: what specifically was the selling point of SPAs, or Flash, or early AJAX? Because despite having live through that the emergence was both sufficiently diverse (a number of different approaches) and gradual that I don't have a sharp recollection of what that was.