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

121–130 of 204 posts

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

#121

Post by jakebailey »

sesm wrote: post #113
jakebailey wrote: post #35

Earlier quoted context omitted.

There are some key things here that maybe weren't clearly stated in my writeup. Firstly, the old codebase is TS namespaces, which compile down to IIFEs that push properties onto objects. Each file that declares that namespace is its own IIFE, and so every access to other files incurs the overhead of a property access. With modules, tooling like esbuild, rollup, can now actually see those dependencies (now they are st…

Maybe they could update esbuild to be aware of TS namespaces instead?

I think it's the case that modules are the future; but the main focus of this change was not actually performance at all. We've been wanting to be able to dogfood the modules experience (used by most TS devs) for a long time. The fact that it turns out to be so much faster is a really great side effect.

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

#122

Post by mathstuf »

spartanatreyu wrote: post #107
robbick wrote: post #63

Earlier quoted context omitted.

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

"Tabs vs spaces" is often misunderstood (and falsely reported) as a problem of preference. The real problem is that using spaces for indentation is an accessibility issue. The solution is to use tabs for indentation, and spaces for alignment.

While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region.

int foobar(int a,

___________int b) // should only ever have spaces (using _ here because HTML)

But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong).

The other issue I have is that diffs break alignment between undented code and anything with tabs because the tabs "eat" the leading space, but unindented lines are offset by one.

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

#123

Post by Dylan16807 »

bragr wrote: post #118
shepherdjerred wrote: post #111

Earlier quoted context omitted.

> The real problem is that using spaces for indentation is an accessibility issue. Not this again https://github.com/prettier/prettier/issues/7475#issuecommen... > Blind programmers have no problems with it.

Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.

There are perfectly good tools for that which don't require text changes.

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

#124

Post by gchamonlive »

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…

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

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

#125

Post by CoastalCoder »

mathstuf wrote: post #122
spartanatreyu wrote: post #107

Earlier quoted context omitted.

"Tabs vs spaces" is often misunderstood (and falsely reported) as a problem of preference. The real problem is that using spaces for indentation is an accessibility issue. The solution is to use tabs for indentation, and spaces for alignment.

While that may be true, "spaces for alignment" is nigh unsupported by all editors I've seen. They insist on replacing 8 (or N) spaces with tab even if in an alignment region. int foobar(int a, ___________int b) // should only ever have spaces (using _ here because HTML) But good luck finding an editor that won't insert a tab when you use the tab key here (willing to be wrong). The other issue I have is that diffs bre…

I'm curious what editors you've experienced that with.

I've had some editors that made tab-space conversion an option, but it was never mandatory.

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

#126

Post by shadowgovt »

bragr wrote: post #118
shepherdjerred wrote: post #111

Earlier quoted context omitted.

> The real problem is that using spaces for indentation is an accessibility issue. Not this again https://github.com/prettier/prettier/issues/7475#issuecommen... > Blind programmers have no problems with it.

Not everyone with vision or vision processing issues is blind. Being able to configure custom tab stops is an easy way to control what level of indentation is useful and clear.

As with all other types of data: the right approach is for model and presentation to be separable concerns.

We're struggling with the wrong problem if we aren't asking why the editor can't treat blocks as entities that are displayed however we want.

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

#127

Post by CoastalCoder »

ddoolin wrote: post #71
jdrek1 wrote: 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 denoted by arrows and I don't like being told what to do! :)

The arrows are not instructions. They're the LHS attacking the RHS. Code is war.

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

#128

Post by CoastalCoder »

recursive wrote: post #109
marssaxman wrote: post #94

Earlier quoted context omitted.

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

Tabs require 2 set bits. Space requires only a single set bit. Spaces therefore requires less electricity.

Well, just a bit...

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

#129

Post by CoastalCoder »

wombatpm wrote: post #80
ElijahLynn wrote: post #72

Earlier quoted context omitted.

That doesn't make sense that spaces vs tabs would result in a 2x longer checkout. Something else is at play if that is the case.

He did mention it was subversion

I see your confusion. They said Subversion with a capital S. So the source control system, not the covert destruction of a dev team from within. Easy mistake to make. (... Stupid git.)

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

#130

Post by ahungry »

gchamonlive wrote: post #124
jdrek1 wrote: 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…

Spaces define by themselves the spacing convention unambiguously, whereas tabs is environment dependent and need other tools like editorconfig to guarantee consistency

Well stated.
Post reply on HN