20 ms·

Deno will stop using TypeScript

241 points by diablo1 6y ago

deleted 6y ago
[deleted]
cocktailpeanuts 6y ago
Thank God, I would really appreciate this. The TypeScript usage was the one thing that I didn't like about Deno. Why add complexity to a new project which starts from scratch? JavaScript is good enough and there's no need to make it confusing by adding another layer.
- untog 6y ago
  This is talking about the internal Deno code. The user facing side will still support TypeScript, though you’re also free to not use it if you want.
- lowercased 6y ago
  > JavaScript is good enough and there's no need to make it confusing by adding another layer. To some people, JS itself is relatively confusing, and TypeScript reduces that confusion. EDIT: And... someone's clarification is saying this is internal framework code, not userland support for TS. Seems like a non-issue, really. They don't want to use it, but want to provide support for others to use it in their projects.
- eloff 6y ago
  You can use JavaScript with Deno. Nobody is forcing you to use TypeScript. This doesn't change anything, it's for their internals. Why anyone would ditch static typing on a large collaborative project is beyond me though.
jbverschoor 6y ago
Yeah. Same same. Not working, so let’s just fix it by creating another ecosystem instead of fixing compiletimes etc. I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be like Mike”. Errr Linus... Lowrey
- untog 6y ago
  Deno is made by the guy who made Node. So no change in notoriety there.
untog 6y ago
> While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. Woah, woah, hold on. This case is showing that in the very specific, atypical case the Deno team are using it in, TypeScript is not the right fit. I’d rather read something that actually interviews the Deno folks about what they are doing, the underlying document is a pretty free ranging discussion and this writeup is making a few assumptions.
- braythwayt 6y ago
  Lawd, the number of times people write an extensive essay detailing how a particular tool didn’t fit their culture, processes, and circumstances, then explain why it’s either irredeemably broken or conversely, that failing to adopt the tool is professional malpractice. N=1. That is all.
- karmakaze 6y ago
  May as well drop tests and code reviews if it feels like it's slowing you down. For one-person or very small teams who have full context of a'll changes this can actually work very well. It's with more contributors participating in a mature project that you'd wish these things weren't dropped. Types can be added later so it's not like using php and later wishing you'd used Kotlin.
  - karmakaze 6y ago
    I'll add a datapoint of an analogous case. I updated a legacy java 1.x codebase that was running java 6/7 without generics. Having spent a small amount of effort over a course of months, all the type annotations were updated. It uncovered exactly one bug. The main improvement is for quickly gaining context in unfamiliar code and being able to enable warnings for newly written code without noisy error messages.
zdragnar 6y ago
> It’s worth mentioning that Deno will stop using TypeScript only for the internal Deno code: the Deno user code will still be in TypeScript and thus type checked.
vimslayer 6y ago
Here's the Deno Design document with the reasoning and some discussion about the decision: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... This post adds little to what's already said there.
whoisjuan 6y ago
This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It definitely slows me down with very little benefits in return. (Again, can’t stress enough that this is a personal opinion based on personal use cases) I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks. Of course I also appreciate when I can identify that an error is coming from a type mismatch, but as I said I learned to program in loosely typed languages first, so I never created that concept of defining types in my head. I’m always extra-aware of types mismatches in my JS code and is usually the first thing I check when something goes wrong. But I have never felt the need to have a way to explicitly define the types that I’m working with. I honestly fail to see the benefit when a large amount of code that you have to interact with (libraries and such) was written in classic JS. Once again. Probably unpopular opinion, so I don’t mind the downvotes.
- deleted 6y ago
  [deleted]
- halfmatthalfcat 6y ago
  You don’t see the benefits of a strongly typed language?
  - cheez 6y ago
    Python is strongly typed, don't confuse static and strong typing.
    - whoisjuan 6y ago
      You’re right.
  - whoisjuan 6y ago
    I do. But not for JS in particular. At the end of the day 95% of JS that is written in classic JS and is used in thousands of high-scale projects like that.
searchableguy 6y ago
They should just use deno to run their setup, there would be no compilation if they did that. ;) Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc https://github.com/swc-project/swc Cool project for runtime checking with ts - https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts Edit: Remove unmaintained runtime type checking library.
- wereHamster 6y ago
  Instead of ts-runtime, use io-ts (https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts). That one is actually maintained, unlike ts-runtime!
  - deleted 6y ago
    [deleted]
  - deleted 6y ago
    [deleted]
echelon 6y ago
Why such a large, important project would want to drop static types is beyond me. > TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just fine. These folks are free to do what they want with their project, but this is not a good look, especially to those that are skeptical of the javascript ecosystem.
- mimixco 6y ago
  Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.
  - efficax 6y ago
    there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.
    - mimixco 6y ago
      I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.
nathancahill 6y ago
Needs "internally" at the end of the title.
hakcermani 6y ago
Was using JS for about 6 yrs now and decided will start using TS for a new Node.js project. Admitted it has its warts ... hit my first bottleneck rightaway when parsing the request query param. TS Express bindings declare it as string | string[] | ParsedQs | ParsedQs[]. Ok extract it 'as' string and move on. But I find as I am using it more and more it is getting better (or I am getting more disciplined!) .. maybe I am reading this wrong re the long compile time reported, could the code not be broken into modules so the compile is more isolated ??
- emptysea 6y ago
  just a heads up, casting `as string` isn't safe since the request param could turn out to be an array. If the request ends up with the query param as an array, there isn't a runtime to validate the cast and now the variable is typed as `string` but is actually `string[]`. I think a safer approach is to use a validation library or refine the type with an if stmt and returning an error when it isn't a string. I use the following lint to prevent all casts except `as const`: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/consistent-type-assertions.md https://github.com/typescript-eslint/typescript-eslint/blob/...
  - hakcermani 6y ago
    Thanks for the headsup. I did realize that. It was a specific case of pulling a username from the query .. checking out the library ..
wufufufu 6y ago
Has anyone else experienced these issues? This reads more like product placement for Deno than a sincere criticism of TS.
- war1025 6y ago
  I've definitely noticed that compiling typescript is slow and extremely resource hungry. It's amusing to me that our "web" stack is the most resource intensive part of our entire codebase at work. A sign of the times I guess that a build system requires 8gb of ram to run. Could be we're doing something wrong, but from what I understand we're using a pretty vanilla setup.
  - inimino 6y ago
    Unfortunately the state of web dev in 2020 is such that using a vanilla "best practice" setup is very much doing something wrong.
devit 6y ago
It seems it might be an issue with their development abilities or problem-solving motivation: 1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action. 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead. 3. They claim that "having two Body classes is obviously wrong" (?!). Of course having two classes with the same name in different namespaces/packages is perfectly fine in properly designed languages (including both JavaScript and TypeScript). Their "Header" shadowing problem also might be due to a lack of understanding of namespaces. 4. They seem to conflate JavaScript vs TypeScript with single file vs multiple files. Of course you can have a single TypeScript file or you can have multiple JavaScript files and bundle them with any JS bundler or just concatenate them. Given that their codebase seems to be complex according to their compile time claims and that they don't seem particularly skilled given their claims, using a type-deficient language will most likely result in software full of bugs.
- untog 6y ago
  I’m never one for developer hero worship, but I feel safe assuming that Ryan Dahl’s development abilities are not the issue here.
- war1025 6y ago
  > 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead. Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescript code at work, I end up just modifying the compiled javascript to debug things because the compile loop is painfully slow.
  - 6y ago
eatonphil 6y ago
I don't remotely see TypeScript as the end state of statically typed JavaScript. I think it was the first major project to prove how static typing could work and benefit browser applications. Flow and TypeScript are just the first generation. In the future I expect the type system to be integrated with the runtime. While there are projects that give you this (Elm, Reason, Bridge.net, Fable, etc.), they are nowhere near as universal as TypeScript nor is that really their aim.
- searchableguy 6y ago
  I am a newbie reason user. I like the language and ocaml ecosystem but it is just a bit of a pain to do anything practical with it. Soon you are writing a lot of js in reason. Compared to typescript, js and reason mixed code stings like a sharp contrast between sun and moon. Until those languages make themselves feel just like js or completely remove excessive js interlop, they won't be as mainstream.
  - kqr 6y ago
    Huh, I don't share your experience at all. I maintain an F#-and-JS application and I'm constantly surprised by how well interpretation works. You literally just import F# code in JavaScript and use it, as well as the other way around. Sure, if you want to make maximal use of the strong typing of F#, you'll have to annotate JS data as it comes in, but that is necessary complexity, not incidental. And if you're happy with having your F# code "dynamically typed", there's zero ceremony around importing JS stuff.
jakear 6y ago
I’m a long time fan of TS, but I think this is a very exciting decision —- I have always been of the opinion any reasonably large project should workout a doubt use TS, so hearing about how this goes for them in 2/5/10 years in terms of how easily people are able to maintain code they didn’t create, how readily large refactorings can be made, how often runtime type errors occur (not just the literal TypeError, but all the things TS can catch, like null checks, index typing checks, etc) will be quite interesting. I wish them luck! One note of concern though: in their design doc they say incremental compilation is the number one problem and list multi-minute compile times. That’s huge! I wouldn’t use TS either of it took minutes to compile my projects. However, I think there’s room for improvement in their tooling if they took some time to explore what other large TS projects do instead of just giving up on it entirely —- VSCode for instance has incremental compilation in hundreds of ms or less.
- smhmd 6y ago
  What a measured response!
underdeserver 6y ago
Due respect, these are issues with how the Deno team uses Typescript, not with the language itself. > TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript. > The Typescript structure that they’re using in the source files that create the actual Deno executable and the user-facing APIs is creating runtime performance problems Then use a better structure? ? TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations https://github.com/denoland/deno/issues/4748 https://github.com/denoland/deno/issues/4748 Then consolidate the two classes...? How is the the language's fault? > The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files Well, it can be. Fix your build rules. > They’re maintaining two TS compiler hosts: one for the internal Deno code and another other for external user code even though both have a similar goal Again, not the language's fault. --- We've been using Typescript for a couple of years now, and it's been great. By trying to do things the right way, it actually forces us to organize our code better. I think the Deno project would benefit from refactoring their code to solve their issues, instead of blaming the tools.
- smhmd 6y ago
  > not the languages's fault. I think that's the whole point. It's not the right tool for their specific goal. In their design doc[0], they agree that Rust glue code should not be written in TS: compiled code "full of weird namespaces." From the design doc discussion[0]: ry: manually managing the d.ts files has been great - it's very much part of the public interface - we need to have 100% control over it we do not want random compiler-generated __namespace0123 in there This is the same situation - but for the bundle It's not good that we do not have visibility nor control over what code is in there. for example, the TS compiler worker, has 15k lines of code in its bundle - EXCLUDING typescript.js TS compiler worker is about 500 line thing that interfaces between ops and TSC this is caused by our attempt to "self host" the internal code self hosting is cute - but if it's effecting performance and the ability to make improvements - it's an unnecessary feature https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 ^--- here is what we ship for the compiler worker we call this code every time deno runs lucacasonato: Ok, wow. I hadn't seen this. That changes things... ry: does the compiler worker really need to generate a UUID? https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#file-compiler_snapshot-js-L9982 https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#... (no) yes, this is fixable within the current system .. but the point is that we're abstracting away the important parts V8 does not run typescript. It runs JS. We need to have a good handle on the JS we ship If we don't try to self-host, we don't need a sourcemap for the internal code. There's 1mb off the executable right there. The point is the internal typescript comes at a cost - and that cost is too high. lucacasonato: So the actual issue is the bundling and opaqueness that that brings with it. It makes sense to stick to pure JS in that case. Its annoying that type checking is gone, but youre right. This is not the kind of code that should be in the runtime. ry: not like the code isn't full of "!" anyway. TS is great, but it gives a false sense of security. [0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/edit?usp=sharing https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
koolba 6y ago
Why remove it entirely rather than split off compilation and type checking? I’m not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.
- anonymousCar 6y ago
  As other's have pointed out, it really sounds like the deno devs were unfamiliar with what's available with build options for typescript. An unanswered question everyone is asking, why do they handwrite the .d.ts that can be autogenerated?
brown9-2 6y ago
> One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations ... choice of programming languages is irrelevant here.
zvmxczxvmcz 6y ago
I'm doing a medium/large project in Coffeescript 2 and it's totally awesome. Rarely a type related bug and I'm progressing waaay faster than having to deal with TS in my way. But for anyone enjoying to specify their types in detail, have fun!
- holler 6y ago
  wow that’s cool to hear! I read about coffee 2 awhile ago and then heard nothing of it. I used to love coffeescript, arguably more than vanilla js, but forces that be led me to move on. are you working with a team? if so was it easy to get buy-in?
moogly 6y ago
Has anyone seen any comments by the TS team on this? Maybe they would be amenable to helping out if the Deno team contacted them.
- apetrovic 6y ago
  Honestly, what is a meaningful answer when someone blames language for problem with having two separate classes with the same name?
- smhmd 6y ago
  https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
RivieraKid 6y ago
I wish Dart was more popular as a JS alternative. I've been using it recently it's really surprisingly productive and fun.
- heavyset_go 6y ago
  Does Dart still allow you to compile to JS or was that feature dropped?
  - Rapzid 6y ago
    It must; the SASS reference implementation is written in Dart and the npm package is transpired from that.
- hashbig 6y ago
  Most of what Dart offers was addressed in ES2017 and beyond. I think it was released a little too late in my opinion.
jackjeff 6y ago
I’m very perplexed about the reasoning. Aside from the compiling takes time issue, the rest sounds like trolling. If the code was organized in a way which is inefficient and confusing, I fail to see why checking types at runtime instead of compile types improves the structure. It’s a completely separate problem.
jeswin 6y ago
Typescript may not work for all types of applications - in fact there is no language that does. So picking one project and generalizing it often comes out of inexperience. As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.
WClayFerguson 6y ago
Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up. Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc. All you're doing by switching from TS to JS, is trading one set of minor problems (which are solvable) to a more vast set of even larger problems that are NOT solvable.
- inimino 6y ago
  Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.
  - holler 6y ago
    That is one key thing I see a disconnect with. I definitely can see the value in having static types in a long-lived/large js project, but at the same time 1) how long does the average js project really stay relevant, 2) people have got by just fine w/o it so far. I’m kind of mixed on it, but for my new web app I’m working on I decided to use vanilla js because it feels much more efficient.
    - WClayFerguson 6y ago
      And if you converted your code to TypeScript you'd immediately find the 100 or 1000 bugs you have that you're just unaware of until they bite. People who have done such a conversion before know this, and unanimously will agree. Those who have't are blissfully ignorant.
  - WClayFerguson 6y ago
    Here's a pretty sizable project I wrote in pure TypeScript: https://github.com/Clay-Ferguson/quantizr https://github.com/Clay-Ferguson/quantizr I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.
meowzero 6y ago
We were actually considering Deno because of its TypeScript support. We have a sizeable TypeScript codebase written for Node. This will probably make us more likely to stay in Node. EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.
- smhmd 6y ago
  In the design doc, you can read this disclaimer: > Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
- the_gipsy 6y ago
  You can't just run your typed node.js app in deno. (Almost) all npm packages that are written in typescript expose .js and then .d.ts files, so you can't "just import the .ts". This is because of huge variances in tsconfig.json files.
burtonator 6y ago
I've migrated to Typescript and have been using it for about 2 years now. Maybe 1.5... TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works. The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design). Here's the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code. You can save a lot of time now writing new code and not using strict typing. OR you can spend a little bit of time now, maintaining your types, and save a MASSIVE amount of time later. > - TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process I have a HUGE typescript repo and using a Macbook Pro from 2015... With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that. If your build is taking a long time - you're doing something wrong. > The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files What? How? That doesn't make any sense. You're doing something wrong here. If all the code is in typescript, you have no additional work to do. If it's in JS you just have to write your own .d.ts files manually. Honestly it seems like this team just needs to sit down and understand how their tools actually work. The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types. Many older projects just don't publish types and if you rely on them, and they refuse to publish types, you're going to be in a bit of pain. You can write your own types though and we've been doing this internally and for some repos just forking them so it's a bit easier to work with them. They usually lag on publishing their types. If you want to avoid all this pain you can just use webpack for your build system and Typescript for your code. We use lerna to build a multi-module system with --hoist to avoid duplicate dependencies. https://github.com/burtonator/polar-bookshelf https://github.com/burtonator/polar-bookshelf ... is the project we're working on if you want to check it out. Our internal build system isn't fully published yet as we're in the process of reworking it but we're open source so you can take a look if you want.
- electrotype 6y ago
  I'm wondering about "--watch" too... My projects are compiled in the background, like pretty much instantly. The only time I wait is when I restart the applications. But I suppose they are aware of this flag.
chmln 6y ago
> TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode. [1] https://github.com/flatpickr/flatpickr https://github.com/flatpickr/flatpickr
smhmd 6y ago
Everyone is drawing conclusions without much context. Read the design doc[0]. [0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...
IBCNU 6y ago
I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.
- qayxc 6y ago
  > Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...
  - verdagon 6y ago
    I dont know Haskell that well, but I thought it had strong static typing? Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?
    - IBCNU 6y ago
      I come from a clojure background, maybe that's why I don't enjoy TS. I find that large projects, so much code is un-necessary, people spend a lot of time troubleshooting types instead of building functionality. Of course it depends on the project. Social security #'s is a different scenario than something like a game or frivolous retail...
- jkachmar 6y ago
  > Types are for compilers, not people [...] This strikes me as a similar sentiment to “Requirements are for managers, not engineers”
- eyerony 6y ago
  > Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time. Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people. As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.
k__ 6y ago
"Always bet on JavaScript" holds true, I guess.
Peteris 6y ago
This seems to lend more credit to ReasonML. Compile times are faster and it doesn't bring the associated complexity of object types while still retaining the benefits of static typing.
chvid 6y ago
Thank you. Finally people are speaking out against the madness of TypeScript. Don't get me wrong. It is a technical achievement to put a static type system on top of JavaScript. And for libraries, it is useful. It let's the users of the library get hints and direction from an editor like Visual Studio. But as a language. It is just not good. No way anyone would end up with a design like that had it been built from scratch without going through JavaScript first. Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...
seemslegit 6y ago
Why Deno ?
- kybernetikos 6y ago
  Deno Deno deno deNo deNodeNodeNo...
  - seemslegit 6y ago
    That wasn't a question about the naming.
    - kybernetikos 6y ago
      You might need to say a bit more about what it is a question about if you want an answer.
      - seemslegit 6y ago
        "Why X ?" is a common shorthand for "What is the raison d'être of X ?"
        kybernetikos 6y ago
        Well, in all the initial presentations Ryan Dahl gave about Deno, he phrased it as solving the things he'd come to realise he hated about Node. So that's what I take as the raison d'être of Deno - taking the lessons he'd learned from some years mainly coding Go and thinking about what he'd learnt from Node, and fixing what he could. Here's the classic video on the topic: https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA
pvg 6y ago
Discussion from two weeks ago: https://news.ycombinator.com/item?id=23462506 https://news.ycombinator.com/item?id=23462506
gjpowell 6y ago
It seems weird to ask other projects to use Typescript when running on Deno when Deno isn't using typescript internally? If you're the Deno team wouldn't you want to dogfood Typescript?
- inimino 6y ago
  Nobody's asking them to.
- hashbig 6y ago
  Different use cases = different technologies.
j1elo 6y ago
I just hope in 5 years we're not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that! (I'm just referring to this nice talk about the regretful mistakes done in Node: https://youtu.be/M3BM9TB-8yA https://youtu.be/M3BM9TB-8yA)
fbn79 6y ago
This is a great victory for Ecmascript. Typescript is a great hinting support language, I use it with JsDoc to check my (not transpired, vanilla js) code. But it cannot replace JavaScript and is not a JavaScript superset. I think If anyone what to accept the drawbacks of have transpiration of source files can choose better alternative to typescript.
kumarvvr 6y ago
HN gods, an off topic question. Would Deno become the new Node? Do you see a vibrant ecosystem building around Deno? What I am interested to know primarily is, is the architecture / stack / goals and vision that resulted in Deno viable in the long term?
- zodiakzz 6y ago
  Deno's main selling point over Node.js seems to be some dubious sandboxing. Unlikely to be compelling enough for people to rewrite their applications from using Node's stdlib to Deno's. Personally, it makes me cringe to see hard-coded HTTP URLs in source code files for loading dependencies. They present it like we're stupid for using package managers all this time. What used to be a simple command line option (changing a package repo) is now a thousand file edit. Excellent.
pjmlp 6y ago
So it happens again, yet another project discovers that whatever improvements a guest language brings into a platform, using it also has its costs versus using the main language of the platform.
diffrinse 6y ago
I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc annotations. If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.
- samhh 6y ago
  TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.
  - diffrinse 6y ago
    But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits. Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started. For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript. tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?
    - samhh 6y ago
      Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible. PureScript I really like but it's a massive jump from JS/TS to PS/HS. All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense. Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.
aogaili 6y ago
Always bet on Javascript.
inimino 6y ago
There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
- snek 6y ago
  Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.
  - yawaramin 6y ago
    That passage didn't say anything about finding the document 'amusing'.
  - dbnoch 6y ago
    I thought the "novice" programmer remark was a pretty cringe-worthy comment. The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".
    - Aeolun 6y ago
oliwarner 6y ago
You know when you say a word over and over again and it starts to lose meaning? Well, I didn't have a clue what Deno was before, but now it's barely letters in a screen. This post says Deno way too much. Deno.
chadlavi 6y ago
oh I thought at first that this meant they were dropping _support for_ typescript, not that they were stopping using ts under the hood. Getting closer to the metal seems good!
root_axis 6y ago
> I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous You do have that class of bug. That's like a cpp programmer saying they don't need smart-pointers because they never introduce memory leak bugs. You're a human.
errantspark 6y ago
I'm stoked on this change, frankly the TS layer being included in Deno felt like a mistake from the get-go and I'm glad they've come around on it. I've seen many transpile-to-JS languages come and go. Javascript is eternal. (Though I also think TS is a verbose mess made so that enterprise programmers/managers can feel safe, but even if it was great I still think this would have been a good choice)
deleted 6y ago
[deleted]
mirekrusin 6y ago
I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type declarations and when declaring functions and pretty much nowhere else. The code has interesting haskell'ish feel to it, ie. most of the code looks something like this: const ofId /*: (Sql, number) => Promise<User> */ = (sql, id) => ... I'm very happy with it after using it on quite complex projects, writing libraries (ie. functional combinators for parsers, assertions/runtime types, template sql generators; and the rest from apis, business logic to anything that is needed). Lack of libdefs is not a huge problem in my case. I have strong preference for shallow or no dependencies in projects and for things I use 3rd party code there are types or were converted from ts or simply added. Better support would help here but it was not a deal breaker. Code editor support is not as good as ts but it does the job. Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn't need transpilation step, can be edited as is; I'm free to use any directory structure, ie. I often use root directory to drop files, they have natural require/import paths, no configuration etc. For me, it's a joy to code like this.
- emptysea 6y ago
  typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j... I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works! Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.
  - mirekrusin 6y ago
    You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?
mikl 6y ago
> While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. It has flaws like any other language. This is not a language flaw. It is a tooling problem.
deleted 6y ago
[deleted]
dbnoch 6y ago
I felt like the article and associated google doc were fishing for reasons to remove TS until ry finally mentioned "typescript provides an extra 500 lines and the namespaces make the code harder to reason with (V8 ingests these files directly)". IMO that was the only solid reason for the change.
jimbob45 6y ago
Is there a reason we can ONLY use JavaScript in the browser? The world would immediately become better if we added a different language compiler on in instead.
- The_rationalist 6y ago
  The reason is language compatibility. But since graalvm solve that, browsers should include graalvm. Sadly this is not going to happen anytime soon, webassembly has too much lobbying
thayne 6y ago
There are tools to transpile typescript only, without doing typechecking, which dramatically reduces "compile time." It's very useful for a quick development iteration cycle, and then do a full type checking pass before merging and during CI.
holtwick 6y ago
I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results: (1) Use a faster bundler like esbuild, here vite's similar considerations [1] (2) Use Flow [2] and just strip it away before distribution like this Babel module [3] --- [1] https://github.com/vitejs/vite#typescript https://github.com/vitejs/vite#typescript [2] https://flow.org/ https://flow.org/ [3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip-types https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...
nojvek 6y ago
When Deno initially mentioned they run Typescript directly I was intrigued. It’s like running GCC every time you want to invoke the script. That being said I run ts-node all the time with transpile-only and that is decently fast. Even on production where the minimal cost is incurred once when loading the module. As for their problems mentioned on the document. That Header class has a .d.ts conflict on an interface. That could be solved with having namespaces in .d.ts or having I prefix for class interfaces. We do this all the time in our codebase. I’m not entirely sure why they have two copies of things. The doc doesn’t give much detail. If you want things to be fast like nodejs, then the other option is to use //@ts-check comments on JS files, or with compiler allowJS and checkJS settings. Webpack checks all their JS. TSC now also has an option to automatically generate .d.ts from JS files with jsdoc comments. With declarationOnly compiler flag. Many existing JS projects already do that. So TLDR is. You don’t have to ditch Typescript totally. Typescript can purely just be a checker that you run at CI time and it will work quite well with existing JS code. Although if you want super strict safety the .ts syntax is less verbose and nicer to write. Even then transpile only mode is much faster than running full tsc. Remember: TS is a superset of JS. All JS is valid typescript. Sometimes we gotta structure the JS properly and that’s where the issue is rather than the typesystem.

241 points by diablo1 6y ago

deleted 6y ago

[deleted]

Thank God, I would really appreciate this. The TypeScript usage was the one thing that I didn't like about Deno. Why add complexity to a new project which starts from scratch? JavaScript is good enough and there's no need to make it confusing by adding another layer.

untog 6y ago
This is talking about the internal Deno code. The user facing side will still support TypeScript, though you’re also free to not use it if you want.
lowercased 6y ago
> JavaScript is good enough and there's no need to make it confusing by adding another layer. To some people, JS itself is relatively confusing, and TypeScript reduces that confusion. EDIT: And... someone's clarification is saying this is internal framework code, not userland support for TS. Seems like a non-issue, really. They don't want to use it, but want to provide support for others to use it in their projects.
eloff 6y ago
You can use JavaScript with Deno. Nobody is forcing you to use TypeScript. This doesn't change anything, it's for their internals. Why anyone would ditch static typing on a large collaborative project is beyond me though.

jbverschoor 6y ago

Yeah. Same same. Not working, so let’s just fix it by creating another ecosystem instead of fixing compiletimes etc. I will refuse deno. Too much ego in JavaScript-land. “Everybody wants to be like Mike”. Errr Linus... Lowrey

untog 6y ago
Deno is made by the guy who made Node. So no change in notoriety there.

untog 6y ago

> While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. Woah, woah, hold on. This case is showing that in the very specific, atypical case the Deno team are using it in, TypeScript is not the right fit. I’d rather read something that actually interviews the Deno folks about what they are doing, the underlying document is a pretty free ranging discussion and this writeup is making a few assumptions.

braythwayt 6y ago
Lawd, the number of times people write an extensive essay detailing how a particular tool didn’t fit their culture, processes, and circumstances, then explain why it’s either irredeemably broken or conversely, that failing to adopt the tool is professional malpractice. N=1. That is all.
karmakaze 6y ago
May as well drop tests and code reviews if it feels like it's slowing you down. For one-person or very small teams who have full context of a'll changes this can actually work very well. It's with more contributors participating in a mature project that you'd wish these things weren't dropped. Types can be added later so it's not like using php and later wishing you'd used Kotlin.
- karmakaze 6y ago
  I'll add a datapoint of an analogous case. I updated a legacy java 1.x codebase that was running java 6/7 without generics. Having spent a small amount of effort over a course of months, all the type annotations were updated. It uncovered exactly one bug. The main improvement is for quickly gaining context in unfamiliar code and being able to enable warnings for newly written code without noisy error messages.

zdragnar 6y ago

> It’s worth mentioning that Deno will stop using TypeScript only for the internal Deno code: the Deno user code will still be in TypeScript and thus type checked.

vimslayer 6y ago

Here's the Deno Design document with the reasoning and some discussion about the decision: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... This post adds little to what's already said there.

whoisjuan 6y ago

This is gonna be an unpopular opinion but as someone who learned to program in loosely typed languages, I have never seen the TS appeal. TS feels like something that was created to lure programmers who couldn’t wrap their heads around JS loose nature. Almost like it was created to convince Java and C# developers to use JS. It have never felt about it like something that would make my code better or more organized. It definitely slows me down with very little benefits in return. (Again, can’t stress enough that this is a personal opinion based on personal use cases) I appreciate that it forces me to be more intentional about organizing my code but I also get that when I use frameworks. Of course I also appreciate when I can identify that an error is coming from a type mismatch, but as I said I learned to program in loosely typed languages first, so I never created that concept of defining types in my head. I’m always extra-aware of types mismatches in my JS code and is usually the first thing I check when something goes wrong. But I have never felt the need to have a way to explicitly define the types that I’m working with. I honestly fail to see the benefit when a large amount of code that you have to interact with (libraries and such) was written in classic JS. Once again. Probably unpopular opinion, so I don’t mind the downvotes.

deleted 6y ago
[deleted]
halfmatthalfcat 6y ago
You don’t see the benefits of a strongly typed language?
- cheez 6y ago
  Python is strongly typed, don't confuse static and strong typing.
  - whoisjuan 6y ago
    You’re right.
- whoisjuan 6y ago
  I do. But not for JS in particular. At the end of the day 95% of JS that is written in classic JS and is used in thousands of high-scale projects like that.

searchableguy 6y ago

They should just use deno to run their setup, there would be no compilation if they did that. ;) Someone is trying to rewrite tsc in rust for speed up here - https://github.com/swc-project/swc https://github.com/swc-project/swc Cool project for runtime checking with ts - https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts Edit: Remove unmaintained runtime type checking library.

wereHamster 6y ago
Instead of ts-runtime, use io-ts (https://github.com/gcanti/io-ts https://github.com/gcanti/io-ts). That one is actually maintained, unlike ts-runtime!
- deleted 6y ago
  [deleted]
- deleted 6y ago
  [deleted]

echelon 6y ago

Why such a large, important project would want to drop static types is beyond me. > TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations This feels like process immaturity or unfamiliarity. Thousands of other projects manage to do just fine. These folks are free to do what they want with their project, but this is not a good look, especially to those that are skeptical of the javascript ecosystem.

mimixco 6y ago
Lisp is large, important, and also not statically typed. It's worked out ok for Lisp programmers. JS itself isn't strongly typed and is the most successful and important language in the world (probably in the history of programming), so that's two game-changers that don't require static typing.
- efficax 6y ago
  there's plenty of huge software projects in dynamically typed languages. There are also huge classes of bugs that exist in these projects that a statically typed language completely eliminates! If they're running into trouble from having to have types, it's almost certainly design and architecture issue and does not make me think that deno is going to be a solid project.
  - mimixco 6y ago
    I didn't read that types were causing problems. My understanding was TS, itself, was causing problems. Specifically waiting around for it to compile. Strong typing is from OOPS, itself an optional programming methodology. There are many JS programs that simply access other (JSON) objects directly without going through an interface. In these instances, typing is counterproductive. One of the beautiful things about JS (and Lisp) is that variables and functions are interchangeable and, the case of JS, both can be accessed directly without worrying about an interface.

nathancahill 6y ago

Needs "internally" at the end of the title.

hakcermani 6y ago

Was using JS for about 6 yrs now and decided will start using TS for a new Node.js project. Admitted it has its warts ... hit my first bottleneck rightaway when parsing the request query param. TS Express bindings declare it as string | string[] | ParsedQs | ParsedQs[]. Ok extract it 'as' string and move on. But I find as I am using it more and more it is getting better (or I am getting more disciplined!) .. maybe I am reading this wrong re the long compile time reported, could the code not be broken into modules so the compile is more isolated ??

emptysea 6y ago
just a heads up, casting `as string` isn't safe since the request param could turn out to be an array. If the request ends up with the query param as an array, there isn't a runtime to validate the cast and now the variable is typed as `string` but is actually `string[]`. I think a safer approach is to use a validation library or refine the type with an if stmt and returning an error when it isn't a string. I use the following lint to prevent all casts except `as const`: https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/docs/rules/consistent-type-assertions.md https://github.com/typescript-eslint/typescript-eslint/blob/...
- hakcermani 6y ago
  Thanks for the headsup. I did realize that. It was a specific case of pulling a username from the query .. checking out the library ..

wufufufu 6y ago

Has anyone else experienced these issues? This reads more like product placement for Deno than a sincere criticism of TS.

war1025 6y ago
I've definitely noticed that compiling typescript is slow and extremely resource hungry. It's amusing to me that our "web" stack is the most resource intensive part of our entire codebase at work. A sign of the times I guess that a build system requires 8gb of ram to run. Could be we're doing something wrong, but from what I understand we're using a pretty vanilla setup.
- inimino 6y ago
  Unfortunately the state of web dev in 2020 is such that using a vanilla "best practice" setup is very much doing something wrong.

devit 6y ago

It seems it might be an issue with their development abilities or problem-solving motivation: 1. It seems that they write a ".d.ts" file manually in addition to using TypeScript for the code. This is dumb, since TypeScript generates the declarations automatically. However, for them "it was too much overhead and complexity when we attempted it before", which caused them to give up, a very dubious course of action. 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead. 3. They claim that "having two Body classes is obviously wrong" (?!). Of course having two classes with the same name in different namespaces/packages is perfectly fine in properly designed languages (including both JavaScript and TypeScript). Their "Header" shadowing problem also might be due to a lack of understanding of namespaces. 4. They seem to conflate JavaScript vs TypeScript with single file vs multiple files. Of course you can have a single TypeScript file or you can have multiple JavaScript files and bundle them with any JS bundler or just concatenate them. Given that their codebase seems to be complex according to their compile time claims and that they don't seem particularly skilled given their claims, using a type-deficient language will most likely result in software full of bugs.

untog 6y ago
I’m never one for developer hero worship, but I feel safe assuming that Ryan Dahl’s development abilities are not the issue here.
war1025 6y ago
> 2. They claim that changes take minutes to recompile, but TypeScript can compile incrementally, so this shouldn't happen assuming they are organizing their code properly. Also, you can just translate without type checking, which is no worse than using JavaScript instead. Interested to know how you're actually supposed to do this. I don't do much web development, but the few times I've had to dive into our typescript code at work, I end up just modifying the compiled javascript to debug things because the compile loop is painfully slow.
- 6y ago

eatonphil 6y ago

I don't remotely see TypeScript as the end state of statically typed JavaScript. I think it was the first major project to prove how static typing could work and benefit browser applications. Flow and TypeScript are just the first generation. In the future I expect the type system to be integrated with the runtime. While there are projects that give you this (Elm, Reason, Bridge.net, Fable, etc.), they are nowhere near as universal as TypeScript nor is that really their aim.

searchableguy 6y ago
I am a newbie reason user. I like the language and ocaml ecosystem but it is just a bit of a pain to do anything practical with it. Soon you are writing a lot of js in reason. Compared to typescript, js and reason mixed code stings like a sharp contrast between sun and moon. Until those languages make themselves feel just like js or completely remove excessive js interlop, they won't be as mainstream.
- kqr 6y ago
  Huh, I don't share your experience at all. I maintain an F#-and-JS application and I'm constantly surprised by how well interpretation works. You literally just import F# code in JavaScript and use it, as well as the other way around. Sure, if you want to make maximal use of the strong typing of F#, you'll have to annotate JS data as it comes in, but that is necessary complexity, not incidental. And if you're happy with having your F# code "dynamically typed", there's zero ceremony around importing JS stuff.

jakear 6y ago

I’m a long time fan of TS, but I think this is a very exciting decision —- I have always been of the opinion any reasonably large project should workout a doubt use TS, so hearing about how this goes for them in 2/5/10 years in terms of how easily people are able to maintain code they didn’t create, how readily large refactorings can be made, how often runtime type errors occur (not just the literal TypeError, but all the things TS can catch, like null checks, index typing checks, etc) will be quite interesting. I wish them luck! One note of concern though: in their design doc they say incremental compilation is the number one problem and list multi-minute compile times. That’s huge! I wouldn’t use TS either of it took minutes to compile my projects. However, I think there’s room for improvement in their tooling if they took some time to explore what other large TS projects do instead of just giving up on it entirely —- VSCode for instance has incremental compilation in hundreds of ms or less.

smhmd 6y ago
What a measured response!

underdeserver 6y ago

Due respect, these are issues with how the Deno team uses Typescript, not with the language itself. > TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process Umm, you can compile single files, and serve them individually. It's no different from bundling (e.g. with webpack) Javascript. > The Typescript structure that they’re using in the source files that create the actual Deno executable and the user-facing APIs is creating runtime performance problems Then use a better structure? ? TypeScript isn’t proving itself helpful to organize Deno code. On the contrary, the Deno team is experiencing the opposite effect. One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations https://github.com/denoland/deno/issues/4748 https://github.com/denoland/deno/issues/4748 Then consolidate the two classes...? How is the the language's fault? > The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files Well, it can be. Fix your build rules. > They’re maintaining two TS compiler hosts: one for the internal Deno code and another other for external user code even though both have a similar goal Again, not the language's fault. --- We've been using Typescript for a couple of years now, and it's been great. By trying to do things the right way, it actually forces us to organize our code better. I think the Deno project would benefit from refactoring their code to solve their issues, instead of blaming the tools.

smhmd 6y ago
> not the languages's fault. I think that's the whole point. It's not the right tool for their specific goal. In their design doc[0], they agree that Rust glue code should not be written in TS: compiled code "full of weird namespaces." From the design doc discussion[0]: ry: manually managing the d.ts files has been great - it's very much part of the public interface - we need to have 100% control over it we do not want random compiler-generated __namespace0123 in there This is the same situation - but for the bundle It's not good that we do not have visibility nor control over what code is in there. for example, the TS compiler worker, has 15k lines of code in its bundle - EXCLUDING typescript.js TS compiler worker is about 500 line thing that interfaces between ops and TSC this is caused by our attempt to "self host" the internal code self hosting is cute - but if it's effecting performance and the ability to make improvements - it's an unnecessary feature https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4 ^--- here is what we ship for the compiler worker we call this code every time deno runs lucacasonato: Ok, wow. I hadn't seen this. That changes things... ry: does the compiler worker really need to generate a UUID? https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#file-compiler_snapshot-js-L9982 https://gist.github.com/ry/a6d4b1466158d82750a6447342fd3af4#... (no) yes, this is fixable within the current system .. but the point is that we're abstracting away the important parts V8 does not run typescript. It runs JS. We need to have a good handle on the JS we ship If we don't try to self-host, we don't need a sourcemap for the internal code. There's 1mb off the executable right there. The point is the internal typescript comes at a cost - and that cost is too high. lucacasonato: So the actual issue is the bundling and opaqueness that that brings with it. It makes sense to stick to pure JS in that case. Its annoying that type checking is gone, but youre right. This is not the kind of code that should be in the runtime. ry: not like the code isn't full of "!" anyway. TS is great, but it gives a false sense of security. [0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/edit?usp=sharing https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

koolba 6y ago

Why remove it entirely rather than split off compilation and type checking? I’m not familiar with the Deno codebase, but a similar problem with large webpack projects is solved by having the type checking be an async process. This gives the best of both worlds as you transpiling alone is near instant.

anonymousCar 6y ago
As other's have pointed out, it really sounds like the deno devs were unfamiliar with what's available with build options for typescript. An unanswered question everyone is asking, why do they handwrite the .d.ts that can be autogenerated?

brown9-2 6y ago

> One of the issues mentioned is that they ended up with duplicate independent Body classes in two locations ... choice of programming languages is irrelevant here.

zvmxczxvmcz 6y ago

I'm doing a medium/large project in Coffeescript 2 and it's totally awesome. Rarely a type related bug and I'm progressing waaay faster than having to deal with TS in my way. But for anyone enjoying to specify their types in detail, have fun!

holler 6y ago
wow that’s cool to hear! I read about coffee 2 awhile ago and then heard nothing of it. I used to love coffeescript, arguably more than vanilla js, but forces that be led me to move on. are you working with a team? if so was it easy to get buy-in?

moogly 6y ago

Has anyone seen any comments by the TS team on this? Maybe they would be amenable to helping out if the Deno team contacted them.

apetrovic 6y ago
Honestly, what is a meaningful answer when someone blames language for problem with having two separate classes with the same name?
smhmd 6y ago
https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

RivieraKid 6y ago

I wish Dart was more popular as a JS alternative. I've been using it recently it's really surprisingly productive and fun.

heavyset_go 6y ago
Does Dart still allow you to compile to JS or was that feature dropped?
- Rapzid 6y ago
  It must; the SASS reference implementation is written in Dart and the npm package is transpired from that.
hashbig 6y ago
Most of what Dart offers was addressed in ES2017 and beyond. I think it was released a little too late in my opinion.

jackjeff 6y ago

I’m very perplexed about the reasoning. Aside from the compiling takes time issue, the rest sounds like trolling. If the code was organized in a way which is inefficient and confusing, I fail to see why checking types at runtime instead of compile types improves the structure. It’s a completely separate problem.

jeswin 6y ago

Typescript may not work for all types of applications - in fact there is no language that does. So picking one project and generalizing it often comes out of inexperience. As a counter example, VSCode is easily bigger than the Deno codebase. Again, that doesn't mean it's good for your project.

WClayFerguson 6y ago

Using JS instead of TypeScript is very short-sighted and they will regret it, eventually. Sounds like they got frustrated and gave up. Their arguments remind me of someone saying they want to use Assembly Language instead of C++, because assemblers are faster than compilers, or to not have to worry about memory heap issues, etc. All you're doing by switching from TS to JS, is trading one set of minor problems (which are solvable) to a more vast set of even larger problems that are NOT solvable.

inimino 6y ago
Spoken like someone who's never solved problems with medium-to-large scale JS projects... criticising people who have.
- holler 6y ago
  That is one key thing I see a disconnect with. I definitely can see the value in having static types in a long-lived/large js project, but at the same time 1) how long does the average js project really stay relevant, 2) people have got by just fine w/o it so far. I’m kind of mixed on it, but for my new web app I’m working on I decided to use vanilla js because it feels much more efficient.
  - WClayFerguson 6y ago
    And if you converted your code to TypeScript you'd immediately find the 100 or 1000 bugs you have that you're just unaware of until they bite. People who have done such a conversion before know this, and unanimously will agree. Those who have't are blissfully ignorant.
- WClayFerguson 6y ago
  Here's a pretty sizable project I wrote in pure TypeScript: https://github.com/Clay-Ferguson/quantizr https://github.com/Clay-Ferguson/quantizr I have 5 years experience in TS and 20 in JS. Trust me, if you don't yet understand the value of type-safety, it's only because you haven't lived long enough yet.

meowzero 6y ago

We were actually considering Deno because of its TypeScript support. We have a sizeable TypeScript codebase written for Node. This will probably make us more likely to stay in Node. EDIT: I didn't read the article thoroughly. It looks like they're still supporting Typescript user code.

smhmd 6y ago
In the design doc, you can read this disclaimer: > Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.
the_gipsy 6y ago
You can't just run your typed node.js app in deno. (Almost) all npm packages that are written in typescript expose .js and then .d.ts files, so you can't "just import the .ts". This is because of huge variances in tsconfig.json files.

burtonator 6y ago

I've migrated to Typescript and have been using it for about 2 years now. Maybe 1.5... TS is the best language I've used. It supports frontend and backend and strict typing and it's scalable so I can refactor and know that my code still works. The one thing its not good at is ML where Python is better but that's mostly because Python has better library support (not language design). Here's the deal. When dealing with a large amount of code 80% of your dev time is spent maintaining code - NOT writing new code. You can save a lot of time now writing new code and not using strict typing. OR you can spend a little bit of time now, maintaining your types, and save a MASSIVE amount of time later. > - TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process I have a HUGE typescript repo and using a Macbook Pro from 2015... With --incremental and --watch my build takes like 5 seconds. About 1 minute on the first build then about 5 seconds after that. If your build is taking a long time - you're doing something wrong. > The internal code and runtime TypeScript declarations must be manually kept in sync since the TypeScript Compiler isn’t helpful to generate the d.ts files What? How? That doesn't make any sense. You're doing something wrong here. If all the code is in typescript, you have no additional work to do. If it's in JS you just have to write your own .d.ts files manually. Honestly it seems like this team just needs to sit down and understand how their tools actually work. The one issue where Typescript DOES kind of suck is when dealing with webpack, typemaps, and types. Many older projects just don't publish types and if you rely on them, and they refuse to publish types, you're going to be in a bit of pain. You can write your own types though and we've been doing this internally and for some repos just forking them so it's a bit easier to work with them. They usually lag on publishing their types. If you want to avoid all this pain you can just use webpack for your build system and Typescript for your code. We use lerna to build a multi-module system with --hoist to avoid duplicate dependencies. https://github.com/burtonator/polar-bookshelf https://github.com/burtonator/polar-bookshelf ... is the project we're working on if you want to check it out. Our internal build system isn't fully published yet as we're in the process of reworking it but we're open source so you can take a look if you want.

electrotype 6y ago
I'm wondering about "--watch" too... My projects are compiled in the background, like pretty much instantly. The only time I wait is when I restart the applications. But I suppose they are aware of this flag.

chmln 6y ago

> TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process They must be doing something horribly wrong, because tsc takes literally 1 second for my 3KLOC codebase[1] in incremental mode. [1] https://github.com/flatpickr/flatpickr https://github.com/flatpickr/flatpickr

smhmd 6y ago

Everyone is drawing conclusions without much context. Read the design doc[0]. [0]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS...

IBCNU 6y ago

I used Typescript for 2 years, and I'm happy to report I'm dropping it and encouraging my team to do the same. Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time.

qayxc 6y ago
> Types are for compilers, not people, and personally I think there's more disadvantages than advantages The Haskell community strongly disagrees...
- verdagon 6y ago
  I dont know Haskell that well, but I thought it had strong static typing? Though, Haskell figures out the types for you, instead of you typing them in, maybe thats a big difference. In Haskell, do you find you have to think about the types anyway, or can you code it like you would clojure?
  - IBCNU 6y ago
    I come from a clojure background, maybe that's why I don't enjoy TS. I find that large projects, so much code is un-necessary, people spend a lot of time troubleshooting types instead of building functionality. Of course it depends on the project. Social security #'s is a different scenario than something like a game or frivolous retail...
jkachmar 6y ago
> Types are for compilers, not people [...] This strikes me as a similar sentiment to “Requirements are for managers, not engineers”
eyerony 6y ago
> Types are for compilers, not people, and personally I think there's more disadvantages than advantages re: time. Hard disagree. Types are for people. They're for people to tell compilers what to tell people. Which is incredibly useful. They are first and foremost a communication and code-navigation/wayfinding tool—for people. As for all this extra time some folks keep complaining about, we must be using TypeScript entirely differently, somehow. I don't get it at all. Its overhead is less than the time it saves me in typo-spotting alone, let alone all the other benefits. Takes 5%, gives back 20-30%. It's not even close. Maybe it's a problem for really, really slow typists? I'm not even some kind of editor wizard and it hardly slows me down. It can't be thinking up the type definitions since you need to do that anyway—right? I hope? And at that point you may as well write them down.

k__ 6y ago

"Always bet on JavaScript" holds true, I guess.

Peteris 6y ago

This seems to lend more credit to ReasonML. Compile times are faster and it doesn't bring the associated complexity of object types while still retaining the benefits of static typing.

chvid 6y ago

Thank you. Finally people are speaking out against the madness of TypeScript. Don't get me wrong. It is a technical achievement to put a static type system on top of JavaScript. And for libraries, it is useful. It let's the users of the library get hints and direction from an editor like Visual Studio. But as a language. It is just not good. No way anyone would end up with a design like that had it been built from scratch without going through JavaScript first. Remember when Java did generics and got flak because of type erasure? Compare with TypeScript ...

seemslegit 6y ago

Why Deno ?

kybernetikos 6y ago
Deno Deno deno deNo deNodeNodeNo...
- seemslegit 6y ago
  That wasn't a question about the naming.
  - kybernetikos 6y ago
    You might need to say a bit more about what it is a question about if you want an answer.
    - seemslegit 6y ago
      "Why X ?" is a common shorthand for "What is the raison d'être of X ?"
      - kybernetikos 6y ago
        Well, in all the initial presentations Ryan Dahl gave about Deno, he phrased it as solving the things he'd come to realise he hated about Node. So that's what I take as the raison d'être of Deno - taking the lessons he'd learned from some years mainly coding Go and thinking about what he'd learnt from Node, and fixing what he could. Here's the classic video on the topic: https://www.youtube.com/watch?v=M3BM9TB-8yA https://www.youtube.com/watch?v=M3BM9TB-8yA

pvg 6y ago

Discussion from two weeks ago: https://news.ycombinator.com/item?id=23462506 https://news.ycombinator.com/item?id=23462506

gjpowell 6y ago

It seems weird to ask other projects to use Typescript when running on Deno when Deno isn't using typescript internally? If you're the Deno team wouldn't you want to dogfood Typescript?

inimino 6y ago
Nobody's asking them to.
hashbig 6y ago
Different use cases = different technologies.

j1elo 6y ago

I just hope in 5 years we're not seeing a talk saying that in retrospective, dropping static types was a huge error... and DoNe is a new project to fix issues like that! (I'm just referring to this nice talk about the regretful mistakes done in Node: https://youtu.be/M3BM9TB-8yA https://youtu.be/M3BM9TB-8yA)

fbn79 6y ago

This is a great victory for Ecmascript. Typescript is a great hinting support language, I use it with JsDoc to check my (not transpired, vanilla js) code. But it cannot replace JavaScript and is not a JavaScript superset. I think If anyone what to accept the drawbacks of have transpiration of source files can choose better alternative to typescript.

kumarvvr 6y ago

HN gods, an off topic question. Would Deno become the new Node? Do you see a vibrant ecosystem building around Deno? What I am interested to know primarily is, is the architecture / stack / goals and vision that resulted in Deno viable in the long term?

zodiakzz 6y ago
Deno's main selling point over Node.js seems to be some dubious sandboxing. Unlikely to be compelling enough for people to rewrite their applications from using Node's stdlib to Deno's. Personally, it makes me cringe to see hard-coded HTTP URLs in source code files for loading dependencies. They present it like we're stupid for using package managers all this time. What used to be a simple command line option (changing a package repo) is now a thousand file edit. Excellent.

pjmlp 6y ago

So it happens again, yet another project discovers that whatever improvements a guest language brings into a platform, using it also has its costs versus using the main language of the platform.

diffrinse 6y ago

I'm a little shocked at some of the outcry in this thread. People are making it sound like they're switching from Rust to Ruby or extolling the virtues of types: TypeScript does absolutely nothing for you at runtime. There are no types, there are no type checks, its all the same guarantees as good ol' JavaScript. You still can't trust function parameters to be what they say. It's a Babel configuration with inline doc annotations. If people are serious about types, then why isn't more front-end moving over to Elm, Reason, PureScript, OCaml etc? Hell, GWT is still out here even. TypeScript has convinced people they're getting the benefits of (strong?) types when they're just populating the auto-complete in VS Code.

samhh 6y ago
TypeScript is really about type safety within the confines of your application. You can address the unsafety at the edges with something like io-ts.
- diffrinse 6y ago
  But this is a niche application of TypeScript, most day-to-day front-end devs I've interviewed aren't reaching for fp-ts, let alone io-ts, whatever the benefits. Even then, why not just use any one of Elm, PureScript, Reason, ScalaJS, etc? Why implement yet another FP runtime? If something like this is the surest way to make optimal use of TypeScript then I feel like we're just right back where we started. For most devs, I'd wager they're still ending up writing all the same tests they were before TypeScript. tsc even offers to just consume jsdoc annotations for crying out loud. If its just some kind of type convention sandbox, what did it really bring to the table?
  - samhh 6y ago
    Elm's got questionable support; I wouldn't feel comfortable recommending that at work, it'd be irresponsible. PureScript I really like but it's a massive jump from JS/TS to PS/HS. All of these languages are harder to abandon than a library in the same language you'll keep using if you decide against the paradigm down the road. Do I like this compromise? Not really, but it makes sense. Also, advertising use of a functional language might open you up to candidates who wouldn't otherwise apply.

aogaili 6y ago

Always bet on Javascript.

inimino 6y ago

There are so many uninformed and misinformed comments on this post. Please read the design doc[1] before commenting if you assume the Deno team is doing it wrong, or hasn't ever considered some obvious solution you came up with in 0.7 seconds. [1]: https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS8ypsTPqed4Btkqkn_-4/preview?pru=AAABcrrKL5k*nQ4LS569NsRRAce2BVanXw# https://docs.google.com/document/d/1_WvwHl7BXUPmoiSeD8G83JmS... First paragragh of that document: > Update June 10 2020: I saw that this design doc was being discussed more widely. Most people don't have the context to understand this narrow technical document - it is only applicable to a very particular, very technical situation in the internals of Deno. This is not at all a reflection on the usefulness of TypeScript in general. It's not a discussion about any publicly visible interface in Deno. Deno, of course, will support TypeScript forever. A website or server written in TypeScript is a very very different type of program than Deno - maybe much more so than novice programmers can appreciate - little of Deno is written in TypeScript. The target audience is the 5 to 10 people who work on this particular internal system. Please don't draw any broader conclusions.

snek 6y ago
Gotta appreciate the part implying that anyone who finds this document amusing is a "novice" programmer.
- yawaramin 6y ago
  That passage didn't say anything about finding the document 'amusing'.
- dbnoch 6y ago
  I thought the "novice" programmer remark was a pretty cringe-worthy comment. The original reasons listed by Deno for removing TS had the undertones of "senior engineer who hates certain tech because they didn't use it right". Naturally, their response was to say "you probably don't understand cause you're a novice".
  - Aeolun 6y ago

oliwarner 6y ago

You know when you say a word over and over again and it starts to lose meaning? Well, I didn't have a clue what Deno was before, but now it's barely letters in a screen. This post says Deno way too much. Deno.

chadlavi 6y ago

oh I thought at first that this meant they were dropping _support for_ typescript, not that they were stopping using ts under the hood. Getting closer to the metal seems good!

root_axis 6y ago

> I never have the class of bugs in my projects that people seem to laud about typing to solve. It’s kind of ridiculous You do have that class of bug. That's like a cpp programmer saying they don't need smart-pointers because they never introduce memory leak bugs. You're a human.

errantspark 6y ago

I'm stoked on this change, frankly the TS layer being included in Deno felt like a mistake from the get-go and I'm glad they've come around on it. I've seen many transpile-to-JS languages come and go. Javascript is eternal. (Though I also think TS is a verbose mess made so that enterprise programmers/managers can feel safe, but even if it was great I still think this would have been a good choice)

deleted 6y ago

[deleted]

mirekrusin 6y ago

I found sweet spot for myself - flow with types in comments. As weird as it sounds it works for me on quite complex projects very well. Unlike typescript, which is language transpiler like coffeescript - flow is just typechecker with guarantee that after stripping types the output is valid js. It wouldn't work with ts, which generates runtime code ie. enums etc. Very good type inference means types appear as type declarations and when declaring functions and pretty much nowhere else. The code has interesting haskell'ish feel to it, ie. most of the code looks something like this: const ofId /*: (Sql, number) => Promise<User> */ = (sql, id) => ... I'm very happy with it after using it on quite complex projects, writing libraries (ie. functional combinators for parsers, assertions/runtime types, template sql generators; and the rest from apis, business logic to anything that is needed). Lack of libdefs is not a huge problem in my case. I have strong preference for shallow or no dependencies in projects and for things I use 3rd party code there are types or were converted from ts or simply added. Better support would help here but it was not a deal breaker. Code editor support is not as good as ts but it does the job. Another interesting effect is that arbitrarily deep npm linking is so much easier, the code is just js, doesn't need transpilation step, can be edited as is; I'm free to use any directory structure, ie. I often use root directory to drop files, they have natural require/import paths, no configuration etc. For me, it's a joy to code like this.

emptysea 6y ago
typescript also supports type checking js code: https://www.typescriptlang.org/docs/handbook/type-checking-javascript-files.html https://www.typescriptlang.org/docs/handbook/type-checking-j... I've found this very useful for gradually migrating a node.js project to a more maintainable state. Types also mean autocomplete works! Additionally since it's typescript we can download the `@types/` packages for our dependencies and get type checking for those as well.
- mirekrusin 6y ago
  You can't do too many things with jsdoc, can you? Ie. generics are not supported or basic things like importing types from other file, right? Ergonomy/verbosity/look and feel of those types in jsdoc is a bit poor IMHO as well. It's absolutely not the same thing. With flow you get the whole flow, with jsdoc it seems some scraps of typechecking. Am I wrong?

mikl 6y ago

> While TypeScript is sometimes seen as an improved version of JavaScript, this case is showing that in fact, it’s not. It has flaws like any other language. This is not a language flaw. It is a tooling problem.

deleted 6y ago

[deleted]

dbnoch 6y ago

I felt like the article and associated google doc were fishing for reasons to remove TS until ry finally mentioned "typescript provides an extra 500 lines and the namespaces make the code harder to reason with (V8 ingests these files directly)". IMO that was the only solid reason for the change.

jimbob45 6y ago

Is there a reason we can ONLY use JavaScript in the browser? The world would immediately become better if we added a different language compiler on in instead.

The_rationalist 6y ago
The reason is language compatibility. But since graalvm solve that, browsers should include graalvm. Sadly this is not going to happen anytime soon, webassembly has too much lobbying

thayne 6y ago

There are tools to transpile typescript only, without doing typechecking, which dramatically reduces "compile time." It's very useful for a quick development iteration cycle, and then do a full type checking pass before merging and during CI.

holtwick 6y ago

I can fully understand that an additional tool layer can cause additional problems, but static type checking is a large quality win for large projects. There are workarounds to achieve similar results: (1) Use a faster bundler like esbuild, here vite's similar considerations [1] (2) Use Flow [2] and just strip it away before distribution like this Babel module [3] --- [1] https://github.com/vitejs/vite#typescript https://github.com/vitejs/vite#typescript [2] https://flow.org/ https://flow.org/ [3] https://babeljs.io/docs/en/babel-plugin-transform-flow-strip-types https://babeljs.io/docs/en/babel-plugin-transform-flow-strip...

nojvek 6y ago

When Deno initially mentioned they run Typescript directly I was intrigued. It’s like running GCC every time you want to invoke the script. That being said I run ts-node all the time with transpile-only and that is decently fast. Even on production where the minimal cost is incurred once when loading the module. As for their problems mentioned on the document. That Header class has a .d.ts conflict on an interface. That could be solved with having namespaces in .d.ts or having I prefix for class interfaces. We do this all the time in our codebase. I’m not entirely sure why they have two copies of things. The doc doesn’t give much detail. If you want things to be fast like nodejs, then the other option is to use //@ts-check comments on JS files, or with compiler allowJS and checkJS settings. Webpack checks all their JS. TSC now also has an option to automatically generate .d.ts from JS files with jsdoc comments. With declarationOnly compiler flag. Many existing JS projects already do that. So TLDR is. You don’t have to ditch Typescript totally. Typescript can purely just be a checker that you run at CI time and it will work quite well with existing JS code. Although if you want super strict safety the .ts syntax is less verbose and nicer to write. Even then transpile only mode is much faster than running full tsc. Remember: TS is a superset of JS. All JS is valid typescript. Sometimes we gotta structure the JS properly and that’s where the issue is rather than the typesystem.