6 ms·

I am surprised he doesn’t like the more recent additions to JavaScript. I liked ES6 features quite a lot.

koromak 4y ago
ES6 is what makes JS bearable to write modern day. Totally don't understand his point here. Who wants endless nested promise chains?
- tombert 4y ago
  I can't speak for Crockford obviously, but my guess is that all these extra features come at the cost of making the language "bigger". I think part of the reason people liked JS in the early days was (at least if you avoided the attempt at OOP) how simple it was. You basically only had a few core types that were flexible enough to do what you needed, you worked with simple functions that worked on those core types, and you built simple abstractions on top of that. Obviously this can be a blessing or a curse depending on who's writing the code; it's not terribly hard to write yourself a spaghetti mess of chaos in JS. Callbacks lead to a mess of nested lambdas, promises are better but still a bit clunky, and trying to work within the "few core types" led to the famous "wat" video [1], so these things come in tradeoffs. Still, I see where Crockford is coming from (at least if I understand his point correctly). My interview language of choice is JavaScript, and I rarely use anything introduced from 2015 or later (except the shorthand function syntax). I like that the core language has basically no bureaucracy, and you can focus on just writing code. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
- capableweb 4y ago
  > Who wants endless nested promise chains? Believe it or not, you can actually structure things so it's "flat" looking without async/await (or even without Promises for that matter, but Promises solve other problems too). Just because someone argues against something like async/await, doesn't mean they want the thing async/await is supposed to address.
  - xhxhskrry 4y ago
- the_other 4y ago
  > Who wants endless nested promise chains? One of the things Promises solves is nesting. If you're nesting them, you're doing it wrong. (I don't mean "never nest them"... but if you find you're nesting them, see if you can refactor to "all()" them or similar)
  - WorldMaker 4y ago
    You "should" never nest them, if you create a new Promise inside a .then() callback, immediately return it and move to a new .then() callback in the chain. Promises were built to flatten. The hard part, of course, is threading complex flows of variables through your .then() callbacks where later Promise calls need a previous variable or three, and that's when a lot of people give up and just resort to deeper nesting. That's what async/await does the best at solving: capturing variables automatically in a simple state machine written like classic imperative code versus manually trying to thread state through callback closures and complex return types.
saiojd 4y ago
I've always felt there's a disconnect between two groups of people, those who use a language in their day-to-day work and those who approach it more as an object of study (i.e. academics or hobbyists). The latter view bloat as a bad thing, while it's not the biggest concern for the former (who have more pressing problems!). So for Crockford an expanding language definition is catastrophic, but for people writing web apps, if 1 new feature out of 10 very useful then it's still a huge win.
- capableweb 4y ago
  I'm not a academic nor hobbyist but work professionally with JavaScript for more than 10 years. I'm also "against" the constant syntactic sugar that gets added with little to no benefits, just leading to JavaScript having a large syntax. Why introduce "classes" which are just sugar on top of existing syntax? Many examples just like this, where sometimes it feels like JavaScript has changes just to have changes. Although I'm not gonna complain too much, many of the new features are more than just syntactic sugar and makes my life a lot easier. I just wish they were slightly more conservative I guess.
  - LordN00b 4y ago
    To take your argument to the extreme, why have for loops, when then are syntatic sugar over while loops? I'm generally a fan of syntatic sugar in a language if it's purpose is to simplify what's already there; but it is a balance between developer productivity and ease-of-use. I once saw javscript described as 'pithy', becuase of it's small syntatical footprint, that's probably not true so much now.
    - ptx 4y ago
      I believe Crockford said in a talk [1] that he was going to stop writing loops when tail-call elimination is supported everywhere. Also, avoiding the for loop in JS might be a good idea because of how easy it is to shoot yourself in the foot with "for (x in stuff) ..." creating a global variable (when you accidentally leave out "var"). [1] Probably this one? https://www.youtube.com/watch?v=XFTOG895C7c https://www.youtube.com/watch?v=XFTOG895C7c
jillesvangurp 4y ago
"The best thing we can do today to JavaScript is to retire it." I think that's a pretty interesting statement from somebody like Douglas Crockford. Not disagreeing; but still ... I think there are two ways of looking at recent changes in Javascript. Either it's progress or it's just not enough progress. I think what he is saying here is that there it has too much baggage and that there are newer and more interesting languages now. That's not such a strange thing to say for somebody that has been involved with trying to create new languages. My personal view is that browser Javascript is mostly a compilation target these days, including for Javascript itself, and that we now have a better compilation target in the form of WASM that is less awkward to target for a lot of languages as well. The question is what languages people will be using in the next years that target that. I'd say there are some interesting alternatives to choose from already and there are likely to be more in the next few years.
- tadfisher 4y ago
  Javascript has GC and tail calls, and I don't think WASM is getting either anytime soon.
  - jillesvangurp 4y ago
    The experimental Kotlin WASM uses some experimental GC related flags in chrome. That stuff is working right now and will no doubt stop being experimental at some point. Tail calls might take a bit longer but there are probably people working on that too. But there are probably ways around that. WASM is already useful today and will incrementally get more useful over the next few years.
  - johnfarrelldev 4y ago
    I'm not sure about other engines but V8 the most popular JS engine does not implement tail calls.
  - dragonwriter 4y ago
    Isn't not efficiently implementing tail calls a current JS standard (in that implementing them means your implementation is technically broken) specifically to prevent software from relying on that optimization?
nicoburns 4y ago
The ES6 additions were great. It's the ones post ES6 (like private fields) which are becoming increasingly questionable.

ES6 is what makes JS bearable to write modern day. Totally don't understand his point here. Who wants endless nested promise chains?

tombert 4y ago
I can't speak for Crockford obviously, but my guess is that all these extra features come at the cost of making the language "bigger". I think part of the reason people liked JS in the early days was (at least if you avoided the attempt at OOP) how simple it was. You basically only had a few core types that were flexible enough to do what you needed, you worked with simple functions that worked on those core types, and you built simple abstractions on top of that. Obviously this can be a blessing or a curse depending on who's writing the code; it's not terribly hard to write yourself a spaghetti mess of chaos in JS. Callbacks lead to a mess of nested lambdas, promises are better but still a bit clunky, and trying to work within the "few core types" led to the famous "wat" video [1], so these things come in tradeoffs. Still, I see where Crockford is coming from (at least if I understand his point correctly). My interview language of choice is JavaScript, and I rarely use anything introduced from 2015 or later (except the shorthand function syntax). I like that the core language has basically no bureaucracy, and you can focus on just writing code. [1] https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
capableweb 4y ago
> Who wants endless nested promise chains? Believe it or not, you can actually structure things so it's "flat" looking without async/await (or even without Promises for that matter, but Promises solve other problems too). Just because someone argues against something like async/await, doesn't mean they want the thing async/await is supposed to address.
- xhxhskrry 4y ago
the_other 4y ago
> Who wants endless nested promise chains? One of the things Promises solves is nesting. If you're nesting them, you're doing it wrong. (I don't mean "never nest them"... but if you find you're nesting them, see if you can refactor to "all()" them or similar)
- WorldMaker 4y ago
  You "should" never nest them, if you create a new Promise inside a .then() callback, immediately return it and move to a new .then() callback in the chain. Promises were built to flatten. The hard part, of course, is threading complex flows of variables through your .then() callbacks where later Promise calls need a previous variable or three, and that's when a lot of people give up and just resort to deeper nesting. That's what async/await does the best at solving: capturing variables automatically in a simple state machine written like classic imperative code versus manually trying to thread state through callback closures and complex return types.

saiojd 4y ago

I've always felt there's a disconnect between two groups of people, those who use a language in their day-to-day work and those who approach it more as an object of study (i.e. academics or hobbyists). The latter view bloat as a bad thing, while it's not the biggest concern for the former (who have more pressing problems!). So for Crockford an expanding language definition is catastrophic, but for people writing web apps, if 1 new feature out of 10 very useful then it's still a huge win.

capableweb 4y ago
I'm not a academic nor hobbyist but work professionally with JavaScript for more than 10 years. I'm also "against" the constant syntactic sugar that gets added with little to no benefits, just leading to JavaScript having a large syntax. Why introduce "classes" which are just sugar on top of existing syntax? Many examples just like this, where sometimes it feels like JavaScript has changes just to have changes. Although I'm not gonna complain too much, many of the new features are more than just syntactic sugar and makes my life a lot easier. I just wish they were slightly more conservative I guess.
- LordN00b 4y ago
  To take your argument to the extreme, why have for loops, when then are syntatic sugar over while loops? I'm generally a fan of syntatic sugar in a language if it's purpose is to simplify what's already there; but it is a balance between developer productivity and ease-of-use. I once saw javscript described as 'pithy', becuase of it's small syntatical footprint, that's probably not true so much now.
  - ptx 4y ago
    I believe Crockford said in a talk [1] that he was going to stop writing loops when tail-call elimination is supported everywhere. Also, avoiding the for loop in JS might be a good idea because of how easy it is to shoot yourself in the foot with "for (x in stuff) ..." creating a global variable (when you accidentally leave out "var"). [1] Probably this one? https://www.youtube.com/watch?v=XFTOG895C7c https://www.youtube.com/watch?v=XFTOG895C7c

jillesvangurp 4y ago

"The best thing we can do today to JavaScript is to retire it." I think that's a pretty interesting statement from somebody like Douglas Crockford. Not disagreeing; but still ... I think there are two ways of looking at recent changes in Javascript. Either it's progress or it's just not enough progress. I think what he is saying here is that there it has too much baggage and that there are newer and more interesting languages now. That's not such a strange thing to say for somebody that has been involved with trying to create new languages. My personal view is that browser Javascript is mostly a compilation target these days, including for Javascript itself, and that we now have a better compilation target in the form of WASM that is less awkward to target for a lot of languages as well. The question is what languages people will be using in the next years that target that. I'd say there are some interesting alternatives to choose from already and there are likely to be more in the next few years.

tadfisher 4y ago
Javascript has GC and tail calls, and I don't think WASM is getting either anytime soon.
- jillesvangurp 4y ago
  The experimental Kotlin WASM uses some experimental GC related flags in chrome. That stuff is working right now and will no doubt stop being experimental at some point. Tail calls might take a bit longer but there are probably people working on that too. But there are probably ways around that. WASM is already useful today and will incrementally get more useful over the next few years.
- johnfarrelldev 4y ago
  I'm not sure about other engines but V8 the most popular JS engine does not implement tail calls.
- dragonwriter 4y ago
  Isn't not efficiently implementing tail calls a current JS standard (in that implementing them means your implementation is technically broken) specifically to prevent software from relying on that optimization?

nicoburns 4y ago

The ES6 additions were great. It's the ones post ES6 (like private fields) which are becoming increasingly questionable.