Comment by edblarney | Hacker News Reader

Comment by edblarney | Hacker News Reader

JS fatigue is not a fake problem, it's real and different from other forms of fatigue.

The metaphor used in the article i.e. 'learning another language every 6 months' is not apt - because those are not 'new languages' and they are not 'new and critical parts of the landscape' for any specific vertical.

If any one of those languages were to have the same degree of evolution as JS ... then 'fatigue' would also be an issue.

JS has a pernicious problem for a few reasons:

1) The language is quirky, fragmented, there are still no 'agreed upon' approaches to do many things even outside the context of libraries. There are really no analogues to 'prototype' based languages, which possibly makes it great for some things, but it's not great for those wanting to use more classical ways of thinking about information organization.

2) Runtimes, particularly browser - are highly fragmented, and there's scant documentation. Safari docs for Mac/iOS are literally empty in some spots.

3) JS doesn't come with a lot of things 'baked in' to the language that most others support, so discovering those 'standard libs' has been a painful process.

4) Due to the limitations of the browser, we see a lot of churn in frameworks.

Though there is some advantage to 'community participation' - the pernicious problem is most of the churn is not fully forward. It's 3 steps forward, 2 steps back, and a step sideways.

There's a lot of time and investment in learning something new that won't exist in the future - that's costly.

Learning Lambda's for Java 8 is probably worth investing in for Java programmers ... because Java 9 will surely use them as well.

Taken as a whole - there is an enormous amount of inherent 'reducible complexity' in the JS ecosystem, which any JS developer intuitively senses.

If someone were to have made up their mind about JS right from the start, and had come up with some good standard libs ... and the evolution of the language were to have been more 'version' and less 'pick and chose' (Es6 means something different in each environment) ... then the complaint would be valid.

It is what it is ... but JS fatigue is a real thing.

You have a lot of great points but one area where I disagree is in this statement:

> Es6 means something different in each environment

Ecmascript 6 (or Ecmascript 2015) by definition is a specification that browsers (and others, such as nodejs) adhere to in order to support that version of JavaScript. The api and functionality are designed to be the same. So Es6 means the same thing no matter the environment. However, there places where they haven't finished implemented ES2015 quite yet.

Most modern browsers have 99% of Ecmascript 2015 all implemented. [0]

And for those that don't, there's always transpilers like Babel or TypeScript.

[0]: https://kangax.github.io/compat-table/es6/

one reason why JS is so popular is because there are no standard lib. There would be no nodejs etc.

node.js was built from scratch, in C, to resemble javascript syntax intentionally.

No, it was not. It uses Chrome's JavaScript Engine, V8.

From nodejs.org:

> Node.js® is a JavaScript runtime built on Chrome's V8 JavaScript engine.

What? The engine is written in C, but all JavaScript engines are written in another language (C being the most popular) because it is an interpreted language. The engine isn't written from scratch because it is the V8 engine from Google. Of course the system binding and package system is written specifically for Node.

C++, actually.

node.js doesn't just resemble JavaScript, it is JavaScript. Like ES5 standard JavaScript, and (very soon) ES6 standard JS as well. It uses the V8 JS engine.

The only non-standard features of Node.js has been the module system (CommonJS), but even that will be ECMA standard as of next version.

(also, Node.js was built in C++ and JS)

The module standard that is present in ES6 is a very different beast than CommonJS

Agreed. I use ES6 modules regularly (via Babel compiled to CommonJS, and also Rollup). Unlike CommonJS, ES6 modules have the advantage (and disadvantage) of being statically resolved, which permits tree-shaking (but denies dynamic resolution of imports like CommonJS).

The "that" in my sentence refers to "module system", not "CommonJS", but I agree my sentence was unclear.

More specifically: in the next major Node.js release (v7.0.0), ES6 modules will be implemented. That's what I was trying to say.

It's popular because it's in the browser.

Everything else is just Stockholm-syndrome.

Nodejs strikes me as an unfortunate consequence of having js in the browser and a drive for reducing the complexity by having the same language on the server.

Example of use outside browsers: Windows and OS X scripting, classic ASP, Pebble watch, MongoDB database, Adobe Photoshop PDF et al, LibreOffice, Unity game engine, Qt, GNOME Shell, Ubuntu Touch, Chromebooks.

ref: https://en.wikipedia.org/wiki/JavaScript

I used JavaScript as a web developer for 15 years, but did not like it. It wasn't until I started with NodeJS three years ago I learned JavaScript in depth. It's when you grok closures, events/async/concurrency, prototype, objects, and commonJS modules it starts to get fun. There where a lot of headache going from serial programming to parallel programming like the pyramid of doom, Christmas tree from hell etc, until I learned to manage it.

When CPU's get more cores instead of getting much faster, concurrency is the way to go, and it fits JavaScript well. You should have raised an eyebrow or two reading this, as JavaScript is "single threaded". That just makes things more simple though, if you know how to write event based code, like handling clicks on a web page, you already know how to write distributed systems and can scale beyond a single CPU or server.

I argue that the reason it's used outside browsers is primarily that a generation of programmers learned it first - IN a browser.

As a language, it has more warts and less features than many other languages, but it also is unimposing and does not get in your way.

It could have been much better though.

Microsoft tried to make vbScript an alternative to JavaScript. vbScript is a good language, but JavaScript is better. For example, how to make a custom object in vbScript:

  Class foo

    Private barval
	
    Public Property Get bar()
      bar = barval
    End Property

    Public Property Let bar(b)
      barval = b
    End Property

    Private Sub Class_Initialize(  )
      barval = 1
    End Sub
	
  End Class

To make an object in JavaScript:

  foo = {bar: 1};

Before NodeJS existed, most people, including myself thought that JavaScript is a stupid language only used in browsers. I was also aware of NodeJS for at least two years before I finally tried it. I thought it was stupid why the hell would you want to code JavaScript outside the browser I thought. After maybe one year of learning, walking through the swamps, I finally saw the light. The most revolutionary I think is the module system in NodeJS, it's what makes writing huge programs in JavaScript manageable. Because of this many JavaScript programs now a days comes with thousands LOC tested and hardened in production, while the actual code you write and maintain yourself is only like one hundred LOC.

I think the NodeJS module system is maybe hundred years ahead of its time, it's right in front of us, but few people seem to notice. And in the direction we are heading now it will soon be forgotten (ES6 import). People use NodeJS modules like imports and couples the code instead of decouple. Sure it works fine for a while, but sooner or later the project will grind to an halt because of code complexity.

"It's popular because it's in the browser. Everything else is just Stockholm-syndrome."

Not quite.

JS is a great language for doing async.

I much prefer Node.js over CGI, Java or Ruby back-ends.

But yes, there is some craziness given how for so many other reasons, JS is not a great language.

Reply on news.ycombinator.com