Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

61–70 of 204 posts

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

#61

> a change in the indentation used in our bundle files (4 spaces -> 2 spaces) I find it interesting that one of the reasons given for the reduction in package size is due to such a simple indentation change from 4 spaces to 2 spaces. Not interesting that 2 bytes are less than 4 bytes, rather, TypeScript is a large project and it would be interesting to know how much size was saved from this one specific change? Seems…

Kind of funny because one of the benefits of tabs vs spaces that people laugh off is that it saves space.

I think it's probably correct to laugh this off though. Why would you care about the non-minified/gzipped size this much?

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

#62

Earlier quoted context omitted.

> Seems like a trivial change, so why not do it sooner? Re: indentation: Literally, no one thought of it, as far as anyone can tell. Linus's law appears to have its limits.

Most minifiers already put things on one line, though.

TS has some unique restrictions due to downstream patching of our package; my PR description briefly talks about this as something we can try to improve in the future. Minification absolutely would save a lot more size out of our package, but I was not willing to change that in this PR.

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

#63

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah. Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabb…

I can see this is probably a calm point that will definitely not escalate, programmers don't really care about tabs and spaces that much, right???

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

#64
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…

Where are you seeing this? The PR that this thread is about doesn't have this quirk. Maybe your setup has some issue...?

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

#65
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…

Yes, you technically can write high-perf JavaScript code...

https://github.com/alangpierce/sucrase/blob/153fa5bf7603b9a5...

But freaking SIGH I don't want to. I prefer coding in environments that don't require unrolling loops by hand.

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

#66
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…

Agree completely. It also makes interop between Node and Deno more painful. But there is hope on the horizon. :) See https://github.com/microsoft/TypeScript/issues/37582 which is referenced in the 4.9 Iteration Plan as "Support .ts as a Module Specifier for Bundler/Loader Scenarios": https://github.com/microsoft/TypeScript/issues/50457

Actually looks to be tabled for TypeScript 5.0, release date of 'March 14th' next year.

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

#67

Earlier quoted context omitted.

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.

This could change with an ongoing work to allow ts extension [1].

[1] https://github.com/microsoft/TypeScript/issues/37582

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

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

Not sure if serious or not, but Firefox is a long-standing example of this. It has always been a mixed C++/JS codebase. (Since before it was even called Firefox, that is, though nowadays, it's also Rust, too.) I routinely point this out in response to complaints about the slowness attributed to e.g. "Electron". JS programs were plenty fast enough even on sub-GHz machines before JS was ever JITted. It's almost never the case that a program having been written in JS is the problem; it's the crummy code in that program. When people experience Electron's slowness, what they're actually experiencing is the generally low quality of the corpus that's available through NPM.

Arguably, the real problem is that GCC et al are enablers for poorly written programs, because no matter how mediocre a program you compile with them, they tend to do a good job making those programs feel like they're performance-tuned. Today's trendier technology stacks don't let you get away with the same thing nearly as much—squirting hundreds or thousands of mediocre transitive dependencies (that are probably simultaneously over- and under-engineered) through V8 is something that works well only up to a point, and then it eventually catches up with you.

Besides, there's no such thing as a fast or slow language, only fast and slow language implementations.

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

#69

After this change, the TypeScript compiler will now be compiled with esbuild. I feel like thats probably the best endorsement esbuild could get, hah. Surprising they call out the 2 space indent level that esbuild is hardcoded[1] to use as a benefit. Why not save even more bytes and re-format the output to single tab indentation? I wrote a simple script to replace the indentation with tabs. 2 indent size: 29.2MB, tabb…

Why a tab when 1 space will do?
Post reply on HN