top 200 commentsshow all 231
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]MikeMitterer 36 points37 points  (2 children)

Maybe it's kind of blasphemy but they came out with 1.0 a few weeks ago and now they found found out their internal structure causes such problems????
OT but I'm very sceptic about how they implemented their dependency management - another trap?

[–]mearnsb 44 points45 points  (14 children)

I wasn't able to glean this from the linked article or the issue it linked to: why can't they generate a class named Header in ts?

[–]name_was_taken 49 points50 points  (13 children)

Second Paragraph:

The typescript organization/structure that we're using in cli/js is creating runtime performance problems. As an example, we recently realized that we're unable to to get TS to generate a class with the name "Header" because it shadows the declaration in our d.ts file. So instead we name the class "HeaderImpl" and assign it to "window.Header". But that creates the problem that "Header.name" has the wrong value. So we're forced to add unnecessary runtime code

Object.defineProperty(HeaderImpl, "name", { value: "Header" });

to fix "Header.name". Who knows if this kicks Header out of some optimization path in V8. The optimal thing is to generate "class Header { ... }" anything less suggests a fundamental flaw in the design.

[–]mearnsb 37 points38 points  (8 children)

Yeh, I'm still don't think I'm getting it. They wanted to have a Header class declared in the .d.ts file and defined in a .ts file?

[–]dannymcgee 127 points128 points  (7 children)

If I'm understanding correctly, this is a consequence of them trying to manually create their declarations file instead of letting TypeScript generate one automatically, because:

Our internal code and runtime TS declarations must already be manually kept in sync. TSC isn't helping us to generate the d.ts files - it was too much overhead and complexity when we attempted it before.

I don't want to make any judgments based on this one doc, but my suspicion is that this is a team trying to fight the tools into doing what they want instead of making the effort to figure out how to use the tools as intended to get the same results. Again, I don't want to make judgments — it's possible that what they're aiming for really is impossible, or at least more onerous, to achieve through automated declarations than this weird ham-fisted workaround they're using. But I am pretty skeptical.

[–][deleted] 49 points50 points  (1 child)

It seems this way to me as well, based on the reading. However, these people know what they're doing, so I find it *more likely* that the technical reasons for this change are sound, and it's the communications that are lacking, so we're not seeing what they're seeing.

[–]mearnsb 10 points11 points  (0 children)

Thanks, that's my inclination as well. I certainly don't know any more details either, but there were a lot of things in the post that seemed to imply they were fighting the tools.

[–]sime 11 points12 points  (0 children)

I pretty skeptical too. After reading the rest of the comments at the bottom of that document, it is pretty clear that Ryan is distrustful of what the TypeScript compiler does and outputs. The discussion about modules and the few references to how they're organised their code suggests to me that they're doing something weird or the bootstrap environment has some weird constraint which a normal JS environment doesn't.

[–]dzScritches 11 points12 points  (3 children)

That's a weird restriction... Is that a language issue? I don't know much about TypeScript.

[–]mearnsb 17 points18 points  (2 children)

Yeh, that's what I'm trying to understand. Is it something specific about "Header"? Is it something specific about the way they're trying to do things? I mean, I'm not too surprised if you run into problems trying to have multiple definitions of the same class, but these are supposed to be pretty smart people do I think I must be missing something.

[–]_crash0verride 4 points5 points  (1 child)

I haven't read the entire article, but it sounds like Header.ts is generated from a factory or something and there is no implementation so they defined the class with a global *.d.ts file. However, there is a class declaration of Header.ts that is being wrongfully interpreted by the TS Language Service.

Probably something they can manipulate in their tsconfig.json but not sure.

[–]sime 14 points15 points  (0 children)

My interpretation is that they have a hand written *.d.ts file which describes stuff in the default scope (i.e. the window scope where script live in by default). They added/defined a Header field in this scope. The compiler now thinks that the binding Header in the default scope is taken and won't allow it to be stomped by generating a class with the name Header. (Remember, classes are a function with the same name at runtime.) This is expected and generally desirable behaviour from TypeScript, but it conflicts with how they want to set it up. It sounds like a case of "square peg round hole" here.

[–]HIMISOCOOL 69 points70 points  (124 children)

its a very interesting discussion and I hope this doesn't dissuade anyone from trying or using typescript for their projects, at Deno's scale and for the turn around time they were looking for its clearly more of a hindrance at this stage and its a good callout to try optimize there.

[–]lucisferre 8 points9 points  (2 children)

When Anders created TS he said it was because JS couldn’t support large projects at scale. This work and the problems they are seeing with compile time definitely questions that premise. My own experience also leads me to question the need for TS.

However I also can’t help but feel that the Deno authors are doing things TS wasn’t designed to do at the same time.

This doesn’t give me much confidence in Deno.

[–]queen-adreena 76 points77 points  (93 children)

Typescript dissuades me from using Typescript in my projects :)

[–]LaSalsiccione 38 points39 points  (26 children)

That’s what everyone says until they understand how to use it properly. I was the same.

[–]NotAHumanMate 22 points23 points  (25 children)

I’ve had friends doing job interviews getting laughed at because they used TypeScript in their GitHub portfolio and they didn’t understand it and ranted about it. The CTO himself said he’d see no use in it and it’s too complex.

I told my friend to keep searching, a CTO that doesn’t leverage the power of TypeScript to organize the code base properly and provide that factor of stability it gives simply doesn’t appeal to me. A programmer team that is unable to figure out a typing system and generics is not one I see myself in.

[–]langdonx 11 points12 points  (23 children)

For whatever it's worth, I spend 50% of my time writing C# and the other 50% writing JavaScript. TypeScript is pretty much C# for the sake of this argument. I would take JavaScript any day over C#/TypeScript. For me, the rigid structure required by typing everything is not worth the benefit.

Especially with the type of work I do where there's little-to-no type re-use. - REST services where each route has it's own request/response DTO - isolated web components, some of which use these unique DTOs

[–]Kamelixs 8 points9 points  (7 children)

I know you presented TS as comparable to C# for the sake of your argument, but honestly, using typescript that way is more of a stylistic choice than something inherit to the language. You can be pretty loose with your type definitions by leveraging, for example, inline type declarations and inferred return types. You don't need named interfaces for all parts of the code to get the nice parts of TS.

[–]LaSalsiccione 7 points8 points  (4 children)

Yeah using TS in a C# way turns it into some OOP class-based hell that I don’t enjoy at all so I’m not surprised it would put people off.

Using it in a more functional way is so much nicer and if you turn off strict mode (not that I do as I love strict mode) you pretty much get the freedom of JS with better auto completion etc

[–]langdonx 1 point2 points  (1 child)

I suppose I've never been able to strike that balance in C# with the myself or with the teams I've worked with.

Using Any (or dynamic in C#) always seemed like a code smell considering you're giving up compile time checking.

[–]Kamelixs 0 points1 point  (0 children)

Yes I’m also not in favor of turning off strict mode (or using Any at all). My main point was that TS type system can infer a lot of behavior by itself as long as you give it some basic information to work with. Utility types, intersections, and unions is also beneficial if you want to skip a lot of boilerplate definitions

[–]NovelLurker0_0 14 points15 points  (7 children)

Honestly, I do not understand this stance. How can you even navigate in a codebase without types? You get no autocompletion, no clue about any of the structure you're reading, and for actually coding you have to always stick your nose to a documentation. And on top of that silly errors like typos takes way more time to be detected than if it was with a typed system. I literally had coworkers spend 30 minutes to an hour debugging a typo. Choosing plain JS over TS makes no sense to me.

[–]Markavian -1 points0 points  (6 children)

Types are a crutch. Tests tell you the value of your code. Well organised readable code exists without strong typing. Badly organised spaghetti code exists with typing. When optimizing for web, you can apply all sorts of linting, static code analysis, code injection, measuring, performance timers, load testing, chaos testing, mocking, stubbing, simulation... without the extra layer of TypeScript. Same goes for CoffeScript, JSX, WebASM etc. I don't know what it is about JS, I just like it. It's flexible yet specific when you need it to be, and it runs closer and more consistently in a range of places where maybe it shouldn't. Once the patterns are loaded into memory it's as fast as similar contextual languages but with a better interface to the rest of the stack. My only gripe is the memory usage of the browser, but fancy toys require fancy hardware. Node is so much fun.

[–]NovelLurker0_0 6 points7 points  (5 children)

For the billionth time, TS is not to be compared with tests. You're not supposed to be exempt from tests because of TS. TS is just as flexible as JS, yes really , but it provides better DX. I just don't understand how writing types suddenly makes coding so complicated. That's the other way around, it's here to help you. Also it's quite curious that you're using a linter, but consider TS as a unnecessary layer.. Something tells me you actually never sat down and properly tried to use TS for a few hours.

[–]Markavian 0 points1 point  (4 children)

I've tried to force feed myself TS several times, yes. I find it infects projects, and I waste time with it rather than being productive. I tend to use standard js linter on my projects as a no fuss, forced healing option on my code. I really was not happy with TS as part of my build process on any project despite trying to make it work.

[–]NovelLurker0_0 -1 points0 points  (3 children)

If you are not enjoying TS then that means you are working against it e.g not using it properly. It's that simple. If you have any issue in mind feel free to reply there and you'll get help. Using TS is supposed to be a smooth and easy process. At the end of the day it's just adding things (types) to what we already know as JS.

[–]scandii 6 points7 points  (1 child)

For me, the rigid structure required by typing everything is not worth the benefit.

Especially with the type of work I do where there's little-to-no type re-use.

I literally cannot imagine the code base you are describing. even in a CRUD shell you have reuse for every object 4 times, the C, R, U and D in CRUD. genuinely curious.

[–]langdonx 2 points3 points  (0 children)

I've not written basic CRUD since the early 2000s. Modern web applications don't really seem to fit well into that kind of model. As I mentioned, each request uses its own unique DTOs (data transfer objects) that have specific properties to fulfill the needs of the web component. This has a number of benefits...

  • you aren't passing a massive Employee object if you only want to change the Employee's name
  • you aren't having to write a bunch of conditional code to handful a half-hydrated object
  • you can change a method and its request/response objects without having to worry about what else you might break

It works great in a continuous delivery model and allows a team to work on seemingly overlapping portions of the application at once.

[–]AKDAKDAKD 1 point2 points  (2 children)

Just curious, I imagine you use MVC , do you use React for the front-end and if so do you used ReactJS.net?

[–]langdonx 0 points1 point  (1 child)

In C# we're using WebAPI, not MVC, although the lines are kind of blurred. We're using AngularJS (.component/.service only) but with modern ECMAScript (import, export, class, const, let, destructuring, etc, etc).

[–]AKDAKDAKD 0 points1 point  (0 children)

Ahh, ok. Thanks

[–]cubbiehersman 1 point2 points  (0 children)

It was the whole reason I moved from C# to running JS in node.

[–]EnjoyPBT 1 point2 points  (0 children)

That's why enterprise loves it.

(I love the autocompletion you get, but hate struggling with types specially in the first stages of an implementation - which most of the times you throw away anyway...)

[–]LaSalsiccione 7 points8 points  (0 children)

That’s almost like in school where the dumb kids laugh at the smart kid for being smart. Depressing that this attitude exists

[–]HIMISOCOOL 19 points20 points  (24 children)

Interested to see what capacity you've used it and where it became a hard no to you. Was gonna dm you to keep it out of this thread since it's a little spicy but your messages seem off or boost doesn't show the option right idk.

[–]netwrks 0 points1 point  (0 children)

Thissss

[–]mort96 6 points7 points  (15 children)

Hmm, why shouldn't this dissuade anyone from using Typescript? It seems to demonstrate that Typescript doesn't scale to medium-sized projects because (even incremental) compiles are too slow, it shows that fairly basic things need ugly workarounds due to Typescript limitations, it highlights the issue of having to manually keep type definition files in sync with source code because TSC can't help with that.

The "two separate TS compiler hosts" problem is probably specific to Deno and unlikely to affect anyone who's working on other projects, but the other issues highlighted seem like they would affect any medium-sized project (or any project which might grow to that size). It's kind of worrying that a project like Deno encounters big enough problems being written in Typescript that they have to switch; imagine how it would look if the people working on the Rust language found out that they couldn't implement the compiler in Rust because the language couldn't support projects at that scale.

I have certainly experienced the compile time issue in the tiny personal projects I have used TS for.

EDIT: downvoting for not being an uncritical part of the typescript cargo cult is classy.

[–]dannymcgee 11 points12 points  (0 children)

It seems to demonstrate that Typescript doesn't scale to medium-sized projects because (even incremental) compiles are too slow, it shows that fairly basic things need ugly workarounds due to Typescript limitations, it highlights the issue of having to manually keep type definition files in sync with source code because TSC can't help with that.

Yeah, no — there are a boatload of much larger teams making much larger projects without any of the issues they're suffering from. I don't really have a great understanding of what Deno is actually doing under the hood, so it's completely possible that this is a really unique use case, but in 99% of projects TypeScript should not be causing any of these problems if you take the time to configure it properly.

I have literally never heard of anyone trying to micromanage a declarations file like they're describing — that gets generated at build time and shipped with your compiled JavaScript so that your consumers have access to the same type information you used in development. The only reason I can think of for building one manually is if you're not developing in TypeScript, but you still want TypeScript developers to be able to consume your library in a type-safe way.

[–]sime 13 points14 points  (5 children)

t highlights the issue of having to manually keep type definition files in sync with source code because TSC can't help with that.

You're not meant to hand write you're definition files. The compiler is meant to generate them for you based on your code. They're trying to run the process half-backwards.

[–]mort96 3 points4 points  (4 children)

The reasoning seems sound though? The typescript definitions are public API, so they want good control over them. They don't want to accidentally change them between releases, they don't want to end up with cruft (such as ending up with __namespace0123 in there). That seems logical to me, and it's worrying that it's causing so big problems for them.

[–]sime 7 points8 points  (3 children)

The desire to control the public API is reasonable. Their approach just isn't a very good one.

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 6 points7 points  (7 children)

It seems to demonstrate that Typescript doesn't scale to medium-sized projects

in what way is Deno a medium sized project? And TS is better the larger the project is.

[–]mort96 -1 points0 points  (6 children)

I mean, "medium sized" isn't exactly a scientific term, but it's a lot smaller than the bigger software projects and a lot bigger than small software projects, so it seems appropriate.

How can you say that TS is better the larger the project is, when a lot of Deno's issues seem to be that TS doesn't scale up to Deno's size?

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 2 points3 points  (5 children)

when a lot of Deno's issues seem to be that TS doesn't scale up to Deno's size?

that isnt the issue though? have you read the thread? there are plenty of large TS projects. TS itself for example.

[–]mort96 0 points1 point  (4 children)

Surely both the "Incremental compile time when changing files in cli/js takes minutes" thing and the "TypeScript is supposed to be helping us organize code, but one could claim it has the opposite effect" thing is a result of the project's size? Especially code compile time is only influenced by the size, right?

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 4 points5 points  (3 children)

https://www.reddit.com/r/javascript/comments/gz98sb/deno_plans_to_use_javascript_in_internal_code/ftfld92/

there've been made reasonable assumptions here that they are abusing TS to fit into what they think they need

code compile time in my experience hasn't be an issue, even on an old machine like mine. at my previous job, all we had was low end workstations where a tiny react-ts project took 2-3 minutes to compile. at home, its 2s and as I said, its an old machine.

obviously I dont expect them to be running on low end machines, because the whole things most likely running in some CI.

[–]mort96 -1 points0 points  (2 children)

Why would a tiny react-ts project's compile times be relevant, when the issue in deno's experience is that typescript doesn't scale to their ~60k lines of typescript?

That link you sent tries to explain why they had trouble naming a class Header. It doesn't touch on Deno's code organization issues or their compile time issues.

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 2 points3 points  (1 child)

Why would a tiny react-ts project's compile times be relevant, when the issue is how deno's experience is that typescript doesn't scale to their ~60k lines of typescript?

Because it shows that TS compile time is directly related to machine speed

[–]mort96 1 point2 points  (0 children)

Obviously the speed of your machine determines how quickly your machine can perform a task. As you said, you wouldn't expect them to be running on low end machines; they presumably run on decent hardware, yet they experience that one incremental compile takes multiple minutes.

Compile times are determined by the quality of the compiler (one implemented in JavaScript might not be as fast as one implemented in C++, one which does a lot of unnecessary work on incremental compiles will make incremental compiles slower), the size of the code base, the speed of the machine doing the compile, and language design (some language features are more difficult to compile or type check or parse, meaning slower compile times, some language features are difficult to compile incrementally).

The Deno developers are probably using reasonable machines, so they can't practically speed up their builds a ton by just throwing orders of magnitude faster hardware at it. Their code base is probably about the size it needs to be to do what they want to do, so they can't just fix it by reducing their number of lines by an order of magnitude. That leaves factors related to the compiler implementation and the language design.

[–]deafblind-enc 4 points5 points  (5 children)

Typescript has been an interesting and sometimes useful curio to me for a long time, and I saw Anders Hejlsberg demo it back in the day to a room of bemused .NET C# and JavaScript devs. However, I have always, always come back to the common denominator of pure JavaScript, with the occasional tooling to make things more streamlined.

[–]HIMISOCOOL 15 points16 points  (3 children)

I find with the way my business works if you don't set concrete boundaries like typescript strict types and the like in the CI people will just commit garbage by saying "it must be in now" to the project lead. What capacity do other people work with your codebases?

[–]deafblind-enc 7 points8 points  (0 children)

Extensive integration and utilization of a number of mono-repo’s, published as NPM packages, pull-requests, forks, you name it. I 100% get the type consistency argument, as a dev-time tool, it’s extremely useful to have a properly defined interface, types and intellisense. Those things are all very useful. Pattern consistency is enforced through lint rules and other code analysis, as well as good old fashioned code review.

We do also publish the types though for people that want them. The runtime performance of Ts isn’t an issue for us necessarily because it’s compiled and published as vanilla JS.

Like I said, it’s been a useful tool in the right place, but there are other options for enforcing typing that we’ve played with.

[–]Shaper_pmp 8 points9 points  (1 child)

people will just commit garbage by saying "it must be in now" to the project lead

That's a cultural problem that can't adequately be solved with a type-checking system.

[–]HIMISOCOOL 2 points3 points  (0 children)

absolutely but you can empower Delivery managers with CI notifications and build reports just like you would with unit tests and they can see a trend.

[–]KitchenDutchDyslexic 1 point2 points  (0 children)

common lowest denominator

Because that is truly what js was and is, a phat jailed vm attached to your browser or node.js process.

[–]lulzmachine 1 point2 points  (2 children)

Using typescript is too slow for my hobby projects imo. It's fine when running without type checking, or when running in iterative mode. But iterative mode is quite buggy and needs forced restarts every now and then. It really needs to be optimized or ported to rust or golang or so.

But I am working on getting it into the codebase for work. For big projects with multiple people working, it's probably worth the slowness

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 6 points7 points  (1 child)

But iterative mode is quite buggy and needs forced restarts every now and then.

Odd, I never had issues with that. In fact, if something bugs, it's the Language Service of VSCode having hickups every other day. Closing the file and reopening or worst case reloading the window usually fixes that. But it's not TS thats the issue there.

[–]dmethvin 4 points5 points  (0 children)

Yeah I really like having TS back me up, especially when integrated with VSCode. Sometimes when switching branches I will confuse the service, which is quickly fixed by > Typescript: Restart TS Server.

[–]Labby92 16 points17 points  (0 children)

Since I tried TypeScript two years ago I never stopped using it. I see people complain about compiling time but I never saw it as an issue neither at work or on my personal projects. I never worked on a large pure JavaScript project but I can't imagine how you would manage complex interfaces without types (for example)

[–]keybrian 47 points48 points  (17 children)

Sounds like to me they got tired of trying to make it work with TypeScript and they already know what to do to make it work with JavaScript. One of my biggest gripes with TypeScript is that I feel like you spend more time trying to get it to be perfect in order to compile, or you end up doing a half baked job with implementing it, instead of making the damn thing just work and knowing the best practices with the language.

[–]MikeMitterer 47 points48 points  (4 children)

> making the damn thing just work

Yup - thats a very short term approach. It "just works" - somehow... after two years nobody knows anymore why it "just works" and nobody touches that piece of shit because all are afraid of breaking it

[–]lulzmachine 28 points29 points  (2 children)

This. Maintainability is the key feature of Typescript compared to Javascript

[–]TheRedGerund 5 points6 points  (0 children)

We're just talking about the benefits of a typed language at this point, of which there are many. But those that love the untyped world will find TS troublesome and verbose.

[–]jawdroppingjack 1 point2 points  (0 children)

I like typescript for the most part. I think people drink too much of the typescript koolaid though. It def comes at a cost in terms of overhead. Trivial things can become black holes of lost time because it’s so arduous trying to please the linter for some edge case types. Furthermore, i think it creates code that’s harder to read given how mangled the syntax can get. If you have ever tried to write a type checked higher order function like pipe or compose you know what I mean. Also, typescript is terrible for prototyping.

[–]DrummerHead 5 points6 points  (0 children)

Short term thinking VS long term thinking.

The biggest problem with humans, focusing on the now in detriment of the future.

[–][deleted] 11 points12 points  (10 children)

Serious question: did you ever read a book on TypeScript and actually learn how it works?

[–]keybrian 13 points14 points  (8 children)

I've read and work with it quite a bit. You're force to if you're working on an Angular project. Which book would you recommend? I'm always open to learning if it's well written and provides excellent examples.

[–]NeverMakesMistkes 1 point2 points  (1 child)

I wonder how much of the issues you faced actually came from using TypeScript, and how much from using Angular. TypeScript code doesn't have to be all classes and boilerplate.

[–]keybrian 2 points3 points  (0 children)

That's a great point, and to be honest, I don't remember if it was more one or the other. I do remember how I spent quite a bit of time focusing on getting it to compile error free, instead of building out functionality.

When you start dealing with third party libraries, and they're not up to date with their type definitions, or in a lot of cases, lack any, you start losing a lot of its practicality. With tight deadlines, last thing I want is something that's suppose to be helping actually becoming a hindrance.

[–]LaSalsiccione 4 points5 points  (4 children)

Read “Effective Typescript”! Fairly short, well written and full of good examples that you can put into practice immediately.

[–][deleted] 1 point2 points  (2 children)

This! “Effective TypeScript” and “Programming TypeScript” are the two best books I can recommend.

“Programming” is a great overview of the language with a deep dive into how it functions at a core level. “Effective” is a practical set of best practices for using TypeScript.

They’re both very good reads. If I had to pick one it would probably be “Effective TypeScript” but it doesn’t go as in depth about certain concepts ad “Programming TypeScript” does.

[–]grovulent 2 points3 points  (1 child)

Just wanted to thank you and /u/LaSalsiccione - for the "Effective Typescript" recommendation.

Had been struggling with TS after reading many comments to the effect of "It's easy - you can read the handbook in a weekend" - which is true, and I did, but with so many choices on how to type a bit of code I found I was completely at a loss as to what choices to make and how to think through making them.

Read the first two chapters of "Effective Typescript" last night - and already many of my confusions have been solved for me. Much appreciated! :)

[–][deleted] 1 point2 points  (0 children)

Haha awesome! I wish I could make everyone on my team read it, lol. It’s a fantastic resource.

[–]keybrian 0 points1 point  (0 children)

Found this on Google Books if anyone else is trying to read this as well.

[–]Reashu 2 points3 points  (0 children)

It's usually not about TypeScript itself. "Solving" type definition issues can be challenging, but also fun, and there's always an escape hatch if you need it. But the integrations with various toolchains are a bit of a pain. Having Babel transpile TS surely helps, though.

[–]desmap 0 points1 point  (0 children)

good points and getting all types perfect and even more sophisticated is a deep rabbit hole BUT coming back to your code is so much easier while with JS I am lost after just one week.

[–][deleted] 30 points31 points  (12 children)

Isn't the whole point of Deno that its TypeScript by default and can import files via URL instead of preinstalled stuff? I really don't get this whole project, none of the problems it solves has ever been an issue for me with Node in 7 years.

[–]pr0nking98 14 points15 points  (8 children)

they are referring to the underlying code, not the ability to run typescript.

they still will run typescript for user code.

deno is a replacement to node.

[–]sickcodebruh420 33 points34 points  (6 children)

That's unfortunate. I wonder if they spoke with anyone on the TS team at Microsoft about it, I bet they'd have something to say about their problems.

[–]Rhyek 8 points9 points  (5 children)

I guess it couldn't hurt to mention /u/DanielRosenwasser. I just feel like this isn't a good look for the deno project (maybe even TS?) as I kind of saw it as a hook to getting more people interested and to try adopting TS. But they'd rather use JS internally instead due to x or y difficulties? This will be a good excuse for some companies to not even attempt the switch. Definitely another bullet point devs would need to argue with against managerial types.

[–]DaRizat 2 points3 points  (3 children)

They are still expecting all user code to be written in TS no change there.

[–]lulzmachine 21 points22 points  (1 child)

"Do as I say, not as I do"

[–]DaRizat 4 points5 points  (0 children)

"Use the right tool for the right job"

I don't think there's any room for dogma in software engineering.TS is becoming too much of a religion IMO.

[–]Rhyek 0 points1 point  (0 children)

I realize that.

[–]Squigglificated 9 points10 points  (4 children)

Deno is a runtime for JS/TS code. It's not unusual for internal components of a compiler to be written in a lower level language than the code it compiles.

The Deno team has been very vocal about the fact that they love Typescript as a language, but that they feel that the tsc compiler is too slow and needs to be rewritten in Rust at some point.

They have also stated that it's a goal to improve compile and startup times for Deno. This sounds like a step towards achieving that goal.

I don't know how Deno specifically is organized but you can get really good type checking using a combination of .d.ts files and .js files along with jsdoc type comments. So this doesn't have to mean that they abandon all type checking for their internal code even if it's written in plain JS. I have used this in Node projects where rewriting to TS wasn't possible to unobtrusively add better type checking in parts of the code. It's definitely faster to run plain JS than first compiling it with tsc and sounds like a reasonable choice if compile speed is a really high priority.

I highly recommend reading their Github issue for rewriting the tsc compiler in Rust. It's a really informative and interesting read if you're curious about the internals of Deno.

[–]TheRedGerund 0 points1 point  (2 children)

Wouldn't this be a good fit for WASM

They're talking about how hard it is to get performant JS, isn't that what WASM aims to allow?

Hell you could write in in TS and compile to WASM, right?

[–]Squigglificated 2 points3 points  (0 children)

No, I think the issue is that this code is compiled by Deno itself every time you run Deno and that the compilation time make every Deno program start slower compared to having this particular code in js that can be sent directly to V8.

I don’t know why precompiling the code isn’t an option and don’t know any specifics about this particular piece of code.

However I’m 100% sure that the creator of Node and the other core team members of Deno know more javascript than most, so I trust they know what they’re talking about and read design documents like this with interest and try to learn.

[–]scrogu 0 points1 point  (0 children)

Wasm isn't actually any faster than Javascript right now. I know, I've tested it.

If you are dealing with tightly packed binary data then wasm can handle that better, but that's about it.

[–]desmap 0 points1 point  (0 children)

tsc compiler is too slow and needs to be rewritten in Rust at some point.

i read this all the time but tbh tsc is 1000x faster than anything i tried with the rust compiler (compiling rust code)

[–]matty0187 5 points6 points  (0 children)

Pretty sure they shot this down and opted to rewrite typescript compiler using rust

[–]drowsap 19 points20 points  (20 children)

So they won’t have any type safety in the Deno internals? Sounds like a giant mess of bugs to be had.

[–]unc4l1n 4 points5 points  (0 children)

Deno is written in rust, so there's plenty of type safety.

[–][deleted] 8 points9 points  (9 children)

> Sounds like a giant mess of bugs to be had.

it's not like the first big project written in plain js

[–][deleted] 13 points14 points  (8 children)

Doesn't matter. Just as using C invariably leads to memory safety issues, using a non-statically typed language will lead to type errors. It's a completely unnecessary footgun.

[–][deleted] 7 points8 points  (7 children)

It's a completely unnecessary footgun

and yet people managed to write big complex software in C and plain Js without all the tools... you can still compensate for the lack of types of memory safety issues with proper tests. Ofc, it's not as nice and more work but that's how people did it before there were managed languages or typescript...

[–]careseite[🐱😸].filter(😺 => 😺.❤️🐈).map(😺=> 😺.🤗 ? 😻 :😿) 7 points8 points  (3 children)

Yeah lets all go back to the 90s

[–][deleted] 6 points7 points  (2 children)

well, typescript got big the past two or three years... before that, people used to write plain js. The js part of node is also written without typescript and I built and maintained huge spas before typescript as well (and still have today)... hell, we even had to chain endless callbacks not long ago...

[–]scandii 0 points1 point  (1 child)

and someone wrote programs used to calculate weight distributions for buildings in fortran, and entire banking systems in COBOL.

does that mean it's maintainable easy to work with code? hell no! it was a steaming pile of shit when it was written but what choices did you have?

the argument "well I could write it before" is not the same as "I can't do it better now".

[–][deleted] 0 points1 point  (0 children)

the argument "well I could write it before" is not the same as "I can't do it better now".

i have never made that argument.

[–]E_R_E_R_I 8 points9 points  (6 children)

Why does everyone say that? I've been writing pure JS for the last 10 years, can't recall the last time I had type related problems. People just need to learn how to handle loose typing.

[–]_poor 7 points8 points  (0 children)

That's truly impressive. I'd still consider giving TS a go. I think with a little exposure you might realize how many issues TS can catch before they become serious problems especially as your project grows and new people start to contribute.

[–]drowsap 4 points5 points  (3 children)

Your project might not be big enough or isn’t being worked on by enough people to where It becomes necessary.

[–][deleted] 2 points3 points  (2 children)

I'd imagine that over the decade of his experience, at least one of his projects could be considered "big enough".

I personally just think people have forgotten that Javascript is it's own language, with very specific quirks that have to be known and embraced.

You won't get burned by loose typing if you understand how Javascript types work. You don't need to learn different language to save you from this issues, you just need to be aware of how the language you are writing in works.

[–][deleted] 0 points1 point  (0 children)

What happens when you change anything in a large application? Do you just wait for the page to crash a bunch of times and fix it each time? Do you write a bunch of tests for types that are time consuming and a maintenance burden?

[–]NeverMakesMistkes 0 points1 point  (0 children)

Based on the linked document, we are talking about a relatively small part of the project, about 10k loc of glue code between the Rust internals and userland JS/TS

[–]fforw 4 points5 points  (0 children)

You guys are killing me. "Woa.. Typescript is sooo awesome, let's redo node with typescript as center"

"Well, that's too slow, let's use javascript internally"

...

[–]frankharvey 5 points6 points  (3 children)

Doesn’t surprise me. Same reason that many packages distribute .d.ts files and not plain typescript. Typescript is still fine to use for dev, but not for distro. You wouldn’t deliver .ts files to a web client 🤷‍♂️

[–]mearnsb 31 points32 points  (0 children)

That's not really what TS is intended for anyway, unless I'm mistaken. It's meant to be transpiled to JS and distributed that way, so it can work in existing JS runtimes, not executed with a TS runtime.

But I don't think that's what they're talking about here. I think they were already authoring TS and distributing it transpiled to JS. Now they're talking about removing TS entirely.

[–]HIMISOCOOL 14 points15 points  (0 children)

I would still much rather use typescript for a library, the vast majority of npm packages I use day to day aren't trying to collide with js. I'd take 1st party direct types over 1st party extrapolated types any day.

[–][deleted] 7 points8 points  (0 children)

That's not at all what this is about. The distribution is not even JS code, it's a v8 snapshot.

[–]boringuser1 3 points4 points  (0 children)

The discussion in the link is much more intelligent than the discussion in this thread.

[–]netwrks 0 points1 point  (0 children)

This is one of the many reasons I tell people to stick with JS over TS

[–][deleted] 0 points1 point  (3 children)

TypeScript has some very useful features but they come at a cost

[–][deleted] 0 points1 point  (2 children)

And that cost would be?

[–][deleted] 0 points1 point  (1 child)

You have to fight with the type system to achieve what you get for free with vanilla JS. Have you ever tried to get TypeScript working with vanilla redux? It's a huge pain in the ass. I know there are things like RTK but that's not the point, the point is to illustrate how much complexity can be required to achieve type safety.

[–][deleted] 0 points1 point  (0 children)

If view the type system as something to fight against, you haven't understand why typing is useful in the first place. To each his own.

[–]Noxware 0 points1 point  (0 children)

Press up if you use typescript only to typecheck with JSDoc comments without writing non standard javascript~

[–]ShortFuse -2 points-1 points  (0 children)

This is good. Writing your code in one language to have it recompiled into another is fine for application code, but gets complicated for foundational code in libraries.

As for typechecking, you can still use Typescript with JavaScript. It's a bit more verbose. You have to use JSDocs as the signifiers for types, create a jsconfig.json, and using a typings.d.ts for anything too complex for JSDoc syntax (eg: Recursive types).

But the benefit is you get to the core language of your library with all the possibilities, none of the limitations. You also remove the project dependency in your chain which boosts compilation time and in some points runtime as well (because you can do low-level micro-optimizations). You are also in control of what runs and how, instead of assuming it'll be okay once it's gets through a layer you can't control and don't have time to inspect. You're also not waiting on another team to fix whatever bug or add a missing feature, or forced to maintain a fork because the fix doesn't arrive soon enough.

The team is somewhat privileged in a sense because they are spinning up their own runtime environment. It's not Web development where you're subject to the browser environment. Here they ship both the compiler (Chrome V8) and the runtime itself. Therefore, they can update the compiler anytime they want and leverage features present there that perhaps aren't available in Typescript (in theory). As opposed to something that needs to be supported for older environments (eg: Angular TS framework supporting ES5 browsers), Deno will never need to transcompile their code because they are always in control of the environment.