Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Deep Roots of JavaScript Fatigue

segment.com

Post reply on HN
Print view View original

111–120 of 189 posts

Re: The Deep Roots of JavaScript Fatigue

#111

Post by Yaggo »

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…

> [Javascript] simply is too limited a language to be used for large and complex applications. 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).

Electron? Atom? Slack? React Native? Espruino?

Also, there are plenty of non-web Node.js applications, e.g. https://github.com/sindresorhus/awesome-nodejs#command-line-...

Re: The Deep Roots of JavaScript Fatigue

#112

Post by [deleted] »

douche wrote: post #110
Klathmon wrote: post #101

Earlier quoted context omitted.

I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and sta…

It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the…

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#113

Post by smt88 »

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 PHP is a better analogy than early-2000s Java/.NET. Those latter technologies were largely enterprise driver, but the PHP ecosystem used to be more like today's JavaScript ecosystem. PHP a Blub[1] language, like JavaScript, which attracts inexperienced developers because it seems easy and has widespread support from hosting platforms. Inexperienced developers tend to reinvent the wheel (badly). One major difference is that PHP has a standard library that does almost everything, whereas JavaScript needs insane numbers of libraries for a typical production system (in my case, 5 explicit dependencies create a tree of ~300 packages).

> This problem will not be fixed because JavaScript itself is the problem. It simply is too limited a language to be used for large and complex applications.

I agree, and Facebook (Flow), Google (Dart, TypeScript, and probably others), and Microsoft (TypeScript), agree with us.

> The best bet would be an intermediate layer

See: WebAssembly[2], the successor to asm.js (sometimes called "the bytecode for the web").

1. http://paulgraham.com/avg.html

2. https://en.wikipedia.org/wiki/WebAssembly

Re: The Deep Roots of JavaScript Fatigue

#114

Post by mkozlows »

prewett wrote: post #35
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…

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.

That's not even true, it's just that nobody pays attention to other things.

Look at Windows desktop apps. If you wanted to make a native Windows desktop line of business app in 2000, you would use Win32 APIs. In 2002 or so, you were supposed to use WinForms. And then it was supposed to be WPF. And then Silverlight. And then WinRT.

Re: The Deep Roots of JavaScript Fatigue

#115

Post by julie1 »

z3t4 wrote: post #42
woah wrote: post #9

Earlier quoted context omitted.

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.

And set top box that may have another version of JS.

Or the "javascript" used in Qt ... or any new appliance/software that wants to provide a common accessible language for their "events" and choose a JS that is patched to support stuff like hardware functions.

I have been using these kinds of FrankeinJS in the past.

Re: The Deep Roots of JavaScript Fatigue

#116

Post by nissimk »

manyxcxi wrote: post #41
prewett wrote: 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 think it is a combination of what you are saying. The reason there is so much variation is because the userbase is extremely wide in the javascript world. If you want to deliver your application to the web, you are going to have javascript in there somewhere, and pretty much everybody needs to have their applications on the web these days. So you have developers from a native mindset, an embedded mindset, a backend / data oriented mindset. Nodejs is great for rapid development of http based api's, so you get a lot of backend api perspectives, and of course, as you mentioned, there is the whole html5 / javascript frontend crowd.

Then you have the situation where javascript is both functional and object oriented, so you get toolmakers who focus on one of those or the other more. Now with compile to javascript being more widely accepted, you get a lot of developers from static typed languages insisting that this missing feature is the panacea which will solve all of the problems.

The wide variety of perspectives within the javascript developer community is what sparks the wide variety of new tools and techniques. And popularity of these tools and techniques is definitely based on trends and fads.

Re: The Deep Roots of JavaScript Fatigue

#117

Post by klibertp »

douche wrote: post #110
Klathmon wrote: post #101

Earlier quoted context omitted.

I don't get the hatred for small JS libs. It's the unix philosophy brought to the web. Have each part do one thing and do it well, then combine them. I've used "one function" libs before, and i'll continue to. The most recent example is a small lib that added Array.prototype.reduce to browsers that don't have it. It's 31 lines total (un-compressed, un-minified, un-anything) Installing that small, well tested, and sta…

It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the…

There's nothing wrong with "going down the bundling path". Virtually every compiled language does this via a linker. Java's jars are another example. You have at least 3-4 different tools for doing this in Python.

In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.

Re: The Deep Roots of JavaScript Fatigue

#118

Post by edtechdev »

The language itself is what is simultaneously causing this craziness and holding back real change. Half of the stuff out there is working around JavaScript's limitations. If a bytecode had been approved 15 years ago instead of blocked by JavaScript's own creator, we would be much better off today. WebAssembly is finally, finally a step in the right direction, but it's not a bytecode, either.

Re: The Deep Roots of JavaScript Fatigue

#119

Post by [deleted] »

klibertp wrote: post #117
douche wrote: post #110

Earlier quoted context omitted.

It's dumb, because most of those little shim libraries are things that would be part of the language's core library in a less shitty language. Then when you have all these little libraries, you've got to go down the bundling path (and navigate the bewildering array of almost but not quite the same tools), because making 47 HTTP GETs to grab < 1KB JS files is slow. Theoretically, some of those might be cached, but the…

There's nothing wrong with "going down the bundling path". Virtually every compiled language does this via a linker. Java's jars are another example. You have at least 3-4 different tools for doing this in Python. In short: "bundling" is just JS catching up to how software was deployed for ages. Source maps are equivalent to leaving debugging symbols in the binary, only without performance costs.

[deleted]

Re: The Deep Roots of JavaScript Fatigue

#120

Post by S4M »

z3t4 wrote: post #39
cubano wrote: 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.

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.

> Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.

Yes, but those developers are not doing front end web development for a living.

Post reply on HN