Hacker News Reader

Comment by gedy | Hacker News Reader

These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, and ability to test, share and modularize suffers. SPAs usually are better engineered UIs than the alternatives.

View on HN

Do you have data to back that up, or are you speaking from personal experience? I know how it can go wrong, but SPAs can become a mess too.

I had one project where we built a very beautiful, modern site that had about 50 lines of js in total. Of course your page-change times are going to be around 0.5s with an MPA, but SPAs are often slower than that anyway.

I don't know but with a service worker you could possibly reduce that 0.5 in your MPA further by caching likely next pages ahead of time.

Yes, mainly personal experience. SPAs can definitely be a mess too. Mostly calling out that managing state in one place makes unit testing easier, which usually results in a better quality codebase

The backend has to handle all of the scale. That's where the real difficult engineering comes in and if you're using JS there, you're going to pay a huge price. It doesn't seem like many front-end JS developers understand that pulling data from different places isn't actually a hard problem but instead correctly storing and managing that data at scale is where the actual engineering happens.

State management is hard. That is the core issue.

Note you can still use an MPA and have a dynamic UI using React/Knockout/whatever. It is just usually not done that way and most go full SPA.

As opposed to spas that take forty seconds to load on a 48-core machine with a gigabit link? Yeah...

Reply on news.ycombinator.com