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.
JavaScript was a minefield of compatibility problems. Many intentional, cough: Microsoft.
Jquery was awesome because it dealt with most of that
Typing up constants in Babel JS is so much uglier than it needs to be.
But Coffeescript also introduced things like arrow functions that bind `this` to JS. Transpiling to ES5 allowed JS to evolve.
Maybe eventually with WebAssembly...
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.
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.
Sparse arrays, all object keys are strings (or symbols), crazy coercion rules, the existence of `null`, weird float vs int rules.
---
†: I haven’t checked, but I bet there are some libraries out there that provide proper optionals using Proxy.
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).
TypeScript brought something good for the JS ecosystem (although Flow did it too, in a different way) and it doesn't look like anything will be able to replace it at what it does anytime soon.
Typescript, meanwhile, is used for hugely popular apps, is used by very large companies, has Microsoft's full backing, etc.
The two are not comparable.
Edit: Clearly I'm misremembering its popularity.
We ported off of Coffeescript when ES6 and Babel came out, and you could start writing `class` and using `() => {...}` function expressions with lexical `this` scoping.
Coffeescript lost because it stood still next to the ecosystem and next to the new Ecmascript language standards, which obliviated its advantages. The only advantage Coffeescript had over ES6 was “some of your code is already written in it”.
Once Ecmascript formalizes a type system, we’ll see the same process happen with Typescript. But, I think it will be many years before that sort of feature is standardized. In the mean time, I’m happy to use Typescript today.
JSX is kind of xml done "right". Differences between children and attributes in xml is very hard to grasp, but JSX has a much better defined structure to it and is super well suited to generate html because of that.
Took over a year to convert to ES6.
It adds to countless attempts of other transpiled *scripts to extend Javascript.
They, and Coffeescript in particular, are good historical references to what will happen to TS in a few years.
I doubt Coffeescript ever saw this scale of adoption.
As much as I like Anders work, it is impossible to understand modern TypeScript without looking into tsconfig.json before looking into source code.
Many toolings make it so you don't even need to worry about the tsconfig anymore (though in reality it is very helpful to understand it).
https://blog.isquaredsoftware.com/2020/03/codebase-conversio...
That unlocked the ability to add React and TypeScript code embedded directly in the existing AngularJS UI, using the `react2angular` library, as a short-term migration approach. I was also able to migrate some of our existing AngularJS controllers and client logic to TS to get a bit more safety.
Since then, I've set up a new Next.js subproject that sits behind the existing Express app server, and was able to show content from Next by inserting iframes into the AngularJS templates and proxying those URLs from the Express app to the Next app. That's let us build new features from scratch inside of the Next codebase while showing them seamlessly in the AngularJS UI, giving us a long-term migration path.
We've been using Flow as a type checker but are converting our code to TypeScript for the tooling, ecosystem, support, and hopefully improved performance.
TS has been running as a project for quite a while and a whole lot of folks have a stake in it. I think it's a pretty good bet.
Additionally, I was there when Angular 2 was announced, and the community had no idea what to do or when it was coming out and didn't know whether to dig their heels in and stay on 1 or what the migration path to 2 would look like. I think that's a slightly different story given the context.
The thing is that many good ideas of Coffee ended up being integrated in newer versions of JS, so of course the need for it decreased; one could argue that Coffee's legacy lives in ES201x.
But there are no types in JS, and none planned.
Out of all pull requests on GitHub in Q4/2020, 18.8% were JavaScript and 6.7% were TypeScript.
For reference CoffeeScript was at 0.25%. At its peak in 2014 it was at around 1.5%, when plain JavaScript was at over 20%.
or idk just say that no, its the kids that are wrong.