Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

41–50 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#41
post #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.

It also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to be earlier in their careers and more likely to come from a 'non-traditional' background into tech. You're not seeing code boot camps popping up for Java and .NET developers like you are HTML/JS and Rails.

It's not a knock, the younger people usually bring the enthusiasm and fresh ideas to the table- but that enthusiasm and zest hasn't been sobered with a decade of real world experience and a more analytical/engineering background and schooling.

Re: The Deep Roots of JavaScript Fatigue

#42
post #9
post #7

well javascript is evolving at a fast pace. Wheat still grow on a seasonal base. Tourism is still yearly based. A car will last you years. telco CPE are lasting for years. Bank terminals are for years. Robots in factories last decades. Peacemakers are intended to last ages. Users do not really like to have their interface changed without any reasons to do simple tasks. Browser ecosystem is just running amok in terms…

When was the last time an existing application stopped working because of new JS features?

The problem now a days is phones. Their browsers work very different from desktop browsers.

Re: The Deep Roots of JavaScript Fatigue

#43
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 would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that.

Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, and you can do that as easily as 15 years ago if you learned it back then.

As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).

Re: The Deep Roots of JavaScript Fatigue

#44
I have learned so much from comments on Hacker News. Every time one of these articles gets posted I hope that I will get to see some thoughtful commentary on why the ecosystem looks like this: is it the enormous influx of new talent? Is it the consensus to finally drop IE support, and that we're getting a decade of progress in two years? What business demands are driving this technology? Is this a race to make the browser experience on-par with native? How do all these things interact, and what about all the other factors that I'm not smart enough to see, but usually someone on HN points out for me?

But no, I never get to read that, just complaints about how the whole community is dumb. Really? That seems unlikely. I don't believe this is pointless tech churn, akin to fashion. It really feels to me, at least, that there is a direction that the tooling is heading. I'm not sure what it is, but I feel like if that's where these conversations were focused (instead of just rejecting the current state of things) we could figure it out.

Yeah, it's frustrating as shit, we needed to all be pissed about it for a bit, but let's have a productive conversation.

Re: The Deep Roots of JavaScript Fatigue

#45
post #9
post #7

well javascript is evolving at a fast pace. Wheat still grow on a seasonal base. Tourism is still yearly based. A car will last you years. telco CPE are lasting for years. Bank terminals are for years. Robots in factories last decades. Peacemakers are intended to last ages. Users do not really like to have their interface changed without any reasons to do simple tasks. Browser ecosystem is just running amok in terms…

When was the last time an existing application stopped working because of new JS features?

When explorer 10 started reporting in js the availability of the firefox xml parser object but then it was not compatible and all code parsing xml suddenly broke for no reason, which is not javascript per se but it isn't like the language exists in a vacuum

Or if you want language proper at some point node allowed keywords to be used as properies.

Re: The Deep Roots of JavaScript Fatigue

#47

Curious questions for those who complain about Javascript fatigue: What reasons are you're dropping your old libraries/frameworks in favor of the new ones? If an unstable API is a big problem for your use case, why not just stick with the old library or just not update the dependencies?

A big problem I have run into on projects that have gathered dust for a few months has been when version wasn't pinned, or the package wasn't using semver, or some other drift in the package.json that causes a slightly or completely newer version to come down, which causes, a whole host of dependencies to update and then boom- hopefully you have unit tests to catch the breaking changes.

Also, when you check the project out and it was relying on global npm packages to build and the system you're working on has been updated in the last few months and now all of a sudden your grunt file doesn't run or your CSS minimizer complains about your Ruby version. God forbid you build multiple JS projects in one CI server!

Re: The Deep Roots of JavaScript Fatigue

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

It reaches much more people if that is what you care about.

Re: The Deep Roots of JavaScript Fatigue

#49
post #35

Earlier quoted context omitted.

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.

It also may be the people that are drawn to it. There are backend/frontend dev stereotypes for a reason. In my experience, the frontend dev teams have tended to be earlier in their careers and more likely to come from a 'non-traditional' background into tech. You're not seeing code boot camps popping up for Java and .NET developers like you are HTML/JS and Rails. It's not a knock, the younger people usually bring the…

This is a really interesting point. I think another factor is that if you have a huge amount of users, you need robust server code. But front end code only has one user at a time. And it's much more tied to design, so it gets "stale" faster, so there are just very different pressures on it that make it less amenable to a traditional engineering approach. In that it might be worth trading some robustness for speed of updates.

Re: The Deep Roots of JavaScript Fatigue

#50

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…

Ember even has a LTS version now!
Post reply on HN