5 ms·

Is he talking about the old < ES5 javascript or the new ES6+ with WebAPI standards? Because to me, it's quite remarkable how JavaScript has evolved since < ES5

Is he talking about the old < ES5 javascript or the new ES6+ with WebAPI standards? Because to me, it's quite remarkable how JavaScript has evolved since < ES5. ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. It's way more developer friendly when writing new stuff than it used to be. Not to mention, the integration with Web APIs has been a game changer. Fetch API, WebSockets, Web Storage, WebRTC and Service Workers, WebAssembly really enables a lot of functionality that's all easy to use and very fast. TypeScript also helps with gradual typing together with syntax highlighting and lookups are superb for avoiding unexpected mutations and a lot easier re-factoring. Also, what do he suggest would be the replacement? Because it's not enough to replace the scripting language, it would need to fit into the DOM, HTML and CSS too.

yakshaving_jgt 3y ago
> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.
- horsawlarway 3y ago
  > All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded context) It has the same warts that literally every production language accumulates: some operators are overloaded in ways that make for wacky edge-cases, some features were introduced by not great, and so they still exist but mostly gather dust. JS also has some really incredible work put into it - --- > ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. --- Frankly - I understand that increasing language complexity is sometimes not the right call - but I think the vast majority of the features you just poo-pooed are pretty damn nice. I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up (otherwise - I sort of mind the classes, at least when not using TS). What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime - that's not something all that many enterprise languages can attest to, and it's that same flexibility and simple extensivity that has allowed JS to continue to grow. Following on: JS (and browsers in general) are actually one of the absolute wins for software freedom (free as in freedom, not as in beer) because absolutely everything is shipped to you in inspectable and modifiable payloads. I can and have edited JS/html/css to make broken sites work. My single biggest complaint about WASM is that we lose this property for websites, and I think that's a pretty huge fucking loss.
  - toastercat 3y ago
    > I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. > What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime Funny enough, this sounds a lot like something Crockford would say. I think Crockford's main gripe with JS these days is that TC39 is more concerned with adding superfluous features than cleaning up footguns. There is a video from 2018 where he goes through some of the more popular ES6 features and mentioned which ones he likes/dislikes. [1] [1] https://www.youtube.com/watch?v=XFTOG895C7c https://www.youtube.com/watch?v=XFTOG895C7c
    - horsawlarway 3y ago
      > This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. Because Crockford was one of the people advocating for a particular style of initialization of objects that mirrored classes, but was not directly a class before classes existed in JS. (see: https://crockford.com/javascript/inheritance.html https://crockford.com/javascript/inheritance.html) It is utterly enterprise and classlike in nature though, and not my cup of tea. Mainly - I just wanted enterprise folks to stop trying to re-invent classes in the language, and the class keyword stopped that behavior. Big net win for the language in my opinion - even though I personally still don't use classes all that often. --- His modern take is fairly reasonable, though.
      - JBits 3y ago
        His modern take, advocating prototypes, has been around since 2006 (https://crockford.com/javascript/prototypal.html https://crockford.com/javascript/prototypal.html).
        horsawlarway 3y ago
        I know - I just keep getting older... hard to believe that was nearly 20 years back now, and not 20 months.
- leetharris 3y ago
  What exactly is "broken" about the foundation of JS? I hear this all the time and people can never back it up. It is extremely performant for a scripting language, it is easy to debug, and it works in many scenarios. People try too hard to be contrarian. Same thing happened with PHP and many other languages.
  - yakshaving_jgt 3y ago
    Have you ever read JavaScript: The Good Parts? It does a great job of describing lots of broken bits. More specifically, a few things that I think are pretty bad off the top of my head: - Implicit type coercion - Confusing scope binding, i.e., `this`, `bind`, etc. - Inconsistent Array API — some methods return a new value; some methods mutate the value![0] - `['1', '7', '11'].map(parseInt)` …lol?! Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension. [0]: I've actually spoken with Brendan Eich about this one, and he conceded it wasn't a good idea. IIRC, he was just copying what Perl did.
    - horsawlarway 3y ago
      > Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension. Maybe your argument just isn't that great? I mean - look, I've worked in a LOT of languages now in the 25 years I've been writing code. Js is certainly no bastion of language perfection, but it's also sure as fuck not on shaky foundations. Almost all of your criticism basically boil down to: JS won't break backwards compatibility for me! WAHHHHH! Because none of your examples are really issues: - Implicit type coercion. happens in a lot of languages - keep a table around if you need it. - Confusing scope binding, i.e., `this`, `bind`, etc. this is literally core to the language - it's not any more confusing than learning about the difference between class definition vs an object instance. - Inconsistent Array API — some methods return a new value; some methods mutate the value![0]. This is a fair complaint - but all the functions that mutate have non-mutating versions now - JS just won't break compatibility for you by removing the old ones... "WAH!") - `['1', '7', '11'].map(parseInt)` …lol?! You know damn well what you're doing Mr radix. Variadic languages have some edge cases. If you don't like it, use Number like a sane person: ['1', '7', '11'].map(Number) ParseInt is usually not what you want, but again... JS won't break compatibility for you - that doesn't mean the foundation is shaky... It just means that some parts are older than others.
- peferron 3y ago
  > All of this has made the language worse. Just accreting features doesn't make the foundation less broken. Nope, most of these have made the language better. Optional chaining is better than a litany of `&&`, `...` is generally better than `Object.assign` or `concat`, `async/await` are generally better than callbacks... The list goes on. Rejecting these new features wouldn't have magically improved the foundation.
- cies 3y ago
  > Just accreting features doesn't make the foundation less broken. That's indeed the gist of Douglas' remark. But if you have not much experience beyond JS, that is very hard to recognize. Douglas is grey and old. Most JS devs are on the younger side of the IT work force.

yakshaving_jgt 3y ago

> ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. All of this has made the language worse. Just accreting features doesn't make the foundation less broken.

horsawlarway 3y ago
> All of this has made the language worse. Just accreting features doesn't make the foundation less broken. I see this view a lot - what I rarely ever see is a concrete discussion about what exactly is wrong with the "foundation" of javascript. Because to me... Javascript is actually a decent-ish solution to the UI space (it nicely balances reactivity and code complexity by presenting an event driven, single threaded context) It has the same warts that literally every production language accumulates: some operators are overloaded in ways that make for wacky edge-cases, some features were introduced by not great, and so they still exist but mostly gather dust. JS also has some really incredible work put into it - --- > ES6+ introduced a slew of features like arrow functions, template literals, async/await, destructuring, classes, enhanced object literals and native modules. This is the problem. --- Frankly - I understand that increasing language complexity is sometimes not the right call - but I think the vast majority of the features you just poo-pooed are pretty damn nice. I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up (otherwise - I sort of mind the classes, at least when not using TS). What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime - that's not something all that many enterprise languages can attest to, and it's that same flexibility and simple extensivity that has allowed JS to continue to grow. Following on: JS (and browsers in general) are actually one of the absolute wins for software freedom (free as in freedom, not as in beer) because absolutely everything is shipped to you in inspectable and modifiable payloads. I can and have edited JS/html/css to make broken sites work. My single biggest complaint about WASM is that we lose this property for websites, and I think that's a pretty huge fucking loss.
- toastercat 3y ago
  > I don't even mind the classes - just because it makes Crockford and the other enterprise java folks shut up This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. > What I do find particularly impressive is how flexible JS is, and how much support can be added without actually changing the runtime Funny enough, this sounds a lot like something Crockford would say. I think Crockford's main gripe with JS these days is that TC39 is more concerned with adding superfluous features than cleaning up footguns. There is a video from 2018 where he goes through some of the more popular ES6 features and mentioned which ones he likes/dislikes. [1] [1] https://www.youtube.com/watch?v=XFTOG895C7c https://www.youtube.com/watch?v=XFTOG895C7c
  - horsawlarway 3y ago
    > This is the second time I've seen in this thread that people lump Crockford in with Java enterprise folks, but Crockford routinely says `class` was the worst addition to JS. Because Crockford was one of the people advocating for a particular style of initialization of objects that mirrored classes, but was not directly a class before classes existed in JS. (see: https://crockford.com/javascript/inheritance.html https://crockford.com/javascript/inheritance.html) It is utterly enterprise and classlike in nature though, and not my cup of tea. Mainly - I just wanted enterprise folks to stop trying to re-invent classes in the language, and the class keyword stopped that behavior. Big net win for the language in my opinion - even though I personally still don't use classes all that often. --- His modern take is fairly reasonable, though.
    - JBits 3y ago
      His modern take, advocating prototypes, has been around since 2006 (https://crockford.com/javascript/prototypal.html https://crockford.com/javascript/prototypal.html).
      - horsawlarway 3y ago
        I know - I just keep getting older... hard to believe that was nearly 20 years back now, and not 20 months.
leetharris 3y ago
What exactly is "broken" about the foundation of JS? I hear this all the time and people can never back it up. It is extremely performant for a scripting language, it is easy to debug, and it works in many scenarios. People try too hard to be contrarian. Same thing happened with PHP and many other languages.
- yakshaving_jgt 3y ago
  Have you ever read JavaScript: The Good Parts? It does a great job of describing lots of broken bits. More specifically, a few things that I think are pretty bad off the top of my head: - Implicit type coercion - Confusing scope binding, i.e., `this`, `bind`, etc. - Inconsistent Array API — some methods return a new value; some methods mutate the value![0] - `['1', '7', '11'].map(parseInt)` …lol?! Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension. [0]: I've actually spoken with Brendan Eich about this one, and he conceded it wasn't a good idea. IIRC, he was just copying what Perl did.
  - horsawlarway 3y ago
    > Maybe you shouldn't be so quick to jump to this conclusion that any criticism of your pet technology comes from a place of ignorance or pretension. Maybe your argument just isn't that great? I mean - look, I've worked in a LOT of languages now in the 25 years I've been writing code. Js is certainly no bastion of language perfection, but it's also sure as fuck not on shaky foundations. Almost all of your criticism basically boil down to: JS won't break backwards compatibility for me! WAHHHHH! Because none of your examples are really issues: - Implicit type coercion. happens in a lot of languages - keep a table around if you need it. - Confusing scope binding, i.e., `this`, `bind`, etc. this is literally core to the language - it's not any more confusing than learning about the difference between class definition vs an object instance. - Inconsistent Array API — some methods return a new value; some methods mutate the value![0]. This is a fair complaint - but all the functions that mutate have non-mutating versions now - JS just won't break compatibility for you by removing the old ones... "WAH!") - `['1', '7', '11'].map(parseInt)` …lol?! You know damn well what you're doing Mr radix. Variadic languages have some edge cases. If you don't like it, use Number like a sane person: ['1', '7', '11'].map(Number) ParseInt is usually not what you want, but again... JS won't break compatibility for you - that doesn't mean the foundation is shaky... It just means that some parts are older than others.
peferron 3y ago
> All of this has made the language worse. Just accreting features doesn't make the foundation less broken. Nope, most of these have made the language better. Optional chaining is better than a litany of `&&`, `...` is generally better than `Object.assign` or `concat`, `async/await` are generally better than callbacks... The list goes on. Rejecting these new features wouldn't have magically improved the foundation.
cies 3y ago
> Just accreting features doesn't make the foundation less broken. That's indeed the gist of Douglas' remark. But if you have not much experience beyond JS, that is very hard to recognize. Douglas is grey and old. Most JS devs are on the younger side of the IT work force.