Live data from Hacker News

PR that converts the TypeScript repo from namespaces to modules

github.com

51–60 of 204 posts

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

#51

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 not suggest this in the PR? Seems like it could be used in pipeline to decrease size further down

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

#52

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 not save even more bytes and re-format the output to single tab indentation?

For your answer search "programmers who use spaces make more money"

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

#53

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 not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

TLDR "Programmers who use spaces are more likely to respond to StackOverflow surveys soliciting information about their income."

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

#54
post #48
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

I suppose it depends on your use case, but I don't really consider 2x to be a significant difference. Between programming languages we often speak in orders of magnitude.

If JS is only half the speed of a compiled language like Rust, that shows remarkably optimized performance.

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

#55

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

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

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

#56
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

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

#57

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…

This was actually a significant issue in a large PHP codebase I used to work on. Client hired a new guy who insisted that we convert everything to spaces, and suddenly it took about twice as long to check the thing out from Subversion.

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

#58

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 not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

Correlation != causation

Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one.

For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors and people just went with it. The people earning more are doing so because those are the seniors who have given up on common sense and just go with the flow of the masses who are unable to grasp "tabs for indentation, spaces for alignment" yet insist on keeping alignment so the (terrible) compromise is just using spaces. And I strongly question whether "alignment" is worth anything, in almost all cases it's just useless and in the rest you're drawing ASCII diagrams in the comments which doesn't affect your code at all.

Also see the top answer at https://www.reddit.com/r/programming/comments/8tyg4l/why_do_...

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

#59
post #58

Earlier quoted context omitted.

> Why not save even more bytes and re-format the output to single tab indentation? For your answer search "programmers who use spaces make more money"

Correlation != causation Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one. For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors a…

> Tabs are simply inferior to spaces...

I think you wrote this the wrong way around?

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

#60
post #58

Earlier quoted context omitted.

Correlation != causation Spaces are simply inferior to tabs since the latter conveys the meaning of "one level of indentation" while the former does not. It's also better for accessibility and file size. There is not one single logical reason to ever use spaces for indentation, not one. For some very fucking stupid historical reason someone in the 80s made the idiotic decision of spaces being the default in editors a…

> Tabs are simply inferior to spaces... I think you wrote this the wrong way around?

Ups, yes. I had it switched originally but then for some reason switched it again. Apparently commenting late at night is not a good idea.
Post reply on HN