[HN Gopher] Building websites with lots of little HTML pages
       ___________________________________________________________________
        
       Building websites with lots of little HTML pages
        
       Author : Kerrick
       Score  : 94 points
       Date   : 2025-03-09 13:25 UTC (3 days ago)
        
 (HTM) web link (blog.jim-nielsen.com)
 (TXT) w3m dump (blog.jim-nielsen.com)
        
       | Terretta wrote:
       | This is brilliant.
       | 
       | Instead of a single page app (SPA), you can almost picture the
       | connections between all these little .html pages as some sort of
       | web.
        
         | dredmorbius wrote:
         | One spanning the world, perhaps.
         | 
         | Even ... widely.
        
           | freedomben wrote:
           | It's a great idea, but I don't see it working long-term. At
           | some point I suspect big tech will aggregate and centralize
           | and kill off these little sites. They may even start
           | implementing technology that locks them down so that you can
           | only visit them with approved devices. Hopefully Netscape
           | refuses to go along with it, though I do worry about their
           | business model's long term viability.
        
             | kreeben wrote:
             | Netscape's too big to fail, yo.
        
         | 0xdeadbeefbabe wrote:
         | It's like a world of webs.
        
       | ilrwbwrkhv wrote:
       | the web is so built for this. when you go to sites like this it
       | just feels right. we could have had this as our future instead of
       | the craziness of javascript and nextjs and react. now some new
       | devs dont know html exist. they think react is the web.
        
         | LigmaBaulls wrote:
         | imagine what the future could have been if the html spec was
         | enhanced to support the features of htmx rather than the push
         | for javascript enhancements.
         | 
         | We may have had a future without javascript ever running on a
         | server.
        
         | geraldwhen wrote:
         | The designers make us commit war crimes with JavaScript. Can't
         | even use native form elements.
        
       | jonwinstanley wrote:
       | Interesting thoughts.
       | 
       | I've been using both Hotwire and HTMX recently.
       | 
       | The swapping in of different html is making a come back.
        
         | mamcx wrote:
         | Yeah, this is `manual` htmx.
        
       | arnley wrote:
       | Views transitions are very useful in content-first websites.
       | 
       | 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.
        
         | gibibit wrote:
         | I guess this is a matter of preference. I see when I click a
         | link on stack.lol that the page header remains visible, but the
         | rest of the page disappears (blanks to white) for a second
         | before the next page appears.
         | 
         | 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.
        
           | nartho wrote:
           | I believe this is related to the implementation of the
           | light/dark theme. It uses the preferred theme but default to
           | light, if your preferred theme is dark, it will take some
           | time where it defaults to light before being set to dark.
           | There are workarounds.
        
           | arnley wrote:
           | Nice catch, thanks for the feedback.
           | 
           | 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...
        
         | jen729w wrote:
         | Sorry to report this doesn't work well on mobile Safari.
         | 
         | Tapping one of the items in the list causes mayhem.
         | 
         | Going 'back' causes stuff to flicker all over the screen.
        
           | arnley wrote:
           | Didn't try on Mobile Safari. That's on me. Going to fix that
           | one.
           | 
           | Kudos to you for reporting it so nicely.
        
         | nayuki wrote:
         | > https://stack.lol/
         | 
         | 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.
        
       | dredmorbius wrote:
       | What were the arguments in favour of SPAs in the first place?
       | 
       | 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
        
         | pavlov wrote:
         | That's also because they were not called SPAs for the first 15
         | years of the web.
         | 
         | 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.)
        
           | jslakro wrote:
           | Macromedia's Rich Internet Application (RIA) concept aimed
           | beyond mere navigation, delivering purposeful, desktop-like
           | experiences.
        
       | bob1029 wrote:
       | Old school web tech is the best. I still reach for
       | multipart/form-data every day. Many of my web applications do not
       | even have javascript.
       | 
       | 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.
        
         | freedomben wrote:
         | I'm increasingly getting to this point as well. I think modern
         | webtech is incredible in many ways, and if properly used could
         | be pretty great but overall and for the most part we are pretty
         | terrible at it. I've started to dread using SPAs because I know
         | it's going to be sluggish and load megabytes of junk, and will
         | still require frequent page reloads when clicking stuff Even
         | though ostensibly it should not.
         | 
         | 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.
        
         | mdwhatcott wrote:
         | What exactly do you mean by "part of the same context"?
        
           | bob1029 wrote:
           | The same HTTP request/response pair. In some languages there
           | are types like HttpContext that contain both sides.
        
         | holoduke wrote:
         | You can also have both. Our apps are all spa. Bundled in single
         | js, html and and js file. But we also have an ssr app runner
         | that contains hundreds of thousands cached static html pages.
         | Initial page load is from the ssr. Further interaction pure
         | clientside. This way you have best app like experience and
         | maximum seo. Setup is maybe 400 lines of code.
        
       | pphysch wrote:
       | I love this approach. I just wish there was better tooling for
       | HTML polyglot programming.
       | 
       | 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?
        
         | solardev wrote:
         | Is this kinda what you want? https://peps.python.org/pep-0750/
         | 
         | (similar to template literals in JS)
         | 
         | You can also do something similar using f-strings, at the risk
         | of content injection attacks.
        
         | davepeck wrote:
         | Slowly but surely...
         | 
         | 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
         | 
         | where `html` is a normal function that takes a `Template` as an
         | instance, and can return whatever it likes -- say, an
         | `HTMLElement` rather than a `str`.
         | 
         | 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.
        
         | freedomben wrote:
         | I think PHP was brilliant, and to this day is still an
         | underrated model, but as websites grow in complexity,
         | particularly around data and access controls, The model needs
         | to be inverted. When logic gets sprinkled throughout templates,
         | it can turn into an unreadable nightmare. Personally, I think
         | ERB in Ruby with Sinatra or rails really nailed The approach.
        
       | vector_spaces wrote:
       | I'm doing something sort of similar now -- my research advisor
       | was remarking on the messy state of all the scripts I use for
       | numerical experiments (there's dozens of them, poorly commented,
       | constantly changing and not well versioned, assumptions/purpose
       | not documented etc).
       | 
       | 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 :(
        
       | mdwhatcott wrote:
       | > "I build separate, small HTML pages for each "interaction" I
       | want, then I let CSS transitions take over and I get something
       | that feels better than its JS counterpart for way less work."
       | 
       | 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?
        
         | andypants wrote:
         | View transitions api, it's pretty new:
         | https://developer.chrome.com/docs/web-platform/view-transiti...
        
           | alberth wrote:
           | Surprisingly, Firefox of all browsers doesn't support it.
           | 
           | https://caniuse.com/view-transitions
        
             | MYEUHD wrote:
             | It's not that surprising if you consider that all the
             | browsers on that page, except for Firefox and Safari, are
             | Chrome-based
        
           | mdwhatcott wrote:
           | Very cool, thanks!
        
       | econ wrote:
       | Yes, rip out all the advanced coding skills and simply do it the
       | way it was originally intended.
       | 
       | 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.
        
       | mariocesar wrote:
       | This is the source code for the blog:
       | https://github.com/jimniels/blog, in case anyone was looking for
       | it
        
       ___________________________________________________________________
       (page generated 2025-03-12 23:00 UTC)