5 ms·

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

by snaky 8y ago

maxxxxx 8y ago
Resume driven development works. Unfortunately.
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 ago
  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.
- dancek 8y ago
  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.
  - fold_left 8y ago
    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.
  - gedy 8y ago
    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
- dmitrygr 8y ago
  As opposed to spas that take forty seconds to load on a 48-core machine with a gigabit link? Yeah...
- sebazzz 8y ago
  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.
StillBored 8y ago
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.

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

by snaky 8y ago

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

maxxxxx 8y ago

Resume driven development works. Unfortunately.

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 ago
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.
dancek 8y ago
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.
- fold_left 8y ago
  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.
- gedy 8y ago
  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
dmitrygr 8y ago
As opposed to spas that take forty seconds to load on a 48-core machine with a gigabit link? Yeah...
sebazzz 8y ago
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.

StillBored 8y ago

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.