7 ms·

There are some nice ideas here, but how many different ways do you need to do something? Since JavaScript has an especially high burden for backward compatibili

There are some nice ideas here, but how many different ways do you need to do something? Since JavaScript has an especially high burden for backward compatibility you can’t really remove old cruft, and adding yet another way to (whatever) just makes the language harder to learn and harder to read. Warts and all, one of the best things about ES5 and earlier is that the language was so simple that you could pick it up in a day. The later additions have added developer convenience for sure, but at the expense of taking something simple, consistent, and very easy to read, and turning it into a complex and subtle language with a lot of redundant syntax. For example all the different syntaxes for defining a function with the subtle differences between them. And in this articles proposal - since switch doesn’t do what I want, we’ll have both switch AND case with different semantics and syntax. Ugh. At this point I’d rather see an effort to deprecate cruft or standardize features over throwing in new things.

scarface74 8y ago
There was nothing easy to read about the callback hell that resulted in the asynchronous nature of JavaScript. Promises made it better but that was still verbose. Then async/await was added that made code read more linearly. There was also the unintuitiveness of how var declarations were always function scoped compared to how most developers would think that variables should be blocked scoped using let and const. Also I understand how prototypical inheritance works and I know that the class syntax is just syntactic sugar, but it is a lot more readable.
- ChrisSD 8y ago
  Improving some of the syntax was sorely needed but I think adding classes was unhelpful. I already have a hard enough time teaching programmers about prototypical inheritance without the language actively lying to them. And it feels like an odd move in that class based OOP isn't the zeitgeist it once was. Shoehorning it in feels like a throw back to 90's and 00's.
  - scarface74 8y ago
    The two most popular statically typed OOP languages for servers are still C# and Java. Besides JavaScript, the most popular scripting language is Python (let’s ignore PHP for now) which is class based. In the mobile space, Swift, Java, and now Kotlin are all class based. “The zeitgeist” is different than “what companies are paying real money for”. Besides, even with OOP based inheritance, the language is still “lying” just as much. Most developers who don’t understand how the lowest level of computers work don’t understand that when you call a function it’s always basically passing in a this pointer to one static instance of the function.
    - jerf 8y ago
      Object orientation in the sense of having some sort of data structure having some officially associated "methods" with it, and then building other structure on top of that, is alive, well, and not going anywhere any time soon despite the occasional functional programmer epiphanies. Object orientation as in "There must be classes, there must be inheritance, each method and instance value must be able to be private, public, or protected, and have official constructors and destructors" and probably a couple of other things I'm missing, is also alive and well and not going anywhere any time soon, but is no longer the only definition of Object Orientation. If you were not around at the time, you'll have to take my word for this, although the echos still reverberate in Javascript tutorials to this day (because of the way they talk about prototype-based inheritance as if you've got to be placated long enough about the fact that it isn't "true" OO long enough to learn what it actually is), but when it was released, Javascript (prior to any sort of "class" keyword) was not considered an "object oriented" language, because it didn't have "real" inheritance, or private values, etc. etc. The point is that in a world where the definition of "OO" has expanded enough to encompass the original JS, it's a bit odd to bodge on a particular definition of OO so late in the process. (People also argued back then about whether Python was object oriented (!), because it didn't have "true" support for private instances or methods. By contrast, I find it amusing when sometimes the question comes up "Is Go really Object Oriented if it has no inheritance?" and the answer generally amounts to "Honestly, who cares?")
    - slifin 8y ago
- type0 8y ago
  You could put callback back in the bag https://github.com/staltz/callbag-basics https://github.com/staltz/callbag-basics
- tenaciousDaniel 8y ago
  I agree that the class keyword is far more readable. I never find myself using them in the "classical" sense, though I could see how it would be tempting for someone coming from, say, Java.
- tonto 8y ago
  We are now in an intermediate hell of Babel and webpack though...the language is cool, but the toolchains are really crazy right now. Someone could dismiss my argument if they got a comfy setup but often times if you're doing even just a little trailblazing you get into some wtf territory. I spent all day this week setting up a karma test cause my node module was failing only in the browser so then I added Babel and karma-webpack, but then regenerator runtime kept giving me errors, then mixing require() and es6 import gave me insanity errors and I almost gave up. Deep googling gave me barely enough clues to get through it...
  - scarface74 8y ago
    I’ve avoided any serious JavaScript development for years because of crap like this except when absolutely necessary. I’ve learned it well enough to get pass “full stack developer” interviews, but as soon as I get hired, I get migrated to the back end. I’m just now putting the finishing touches on my first Node/Express microservice for production. I’m putting off front end development for another year or so.
javasharp1 8y ago
there was nothing easy about var hoisting. modern javascript with a good linter is a lot cleaner and easier to read.
danarmak 8y ago
> Since JavaScript has an especially high burden for backward compatibility you can’t really remove old cruft You can't remove features from JS runtimes (browsers or node), but you can certainly remove them from a new language version. "use strict" already did it once in JS. It can be replaced/upgraded with "use ecmascriptX.Y" for each language version. And transpilers targeting JS and tools like packers and minifiers can enforce language versions without declaring them in each file.
- WorldMaker 8y ago
  "use strict" was also highly contentious for a time. "use versionNumber" would have similar issues to the battles the web fought over DOCTYPES and "quirks" modes and browser compatibility.
userbinator 8y ago
It reminds me a lot of what happened with C++ in the past few years, and in contrast to C which has basically stayed still meanwhile (I know there's C99 and C11, but a lot of code out there is still C89 --- and IMHO that's the way it should be.) I am very much against constant change in a fundamental platform. I should be able to write JS that works for decades without worrying about deprecation or any other sort of useless "churn". The less the platform changes, the more you can focus on understanding it and doing more. But of course it seems the majority of developers would rather have "new and shiny" over "old and stable", which I think is quite unfortunate. The old saying is "do more with less". What's happening now in development, especially Web, seems to be more like "do less with more".
- int_19h 8y ago
  JS was born a horrible language. It needs to be fixed before it becomes so entrenched that you might write code in it that has to work for decades.
  - rhapsodic 8y ago
    > JS was born a horrible language. It needs to be fixed before it becomes so entrenched that you might write code in it that has to work for decades. That ship sailed long ago.
licyeus 8y ago
I've never thought of ES5 as simple, consistent, and easy to read. There are plenty of features that many devs wouldn't recognize (ie, "the bad parts"). They've fallen out of vogue because there are better ways to do things, but they're still part of the language. I, too, would love a simplification of the language, but as you mention, backwards compat is necessary. And what does `case` not do that you want it to? Fall-through? Re: forced destructuring, if you want to switch on a value, why not just wrap it in an object, eg, `case({ someVal })`? It's not perfect, but I'd prefer consistently using `case` to the confusion you call out re: `case` vs `switch`.
- burlesona 8y ago
  The point is that case does not currently exist, but switch does, and is fine. If we could get rid of switch and replace it with this case proposal, that might be nice, but we can’t. Having the language with both existing side by side is, to me, worse than just living with switch.
ErikAugust 8y ago
ES5 took me months to understand well. And today, after years (and now on ES6/TypeScript) I cannot always properly describe some features of ES5 without seriously reviewing them.

scarface74 8y ago

There was nothing easy to read about the callback hell that resulted in the asynchronous nature of JavaScript. Promises made it better but that was still verbose. Then async/await was added that made code read more linearly. There was also the unintuitiveness of how var declarations were always function scoped compared to how most developers would think that variables should be blocked scoped using let and const. Also I understand how prototypical inheritance works and I know that the class syntax is just syntactic sugar, but it is a lot more readable.

ChrisSD 8y ago
Improving some of the syntax was sorely needed but I think adding classes was unhelpful. I already have a hard enough time teaching programmers about prototypical inheritance without the language actively lying to them. And it feels like an odd move in that class based OOP isn't the zeitgeist it once was. Shoehorning it in feels like a throw back to 90's and 00's.
- scarface74 8y ago
  The two most popular statically typed OOP languages for servers are still C# and Java. Besides JavaScript, the most popular scripting language is Python (let’s ignore PHP for now) which is class based. In the mobile space, Swift, Java, and now Kotlin are all class based. “The zeitgeist” is different than “what companies are paying real money for”. Besides, even with OOP based inheritance, the language is still “lying” just as much. Most developers who don’t understand how the lowest level of computers work don’t understand that when you call a function it’s always basically passing in a this pointer to one static instance of the function.
  - jerf 8y ago
    Object orientation in the sense of having some sort of data structure having some officially associated "methods" with it, and then building other structure on top of that, is alive, well, and not going anywhere any time soon despite the occasional functional programmer epiphanies. Object orientation as in "There must be classes, there must be inheritance, each method and instance value must be able to be private, public, or protected, and have official constructors and destructors" and probably a couple of other things I'm missing, is also alive and well and not going anywhere any time soon, but is no longer the only definition of Object Orientation. If you were not around at the time, you'll have to take my word for this, although the echos still reverberate in Javascript tutorials to this day (because of the way they talk about prototype-based inheritance as if you've got to be placated long enough about the fact that it isn't "true" OO long enough to learn what it actually is), but when it was released, Javascript (prior to any sort of "class" keyword) was not considered an "object oriented" language, because it didn't have "real" inheritance, or private values, etc. etc. The point is that in a world where the definition of "OO" has expanded enough to encompass the original JS, it's a bit odd to bodge on a particular definition of OO so late in the process. (People also argued back then about whether Python was object oriented (!), because it didn't have "true" support for private instances or methods. By contrast, I find it amusing when sometimes the question comes up "Is Go really Object Oriented if it has no inheritance?" and the answer generally amounts to "Honestly, who cares?")
  - slifin 8y ago
type0 8y ago
You could put callback back in the bag https://github.com/staltz/callbag-basics https://github.com/staltz/callbag-basics
tenaciousDaniel 8y ago
I agree that the class keyword is far more readable. I never find myself using them in the "classical" sense, though I could see how it would be tempting for someone coming from, say, Java.
tonto 8y ago
We are now in an intermediate hell of Babel and webpack though...the language is cool, but the toolchains are really crazy right now. Someone could dismiss my argument if they got a comfy setup but often times if you're doing even just a little trailblazing you get into some wtf territory. I spent all day this week setting up a karma test cause my node module was failing only in the browser so then I added Babel and karma-webpack, but then regenerator runtime kept giving me errors, then mixing require() and es6 import gave me insanity errors and I almost gave up. Deep googling gave me barely enough clues to get through it...
- scarface74 8y ago
  I’ve avoided any serious JavaScript development for years because of crap like this except when absolutely necessary. I’ve learned it well enough to get pass “full stack developer” interviews, but as soon as I get hired, I get migrated to the back end. I’m just now putting the finishing touches on my first Node/Express microservice for production. I’m putting off front end development for another year or so.

javasharp1 8y ago

there was nothing easy about var hoisting. modern javascript with a good linter is a lot cleaner and easier to read.

danarmak 8y ago

> Since JavaScript has an especially high burden for backward compatibility you can’t really remove old cruft You can't remove features from JS runtimes (browsers or node), but you can certainly remove them from a new language version. "use strict" already did it once in JS. It can be replaced/upgraded with "use ecmascriptX.Y" for each language version. And transpilers targeting JS and tools like packers and minifiers can enforce language versions without declaring them in each file.

WorldMaker 8y ago
"use strict" was also highly contentious for a time. "use versionNumber" would have similar issues to the battles the web fought over DOCTYPES and "quirks" modes and browser compatibility.

userbinator 8y ago

It reminds me a lot of what happened with C++ in the past few years, and in contrast to C which has basically stayed still meanwhile (I know there's C99 and C11, but a lot of code out there is still C89 --- and IMHO that's the way it should be.) I am very much against constant change in a fundamental platform. I should be able to write JS that works for decades without worrying about deprecation or any other sort of useless "churn". The less the platform changes, the more you can focus on understanding it and doing more. But of course it seems the majority of developers would rather have "new and shiny" over "old and stable", which I think is quite unfortunate. The old saying is "do more with less". What's happening now in development, especially Web, seems to be more like "do less with more".

int_19h 8y ago
JS was born a horrible language. It needs to be fixed before it becomes so entrenched that you might write code in it that has to work for decades.
- rhapsodic 8y ago
  > JS was born a horrible language. It needs to be fixed before it becomes so entrenched that you might write code in it that has to work for decades. That ship sailed long ago.

licyeus 8y ago

I've never thought of ES5 as simple, consistent, and easy to read. There are plenty of features that many devs wouldn't recognize (ie, "the bad parts"). They've fallen out of vogue because there are better ways to do things, but they're still part of the language. I, too, would love a simplification of the language, but as you mention, backwards compat is necessary. And what does `case` not do that you want it to? Fall-through? Re: forced destructuring, if you want to switch on a value, why not just wrap it in an object, eg, `case({ someVal })`? It's not perfect, but I'd prefer consistently using `case` to the confusion you call out re: `case` vs `switch`.

burlesona 8y ago
The point is that case does not currently exist, but switch does, and is fine. If we could get rid of switch and replace it with this case proposal, that might be nice, but we can’t. Having the language with both existing side by side is, to me, worse than just living with switch.

ErikAugust 8y ago

ES5 took me months to understand well. And today, after years (and now on ES6/TypeScript) I cannot always properly describe some features of ES5 without seriously reviewing them.