Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

181–189 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#181
post #106
post #77

Earlier quoted context omitted.

> I don't believe this is pointless tech churn, akin to fashion. This is not pointless, but it is pretty uncontrolled. Basically, there is a natural tendency for engineers to want and rewrite old stuff, once all the flaws of once-cherished yesteryear solutions are glaring. Normally, engineers don't have a freehand in ditching old projects and rewriting from scratch, so they have to maintain what exists. But with all…

Rewriting can pay off in spades very quickly. Just as some examples.... we've moved some pages to vanilla jQuery to Angular and have gained orders of magnitude more stability (read: basically no state-inconsistency bugs in newer pages). If you're faced with vanilla javascript in the DOM and have any amount of complexity to it, then you should be using angular/react, if not for your sanity than for the sanity of the o…

You know, if people approached web programming like actual programming, with layers of abstraction, there wouldn't be spaghetti code in the first place, and one could move to a different framework as needed.

But the problem is nobody stays with anything long enough in the web world to learn it well. 5 years ago, Backbone, Then Knockout. Then Angular. Then Ember. Now React.

Seriously, a dev with 5 years of experience in JS has literally the same 1 year of experience over and over now.

:D

Re: The Deep Roots of JavaScript Fatigue

#182
'Most of the tools we use today didn’t even really exist a year ago: React, JSX, Flux, Redux, ES6, Babel, etc.'

ES6 is a new version of the language under discussion, Babel is a tool to allow you to compile code written in the new version into the old version. The other 4 examples are all closely related to each other, if you use JSX and FLUX you use React, if you use Redux you probably use React.

In other words while I believe fatigue exists and is probably warranted, these were bad examples of what would cause the fatigue.

Re: The Deep Roots of JavaScript Fatigue

#183

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 don't know how productive this is, but here is my take on this situation that you likely aren't going to hear anywhere else. I believe there is a fundamental lack of understanding about web development - mainly HTTP and HTML. These technologies are simple which is why most developers don't bother to learn them. Being a developer both before and after putting in an effort do deeply understand the foundations of web…

Can you point to any more elaborated examples or write-ups of the kind of html/http work you're describing here? I'd love to learn more.

Re: The Deep Roots of JavaScript Fatigue

#184

'Most of the tools we use today didn’t even really exist a year ago: React, JSX, Flux, Redux, ES6, Babel, etc.' ES6 is a new version of the language under discussion, Babel is a tool to allow you to compile code written in the new version into the old version. The other 4 examples are all closely related to each other, if you use JSX and FLUX you use React, if you use Redux you probably use React. In other words whil…

that said if anyone can explain to me the benefits of webpack in comparison to my gulp.js build pipeline with real examples then it would be nice.

Re: The Deep Roots of JavaScript Fatigue

#185

Earlier quoted context omitted.

jquery spaghetti code can be quite readable if you're smart about layout... group things into sections, arrange everything sequentially where possible, etc etc I've had to do a fair amount of complex UI and, frankly, I don't see why people stress so much about it. I rarely end up with more than a screen's worth of event handling code (which is a small amount of pasta, really), and things flow around fairly intuitivel…

It sucks; I'm 31, but the only people I can relate to here are the old men. Nope, 31, you're an old man now.

sigh :)

Re: The Deep Roots of JavaScript Fatigue

#186

Companies will never stop wanting better tools to build apps. The software industry is highly competitive - If tools didn't keep improving, established players (big companies) would have the upper hand. New tools allow increasingly small startups to compete against big companies - Being able to start fresh with the most cutting edge tools is a huge competitive advantage for startups. I don't think progress will stop…

Still waiting for that reality on the desktop side of things....

Re: The Deep Roots of JavaScript Fatigue

#187

Earlier quoted context omitted.

"...but let's have a productive conversation." Okay, I'll bite. With a web browser, a DOM, and Javascript, where do you see this all heading that's full of truth and beauty? Where does the churn end if it's not pointless? Cause you've got a web browser that was designed to view pages of linked information that has now been pressed into service as a ad-hoc run-time for building applications, a DOM that is so poorly im…

Monty Python explains the foundation of frontend web development better than anyone. "When I first came here, this was all swamp. Everyone said I was daft to build a castle on a swamp, but I built in all the same, just to show them. It sank into the swamp. So I built a second one. That sank into the swamp. So I built a third. That burned down, fell over, then sank into the swamp. But the fourth one stayed up. And tha…

We're still working on the second castle.

Re: The Deep Roots of JavaScript Fatigue

#188

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…

For people who have used more batteries-included style frameworks like Ember, the churn isn't as bad. But for those who tend to lean more toward small libraries like Backbone and React, the churn can be overwhelming.
Post reply on HN