TypeScript is weakening the JavaScript ecosystem(timdaub.github.io)
timdaub.github.io
TypeScript is weakening the JavaScript ecosystem
https://timdaub.github.io/2020/09/01/typescript/
52 comments
> The -only- difference between TS and JS is the type annotations. It should be perfectly readable JS aside from that.
TypeScript has a few differences:
Automatic class properties from arguments:
TypeScript has a few differences:
Automatic class properties from arguments:
class Foo {
constructor(
public bar: string,
) {}
}
I find this argument weird. JS doesn't have Public Class fields yet [1] (stage 3), hence any TS or JS code making use of such concept will differ.
Similarly, as reliance of types in JS is not guaranteed, as it may in TS, will produce code with different assumptions too.
So while you may "easily" go from (1) JS => TS, it may be much harder going from (2) TS => JS, as in (1) you're preserving all information and in (2) you're losing information.
My point being, TS !== JS.
- [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Similarly, as reliance of types in JS is not guaranteed, as it may in TS, will produce code with different assumptions too.
So while you may "easily" go from (1) JS => TS, it may be much harder going from (2) TS => JS, as in (1) you're preserving all information and in (2) you're losing information.
My point being, TS !== JS.
- [1]: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
I mean, enums literally get compiled into an object at runtime so aside from the definition it's basically the same :/
They're definition avoiding anything different now: see goal 6: https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...
They're definition avoiding anything different now: see goal 6: https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...
To be fair there is TypeScript code which is not idiomatic to JS. I at least remember the early namespace system. Not so sure about 2020 TypeScript.
But I agree with everything else you wrote.
But I agree with everything else you wrote.
2020 Typescript has very few non-idiomatic JS constructs left, most of which are left only for compatibility reasons with really old TS code, have deprecation markers or strict flag errors around their usage, and generally are frowned upon, with one odd exception that proves the rule.
Almost all of them come from the early days of module development as ES2015 and ES2015 modules were finalized. Most of them resemble idiomatic JS of their time. There's an old import and export syntax that idiomatically looks and acts more like CommonJS (aka most older npm packages). That's been deprecated since 1.x and I believe an error or warning since 2.x.
The "namespace" thing you are probably recalling is about the only surviving piece of that legacy, as the exception that proves the rule. It got renamed to "module" to at least sound more JS than C#, and while the syntax is still not entirely idiomatic, the concept that it has always wrapped and been mere syntactic sugar for is a classic (thankfully on life support more than not) pattern: the IIFE [Immediately Invoked Function Expression] module pattern.
Almost all of them come from the early days of module development as ES2015 and ES2015 modules were finalized. Most of them resemble idiomatic JS of their time. There's an old import and export syntax that idiomatically looks and acts more like CommonJS (aka most older npm packages). That's been deprecated since 1.x and I believe an error or warning since 2.x.
The "namespace" thing you are probably recalling is about the only surviving piece of that legacy, as the exception that proves the rule. It got renamed to "module" to at least sound more JS than C#, and while the syntax is still not entirely idiomatic, the concept that it has always wrapped and been mere syntactic sugar for is a classic (thankfully on life support more than not) pattern: the IIFE [Immediately Invoked Function Expression] module pattern.
Thanks. Yeah, that is also my limited insight.
You're making a fine argument, but you assume things freeze in time. Whether or not TS will stick to ECMA script in the future is speculation.
A similar argument to yours could be made where we speculated that JS introduces a typing system in the future and hence creates an incompatibility (to .e.g. TS), hence TS is bad. But I've specifically not tried to speculate in the post.
I value that the two languages are very similar and that TS respects ECMA script. However, my argument was (whether you think it was misguided by that silly Objective-C example or not) that TS and JS are different by equality and identity (current and potentially for the future), which is why they belong in different package managers.
A similar argument to yours could be made where we speculated that JS introduces a typing system in the future and hence creates an incompatibility (to .e.g. TS), hence TS is bad. But I've specifically not tried to speculate in the post.
I value that the two languages are very similar and that TS respects ECMA script. However, my argument was (whether you think it was misguided by that silly Objective-C example or not) that TS and JS are different by equality and identity (current and potentially for the future), which is why they belong in different package managers.
Except its directly trended towards being like JS. It was slightly divergent at some point. (see other commends under my original).
Your reasoning is unsound. I'm sorry.
https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...
Please see goal number 6.
Typescript is an opensource language (probably in mostly control of MS. but they are a -very- different company from even 10 years ago).
I can tell you from the last few years that they are taking it very very seriously. Now that ES is actually moving again, no one wants a repeat of coffeescript.
Your argument is basically also saying that JSX/React are bad as well and should not be in npm either.
I don't think any npm package owes it to anyone to be in any language. They are just under the contract of producing javascript that is runnable under the node versions they've specified (and even then, not even, as there are plenty of browser-only packages).
There are plenty of npm modules that have some sort of compilation from C or some such. (anything with node-gyp). Not as common as in ruby land but still happens.
Your reasoning is unsound. I'm sorry.
https://github.com/microsoft/TypeScript/wiki/TypeScript-Desi...
Please see goal number 6.
Typescript is an opensource language (probably in mostly control of MS. but they are a -very- different company from even 10 years ago).
I can tell you from the last few years that they are taking it very very seriously. Now that ES is actually moving again, no one wants a repeat of coffeescript.
Your argument is basically also saying that JSX/React are bad as well and should not be in npm either.
I don't think any npm package owes it to anyone to be in any language. They are just under the contract of producing javascript that is runnable under the node versions they've specified (and even then, not even, as there are plenty of browser-only packages).
There are plenty of npm modules that have some sort of compilation from C or some such. (anything with node-gyp). Not as common as in ruby land but still happens.
The author admits to not using Typescript and not knowing how it works but is quick to point out that it’s polluting the JavaScript community?
He does state that typescript is a subset of JavaScript and this compiles to JS so I largely don’t see the problem. TS is making complex projects in JS more tenable and I believe we should encourage TS.
A separate repo for TS doesn’t make sense, Microsoft owns npm now by extension of github and is doing fantastic work supporting TS and by extension JS.
My hope is the opposite, at some point TS is the gold standard for a package, it is self documenting and again the types can be stripped out (and usually are for distribution).
He does state that typescript is a subset of JavaScript and this compiles to JS so I largely don’t see the problem. TS is making complex projects in JS more tenable and I believe we should encourage TS.
A separate repo for TS doesn’t make sense, Microsoft owns npm now by extension of github and is doing fantastic work supporting TS and by extension JS.
My hope is the opposite, at some point TS is the gold standard for a package, it is self documenting and again the types can be stripped out (and usually are for distribution).
To me whether or not using JS or TS as the "gold standard" for a package is insignificant. I've argued that JavaScript is not the same as TypeScript. It may be transpiled but it's not the same. Hence, being kinda pedantic in my rhetoric while e.g. a popularity increase in TypeScript may, strengthen e.g. the web ecosystem because more programs have less bugs because devs use types, it doesn't directly strengthen or benefit the JavaScript language (which is the one without types).
For now, what I can see is that my argument (e.g. in the comments of this thread) creates fragmentation and controversy.
For now, what I can see is that my argument (e.g. in the comments of this thread) creates fragmentation and controversy.
But the point is it creates fragmentation.
The argument feels like it started from a pre-existing conclusion (not liking/knowing TS) and retrofitting a reason (supposed fragmentation).
The reality is that NPM is already a fragmentation mess. There are many libraries that break because of things like poorly tested `module` field in package.json and/or .mjs support. There are libraries that break with different versions of node, or different package managers, or different OSes, libraries that only work with webpack and/or babel (and/or react/vue/[insert framework here]). There are libraries that break with random transitive pins because who tests that every permutation within a semver range is actually following semver correctly. There are libraries with broken CI because it's in "maintenance mode" for years but the travis setup is stuck 5 major versions of Node behind. There are abandoned libraries, libraries that drop support for browsers on minor bumps, and libraries with hostile maintainers. There are libraries written in clojurescript and nim and reason. There are libraries written with other type systems (e.g. flow)
Maybe the author feels left out for not knowing typescript, but honestly, it's kinda becoming a requirement in the industry these days. I might understand being reluctant to learn C++ and its toolchain for a one-off fix in some Node-GYP thing, but being able to understand typescript is something that one could reasonably expect a senior level frontend person to be able to handle nowadays.
The reality is that NPM is already a fragmentation mess. There are many libraries that break because of things like poorly tested `module` field in package.json and/or .mjs support. There are libraries that break with different versions of node, or different package managers, or different OSes, libraries that only work with webpack and/or babel (and/or react/vue/[insert framework here]). There are libraries that break with random transitive pins because who tests that every permutation within a semver range is actually following semver correctly. There are libraries with broken CI because it's in "maintenance mode" for years but the travis setup is stuck 5 major versions of Node behind. There are abandoned libraries, libraries that drop support for browsers on minor bumps, and libraries with hostile maintainers. There are libraries written in clojurescript and nim and reason. There are libraries written with other type systems (e.g. flow)
Maybe the author feels left out for not knowing typescript, but honestly, it's kinda becoming a requirement in the industry these days. I might understand being reluctant to learn C++ and its toolchain for a one-off fix in some Node-GYP thing, but being able to understand typescript is something that one could reasonably expect a senior level frontend person to be able to handle nowadays.
No, JavaScript being the kind of language that requires 3rd parties to implement what should be core features is what creates fragmentation.
There was similar fragmentation with JavaScript's async patterns. Callbacks, promises, async/await also resulted in fragmentation as you had different projects supporting different patterns as 3rd parties introduced new capabilities (that eventually graduated into fully-fledged language features).
Hopefully the best of what TypeScript provides will make its way into the ECMAScript spec eventually...
There was similar fragmentation with JavaScript's async patterns. Callbacks, promises, async/await also resulted in fragmentation as you had different projects supporting different patterns as 3rd parties introduced new capabilities (that eventually graduated into fully-fledged language features).
Hopefully the best of what TypeScript provides will make its way into the ECMAScript spec eventually...
Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto
I think about the fragmentation that shows up in the form of multiple frameworks and patterns as a necessary part of that. It's not something that I want to fix.
So to draw a line and say, "extending core Javascript features is fine, but compiling into Javascript isn't" -- I just don't get that. Typescript is a testing ground not just for typed programming in general, but also for features like decorators and meta-programming features. It's good to have a diversity in what people are building and using, that's how we get real world data on what works.
I think about the fragmentation that shows up in the form of multiple frameworks and patterns as a necessary part of that. It's not something that I want to fix.
So to draw a line and say, "extending core Javascript features is fine, but compiling into Javascript isn't" -- I just don't get that. Typescript is a testing ground not just for typed programming in general, but also for features like decorators and meta-programming features. It's good to have a diversity in what people are building and using, that's how we get real world data on what works.
You forgot observables :)
[deleted]
> My context is that I've not looked into TypeScript yet. That means I have no idea how it works.
This is all you need to know about this article. There is no such thing as a "TypeScript package" on npm. It's simply a JavaScript package with a bundled type definition file. A pure JavaScript project can use this package as they normally would, and just ignore the types. So I don't understand where the question of fragmentation even comes from.
If the author is concerned that they aren't going to be able to contribute to projects written in TypeScript, then it's really the same problem as having JavaScript projects that enforce ES6 syntax, a specific module strategy, have custom linting rules, file structures, use Promises vs callbacks etc. Should those be disallowed as well?
This is all you need to know about this article. There is no such thing as a "TypeScript package" on npm. It's simply a JavaScript package with a bundled type definition file. A pure JavaScript project can use this package as they normally would, and just ignore the types. So I don't understand where the question of fragmentation even comes from.
If the author is concerned that they aren't going to be able to contribute to projects written in TypeScript, then it's really the same problem as having JavaScript projects that enforce ES6 syntax, a specific module strategy, have custom linting rules, file structures, use Promises vs callbacks etc. Should those be disallowed as well?
> My context is that I've not looked into TypeScript yet. That means I have no idea how it works.
The main problem Tim has is that he doesn't write TypeScript, so he wouldn't be able to contribute to dependencies. I don't think that's a huge problem since learning limited TypeScript to make patches to projects isn't very hard. In most cases, some patches might not require any TypeScript features at all.
> So essentially, the problem is that TypeScript authors publish their packages on npm, the package manager for Node.js. And to me, that's what is weakening the JavaScript ecosystem.
This doesn't make much sense to me, because the convention is to publish the "dist" folder to npm that has compiled JavaScript with declaration files, not the TypeScript source. To the Node.js engine, a package written in TypeScript is indistinguishable from one written in plain JavaScript. Declaration files have the added advantage of intellisense in IDEs that support language tools like VS Code.
> However, continuing to publish TypeScript packages to npm is, in my opinion weakening the JavaScript ecosystem as it's splitting its community and polluting the npm namespace.
Again, I point out that you can use TypeScript packages in Node.js/JavaScript projects. The pollution argument doesn't hold for me. npm packages already have a lot of "versions", like publishing ES Modules, compiled JS, legacy Node.js modules (module.exports), etc., so having TypeScript-compiled code that doesn't require additional tooling is the least of our problems. :)
The main problem Tim has is that he doesn't write TypeScript, so he wouldn't be able to contribute to dependencies. I don't think that's a huge problem since learning limited TypeScript to make patches to projects isn't very hard. In most cases, some patches might not require any TypeScript features at all.
> So essentially, the problem is that TypeScript authors publish their packages on npm, the package manager for Node.js. And to me, that's what is weakening the JavaScript ecosystem.
This doesn't make much sense to me, because the convention is to publish the "dist" folder to npm that has compiled JavaScript with declaration files, not the TypeScript source. To the Node.js engine, a package written in TypeScript is indistinguishable from one written in plain JavaScript. Declaration files have the added advantage of intellisense in IDEs that support language tools like VS Code.
> However, continuing to publish TypeScript packages to npm is, in my opinion weakening the JavaScript ecosystem as it's splitting its community and polluting the npm namespace.
Again, I point out that you can use TypeScript packages in Node.js/JavaScript projects. The pollution argument doesn't hold for me. npm packages already have a lot of "versions", like publishing ES Modules, compiled JS, legacy Node.js modules (module.exports), etc., so having TypeScript-compiled code that doesn't require additional tooling is the least of our problems. :)
> Since its inception, and throughout trends like Coffeescript, npm has mostly held the promise of only hosting JavaScript packages.
I don't think this is true. There are multiple NPM packages that rely on non-JS extensions and external binaries to run. The entire `node-gyp` ecosystem, which is a pain because it makes it impossible to vendor dependencies in a portable way.
On that front, compiled Typescript isn't that hard to read. I'm less concerned about someone cross-compiling a language into Javascript than I am about someone pushing a C binary alongside their code as part of the install script. WASM modules are going to start becoming more common in Node eventually. Deciphering Typescript with a pure-JS background is way easier than deciphering Rust.
I see this argument come up with frameworks and libraries as well: "Javascript has too many frameworks, it makes it impossible to evaluate a 3rd-party package." I don't think the argument stands up to much scrutiny there, and I don't think it stands up to a ton of scrutiny here.
I don't think this is true. There are multiple NPM packages that rely on non-JS extensions and external binaries to run. The entire `node-gyp` ecosystem, which is a pain because it makes it impossible to vendor dependencies in a portable way.
On that front, compiled Typescript isn't that hard to read. I'm less concerned about someone cross-compiling a language into Javascript than I am about someone pushing a C binary alongside their code as part of the install script. WASM modules are going to start becoming more common in Node eventually. Deciphering Typescript with a pure-JS background is way easier than deciphering Rust.
I see this argument come up with frameworks and libraries as well: "Javascript has too many frameworks, it makes it impossible to evaluate a 3rd-party package." I don't think the argument stands up to much scrutiny there, and I don't think it stands up to a ton of scrutiny here.
TypeScript strengthens the JavaScript ecosystem by making it easier to write correct code, and easier to use code correctly. I suspect the author's self-professed lack of knowledge of TypeScript is the biggest barrier, but that's not why I decided to write this comment.
I wonder how many times the author has used node-gyp, node-sass, or even a wasm-pack packaged NPM package? The latter allows writing NPM packages in any language that compiles to web assembly. That's quite a few languages already, most of which are much further removed from JavaScript.
Despite that, I think that strengthens the NPM ecosystem, even if it "weakens" the JavaScript ecosystem. (I don't think it does, actually.) It means NPM is one the first and largest polyglot package repository. It's certainly the largest public source code and library repository in the world, and now or very soon, it will be possible to reap the benefits of packages using webassembly to get (nearly) bare metal performance without compromising security.
I would also argue this strengthens the JavaScript ecosystem too because all of these languages work transparently with JavaScript. The first-class citizen remains JS, for now, and people writing C/C++, Rust, Scala, ML, and others to webassembly are making their code available with JS bindings that just work. That's pretty amazing.
The closest thing to this is Python, and it's so nontrivial to contribute native or FFI code that works reliably to pip that it's not done outside of a handful of extremely performance sensitive data science projects. For this reason, I think JS (and webassembly) is ascendant, and Python's star is at its peak.
I wonder how many times the author has used node-gyp, node-sass, or even a wasm-pack packaged NPM package? The latter allows writing NPM packages in any language that compiles to web assembly. That's quite a few languages already, most of which are much further removed from JavaScript.
Despite that, I think that strengthens the NPM ecosystem, even if it "weakens" the JavaScript ecosystem. (I don't think it does, actually.) It means NPM is one the first and largest polyglot package repository. It's certainly the largest public source code and library repository in the world, and now or very soon, it will be possible to reap the benefits of packages using webassembly to get (nearly) bare metal performance without compromising security.
I would also argue this strengthens the JavaScript ecosystem too because all of these languages work transparently with JavaScript. The first-class citizen remains JS, for now, and people writing C/C++, Rust, Scala, ML, and others to webassembly are making their code available with JS bindings that just work. That's pretty amazing.
The closest thing to this is Python, and it's so nontrivial to contribute native or FFI code that works reliably to pip that it's not done outside of a handful of extremely performance sensitive data science projects. For this reason, I think JS (and webassembly) is ascendant, and Python's star is at its peak.
Also why thinking NPM to limit to a language. The browsers and node are essentially virtual machines (evidence: see wasm). NPM is the package manager of this VM and not the JS language (ignoring that there is no TS code shipped).
What the OP is talking about? Nobody is publishing TypeScript to npm. Maybe they need to understand how things work before writing a lengthy blog post. Those packages have types built in because of the emitted .d.ts files.
I think he's suggesting that one of his criteria for package selection is his ability to contribute changes to the upstream project if needed, which he feels he can't do for TypeScript on account of him not knowing the language.
Yep that's what I intended to say.
That is a valid point, but honestly, avoiding (learning) TypeScript as a modern day JavaScript developer is a mistake.
I know it is annoying that there is a breach into the purity of the JavaScript language by a different actor. But let us face it: TS is useful, it is the right tool for the job and it is not niche. It complements JavaScript and solves problems JavaScript is structurally unable to solve. It helps and improves the JavaScript language. It helps millions of developers with static typing backgrounds to accept and deal with the imperfections of JavaScript.
In my primary language - C# - there is tons of influx of functional programming nowadays (sourced via F# and OCaml). I could fight against it but I do not. I embrace change and adapt. Take the Linux Kernel: After three decades of C code they are talking/merging support for Rust. Why: it is the right thing and it is a good complement for their C tooling.
I know it is annoying that there is a breach into the purity of the JavaScript language by a different actor. But let us face it: TS is useful, it is the right tool for the job and it is not niche. It complements JavaScript and solves problems JavaScript is structurally unable to solve. It helps and improves the JavaScript language. It helps millions of developers with static typing backgrounds to accept and deal with the imperfections of JavaScript.
In my primary language - C# - there is tons of influx of functional programming nowadays (sourced via F# and OCaml). I could fight against it but I do not. I embrace change and adapt. Take the Linux Kernel: After three decades of C code they are talking/merging support for Rust. Why: it is the right thing and it is a good complement for their C tooling.
> That is a valid point, but honestly, avoiding (learning) TypeScript as a modern day JavaScript developer is a mistake.
You're probably right. My argument, however, was purely about separation of concerns: different language means different package manager (or namespace...).
You're probably right. My argument, however, was purely about separation of concerns: different language means different package manager (or namespace...).
I disagree. Node and the browsers script engines are virtual machines nowadays. Package managers go by VMs not by language.
Not sure I get your argument. As far as I understand there's no VM for Typescript specifically. Hence as "no VM" is different from Spidermonkey/V8, Typescript packages should go into its own package manager?
A kotlin project is going to use both java and kotlin sources (and maybe closure).
We're going to start seeing a lot more WASM stuff on npm, which is going to be whatever language anyone wants.
The VM for typescript is node/browser. Because it gets compiled to target those.
We're going to start seeing a lot more WASM stuff on npm, which is going to be whatever language anyone wants.
The VM for typescript is node/browser. Because it gets compiled to target those.
Doesn't it depend on the way you package your library?
This tutorial [0] puts the building in "prepare", which means it will be built by anyone installing the library. But it won't be built yet in the version uploaded to NPM, so it would be correct to say that the package uploaded to NPM doesn't contain JavaScript.
[0]: https://itnext.io/step-by-step-building-and-publishing-an-np...
This tutorial [0] puts the building in "prepare", which means it will be built by anyone installing the library. But it won't be built yet in the version uploaded to NPM, so it would be correct to say that the package uploaded to NPM doesn't contain JavaScript.
[0]: https://itnext.io/step-by-step-building-and-publishing-an-np...
By this argument, JSX shouldn't be published to NPM either.
You might argue that you know what you're consuming if you're importing, say, a React component, and it's likely written in JSX, but it's really a categorization issue.
A standard field in the package.json indicating what the source is written in might be useful, but would probably be left unpopulated. Personally, I find it fairly straightforward to tell what a package is written in just by looking at the source.
You might argue that you know what you're consuming if you're importing, say, a React component, and it's likely written in JSX, but it's really a categorization issue.
A standard field in the package.json indicating what the source is written in might be useful, but would probably be left unpopulated. Personally, I find it fairly straightforward to tell what a package is written in just by looking at the source.
IMO including TS packages in JS ecosystem strengthens rather then weakens the ecosystem. A library consumer doesn't have to know whether a package is written in JS or just compiled to JS. Either way, it's still useful.
And TS isn't so magically different from plain JS that it's not understandable. Most TS ends up being plain JS, so the comparison to CoffeeScript or even Objective-C doesn't see fair to me.
And TS isn't so magically different from plain JS that it's not understandable. Most TS ends up being plain JS, so the comparison to CoffeeScript or even Objective-C doesn't see fair to me.
I would highly recommend the author to "pause" this post, learn the little of TS you need to understand, and then rewrite the post.
I mean there is a valid argument about TS making JS more typed than the ecosystem should (not my personal opinion) but that was not even scratched as a topic here.
I mean there is a valid argument about TS making JS more typed than the ecosystem should (not my personal opinion) but that was not even scratched as a topic here.
I think Typescript as a standalone language will reach is maximum adoption in a couple of years. Than we will gradually see more and more packages roll-back to standard ECMA script eventually with typescript checks by JsDoc annotation and .d.ts files. That's the more trational solution. Take as case Deno migrating from Typescript to Javascript https://startfunction.com/deno-will-stop-using-typescript/
I only see that happening if TC39 pulls a PEP 3107 [1] approach and adds type annotations as optional part of the JS language directly that browsers don't need to understand and can ignore but should parse. The Typescript format of type annotations is much more convenient than the JSDoc style (and think Typescript surpassing Flow is in part because of that; among several other reasons), so there likely will always be people wanting it. At that point a PEP 3107 approach would both mean a lot less need for Typescript and also a lot more use of Typescript-like type annotations.
Deno's odd choices made on V8 performance issues (failures) also does not look to implicate a trend so much as Deno making some interesting choices. (There too a PEP 3107 approach would have helped them as the performance issue they were trying to fix was type stripping as V8 itself doesn't today have any reason to performantly type strip TS-like annotations, but of course that would change tomorrow if TC39 made that a first class citizen of the JS parser directly.)
[1] https://www.python.org/dev/peps/pep-3107/
Deno's odd choices made on V8 performance issues (failures) also does not look to implicate a trend so much as Deno making some interesting choices. (There too a PEP 3107 approach would have helped them as the performance issue they were trying to fix was type stripping as V8 itself doesn't today have any reason to performantly type strip TS-like annotations, but of course that would change tomorrow if TC39 made that a first class citizen of the JS parser directly.)
[1] https://www.python.org/dev/peps/pep-3107/
I would think most Typescript packages today would fall under the author's second criterion:
> picking packages that are well-maintained by a large community
Whether or not the author feels they can directly contribute to a Typescript package, overall Typescript seems to balancing the scale on npm in favor of well-maintained and large community. Admittedly, I've been a fan of Typescript since 0.97 so I'm biased but I very deeply feel that you cannot have well-maintained in JS overall without Typescript.
I don't see that as weakening the ecosystem at all, in that the rising tide of Typescript quite clearly seems to me to reflect a rising tide of maintenance in the ecosystem.
Obviously opinions will continue to vary, but I certainly invite the author to spend at least a bit more time with Typescript before jumping to the conclusion that Typescript is neither well maintained nor encourages a large community as it this article implies if the author truly does not feel comfortable under their own criteria of worse case treating typescript as a blackbox similar to C/WASM and trusting communities that do use Typescript.
I think the attempted analogy between C and Objective-C especially points out that probably at least a bit more familiarity with Typescript might help the author a ton. The comparison between C and Objective-C seems pretty weak to me. Objective-C makes a ton of syntax changes to the language. Typescript makes relatively few. About the best comparison I can think of is Python and MyPy with the only missing piece being a PEP 3107 [1] equivalent asking browsers to support Typescript annotations even if they don't understand them.
What the analogy says to me, if Typescript looks foreign enough from JS to the author as Objective-C to C is much more that JS itself has changed so much in the last few years that the author is perhaps behind on what ES2015+ flavors of JS look like as most of what makes Typescript look "foreign" today really is just JS today. It may be worth digging more into Typescript simply to learn more about how JS is evolving/has evolved.
[1] https://www.python.org/dev/peps/pep-3107/
> picking packages that are well-maintained by a large community
Whether or not the author feels they can directly contribute to a Typescript package, overall Typescript seems to balancing the scale on npm in favor of well-maintained and large community. Admittedly, I've been a fan of Typescript since 0.97 so I'm biased but I very deeply feel that you cannot have well-maintained in JS overall without Typescript.
I don't see that as weakening the ecosystem at all, in that the rising tide of Typescript quite clearly seems to me to reflect a rising tide of maintenance in the ecosystem.
Obviously opinions will continue to vary, but I certainly invite the author to spend at least a bit more time with Typescript before jumping to the conclusion that Typescript is neither well maintained nor encourages a large community as it this article implies if the author truly does not feel comfortable under their own criteria of worse case treating typescript as a blackbox similar to C/WASM and trusting communities that do use Typescript.
I think the attempted analogy between C and Objective-C especially points out that probably at least a bit more familiarity with Typescript might help the author a ton. The comparison between C and Objective-C seems pretty weak to me. Objective-C makes a ton of syntax changes to the language. Typescript makes relatively few. About the best comparison I can think of is Python and MyPy with the only missing piece being a PEP 3107 [1] equivalent asking browsers to support Typescript annotations even if they don't understand them.
What the analogy says to me, if Typescript looks foreign enough from JS to the author as Objective-C to C is much more that JS itself has changed so much in the last few years that the author is perhaps behind on what ES2015+ flavors of JS look like as most of what makes Typescript look "foreign" today really is just JS today. It may be worth digging more into Typescript simply to learn more about how JS is evolving/has evolved.
[1] https://www.python.org/dev/peps/pep-3107/
> My context is that I've not looked into TypeScript yet. That means I have no idea how it works.
The problem lies in the author, since knowing TypeScript is an essential skill if you are doing anything browser-related or JavaScript-related.
Also TypeScript produces readable JavaScript, and anyway it's trivial to mentally strip the types when reading TypeScript, and also very easy to learn enough to fully understand most TypeScript code.
The problem lies in the author, since knowing TypeScript is an essential skill if you are doing anything browser-related or JavaScript-related.
Also TypeScript produces readable JavaScript, and anyway it's trivial to mentally strip the types when reading TypeScript, and also very easy to learn enough to fully understand most TypeScript code.
Typescript is SUPERSET of JavaScript, not subset...
Technically, it's neither. `a<b,c>(d)` is valid JS, but it means something different in TS.
Right. I think it should be fixed soon.
What needs fixing is not just replacing the word "subset" with the word "superset," but the entire argument in the paragraph. Your argument is based on your misunderstanding. Valid TS in not necessarily valid JS. No informed person will claim that you can just drop TS into a JS project the same way you can drop JS into TS. Also, no one is publishing TS to NPM, and certainly not for the (mistaken) reason you describe.
I think there may be a misunderstanding. I too know that nobody published TypeScript packages directly in NPM, but they always include a transpiled version. Nevertheless it'd consider it a "TypeScript package (that was transpiled to JS and then published to NPM)".
Edit: To make sure this misunderstanding is avoided, I've adjusted a section in the blog post to make it super clear.
Edit: To make sure this misunderstanding is avoided, I've adjusted a section in the blog post to make it super clear.
If your claim is that it's impossible to contribute to a package written in TS without writing TS, even if the authors publish a JS version to NPM, I completely agree. I also agree that this creates a divide between authors who write TS/publish JS, and those who write JS directly.
OK. Then I guess we're on the same page.
Actually, it should be: JavaScript is weakening the JavaScript ecosystem.
In the olden days, html, css, js were it. But each were "subclassed" by better solutions compiling to html, css, js.
Then huge frameworks arrived to try to organize the mess we'd created. Making devs further than ever from html, css, js.
Remember the old saw: Sure I understand JS, I use jQuery every day! Er, but how about closures? direct DOM use via JS? And so on.
To be fair, jQuery and later CoffeeScript, improved JS considerably.
I don't get the feeling that TS is going to help JS, but hopefully I'm wrong. But unarguably it is SPLITTING the JS ecosystem into warring camps.
In the olden days, html, css, js were it. But each were "subclassed" by better solutions compiling to html, css, js.
Then huge frameworks arrived to try to organize the mess we'd created. Making devs further than ever from html, css, js.
Remember the old saw: Sure I understand JS, I use jQuery every day! Er, but how about closures? direct DOM use via JS? And so on.
To be fair, jQuery and later CoffeeScript, improved JS considerably.
I don't get the feeling that TS is going to help JS, but hopefully I'm wrong. But unarguably it is SPLITTING the JS ecosystem into warring camps.
It is getting in the way of the way the author decided to select the packages for their projects, just that. It is not weakening the JavaScript ecosystem in the least.
In my opinion, by solving a pain point that a relevant part of the developers involved in the JavaScript ecosystem have, it is making the ecosystem stronger. An ecosystem that make more people happier is a more robust one.
In my opinion, by solving a pain point that a relevant part of the developers involved in the JavaScript ecosystem have, it is making the ecosystem stronger. An ecosystem that make more people happier is a more robust one.
As your run-of-the-mill web dev who's been using TypeScript professionally for about 5 years, I find posts like this fascinating.
Other comments address the main themes in this guys article, mostly not having any context on which to base the argument.
If you don't keep up with the trend, you're going to lose out.
Other comments address the main themes in this guys article, mostly not having any context on which to base the argument.
If you don't keep up with the trend, you're going to lose out.
[deleted]
Coffeescript specifically decided to throw out ECMA script. Typescript embraces it.
There was SO SO SO much waiting around the ".?" operator in TS because they specifically did NOT want to do what coffeescript did (make their own, and then get hosed when the official spec came out and they were different from their own implimentation).
The -only- difference between TS and JS is the type annotations. It should be perfectly readable JS aside from that.
Objective-C can actually compile C. Objective-C is a -superset- of C. So again, the argument is misguided.
All the typescript webpack plugin does is strip out typescript stuff. And that leaves you with the underlying JS.
Typescript projects should be pushed up to NPM with their transpiled modules.
I believe any small bug that the author of this article was hoping to fix in subprojects should have been caught by the typing system. You should see about 25% less bugs in TS code vs JS (number pulled semi-out of my ass, pulled from some strong blog with strong opinions against TS).
I believe, if anything, that TS's impact on the JS ecosystem is incredibly important for the long term survivability and reliability of it. As our sub projects get larger and more complicated, having the compiler save our collective butts is huge.