4 ms·
These "carefully engineered solutions" typically aren't - and instead random js bolt-ons to whatever server side language. UI state is smeared across layers, an
by gedy 8y ago
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.
- malvosenior 8y agoThe 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.
- dancek 8y agoDo 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.
- fold_left 8y agoI 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.
- gedy 8y agoYes, 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
- dmitrygr 8y agoAs opposed to spas that take forty seconds to load on a 48-core machine with a gigabit link? Yeah...
- sebazzz 8y agoState 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.