Hacker News Reader

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

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

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.