5 ms·

Interesting. I had no idea he had transitioned from promoting Javascript's good parts to calling for its retirement. I started to get a bad feeling when the c

Interesting. I had no idea he had transitioned from promoting Javascript's good parts to calling for its retirement. I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there.

tombert 4y ago
Yeah, but the problem is that people will still use the new parts too. I never really liked any of the JS's attempts at OOP, be it the original prototype-based or the newer class-based, but I think that people were sufficiently confused enough by the prototype system that most people didn't bother with it. The class stuff is more approachable, and for some people that can sort of be viewed as a bad thing.
- irrational 4y ago
  The newer class based IS the original prototype based. Class is literally just syntactic sugar on top of prototype inheritance. It was just added to help people coming from true OOP languages to feel comfortable. Notice, for instance, in Java the class acts as a blueprint for the object. You can’t have the object without the class. Not so in JS. The class is just window dressing and is not required at all.
  - corrral 4y ago
    Sure, but in practice most people ignore the prototypal features, especially if they're using the "class" keyword, so it may as well not be prototypal. Which is good, because the distinctly prototypal pieces are usually bad behaviors to rely on. The wrong kind of magic.
  - ElectricalUnion 4y ago
    Most of this seems reasonably on point except for > true OOP languages Specifically the Java used as a example isn't exactly a "true OOP language" either; in a sense it's actually a very leaky imperative VM with implementation details like non-object Primitive Data Types and very visible and prominent imperative flow control structures. Javascript is much closer to an actual "true OOP language" as, unless you're dealing with bad/naive bindings to other stuff in C, it's very hard to even get a handle of a non-object.
eyelidlessness 4y ago
I vastly prefer functional programming to OOP. But I find my use of `class` in JS increasing for two reasons orthogonal to the paradigm distinction: 1. Particularly in pure JS projects which either haven’t yet or won’t migrate to TypeScript, classes are an excellent way to define data types. They needn’t be stateful, they can be used just like POJOs in otherwise pure functional code. But their shape is clear (or can/should be), and can be used as both types and runtime references without a lot of ceremony. 2. Classes, when they have a clear shape, are great for performance-sensitive code. POJOs can achieve this, but it’s frequently all too easy for their shape to evolve as a codebase is in maintenance. And that can cause hard to find performance regressions.
- zdragnar 4y ago
  Using runtime classes can also be handy if you're willing to use `instanceof` (or the speedier constructor comparison) to disambiguate between types, such as when you want to branch on Left/Right in an Either, or None/Just in a Maybe, or Error/Success in a Result, etc.
- gavinray 4y ago
  Seconding this
- WorldMaker 4y ago
  I also tend to prefer functional programming to OOP in JS, but there's a massive legacy of OOP in JS. The `class` syntax really is just syntactic sugar for classic IIFE-wrapped `.prototype.` JS OOP. You can pass modern classes to ancient JS OOP libraries like for instance Dojo and there's sometimes few things quite as satisfying when upgrading legacy code as replacing the classic legacy spaghetti Dojo class definition IIFE with a much simpler `class SomeLegacyWidget extends DojoWidget {}`. Almost no one even needs to know what an IIFE even is or stands for today. It's great. That `class` syntax works in all the modern browsers today, no Typescript transpile or Babel plugin or "polyfill" needed. (Dojo comes to mind because of doing code on current ArcGIS-related projects that are still stuck in the mines of ancient Dojo versions, IIFE "classes", and AMD wrappers. Still great to have Typescript generate the AMD wrappers for you from modern ES2015 module syntax, but `class` and even `await/async` you can get for "free" in modern browsers and are huge clarifying changes to legacy Dojo work.)
lucideer 4y ago
> I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there. I actually like many of the new parts - the class keyword being a notable exception. The other (much much milder) exception is async/await syntax - I love Promises but the async/await sugar on top of it this seems a little too much like magic. At the end of the day, they're still just Promises, just weirdly abstracted (just as classes are still just prototypes, just obscured so they look like something they're not). The odd thing imo about the class keyword is it doesn't even seem to "fit" with the direction of may of the other new changes. E.g. arrow-functions are a very un-classy simplified functional form (no this re-assignment). This is very evident in the direction of many frameworks - e.g. React quickly moved to using classes (extends React.Component) and then quickly moved away from that convention (function components) as if realising their mistake.
- hajile 4y ago
  I think async/await could perhaps have been better used as more general threading primitives to shift the language more toward multithreading. I do like them in comparison to raw promises though.
  - lucideer 4y ago
    > I do like them in comparison to raw promises though. Promises can get a little unwieldy raw - working on making that easier is a noble goal. But I'm never a fan of systems that actively obscure how something works. We now have plenty of people throwing asyncs and awaits around their code without a clue about how Promises work. It's significantly easier to learn how specific control flows work while writing raw Promises.

tombert 4y ago

Yeah, but the problem is that people will still use the new parts too. I never really liked any of the JS's attempts at OOP, be it the original prototype-based or the newer class-based, but I think that people were sufficiently confused enough by the prototype system that most people didn't bother with it. The class stuff is more approachable, and for some people that can sort of be viewed as a bad thing.

irrational 4y ago
The newer class based IS the original prototype based. Class is literally just syntactic sugar on top of prototype inheritance. It was just added to help people coming from true OOP languages to feel comfortable. Notice, for instance, in Java the class acts as a blueprint for the object. You can’t have the object without the class. Not so in JS. The class is just window dressing and is not required at all.
- corrral 4y ago
  Sure, but in practice most people ignore the prototypal features, especially if they're using the "class" keyword, so it may as well not be prototypal. Which is good, because the distinctly prototypal pieces are usually bad behaviors to rely on. The wrong kind of magic.
- ElectricalUnion 4y ago
  Most of this seems reasonably on point except for > true OOP languages Specifically the Java used as a example isn't exactly a "true OOP language" either; in a sense it's actually a very leaky imperative VM with implementation details like non-object Primitive Data Types and very visible and prominent imperative flow control structures. Javascript is much closer to an actual "true OOP language" as, unless you're dealing with bad/naive bindings to other stuff in C, it's very hard to even get a handle of a non-object.

eyelidlessness 4y ago

I vastly prefer functional programming to OOP. But I find my use of `class` in JS increasing for two reasons orthogonal to the paradigm distinction: 1. Particularly in pure JS projects which either haven’t yet or won’t migrate to TypeScript, classes are an excellent way to define data types. They needn’t be stateful, they can be used just like POJOs in otherwise pure functional code. But their shape is clear (or can/should be), and can be used as both types and runtime references without a lot of ceremony. 2. Classes, when they have a clear shape, are great for performance-sensitive code. POJOs can achieve this, but it’s frequently all too easy for their shape to evolve as a codebase is in maintenance. And that can cause hard to find performance regressions.

zdragnar 4y ago
Using runtime classes can also be handy if you're willing to use `instanceof` (or the speedier constructor comparison) to disambiguate between types, such as when you want to branch on Left/Right in an Either, or None/Just in a Maybe, or Error/Success in a Result, etc.
gavinray 4y ago
Seconding this
WorldMaker 4y ago
I also tend to prefer functional programming to OOP in JS, but there's a massive legacy of OOP in JS. The `class` syntax really is just syntactic sugar for classic IIFE-wrapped `.prototype.` JS OOP. You can pass modern classes to ancient JS OOP libraries like for instance Dojo and there's sometimes few things quite as satisfying when upgrading legacy code as replacing the classic legacy spaghetti Dojo class definition IIFE with a much simpler `class SomeLegacyWidget extends DojoWidget {}`. Almost no one even needs to know what an IIFE even is or stands for today. It's great. That `class` syntax works in all the modern browsers today, no Typescript transpile or Babel plugin or "polyfill" needed. (Dojo comes to mind because of doing code on current ArcGIS-related projects that are still stuck in the mines of ancient Dojo versions, IIFE "classes", and AMD wrappers. Still great to have Typescript generate the AMD wrappers for you from modern ES2015 module syntax, but `class` and even `await/async` you can get for "free" in modern browsers and are huge clarifying changes to legacy Dojo work.)

lucideer 4y ago

> I started to get a bad feeling when the class keyword became popular, but all of the old good parts are still there. I actually like many of the new parts - the class keyword being a notable exception. The other (much much milder) exception is async/await syntax - I love Promises but the async/await sugar on top of it this seems a little too much like magic. At the end of the day, they're still just Promises, just weirdly abstracted (just as classes are still just prototypes, just obscured so they look like something they're not). The odd thing imo about the class keyword is it doesn't even seem to "fit" with the direction of may of the other new changes. E.g. arrow-functions are a very un-classy simplified functional form (no this re-assignment). This is very evident in the direction of many frameworks - e.g. React quickly moved to using classes (extends React.Component) and then quickly moved away from that convention (function components) as if realising their mistake.

hajile 4y ago
I think async/await could perhaps have been better used as more general threading primitives to shift the language more toward multithreading. I do like them in comparison to raw promises though.
- lucideer 4y ago
  > I do like them in comparison to raw promises though. Promises can get a little unwieldy raw - working on making that easier is a noble goal. But I'm never a fan of systems that actively obscure how something works. We now have plenty of people throwing asyncs and awaits around their code without a clue about how Promises work. It's significantly easier to learn how specific control flows work while writing raw Promises.