Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

31–40 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#31

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem…

> I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept.

Yup, it doesn't make sense to keep chasing the perfect solution. Developers wouldn't be suffering from fatigue if they focused on "done is better than perfect".

Re: The Deep Roots of JavaScript Fatigue

#32

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem…

Yeah, Ember is awesome. Hassle free tooling and you can get up and going in minutes.

Re: The Deep Roots of JavaScript Fatigue

#33

I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Ember is matured and production ready for years now. You can focus on your product. So, as an Emberjs dev never felt that problem…

> I still dont understand this fatigue rant around JavaScript. Because I started to work with Ember.js 4 years ago, and it is the solution for everything. The framework evolved nicely and works perfectly. It was not a bet, it was serious choice which based on a real perspective and concept. Yup, it doesn't make sense to keep chasing the perfect solution. Developers wouldn't be suffering from fatigue if they focused o…

Sure, if you're always in a position to pick your stack then just sticking with your proven tech works. If you're working for other people with existing code you might need to learn a whole new JS stack every time you switch employers. Since you're already engaged in a Sisyphean cycle of learning new ways to JS why not be on the lookout for perfect for when you do get to pick your own?

Re: The Deep Roots of JavaScript Fatigue

#34
post #19
post #18

I was taking a shower, and this question popped into my head: What is harder to master nowadays? C++/STL/Boost or the Javascript ecosystem? I don't know the answer.

As a C++ developer completely ignorant of everything going on in webdev, except that 'something.js is always the new hotness', neither do I. I've basically ignored the boom in the web ecosystem for 10 years and have even less interest in getting in to it than 10 years ago.

Also a C++ developer, I completely agree. If frameworks repeatedly have lifetimes of a year, that suggests to me that a) nobody really knows what they are doing, b) there is no way to do it well in JavaScript, or c) maybe the problem is that a document description language (HTML/DOM) is unsuited for the kinds of things we want to do on our websites. You can pick pretty much any of a number of UI toolkits for inspiration, they all look pretty much the same. It's not like UI is a completely unsolved problem. It's not even a partially unsolved problem.

I'd be interested to know what the problem actually is, because I certainly don't want to have anything to do with the mess until someone comes up with something solid.

Re: The Deep Roots of JavaScript Fatigue

#35

We are simply going through a Cambrian explosion in the JavaScript ecosystem. Today there is huge demand for the ability to develop desktop standard applications inside the browser. At some point in the last few years we hit a tipping point where the potential to do this was unleashed. I am not sure exactly what the technology was that tipped us over, maybe a combination of several. Was it fast JavaScript performance…

JavaScript is the only UI environment that has gone through 10 years of solid churn. Pick any other UI environment besides HTML/CSS/Javscript and it is pretty stable. So why is the web so churny? It makes me think there is something rotten underneath.

Re: The Deep Roots of JavaScript Fatigue

#36
post #27
post #14

Earlier quoted context omitted.

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.

We old coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.

Re: The Deep Roots of JavaScript Fatigue

#37
post #14

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typ…

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

I wasn't around for the C-explosion but it seems like something that is exacerbated by the current ease and normalization of sharing code.

Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools.

On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome.

My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.

Re: The Deep Roots of JavaScript Fatigue

#38
post #27
post #14

Earlier quoted context omitted.

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.

> You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.

For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it.

Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript.

In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff.

It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work.

It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later...

It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...

Re: The Deep Roots of JavaScript Fatigue

#39
post #14

I thought the article started strong and skipped around serious issues so it could focus on a pretty nice history of JS, but the conclusion was horrible. > Babel has worked it’s way into the standard Javascript toolchain, and now most builders include it as a first-class plugin Which version of Babel, 5? or 6? Because there's a lot of incompatibility issues right there and I think it is just as symptomatic of the typ…

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

Don't worry, it's mainly in the HN bubble, reading HN every day will after some years make you think this is how the world looks like. Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.

Re: The Deep Roots of JavaScript Fatigue

#40
post #20
post #19

Earlier quoted context omitted.

As a C++ developer completely ignorant of everything going on in webdev, except that 'something.js is always the new hotness', neither do I. I've basically ignored the boom in the web ecosystem for 10 years and have even less interest in getting in to it than 10 years ago.

Hear, hear. I wrote gui applications fifteen+ years ago in MFC and the ATL. Front-end programming was boring then and it's boring now. I can't believe people are wasting so much time re-figuring this stuff out.

I am also not really into web development, but from the outside it seems especially primitive. I did write some Qt applications the last ~10-15 years and even at the turn of the century it was far easier: design graphically using Qt designer, run the UI file through uic, connect some signals to slots, done. All fast, smooth, with a much more native look & feel than web apps.

I recently ported a larger Qt 4 application to Qt 5. It took one or two hours. (Qt 4 was introduced in 2005.)

Post reply on HN