Hacker News Reader

Comment by snaky | Hacker News Reader

SPA building experience, coupled with popular JS frameworks, sells usually better than the skills of carefully engineering solution for the task.

View on HN

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.

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...

Well in a way it makes sense. Its like learning any other technology stack. The core stack may not be the best fit, but its considered a better bet to hire someone with experience in the target language/stack because the learning curve is reduced.

AKA, a developer that knows the same framework your app uses, only has to learn about your specific application rather than all the background libraries/etc your using. Its the same reason for preferring a C programmer for a C position over a ruby programmer (or flip it). Sure the ruby programmer might be awesome and after a couple years more productive, but in the meantime they will be making a bunch of newbie C mistakes, and generally bootstrapping slower.

This is part of the reason i'm in favor of generally reducing the number of languages/frameworks in general use. Its better for everyone if we all agree on some simple baselines even if they may not be the most optimum for any given problem. The efficiencies of repeatedly avoiding a bunch of rookie mistakes (and then having to debug/fix/test them for the next few years) is well worth it in the long run.

Resume driven development works. Unfortunately.

Reply on news.ycombinator.com