The Deep Roots of JavaScript Fatigue • Hacker News Board

Re: The Deep Roots of JavaScript Fatigue

#121

Post by geebee » Wed, Mar 16, 2016, 1:54 PM UTC

aedron wrote: post #108

samcodes wrote: post #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 br…

> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alon…

I think you've nailed it. Web programming in javaland was verbose but relatively straightforward until about 2004, maybe a little earlier, when frameworks exploded. I'm not sure the frameworks themselves were worse than what preceded then - Struts2 was, in my opinion, an improvement over the original Struts. But I do recall hating web programming for a few years, wanting to leave and do something else (in a way, I did, I got a job writing java code to interact with CPLEX, and other developers handled the webapp stuff, so I was able to just mainly write straightforward Java, which I still don't think is such a bad language, it was the framework bloat that I disliked). The reason was doing very simple things had become mind numbingly difficult, and you had to wade through massive amounts of configuration and framework documentation (or code, since documentation often didn't exist for your specific issue) to do relatively simple things. The Java web programming cookbook became relatively obsolete, because everything was now handle by a framework that promised to make things simpler, but (often due to churn) massively increased the overhead.

Interestingly, it was, as you've pointed out, never resolved. Instead, it all became obsolete. I personally left javaland and started writing with Rails (even the non-web stuff I generally started using Python rather than java).

I suspect that we're heading down that road again. I think the modern javascript frameworks are the product of very intelligent and talented people, but my gues is that something interesting and "unanticipated" will sweep this all aside.

To risk a prediction, I think that other languages transpiled to isomorphic javascript will provide a new approach that will allow excellent languages like ruby and python to be used to write an entire web app again.

Until then? I wish I'd had the conviction to avoid MVC frameworks in the early 2000s. It's easy to feel like you're doing things the "old way", but I wasted a lot of time chasing java frameworks only to abandon the entire enterprise a year or two later… of course, it wasn't entirely my decision, it's hard to go against the grain, since you're rarely the only developer on a team.

Re: The Deep Roots of JavaScript Fatigue

#122

Post by cognivore » Wed, Mar 16, 2016, 1:54 PM UTC

samcodes wrote: post #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 br…

"...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 implemented that most everyone tries to abstract it away at some point, and a language that is universally regarded as one of the worst ever.

Is that what you build on for the future? Cause then I do see it being pointless tech churn because your fundamental building blocks are too seriously flawed.

If the future is programs that people can download and run on their computer on demand you'll need a good run-time, language agnostic, compiles to binary, sandboxed, with a well defined UI system not based on document display. There's no web-browser, DOM, or Javascript in sight.

If you had such a thing this thread of conversations wouldn't even be happening. I sincerely hope that someone smarter than me comes up with that (yes, Java was a close but no cigar) and we gravitate away from the morass we have now.

Re: The Deep Roots of JavaScript Fatigue

#123

Post by weego » Wed, Mar 16, 2016, 1:55 PM UTC

Klathmon wrote: post #103

weego wrote: post #92

Earlier quoted context omitted.

Agree. The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use…

That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?

It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs.

I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?

Re: The Deep Roots of JavaScript Fatigue

#124

Post by cesarb » Wed, Mar 16, 2016, 1:58 PM UTC

aedron wrote: post #108

samcodes wrote: post #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 br…

> why the ecosystem looks like this It is a symptom that the platform is woefully broken, hence the multitude of solutions to try to make it workable. Neither of which work particularly well, so there is always room for one more to 'solve' it slightly differently. The same story played out during the early 2000s, before rich JavaScript applications were really an option, with non-JS based web frameworks. In Java alon…

> The proof of this is that JavaScript is used for exactly zero non-browser runtime environments (discounting node.js whose only appeal is to use the same language on the server as in the browser).

I believe Qt's QML also uses JavaScript.

Re: The Deep Roots of JavaScript Fatigue

#125

Post by samth » Wed, Mar 16, 2016, 2:01 PM UTC

So much of this history is wrong.

1. ECMAScript is called that because Sun (now Oracle) owns the JavaScript trademark, not because anyone wanted to be diplomatic.

2. JavaScript language evolution was not primarily driven by the Firefox team. Mozilla didn't start until 1998, by which time pre-ES5 standards were mostly done. There was an effort called JS2, led by Waldemar Horwat (then of Netscape) which didn't result in a standard. Other SpiderMonkey JS extensions were mostly not adopted, or adopted in ES6 in heavily revised form.

3. The creation of the spec was driven in significant part by Microsoft, whose internal spec documents formed the initial basis for ES1.

4. The "harmony" name came entirely after the end of ES4.

5. None of the design of classes, modules, or other major ES6 features comes from ES4. Smaller features such as `let` were present in ES4, along with very different class systems, namespace systems, and other features.

6. Neither JScript versions nor Spidermonkey's JavaScript versions ever had a significant impact on JS on the web.

7. Unlike ES4, ES6 is backwards compatible. ES6->ES5 compilers are not needed to make it backwards compatible.

Re: The Deep Roots of JavaScript Fatigue

#126

Post by mtberatwork » Wed, Mar 16, 2016, 2:03 PM UTC

Klathmon wrote: post #103

weego wrote: post #92

Earlier quoted context omitted.

Agree. The worst issue for me is how unfocused the efforts are. I experienced issues at a large media company where new features to the public site to improve user experience where delayed for entire sprints because someone in the team became obsessed with the notion that their env was wrong because they were using grunt instead of gulp, or they used a particular Sass processor that relied on Ruby and they could use…

That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?

Given how difficult it can be to get past HR keyword filters when applying for a new job ("Oh we need a candidate with gulp experience, not grunt."), I can see how folks are fearful that they aren't using the "right" technologies. It's insanity.

Re: The Deep Roots of JavaScript Fatigue

#127

Post by [deleted] » Wed, Mar 16, 2016, 2:07 PM UTC

weego wrote: post #123

Klathmon wrote: post #103

Earlier quoted context omitted.

That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?

It wasn't a single developer, it was a subset culture in the team of frontend developers. Those 2 examples were 2 different devs. I don't really get your point though. Are suggesting that JS fragments and reinvents itself outside of the will of the general populace of frontend developers? How else could the problems in frontend dev arise if not from the culture created by the people?

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#128

Post by [deleted] » Wed, Mar 16, 2016, 2:08 PM UTC

mtberatwork wrote: post #126

Klathmon wrote: post #103

Earlier quoted context omitted.

That sounds like your developer's problem, not the technology's problem. Would you blame the language C++ if the developer was constantly compiling their own compiler from master every single day and spending hours upon hours dealing with that?

Given how difficult it can be to get past HR keyword filters when applying for a new job ("Oh we need a candidate with gulp experience, not grunt."), I can see how folks are fearful that they aren't using the "right" technologies. It's insanity.

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#129

Post by untog » Wed, Mar 16, 2016, 2:24 PM UTC

rimantas wrote: post #104

PhilWright wrote: post #17

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…

> Today there is huge demand for the ability to develop > desktop standard applications inside the browser. Is there? Or just devs wanting to do that, for reasons unknown? I as a user could not care less about "desktop standard applications inside the browser", desktop applications work just fine.

It's a huge boon for administration - auto updates, no install procedure, cross platform...

Re: The Deep Roots of JavaScript Fatigue

#130

Post by dham » Wed, Mar 16, 2016, 2:27 PM UTC

br3w5 wrote: post #109

"No other language does anything remotely resembling that kind of thing". Have you ever worked on a Java EE project?

I did JSF for 4 years, along with the rest of the Java EE stack. Glassfish web server. There was never churn like this . I was pretty enthusiastic about front end dev for years. I'm pretty burnt on it now though.