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

91–100 of 204 posts

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

#91

Post by jsyolo »

jdrek1 wrote: post #58
CodeWriter23 wrote: post #52

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…

What's the difference between indentation and alignment?

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

#92

Post by Accacin »

robbick wrote: post #63
zebracanevra wrote: post #29

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

Heh, I always wondered what the big deal was. I'll just use whatever the company I'm working for uses and not even think about it.

To be honest, that's why I love auto formatting cause I never need to think about that stuff, I can just write code.

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

#94

Post by marssaxman »

breck wrote: post #69
zebracanevra wrote: post #29

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?

Tab is ASCII 9 while space is 32. Tabs, having the lower number, are therefore obviously cheaper.

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

#95

Post by CSSer »

z3t4 wrote: post #41
foobarian wrote: post #21

Earlier quoted context omitted.

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

This can vary a ton as well. I was talking to a friend yesterday who said he was pounding a native browser interface with an iterator and experiencing slow performance. He switched to buffering the entire thing into memory first and experienced huge performance gains.

The aspect of the language you're using, if optimized, is virtually always optimized for the most common use-case. If your use-case isn't the most common use-case, you must account for this.

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

#96

Post by Chyzwar »

redox99 wrote: post #86
Chyzwar wrote: post #81

Earlier quoted context omitted.

No, you were using non-standard ESM modules (compiled to CommonJS defined by babel) Typescript recently added support for ESM compatible with node.js see "module": "node16"[1][2] The Whole ESM saga is clusterfuck, not much better than python 2 -> 3 migration. Large node.js codebases have no viable path to migrate, and most tools still cannot support ESM properly[3]. Stuff is already breaking because prolific library…

Yeah it's pretty ugly. This whole thing is a prime example of those cases in which maintainers for mostly arbitrary reasons decide on something and then absolutely ignore all the massive negative feedback they get for this. They'll cite some nebulous technical reasons of why it has to be this way, but if you offer a PR that actually solves the issue that the community complains about, they'll reject it. In this case…

It is complicated but most user anger should be directed to node.js module group[1]. TS is forced to follow node.js standard.

[1] https://github.com/nodejs/modules/issues/323

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

#97

Post by jakebailey »

tantalor wrote: post #93

500k lines changed, oof. Imagine the merge conflicts. Could this not have been done incrementally?

This is as incremental as it really could be; the entire build had to change, all of the code needed to be unindented one level, etc.

I have tested the merge conflict problem, and thanks to the way the PR is constructed (in steps), git actually does a good job figuring things out.

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

#98

Post by eyelidlessness »

kasajian wrote: post #45
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.

AFAIK all of the major browsers (and other JS runtimes) have implemented some performance-sensitive APIs in JS, specifically because it performs better than crossing the JSnative boundary. Granted that’s usually specifically about JS API performance, but that’s a lot of where performance matters in a JS host environment.

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

#99

Post by iainmerrick »

A little while ago I asked (https://news.ycombinator.com/item?id=33051021):

I’m curious, how many people are using TSC only for type-checking, and a different system (eg esbuild or ts-node) to actually compile/bundle/execute their code?

Looks like my suspicion was correct; not even tsc uses tsc!

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

#100

Post by CodeWriter23 »

jdrek1 wrote: post #58
CodeWriter23 wrote: post #52

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…

Testimonial: I experienced a significant increase in earnings about 4 months after abandoning tabs for spaces. Cause not known but that’s what happened.
Post reply on HN