[HN Gopher] The Curious Case of the Shallow Session SPAs
       ___________________________________________________________________
        
       The Curious Case of the Shallow Session SPAs
        
       Author : tatersolid
       Score  : 12 points
       Date   : 2026-01-01 15:54 UTC (7 hours ago)
        
 (HTM) web link (calendar.perfplanet.com)
 (TXT) w3m dump (calendar.perfplanet.com)
        
       | tatersolid wrote:
       | @dang how do I change "Spas" in the title back to "SPAs" as was
       | originally submitted? It's a misleading title after the automatic
       | transformation.
        
         | dang wrote:
         | You can edit the title via the 'edit' link for a couple hours.
         | After that it's best to email hn@ycombinator.com, because @dang
         | doesn't work reliably (I happened to see it this time but don't
         | always).
        
       | normie3000 wrote:
       | > huge accretions of complexity for very little payoff
       | 
       | Am I in a minority finding SPAs significantly easier to write and
       | maintain than server-rendered HTML and JS? Or is this point of
       | view merely a reflection of where my experience lay in the 2000s
       | (server-rendered) vs 2020s (SPAs)?
        
         | hnthrow0287345 wrote:
         | SSR HTML/JS sucks if:
         | 
         | - there is repeated code among pages
         | 
         | - the JS isn't in Typescript
         | 
         | - the JS is still using callbacks
         | 
         | - it's using a JS UI framework (Kendo) that you don't like
         | 
         | - the CSS is a mess
         | 
         | All of which was more common closer to 2000 than 2020 because
         | we didn't have things or didn't know better.
         | 
         | SPAs by default at least helped with repeated code and CSS
         | since code organization and maintainability were one of its
         | main selling points. These days most new projects will use
         | Typescript out of the box too.
        
         | jauntywundrkind wrote:
         | I'm with you brother.
         | 
         | Trying to hold sufficient session state on the server and then
         | doing your work afar is a ridiculously hard problem to keep up.
         | The controller of that distributed system is very far from what
         | it's trying to work. State keeping from afar is not pleasant.
         | Especially when there are little pools of state that are
         | essential on that client, when the illusion being worked to
         | maintain keeps breaking down.
         | 
         | A thick client page, that has the agency there, that can
         | operate & control the local experience, is imo just so clearly
         | a simpler system to build and run. It also often has much
         | better performance characteristics.
         | 
         | Representative state transfer allowing the page to become the
         | operator _is_ simpler. Let the client be it 's own thing. Give
         | it tools to get and work that state, to update the remote
         | server.
         | 
         | Sounds scary, sounds complex, is mechanically much simpler.
        
         | llmslave2 wrote:
         | I think it's just what you are used to. I think a Spa is easier
         | than server rendered html as well, although server rendering a
         | spa brings its own complications. But the component model a la
         | React is so crucial.
        
       ___________________________________________________________________
       (page generated 2026-01-01 23:01 UTC)