9 ms·

TypeScript is weakening the JavaScript ecosystem

28 points by timdaub 6y ago

msoad 6y ago
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.
- iso8859-1 6y ago
  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-npm-typescript-package-44fe7164964c https://itnext.io/step-by-step-building-and-publishing-an-np...
- arusahni 6y ago
  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.
  - timdaub 6y ago
    Yep that's what I intended to say.
    - oaiey 6y ago
      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.
      - timdaub 6y ago
        > 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...).
        oaiey 6y ago
        I disagree. Node and the browsers script engines are virtual machines nowadays. Package managers go by VMs not by language.
        timdaub 6y ago
        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?
        virtue3 6y ago
        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.
      - wryoak 6y ago
        >It helps millions of developers with static typing backgrounds to accept and deal with the imperfections of JavaScript. Ah, just like when I made my superset of Spanish that gets rid of all those pesky verb endings and gendered articles and adjectives. People complained: "BUT THIS ISN'T SPANISH!" But really, why should any language be different from any other? It's just an impediment to their adoption.
devit 6y ago
> 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.
gvkhna 6y ago
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).
- deleted 6y ago
  [deleted]
- digitaltrees 6y ago
  But the point is it creates fragmentation.
  - ryandvm 6y ago
    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...
    - danShumway 6y ago
      Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto 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.
soneca 6y ago
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.
anandchowdhary 6y ago
> 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. :)
jpnelson 6y ago
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.
virtue3 6y ago
I think comparing typescript to coffeescript is a very amateur call. 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.
- oaiey 6y ago
  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.
  - WorldMaker 6y ago
    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.
tanilama 6y ago
Typescript is SUPERSET of JavaScript, not subset...
- timdaub 6y ago
  Right. I think it should be fixed soon.
  - legerdemain 6y ago
    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.
    - timdaub 6y ago
      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.
      - legerdemain 6y ago
        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.
        timdaub 6y ago
        OK. Then I guess we're on the same page.
oaiey 6y ago
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.
ncphillips 6y ago
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.
danShumway 6y ago
> 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.
deleted 6y ago
[deleted]
paxys 6y ago
> 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?
- watt 6y ago
  The author's context is that he has no context. No frame of reference. Out of his element. I wonder who's more misguided, author, or the person who decided this link is worth posting.
  - oaiey 6y ago
    That was the author himself. A lot of ppl do instead of a comment section under posts.
fbn79 6y ago
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/ https://startfunction.com/deno-will-stop-using-typescript/
- WorldMaker 6y ago
  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/ https://www.python.org/dev/peps/pep-3107/
WorldMaker 6y ago
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/ https://www.python.org/dev/peps/pep-3107/
AaronFriel 6y ago
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.
- oaiey 6y ago
  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).
kyranjamie 6y ago
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.
backspaces 6y ago
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.

28 points by timdaub 6y ago

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.

iso8859-1 6y ago
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-npm-typescript-package-44fe7164964c https://itnext.io/step-by-step-building-and-publishing-an-np...
arusahni 6y ago
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.
- timdaub 6y ago
  Yep that's what I intended to say.
  - oaiey 6y ago
    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.
    - timdaub 6y ago
      > 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...).
      - oaiey 6y ago
        I disagree. Node and the browsers script engines are virtual machines nowadays. Package managers go by VMs not by language.
        timdaub 6y ago
        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?
        virtue3 6y ago
        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.
    - wryoak 6y ago
      >It helps millions of developers with static typing backgrounds to accept and deal with the imperfections of JavaScript. Ah, just like when I made my superset of Spanish that gets rid of all those pesky verb endings and gendered articles and adjectives. People complained: "BUT THIS ISN'T SPANISH!" But really, why should any language be different from any other? It's just an impediment to their adoption.

devit 6y ago

> 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.

gvkhna 6y ago

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).

deleted 6y ago
[deleted]
digitaltrees 6y ago
But the point is it creates fragmentation.
- ryandvm 6y ago
  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...
  - danShumway 6y ago
    Agreed. And importantly, the fragmentation of the Javacript ecosystem is on purpose: https://github.com/extensibleweb/manifesto 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.

soneca 6y ago

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.

anandchowdhary 6y ago

> 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. :)

jpnelson 6y ago

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.

virtue3 6y ago

I think comparing typescript to coffeescript is a very amateur call. 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.

oaiey 6y ago
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.
- WorldMaker 6y ago
  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.

tanilama 6y ago

Typescript is SUPERSET of JavaScript, not subset...

timdaub 6y ago
Right. I think it should be fixed soon.
- legerdemain 6y ago
  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.
  - timdaub 6y ago
    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.
    - legerdemain 6y ago
      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.
      - timdaub 6y ago
        OK. Then I guess we're on the same page.

oaiey 6y ago

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.

ncphillips 6y ago

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.

danShumway 6y ago

> 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.

deleted 6y ago

[deleted]

paxys 6y ago

> 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?

watt 6y ago
The author's context is that he has no context. No frame of reference. Out of his element. I wonder who's more misguided, author, or the person who decided this link is worth posting.
- oaiey 6y ago
  That was the author himself. A lot of ppl do instead of a comment section under posts.

fbn79 6y ago

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/ https://startfunction.com/deno-will-stop-using-typescript/

WorldMaker 6y ago
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/ https://www.python.org/dev/peps/pep-3107/

WorldMaker 6y ago

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/ https://www.python.org/dev/peps/pep-3107/

AaronFriel 6y ago

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.

oaiey 6y ago
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).

kyranjamie 6y ago

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.

backspaces 6y ago

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.