Comment by underdeserver | Hacker News Reader

Comment by underdeserver | Hacker News Reader

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

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.

Your main point seems to be that these problems aren’t the language’s fault. But I don’t see the Deno team claiming that to be the case. There’s nothing wrong with choosing a language that works with how your team likes to develop software, and rejecting a language that doesn’t work well for your team. Doesn’t need to be anyone’s “fault.”

It's entirely valid for them to decide they don't want to change their ways. However, it is frequent that technologies will be rejected because the requisite learning to understand why and how to best use the technology is not done. A common example of this (in my observation and ignoring the application of the technology where it's entirely unnecessary) is NoSql where teams have attempted to use those databases as they used their relational counterparts which obviously didn't work because they didn't shift how they were thinking about using storage and structuring their systems. Anyway, that was how I read the GPs post, as attempting to note that the Deno team may not have pushed through the mental shift required to really get the most out of TypeScript.

[edit: not trying to take a stance in support of the GPS post or either side of this discussion, to be clear]

That's true, but I think when you choose to use a programming language, you essentially commit to doing things its way, otherwise you end up dealing with lots of friction and having to reinvent a lot of wheels. Like the Deno team claim they do.

Taking up Typescript then ignoring best practices when trying to use it is unfortunate. This kind of thing would be a teaching moment for a junior engineer.

It's like saying you don't want to use a dishwasher because if you stack bowls on top of each other, it doesn't clean them well. Well, a dishwasher has its faults - a lot of dishes are not dishwasher-safe, etc. - but your reason kind of misses the point.

> 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 ^--- 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#... (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_WvwHl7BXUPmoiSeD8G83JmS...

The compiled 'mess' that is shipped in the runtime is mostly due to SystemJS, not TypeScript - it doesn't handle modules, and compiles to very clean code if you target a recent ES version. I'm confused as to how dropping TS will help with the code emitted for modules.

Is SystemJS still a thing? What's their point now that browsers support ESM natively?

Deno != browser

I know that. What eludes me is what advantages SystemJS brings over ESM, for browser runtimes and server runtimes (node, deno)…

IIRC SystemJS can be used without any transpilation at runtime. ESM cannot (unless natively supported of course, like it is in browsers)

These two have me confused:

"TypeScript compile time when changing files takes several minutes, making continuous compiling an excruciatingly slow process"

and

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

If you're compiling Typescript, the .d.ts files are output by the compiler. The only time you need to manually keep them in sync is when you're writing .js and manually writing the .d.ts.

Reply on news.ycombinator.com