4 ms·

> Less that 10 years ago, JavaScript sucked bad. It had no imports, no classes, no async, no arrow functions No classes in JS was much better than with. As som

> Less that 10 years ago, JavaScript sucked bad. It had no imports, no classes, no async, no arrow functions No classes in JS was much better than with. As someone who used and contributed to CoffeeScript, I was initially excited by them but in retrospect, they've been a huge negative IMO. Douglas Crockford saw it immediately: https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=300s https://www.youtube.com/watch?v=PSGEjv3Tqo0&t=300s

moron4hire 3y ago
I'm so sick of these paradigm religious wars. There's nothing wrong with object oriented programming. There's nothing wrong with functional, either. You use them for different purposes. These people like Crockford who talk about "Java programmers are stuck in this inferior way" are the ones who are stuck and not all that educated on programming.
- AlchemistCamp 3y ago
  There's also a lot to be said for having fewer footguns. One reason I liked CoffeeScript is that it actually removed JS footguns such as "with", ==, etc. I'd rather either Clojure or Java to using Scala and having all the possible complexity and interactions between paradigms it makes possible. Sometimes less is more.
- suzzer99 3y ago
  Wait until you have to maintain someone else's overly crufty, inheritance-based JS framework.
  - moron4hire 3y ago
    There's nothing wrong with inheritance, even in JavaScript.
- lobstrosity420 3y ago
  They weren’t criticizing OOP per se. Before the class keyword, JavaScript had much more powerful OOP semantics using metaobjects.
  - jdlshore 3y ago
    The class keyword is just syntactic sugar. JS still uses prototypal inheritance. Nothing has changed. Check out objectplayground.com for details.
    - lobstrosity420 3y ago
      Not ‘nothing’ has changed. Classes are supposed to be syntactic sugar over constructor functions, but the later could be invoked as well as instantiated with the ‘new’ keyword, whereas the interpreter will error out on you if you attempt to invoke a class. That is fine though, I don’t care for constructor functions. I was talking about using metaobjects, a different concept altogether.
      - jdlshore 3y ago
        Okay, I think I get your complaint. JavaScript doesn’t have a metaobject protocol, but there were a variety of user-land approaches to OOP that added one. Although they’re still technically possible, the class syntax formalized a non-MOP approach to OOP, and those third-party tools have all fallen by the wayside. It’s not so much that you can’t use a MOP in JS, so much that people don’t, and will look at you funny if you do. As a lover of simple and straightforward code, I never used the MOPs—I hand-coded “class.prototype.method = function()” like God intended*—and I’m happy the standard uses that more traditional approach. But I can see how someone who did use a MOP would feel that the class syntax is a step backwards. *that’s a joke.
        lobstrosity420 3y ago
        Yes, this is it. The MOP approach basically involves using ‘Object.assign’ to instantiate new objects from the metaobject. It is quite straightforward in my opinion, but that is relative I suppose. I don’t know if this is true but I’ve been told that Brendan Eich intended for this exact approach to be the one and true OOP in JS, but was persuaded by his boss to implement constructor functions to make it more like Java.
hot_gril 3y ago
Yeah, I write all my new stuff in JS (React frontend, Node backend) and have never felt the need for defining my own classes. Wasn't actively avoiding them either. React was fully centered around classes and they ditched all that in the new hooks system. I also don't understand the big deal with arrow functions. Yeah I use them, but they're basically regular functions except slightly shorter to write. `async` was a big improvement, though.
- jfengel 3y ago
  Arrow functions have less-incomprehensible semantics of what "this" means. Though that's less important if you're not using the classes. Most users just use arrow functions as syntactic sugar. But it's really good syntactic sugar.
suzzer99 3y ago
That just described how I feel about Typescript - created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. I was a Java dev for a decade. It's so much more tedious and less fun than programming in Javascript. I get Java recruiting emails and I shudder. I accept that in gigantic apps worked on by multiple teams, and libraries shared with 3rd parties, Typescript makes sense. But 90% of the time I see it used it's with a smallish node app or SPA worked on by a few people, and all Typescript does is slow things down. I feel like I can count on one hand the number of times I've gotten burnt by a run-time JS bug that a compiler would have caught. I just don't see that as a strong use case for the overhead and development drag of TS. I only see sharing lib-ish code across teams as a net benefit of TS. 99% of the time when the TS IDE complains over something that a JS linter wouldn't have caught, it's just because something wasn't defined properly in TS, not because it's an actual error in the code.
- toastercat 3y ago
  > That just described how I feel about Typescript - created by Java programmers Close! C# programmers. :)
  - deleted 3y ago
    [deleted]
- okeuro49 3y ago
  > created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. Well... C# .Net developers, as Microsoft found, correctly, that you can't build complex products easily with a lack of types. I also don't think many program in vanilla Javascript; it seems everyone is using JSX.
  - capableweb 3y ago
    Are you really trying to say people couldn't build complex apps before TypeScript? I know of hundreds of examples that were made before TS... Complex apps still had lots of tests, which basically solve the same problem as TS is trying to address, without having to write a different language than what gets run by the browsers.
WorldMaker 3y ago
> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail from MOO Tools to YUI to Backbone to…) ES2015 class syntax just standardized already common patterns and increased interoperability and cleaned up a lot of footguns regarding Prototype-style inheritance along a "garden path". The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.
- pier25 3y ago
  > The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced. I agree. Honestly I don't understand the obsession some people in the JS world have against classes. React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r... Of course I know I'm in the minority here.
  - schwartzworld 3y ago
    It's because they have been bitten by inheritance issues. Classes are great as long as you limit or avoid inheritance altogether. They work so nice with typescript.
    - WorldMaker 3y ago
      Relatedly, it's also because of multi-inheritance issues specifically. React built hooks in part to handle cross-cutting concerns that needed some form of multi-inheritance (mixins and "higher-order components" which themselves were often something of a hack around the existence of strong JS mixin libraries/standards/best practices/meta-programming). The best hooks are an improvement over their HOC counterparts (and many of their mixin counterparts): better Typescript types, fewer footguns, fewer composability limits (HOCs had stack problems where stack them in the wrong order and they broke or interfered with each other), easier to reason about (even given the weird learning curve of hooks in general, as black box "units" they have simpler mechanics and APIs than HOCs ever did). To be fair, you can build a lot of React components without ever feeling a need for something like an HOC and never deal with some of the inheritance problems that Hooks were built to solve so some of that "classes are a better way to write components" feeling is that one has never quite before had the multi-inheritance itch to scratch that Hooks solves for. It's obviously hard to judge a tool when you don't know if you've had the problem it solves for or not.

moron4hire 3y ago

I'm so sick of these paradigm religious wars. There's nothing wrong with object oriented programming. There's nothing wrong with functional, either. You use them for different purposes. These people like Crockford who talk about "Java programmers are stuck in this inferior way" are the ones who are stuck and not all that educated on programming.

AlchemistCamp 3y ago
There's also a lot to be said for having fewer footguns. One reason I liked CoffeeScript is that it actually removed JS footguns such as "with", ==, etc. I'd rather either Clojure or Java to using Scala and having all the possible complexity and interactions between paradigms it makes possible. Sometimes less is more.
suzzer99 3y ago
Wait until you have to maintain someone else's overly crufty, inheritance-based JS framework.
- moron4hire 3y ago
  There's nothing wrong with inheritance, even in JavaScript.
lobstrosity420 3y ago
They weren’t criticizing OOP per se. Before the class keyword, JavaScript had much more powerful OOP semantics using metaobjects.
- jdlshore 3y ago
  The class keyword is just syntactic sugar. JS still uses prototypal inheritance. Nothing has changed. Check out objectplayground.com for details.
  - lobstrosity420 3y ago
    Not ‘nothing’ has changed. Classes are supposed to be syntactic sugar over constructor functions, but the later could be invoked as well as instantiated with the ‘new’ keyword, whereas the interpreter will error out on you if you attempt to invoke a class. That is fine though, I don’t care for constructor functions. I was talking about using metaobjects, a different concept altogether.
    - jdlshore 3y ago
      Okay, I think I get your complaint. JavaScript doesn’t have a metaobject protocol, but there were a variety of user-land approaches to OOP that added one. Although they’re still technically possible, the class syntax formalized a non-MOP approach to OOP, and those third-party tools have all fallen by the wayside. It’s not so much that you can’t use a MOP in JS, so much that people don’t, and will look at you funny if you do. As a lover of simple and straightforward code, I never used the MOPs—I hand-coded “class.prototype.method = function()” like God intended*—and I’m happy the standard uses that more traditional approach. But I can see how someone who did use a MOP would feel that the class syntax is a step backwards. *that’s a joke.
      - lobstrosity420 3y ago
        Yes, this is it. The MOP approach basically involves using ‘Object.assign’ to instantiate new objects from the metaobject. It is quite straightforward in my opinion, but that is relative I suppose. I don’t know if this is true but I’ve been told that Brendan Eich intended for this exact approach to be the one and true OOP in JS, but was persuaded by his boss to implement constructor functions to make it more like Java.

hot_gril 3y ago

Yeah, I write all my new stuff in JS (React frontend, Node backend) and have never felt the need for defining my own classes. Wasn't actively avoiding them either. React was fully centered around classes and they ditched all that in the new hooks system. I also don't understand the big deal with arrow functions. Yeah I use them, but they're basically regular functions except slightly shorter to write. `async` was a big improvement, though.

jfengel 3y ago
Arrow functions have less-incomprehensible semantics of what "this" means. Though that's less important if you're not using the classes. Most users just use arrow functions as syntactic sugar. But it's really good syntactic sugar.

suzzer99 3y ago

That just described how I feel about Typescript - created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. I was a Java dev for a decade. It's so much more tedious and less fun than programming in Javascript. I get Java recruiting emails and I shudder. I accept that in gigantic apps worked on by multiple teams, and libraries shared with 3rd parties, Typescript makes sense. But 90% of the time I see it used it's with a smallish node app or SPA worked on by a few people, and all Typescript does is slow things down. I feel like I can count on one hand the number of times I've gotten burnt by a run-time JS bug that a compiler would have caught. I just don't see that as a strong use case for the overhead and development drag of TS. I only see sharing lib-ish code across teams as a net benefit of TS. 99% of the time when the TS IDE complains over something that a JS linter wouldn't have caught, it's just because something wasn't defined properly in TS, not because it's an actual error in the code.

toastercat 3y ago
> That just described how I feel about Typescript - created by Java programmers Close! C# programmers. :)
- deleted 3y ago
  [deleted]
okeuro49 3y ago
> created by Java programmers so that they can feel comfortable and not have to learn how to program in Javascript. Well... C# .Net developers, as Microsoft found, correctly, that you can't build complex products easily with a lack of types. I also don't think many program in vanilla Javascript; it seems everyone is using JSX.
- capableweb 3y ago
  Are you really trying to say people couldn't build complex apps before TypeScript? I know of hundreds of examples that were made before TS... Complex apps still had lots of tests, which basically solve the same problem as TS is trying to address, without having to write a different language than what gets run by the browsers.

WorldMaker 3y ago

> No classes in JS was much better than with. I think you experienced a different JS than I did. JS has always had classes, they were just "harder" to build/use and every "Framework" had a different mixed bag of "utilities" and patterns to work with it and they weren't always compatible. (Mixing jQuery style classes and Dojo style classes was "fun", for two random examples. I could go on all day about the long tail from MOO Tools to YUI to Backbone to…) ES2015 class syntax just standardized already common patterns and increased interoperability and cleaned up a lot of footguns regarding Prototype-style inheritance along a "garden path". The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced.

pier25 3y ago
> The class syntax garden path is much nicer than the weed-filled hedge maze it mostly replaced. I agree. Honestly I don't understand the obsession some people in the JS world have against classes. React components with state made more sense with classes than hooks. And yeah some people argue hooks are composable yada yada but if you need a React expert to write a useInterval hook to use a fundamental language feature, then maybe the model is not a great idea to begin with. https://overreacted.io/making-setinterval-declarative-with-react-hooks/ https://overreacted.io/making-setinterval-declarative-with-r... Of course I know I'm in the minority here.
- schwartzworld 3y ago
  It's because they have been bitten by inheritance issues. Classes are great as long as you limit or avoid inheritance altogether. They work so nice with typescript.
  - WorldMaker 3y ago
    Relatedly, it's also because of multi-inheritance issues specifically. React built hooks in part to handle cross-cutting concerns that needed some form of multi-inheritance (mixins and "higher-order components" which themselves were often something of a hack around the existence of strong JS mixin libraries/standards/best practices/meta-programming). The best hooks are an improvement over their HOC counterparts (and many of their mixin counterparts): better Typescript types, fewer footguns, fewer composability limits (HOCs had stack problems where stack them in the wrong order and they broke or interfered with each other), easier to reason about (even given the weird learning curve of hooks in general, as black box "units" they have simpler mechanics and APIs than HOCs ever did). To be fair, you can build a lot of React components without ever feeling a need for something like an HOC and never deal with some of the inheritance problems that Hooks were built to solve so some of that "classes are a better way to write components" feeling is that one has never quite before had the multi-inheritance itch to scratch that Hooks solves for. It's obviously hard to judge a tool when you don't know if you've had the problem it solves for or not.