The whole tone of this post feels a bit sketchy to me. Not everyone gets 100% control over what they have to learn.
> JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.
Or those who work for (or with) those whose priorities are poorly chosen, and who don't have a veto.
I've largely avoided having to deal with JS in its recent pathological era, and I'm very very thankful for that. My attitude toward those less fortunate in this regard is sympathy, not contempt.
Agreed! There's merit to the perspective here, but it speaks mainly to developers who are 1) very good at picking up a new framework and getting it to work, and 2) largely in a position to make their own technology choices.
I've found it much harder to pick up some of these frameworks. Even ember, which should probably be one of the easiest for me as a rails developer (former? I sure hope not...) Learning a framework is, for me, a big enough undertaking that the analogy to ordering something free from the menu doesn't really hold. Some people are much quicker with this than I am, though.
I'm also, unfortunately, really not in control of technology decisions (in spite of the fact that making these decisions is written in my job description signed all the way up the chain - in many orgs, you have to fight like a banshee to exercise this right, even if it is explicitly listed in your job responsibilities!). I can sometimes influence them, but one of the reasons people get into such intense arguments about what framework to use is that you're far more productive with one you already know. If you're good at Ember, you might not want to switch over to React, and vice-versa.
Honestly, if it were up to me, I'd probably stick with the integrated rails app for now, unless there was a very compelling reason to do otherwise.
That says a lot about the kinds of apps I develop. I personally think that the amount of complexity introduced into web apps through the SPA approach is substantial. There's no saying it's strictly right or wrong, just something that needs to be balanced against what you get out of it.
There was a time when a spreadsheet, a server, a database, a web app, all took great skill and cutting edge knowledge. The day will probably come where relatively rich web apps are much simpler and straightforward. Until then, there is a huge opportunity for people who can learn this and leverage the power. There is also a huge opportunity for people to massively over engineer their systems for "no reason", except that there is a reason - resume building. I'm not naive, I was around in the days when if you didn't know "EJB", you might have a harder time getting your next gig, which lead lots of devs to introduce EJBs into apps that had no need for them, mainly to get the experience and skill.
If developers chose technologies based on what their project needs, rather than what their resume needs, I suspect the software development world would be more conservative in applying new technologies. As it stands, there is a lot of incentive to be unnecessarily (possibly even destructively) cutting edge, because that's how you get the experience.
I don't necessarily blame the devs, this is the game.
> JavaScript fatigue is an affliction that affects only those who's learning priorities are poorly chosen, such as framework-of-the-month.
Or those who work for (or with) those whose priorities are poorly chosen, and who don't have a veto.
I've largely avoided having to deal with JS in its recent pathological era, and I'm very very thankful for that. My attitude toward those less fortunate in this regard is sympathy, not contempt.