Hacker News Reader

>The majority of people I have seen complaining about Javascript fatigue do it from the peanut gallery.

You'd be surprised.

In any case, my anecdotal experience has been different: both me, and other front-end developers I know, have been frustrated with the pace of change in JS libraries and tooling.

>If you are a Javascript developer: you shouldn't have javascript fatigue unless you chase after the latest and greatest - which you shouldn't do.

You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough.

Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.). In Python or Ruby I could still use the Rails and Django I learned in 2006 -- not so much with JS.

>If you do not experience have "cereal fatigue" at the supermarket, you shouldn't get Javascript fatigue either.

Only people have (cereal fatigue). Too much choice leads to fatigue and stress in itself -- and this is backed by science...

Yes, and even within a framework... investing in using for example React for a project and some plugs, come back to project a couple of months later to add some library for let's say graphs, and face need to upgrade every lib/plug and lots of version mismatches. Not all libraries you opted to use might be compatible with new version of React.

Rails and Django are back-end; a good analogy there would have been Node.js which, as a framework, has done little but expand its API, implement ES6 features, and improve performance.

Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?

>Comparing back-end frameworks to front-end is silly; there are entirely different concerns on each level. Or is Rails suddenly diffing DOM elements?*

There's nothing "silly" about it. If anything, this arbitrary distinction is silly.

It's still all frameworks.

Whether they are front-end or back-end doesn't matter one iota to whether they could (or should) be stable.

There's nothing about "diffing DOM elements" (or any other thing front-end frameworks do) that necessitates tons of new and redesigned frameworks each going about it in its own way. In fact it could be retrofitted to an existing framework with care for backwards compatibility -- if only more JS frameworks were like Ember.

It's not a matter of some inherently technical concerns making the backend more stable. It's just the JS community churning out new frameworks and redesigned stuff all the time (because it's easy, and because they're many more millions that Python or Ruby programmers).

It's not even JS getting more features with ES6/7 (Python got tons of new features and syntax since early Django but you still don't get the same framework churn. Heck, Django even works with 3 -- and all only with tiny incremental changes to the same framework over many releases).

> You don't have to chase the "latest and greatest" to feel the fatigue. Merely keeping up with what's considered "best practice" and avoiding what's considered a dead-end and people abandon is enough

Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype. Best practices for who? Facebook's "best practices" might not work for you. You can't blame external circumstances for your technology churn, especially if the "dead-end" technologies are still actively maintained. "Best practices" are just design by committee writ large. I still use Grunt rather than Gulp, for me the 'improvemements' are marginal. I still support a Dojo SPA even though it's considered ancient. These technology decisions are not considered best practices, but they work for me. The buck stops with you (or whoever makes tech decisions at your org) - you can't pass the blame to the larger JavaScript community.

My point is you can safely ignore the latest and greatest (or 'best practice' as you call it). Apply common sense and only use what you need.

Speaking of hype: aren't containerized Flask-based microservices the current 'best practice' rather than monstrous Django apps? Looks like your 2006-era technology won't cut it on the back end either - it's all about scalability now ;)

Edit: added text below this line

> Too much choice leads to fatigue and stress in itself -- and this is backed by science

This is not inherently bad in any way: it's a trade-off. The paradox of Choice states that choice decreases (present) happiness. If this is what you are optimizing for, then less choice is good. Unfortunately, large and complex systems are...complex and multifaceted. I'm willing to sacrifice a little happiness in the present for ease of maintainability (when choosing a library that better fits my needs). Nature itself seems to celebrate choice when it comes to genetics in sexually reproducing organisms. Diversity has it's benefits -- and this is also backed by science.

>Sounds like the same thing to me - you can deal with this in 2 easy steps: 1) Ignore the hype 2) Ignore the hype.

And then you end with abandoned npm dependencies and no new development/books/blogs/tutorials after a short while.

How much does that actually matter if the libraries continue to work for you?

> Case in point, it's only 5 years since Backbone came out. Backbone! And if feels like we've had 3-5 transitions already (Angular. No wait, Ember. No React. Oh, and add Flux. Actually, go Redux.).

And yet you can use any/all of those as desired, still - Backbone's still chugging along, being a mature framework at this point - Angular still has a huge community - Ember definitely still exists, and I'm starting a project using it.

What you're possibly missing out on is hacky "components" and "integrations" with whatever CSS framework, protocol or SaaS service is popular this week - but all of them have pure javascript versions which you can use just fine in any framework you want.

The only reason you should be forced to use the bleeding edge is if your customer/VC demands it.

Member of the peanut gallery here, and I fully agree with Renner1. I occasionally do front end development work, and the pace of change makes life very difficult.

Imagine someone who last wrote a Python/Ruby/C/Java application 5 years ago - they could hit the ground running and learn a few new best practices and tools in 1-2 new weeks.

Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do. It feels like the JS landscape is changing so fast that keeping up with things is a full-time job.

This situation is way better than everyone having an in-house "library" that you have to learn, which is what it seemed like what happened a few years ago (it would be something in house, layered on top of jQuery or whatever).

I actually just went through this myself. I had last done frontend work in about 2010, maybe a little in 2011, and realized my skill set was probably getting stale, so I asked my boss if I could do frontend for a bit, with the understanding that I'd underperform. He said sure.

I've left and returned to C++ a couple of times. Same for Java. Most recently, I did some Ruby dev in 2015 after last doing it in 2006. In all of these instances, while there was some library and language churn, it was pretty easy to pick up. C++ lambdas are just cleaner syntax for functors, and the better optimizers and reworked libraries mean they're more widely usable, but no big deal. Java has a streaming library now and lambdas of its own, but it's largely syntax sugar, and even if Grade has largely replaced Maven, the concepts and issues are roughly identical. Bundler was new to me, but why it existed was transparent and its relationship to gems was clear, so only an hour or so of work was enough to get me up to speed. I assumed web work would be similar.

I felt like I was relearning from scratch. jQuery was gone; use anything else. There are several different build systems, all slightly incompatible with each other, to replace YUI compressor and Closure. Prototypes are gone, classes are in. Underscore is gone, and a richer class library is in, but it's not widely supported, so you have to cross compile, for which you need source maps. Some best practices became worst (shove all the JS into one file is the new hotness), but apparently may go to worst (fracturing is better due to HTTP/2 push).

I have actually seen this before: Windows, as it switched from the 3.1/95 series to the COM-heavy NTs, had churn like this. So did Carbon to Cocoa, and arguably Cocoa prior to 10.3 and after, and again once ARC was introduced. But those were single events, whereas this seems, from where I sit, to be a sustained burn.

It really depends on what your goal is. You don't need to buy into any of it and still write high quality software. Concat & minify is still there like it always was (what tools you use to get this done is really irrelevant). You don't need to use Node, NPM, webpack, rollup, babel/buble or classes because today that means you're obligated to use all the tooling and compilation. Not to say that these things dont add value, but the value is greatly overhyped for projects that are not Facebook or Google sized. Virtual dom, Promises, rAF, Canvas, CSS3, new web APIs are definitely worth learning because they provide huge value and will be around for a long time. There has certainly been a shift towards declarative/functional/immutable paradigms in JS but that doesnt mean it works better for all cases.

Might as well do a shameless plug here. If you don't want to learn the current hotness-of-the-month. I've written domvm [1] to be small, fast, fully free from dependencies and build/tooling requirements. It uses virtual dom concepts under the hood, so you get the benefits of both declarative templates and imperative views in pure JS and a very small learning curve.

Believe me when I tell you that you can still write complex-yet-maintainable, performant web-apps with just your browser and vim/notepad w/syntax coloring.

If you're looking to be employable, though, you'll probably need to learn Angular/React/Vue and everything that comes with them ;)

[1] https://github.com/leeoniya/domvm

>It really depends on what your goal is. You don't need to buy into any of it and still write high quality software.

Unless you also make the decisions at the company you work for, no you really can't.

What you said only applies to people making those decisions for their teams or working alone. Others are at the mercy of whatever BS du jour they'll be asked to code in.

Good point. But if you come to a team where the environment is already set up for you, then at least you avoid the headache of choosing/debugging every nut and bolt of the system just to begin writing code.

If you're in a position to define the stack, you have to weigh the benefits vs churn very carefully.

It's because the things people do in the frontend are very different now than 5 years ago.

People forget SPAs and modern frontends are very new and in their infancy... of course they change quickly.

> Compare that to someone who wrote a JS app 1-2 years ago - they have months of catching up to do.

1-2 years ago I'd randomly guess they were using basic jQuery, Backbone, or Angular 1.x... which still work fine. Don't see the problem here.

Visual Basic still works fine. Doesn't mean it's a practical solution to building stuff.

I am not "a JavaScript developer" (Python and Django mainly), but that doesn't mean that I don't need to do some stuff in JavaScript. Where do I start? The choices are overwhelming and there is no clear answer.

In addition the JavaScript world seems to be full of people loudly shouting hype about the latest and greatest new framework, then 6 months later it has changed to something else. Its really frustrating from someone that only spends maybe 10% of my time in JavaScript.

OP's not forcing anyone to do anything. Just suggesting that contributing to an existing project with traction might be more useful.