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
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.
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-r...
Of course I know I'm in the minority here.
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.
That said, I don't miss higher order components, but I do find myself reaching for renderprops sometimes. I think it's still a great pattern.
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.
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.
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.
Most users just use arrow functions as syntactic sugar. But it's really good syntactic sugar.
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.
Close! C# programmers. :)
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.
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.
Obviously tests are still useful in TS, but not as many I think. Also, the feedback loop of a static type system is, IME, much faster than with tests only.
On the flip side, the TS type checker is painfully slow, the code is noisy, and you’ll waste a lot of time satisfying the type checker.
For me, the sweet spot has been dynamic (runtime) type assertions in JS. Fast feedback loop, no transpilation hassles, good error messages when type-related errors occur. Downside is that now the editor can’t statically analyze types.
Lately, I’ve been experimenting with using swc to transpile TypeScript without typechecking it. Now there’s a fast feedback loop and I use the IDE to discover type errors. (And the integration build checks types too.) I’ve just recently started this experiment, so jury’s out on whether it’s better than runtime type checking.
And my editor does the autocomplete thing seemingly just as well as the autocomplete I get from TS, even when I just write JS code normally.
I said easily. Types remove whole categories of errors.
I think the industry has generally found dynamic typing to be a mistake. Most dynamic languages are now trying to retrofit types.
I enjoy coding in vanilla JS - my canvas library is 100% vJS, with a hand-written .d.ts file in the root directory in case anyone wants to import it into their TS project.
That said, I also enjoy jogging along cliff edges and sheltering under trees during storms so I'm not the sort of person who should be offering programming advice...
The great thing is it's powerful enough that you don't lose JS's dynamic features, but your code becomes much more self documenting and clearer, and your IDE has a much better idea how to support you. I would never go back to vanilla JS, typescript saves me way too much time and from too many headaches.