Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

Post reply on HN
Print view View original

41–50 of 204 posts

Re: PR that converts the TypeScript repo from namespaces to modules

#41

Post by z3t4 »

foobarian wrote: post #21
longrod wrote: post #8

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this. Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as…

How far can you get with JS/other interpreted things in e.g. optimizing for cache access etc? Sounds like you're at the mercy of the JIT compiler (which may go far, but still).

JavaScript does not have any input/output (IO/syscalls) all those functions like reading a file, socket, etc needs to be implemented in the runtime language, like the browser, Node.JS, ASP, etc. So you are at the mercy of the runtime executable. The JS JIT slows down startup time as the JavaScript first have to be parsed and compiled before running, but the runtime can then cache the compiled version for faster startups. When JavaScript was new it was slow, for example string concatenation was slow, but most JS engines now implement string concatenation with a "rope" structure making it very fast. v8 (Chrome) and Spidermonkey (Firefox) have got a lot of optimizations over the years, so if you are doing things like incrementing a number in a loop it will be just as optimized as something written in a systems level language.

Re: PR that converts the TypeScript repo from namespaces to modules

#42

Post by [deleted] »

redox99 wrote: post #33

I absolutely hate how with Typescript and ES Modules, if you have a file utils/foo.ts you have to import it as import Foo from "utils/foo.js" Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file. Importing a file that "doesn't exist" is so counterintuitive. In addition all code breaks because you have to change all your imports, and /index.ts or /index.j…

[deleted]

Re: PR that converts the TypeScript repo from namespaces to modules

#44

Post by constexpr »

berkes wrote: post #23
swsieber wrote: post #22

> Finally, as a result of both of the previous performance improvements (faster code and less of it), tsc.js is 30% faster to start and typescript.js (our public API) is 10% faster to import. As we improve performance and code size, these numbers are likely to improve. We now include these metrics in our benchmarks to track over time and in relevant PRs. > [...] > The TypeScript package now targets ES2018. Prior to 5…

I'm curious about that too. From my superficial knowledge of compilers, "modularization" itself should not make code faster, if anything slower. There'll always be some overhead of loading modules and communicating between them, not? I presume, from my own experience when building software (not compilers), that modules allow for a much easier to reason about, much better isolated (cohesion, loose coupling). And there…

There are two performance implications of "modularization": initialization-time and run-time.

You are correct that initializing many modules is usually slower than initializing one module [1]. However, bundling puts all modules into one file, so this PR doesn't actually change anything here. Both before and after this PR, the TypeScript compiler will be published as a single file.

At run-time, switching to ES modules from another JavaScript module system can be a significant performance improvement because it removes the overhead of communicating between them. Other module systems (e.g. TypeScript namespaces, CommonJS modules) use dynamic property accesses to reference identifiers in other modules while ES modules use static binding to reference the identifiers in other modules directly. Dynamic property access can be a big performance penalty in a large code base. Here's an example of the performance improvement that switching to ES modules alone can bring: https://github.com/microsoft/TypeScript/issues/39247.

[1] This is almost always true. A random exception to this is that some buggy compilers have O(n^2) behavior with respect to the number of certain kinds of symbols in a scope, so having too many of those symbols in a single scope can get really slow (and thus splitting your code into separate modules may actually improve initialization time). This issue is most severe in old versions of JavaScriptCore: https://github.com/evanw/esbuild/issues/478. When bundling, esbuild deliberately modifies the code to avoid the JavaScript features that cause this behavior.

Re: PR that converts the TypeScript repo from namespaces to modules

#45

Post by kasajian »

longrod wrote: post #8

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this. Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as…

When you write Chrome itself in JS, then you can talk to me about performance.

Re: PR that converts the TypeScript repo from namespaces to modules

#46

Post by dickfickling »

bigyikes wrote: post #39
redox99 wrote: post #33

I absolutely hate how with Typescript and ES Modules, if you have a file utils/foo.ts you have to import it as import Foo from "utils/foo.js" Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file. Importing a file that "doesn't exist" is so counterintuitive. In addition all code breaks because you have to change all your imports, and /index.ts or /index.j…

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

have you worked on Typescript projects using ES modules? What you’ve described is the status quo for CommonJS modules, but doesn’t work when you switch to ESM (afaik, at least)

Re: PR that converts the TypeScript repo from namespaces to modules

#47

Post by sebdufbeau »

bigyikes wrote: post #39
redox99 wrote: post #33

I absolutely hate how with Typescript and ES Modules, if you have a file utils/foo.ts you have to import it as import Foo from "utils/foo.js" Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file. Importing a file that "doesn't exist" is so counterintuitive. In addition all code breaks because you have to change all your imports, and /index.ts or /index.j…

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

From my understanding, this is a fairly new predicament, for projects that target ESM (type module in package.json) instead of the default CJS

Re: PR that converts the TypeScript repo from namespaces to modules

#48

Post by __s »

longrod wrote: post #8

Sucrase is proof that JS is not the problem when it comes to slow performance. JS is not slow. NodeJS is not slow. It's the code that is slow. All these people wanting to write it in Rust or Go or XYZ programming language need to acknowledge this. Yes, multithreading is awesome and really helpful but it's the cherry on top, not the whole thing. If the same amount of effort was put into optimizing the TSC codebase as…

I rewrote a card game engine, openEtG, from JS to Rust. It was a pretty 1:1 rewrite. 2x improvement even when I was using HashMap everywhere. I've since entirely removed HashMap, which has only further improved perf

As a bonus, the code is now statically typed

Re: PR that converts the TypeScript repo from namespaces to modules

#49

Post by cypress66 »

bigyikes wrote: post #39
redox99 wrote: post #33

I absolutely hate how with Typescript and ES Modules, if you have a file utils/foo.ts you have to import it as import Foo from "utils/foo.js" Even though there is no .js file on disk, and you might be running ts-node or whatever that doesn't build a .js file. Importing a file that "doesn't exist" is so counterintuitive. In addition all code breaks because you have to change all your imports, and /index.ts or /index.j…

Every TypeScript project I have worked on either: 1) enforces no extension, e.g. “utils/foo”, or 2) allows TS extensions, e.g. “utils/foo.ts” I have never imported a TS file using a JS extension. Maybe your woes could be fixed with a configuration change?

And that's how it should work imo. But if you enable esm (which you might need in the future because of packages being esm only) you can't use those, only .js.

That's because typescript developers are dead set that they don't want to transpile the imports, they just want to copy paste them into the resulting file when running tsc.

Post reply on HN