The heuristic of "new JS tech is just needless complexity/over-engineering" is not a bad one to have in the JS ecosystem imo :)
Typescript is hardly "new", it's fairly widely accepted now. It might be worth thinking "why do all these people enjoy using Typescript?".
or idk just say that no, its the kids that are wrong.
I mean, Coffeescript was fairly widely used at its peak, and now it's all but dead.
Front-end fads are fickle. At least TypeScript has Microsoft backing it so they'll likely continue to support even if the rest of the webdev world moves on to the next shiny object.
I also have fond memories of painstakingly converting hundreds of coffeescript files back to JS. There's something to be said for using the native language.
Browser support and consistency got a lot better.
JavaScript was a minefield of compatibility problems. Many intentional, cough: Microsoft.
Jquery was awesome because it dealt with most of that
JQuery dealt with DOM and browser stuff. Coffeescript dealt with syntactic language stuff. I can't think of a case where Coffeescript helps with the same thing JQuery does, although it may exist.
Yeah as best I can tell, Coffeescript was a thing because Ruby was very popular at the time, and some Ruby devs had to write JS but they wanted to write Ruby.
I think everyone except JS devs wishes they could write something other than JS for the browser.
Maybe eventually with WebAssembly...
That was definitely the case before ES2015. I think many of the non-JS devs that still hugely wish they could write something other than JS for the browser haven't kept up with ES2015+ nor Typescript. ES2015 is a much improved language and vanilla JS isn't painful anymore, especially with type="module" support now green enough in caniuse statistics that we can finally kill AMD and CommonJS for good in greenfield vanilla JS projects. The sky is quite sunny and ES2015+ is a better language than a lot of non-JS devs think JS is.
It will still be a while before all the brownfields in the larger ecosystem get cleaned up (if some of them ever do), but that's no longer a language problem, that's a a long tail ecosystem problem.
Yup. I don't find myself using classes much, but some of the other new features remove the vast number of issues you tend to face.
Is scoping an issue for you? Just use arrow functions!
Is callback nesting an issue for you? Just use `async/await`!
I love it so much.
I use classes a fair amount, but there's still some weird stuff in the language I'd take out if I could.
Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.
You can use `Map` instead of object which allows keys of any type, or typecheck your objects with `Record` and let typescript warn you about any weirdness. Typescript can also warn you if you do some weird implicit coercion. You can typeguard against `null` (although I admit it is annoying, I just want to use an optional†). And if you really want to use integer types there is always `BigInt`.
---
†: I haven’t checked, but I bet there are some libraries out there that provide proper optionals using Proxy.
I use BigInt often, but you can't (for example) do most substring operations with it, even though floating point indexes make no sense.
Map goes part of the way to what I want. But I really want to control which objects are considered equivalent keys, rather than being limited to reference equality.
It's also easy enough to find or write quick simple Map wrappers that use a hash function on an object as keys when provided (either piggy-backing on the existing Object.prototype.valueOf, which always exists on every object and easily falls back to the reference-based current behavior, and expecting classes to have custom overrides for that, or using a Symbol named function of their own to avoid polluting own-property-keys/name clashes with other libraries).