Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

51–60 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

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

What's rotten is probably raw javascript. The fact that pretty much no one uses raw javascript and have to rely on all these libraries to abstract the uglyness and inconsistencies isn't a vote of confidence. Javascript is popular by necessity not by its own merits. All new and growing platforms (iOS, Android) have been locked down into proprietary languages / libraries, and javascript is the only language neither Apple or Google could block, just because they were forced to preserve compatibility with the web, not because it was a terrific language.

We pretend to like it just because it's the only meal we get to eat if we don't want to starve.

Re: The Deep Roots of JavaScript Fatigue

#52

Earlier quoted context omitted.

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…

You bring up a good point that I missed in my first comment. The design. God damned designers! I kid- I worked at an agency for years and the hardest part was always getting the build to match the design when they were still laying out the design pixel perfect in Photoshop and Illustrator as if we were doing print work or doing fixed width pages.

I've seen some designs that were, frankly, beautiful but it took no more than 5 seconds to highlight the 30 areas that were going to cause massive budget overruns trying to make look exactly right, have decent performance, and work in eleventybillion browsers.

I've certainly appreciated what interesting designers can bring to the table, but we're still a ways away from a lot of traditional designers having a good handle of what their design really means when we're building it. Kind of like the contractor who bitches about the architect for designing an angle that is impossible to hammer into. Sometimes there is a disconnect.

Re: The Deep Roots of JavaScript Fatigue

#53
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…

I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5.

It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways.

So the JS churn model has begun to infect another language as a model to be emulated rather than reviled.

Re: The Deep Roots of JavaScript Fatigue

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

I don't really understand the point of what you're saying.

I ignore all of the .NET and C ecosystem and I have absolutely no interest in them for many reasons, but that's not saying much about anything. Just because you don't care about Javascript doesn't inherently make it's ecosystem so bad.

Re: The Deep Roots of JavaScript Fatigue

#55
post #51
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.

What's rotten is probably raw javascript. The fact that pretty much no one uses raw javascript and have to rely on all these libraries to abstract the uglyness and inconsistencies isn't a vote of confidence. Javascript is popular by necessity not by its own merits. All new and growing platforms (iOS, Android) have been locked down into proprietary languages / libraries, and javascript is the only language neither App…

Oh, language is rotten if developers use libraries and abstractions? When was last time you wrote an application in "raw" Python/C/Swift/Erlang? (Whatever "raw" is supposed to refer to, is standard lib allowed?)

No language is perfect, and javascript is actually pretty nice one, also considering that there are multiple independent runtime implementations for almost every platform, I would say javascript as an ecosystem works surprisingly well.

Javascript only has problem if you think diversity is problem. It's totally expected outcome that people (wildly) try things when the language is well designed, i.e. relatively small but flexible core.

Re: The Deep Roots of JavaScript Fatigue

#56

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 br…

I can't help but think this is just a whole bunch of people up in arms about not wanting to learn something they think they have to because 'all the cool kids' are.

This discussion is often brought up in relation to React/Redux/Babel/Webpack, and people thinking they have to completely master all of them to start making websites, when the reality couldn't be further from the truth.

Twitter had an amusing quip of the topic last week:

> If you’re feeling overwhelmed by Slack or React (judging by the HN front page this week), I politely suggest you re-evaluate your life.

https://twitter.com/iamdevloper/status/707146929075949568

Re: The Deep Roots of JavaScript Fatigue

#57

This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just ramping up on whatever the new hotness happens to be?

You don't have to. The tools which worked 10 years ago still work today. The tools which worked 5 years ago still work today. No one forces you to switch to the new hotness, people choose to.

Re: The Deep Roots of JavaScript Fatigue

#58

Earlier quoted context omitted.

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…

I would have agreed with this, but I've just been exposed to what's happening in the new .Net core and asp.net 5. It's a clusterfuck of the sublime and the downright stupid. Any new trendy idea has been rammed in to the new ASP.Net with startlingly high churn for a MS product and bizarre choices like forcing you to program in particular (often undesirable overkill) ways. So the JS churn model has begun to infect anot…

Yeah, that's a good point. In fairness to MSFT, with Roslyn and really trying to make the .NET stack able to run on non-Windows boxes you would think there would have to be a few hiccups along the way. I feel like the JS scene is facing this level of upheaval every 9-12 months right now.

Re: The Deep Roots of JavaScript Fatigue

#59

This is interesting but good lord, I want nothing to do with any of this. How are you supposed to get anything done if you have to spend so much time just ramping up on whatever the new hotness happens to be?

I don't really understand this. The height of confusion was at the beginning of the article when the author's friend regretted using RequireJS

> We talked again last night, and he said that he’d chosen RequireJS. By now, his company had built a massive codebase around it –- “I guess we bet on the wrong horse there.”

What makes RequireJS the wrong horse? Is it not doing what it was originally doing? Do you need more from it? How do you build 'a massive codebase' around a module spec? I'm guessing here the person thinks Webpack is the right horse - Webpack supports the AMD spec RequireJS uses if they felt the need to switch (which I can't see why you would), which would minimise whatever changes needed if you had the urge to 'churn'.

I think people need to stop getting so anxious about doing what all the 'cool kids' are doing.

Re: The Deep Roots of JavaScript Fatigue

#60

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 is fantastic, the oldest projects I have are about 4 years old and have been (more-or-less) painlessly upgraded every now and again. Everything is ember-cli and ember-cli-deploy now. Time and time again it shows that Ember is a community project that has a strong focus on scalability and maintainability over time.

I also do a lot of work in Angular and React (this year) and all the tooling, build, best practices change every couple of months.

A lot of people complain about Ember's learning curve, but the things you learn _stay relevant_. Personally I'd rather invest in that kind of knowledge than learning yet another arbitrary build system.

Post reply on HN