PR that converts the TypeScript repo from namespaces to modules • Hacker News Board

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

#191

Post by Dylan16807 » Thu, Nov 03, 2022, 7:49 PM UTC

Sirened wrote: post #135

SquareWheel wrote: post #54

Earlier quoted context omitted.

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.

Twice as fast is a big deal for damn near any program except like...unimportant, already slow background tasks or things that are already exceptionally fast. Cutting the frame render time in half could give you twice the framerate. Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!). People regularly fight tooth and nail to squeeze 10% perf…

Plenty of game engines are already spending less than a millisecond of CPU time per frame in their own code, so 2x one way or the other makes almost no difference.

Things don't need to be "exceptionally" fast to be in the area where programming language doesn't really matter.

> Twice the performance on a server could let you handle twice as many concurrent sessions (and possible run half as many servers!)

Which might matter, or it might not. Very situational.

> People regularly fight tooth and nail to squeeze 10% performance boosts on critical tasks, doubling it would be incredible

That kind of task is a small fraction of tasks. And often you're best off using a library, which can often make its own language choices independent of yours.

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

#192

Post by WorldMaker » Thu, Nov 03, 2022, 7:53 PM UTC

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?

TS namespaces are a really interesting relic of Typescript pre-1.0 in the bad old "jQuery era" before ECMAScript Modules and even before Node CommonJS modules were that dominant and the two most common "module" formats in the browser were "no module at all" and less beloved AMD [RIP]. Typescript namespaces were based on one of the IIFE approaches to "no module at all" smashing a sometimes large codebase into a single global variable, jQuery style.

Most Typescript projects today wouldn't use TS namespaces if you paid them too. It's a backwards "module format" that the modern web and modern Node (and Deno) is trying to leave behind. Several issues and PRs have been filed on Typescript to drop namespaces as a first-class syntax altogether because it unnecessarily confuses newcomers and shouldn't be used in new code in 2022, but there are some major pre-1.0 Typescript projects that still need them for legacy reasons. Typescript itself bootstrapped itself with itself and was one of those large projects with such a legacy dependency, hah. (From the PR you can see precisely how much tech debt that this has left in Typescript's own codebase!)

So, long story short: esbuild doing a bunch of work to support jQuery-era IIFE patterns is maybe not the best use of esbuild developers' time in 2022.

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

#193

Post by ghusbands » Thu, Nov 03, 2022, 8:00 PM UTC

sublinear wrote: post #133

Beltalowda wrote: post #132

Earlier quoted context omitted.

This is one of those things that started out as good advice, and then got turned in to an oversimplified parody of the original argument. If you have something like: var ( x = foo other = bar ) Then clearly you should use spaces to align those "="s, no matter if you use spaces or tabs for indentation. Similarly, "hanging indents" like: coolFun(arg1, arg2) Can only be done correctly with spaces, and it doesn't really…

> If you had used tabs, changing the tab size would make it align all wrong. This is clearly false. You said this after giving a perfect example of how it's done with tabs.

> > If you had used tabs, changing the tab size would make it align all wrong.

> This is clearly false. You said this after giving a perfect example of how it's done with tabs.

I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.

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

#194

Post by WorldMaker » Thu, Nov 03, 2022, 8:01 PM UTC

presentation wrote: post #165

iainmerrick wrote: post #99

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!

Probably the majority since popular frameworks like NextJS do it with SWC now.

The default configurations for Create-React-App and others use babel for type stripping today.

This seems to me like a great "win" for Typescript that so many tools just natively handle TS type stripping and that so much Typescript today only needs type stripping and doesn't need other parts of TS emit processes (or tslib).

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

#195

Post by WorldMaker » Thu, Nov 03, 2022, 8:13 PM UTC

iainmerrick wrote: post #104

Chyzwar wrote: post #96

Earlier quoted context omitted.

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

Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. This explanation in the comments makes sense to me: Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler. It seems sensible for Node to expect fully-qualified i…

The complication here is that Node in part decided on needing fully-qualified imports not just to better align with the browser, but also to use multiple file extensions in a complex signaling process (ETA: which the browser uses mime-types and metadata like type="module" for rather than file extensions): the file extension could be any of .js, .cjs, and .mjs, and then depending on package.json and some other metadata, Node may load the various files in all sorts of different ways.

Typescript decided that they don't always know what output file extension you may need because Node made that logic way too complex and they don't want to just reimplement their own buggy version of Node's loader mechanics but "backwards" in a terrible "guess the file extension" game, so they went with the easiest option which was "user now has to tell us the file extension".

Even if Typescript didn't have a policy to reduce the number of modifications it emits, it's still Node's fault that the file extensions now have three options with an extremely complex dance between them and getting a "guess the file extension" game right would be an extended PITA.

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

#196

Post by mathstuf » Thu, Nov 03, 2022, 9:44 PM UTC

CoastalCoder wrote: post #125

mathstuf wrote: post #122

Earlier quoted context omitted.

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.

When I'm working in Git, Go, or Linux code, Vim (and NeoVim) uses `expandtab` in conjunction with `softtabstop` and converts any `tabstop` spaces into a tab (with `noexpandtab`) regardless of whether or not it is "alignment".

I've not done lots of development with other editors, but Kate didn't do it and the few times I used Visual Studio, it also had similar behaviors (I'm assuming VSCode inherited that stuff).

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

#197

Post by iainmerrick » Thu, Nov 03, 2022, 11:29 PM UTC

WorldMaker wrote: post #195

iainmerrick wrote: post #104

Earlier quoted context omitted.

Hmm, what is it that Node is doing that’s so bad? I don’t understand why that issue is a big problem. This explanation in the comments makes sense to me: Transpilers can add the ability to add extensions at compile time, so a specifier like './file' can be rewritten to './file.js' during compilation along with whatever else is getting converted by the transpiler. It seems sensible for Node to expect fully-qualified i…

The complication here is that Node in part decided on needing fully-qualified imports not just to better align with the browser, but also to use multiple file extensions in a complex signaling process (ETA: which the browser uses mime-types and metadata like type="module" for rather than file extensions): the file extension could be any of .js, .cjs, and .mjs, and then depending on package.json and some other metadat…

If I’m in a TypeScript file and I import “foo.ts”, why can’t TSC just rewrite that to whatever filename TSC will emit when it compiles foo.ts?

If you’re just using TSC to typecheck and not emitting code (which is what most people actually do in practice), it’s even easier -- just let me import “foo.ts” if that’s the name of a file that exists. The popular bundlers can all handle that just fine.

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

#198

Post by sublinear » Fri, Nov 04, 2022, 4:38 AM UTC

ghusbands wrote: post #193

sublinear wrote: post #133

Earlier quoted context omitted.

> If you had used tabs, changing the tab size would make it align all wrong. This is clearly false. You said this after giving a perfect example of how it's done with tabs.

> > If you had used tabs, changing the tab size would make it align all wrong. > This is clearly false. You said this after giving a perfect example of how it's done with tabs. I believe the post you're replying to meant "used more tabs". That is, if you used any tabs beyond the code indentation, they would get altered when you change the indentation size and ruin the alignment.

This was indeed the misunderstanding.

When I made my original comment I thought what I was replying to was an example of "tabs to indent and spaces to align" immediately followed by a statement that the only way to use tabs is to both indent and align.

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

#199

Post by WorldMaker » Fri, Nov 04, 2022, 7:01 AM UTC

iainmerrick wrote: post #197

WorldMaker wrote: post #195

Earlier quoted context omitted.

The complication here is that Node in part decided on needing fully-qualified imports not just to better align with the browser, but also to use multiple file extensions in a complex signaling process (ETA: which the browser uses mime-types and metadata like type="module" for rather than file extensions): the file extension could be any of .js, .cjs, and .mjs, and then depending on package.json and some other metadat…

If I’m in a TypeScript file and I import “foo.ts”, why can’t TSC just rewrite that to whatever filename TSC will emit when it compiles foo.ts? If you’re just using TSC to typecheck and not emitting code (which is what most people actually do in practice), it’s even easier -- just let me import “foo.ts” if that’s the name of a file that exists. The popular bundlers can all handle that just fine.

Because TSC isn't your bundler. It's job is different from a bundler. A bundler runs under the assumption that everything you import it has to find and handle. Typescript only needs to find a definition for an import.

Typescript may have a complete view of a single project, in which case yes, it should know what file type it is emitting in that project, but then it has to track "in project" imports differently from "out of project" imports and needs two different behaviors for those.

All of that gets further complicated by incremental builds and multi-project references and multi-project references with incremental builds.

Which isn't to say that it isn't technically solvable, and maybe "two behaviors" is an alright developer experience even if it would confuse so many new users, it's just that there are a lot of obvious complications in the face of it.

It's also not like they haven't been trying to work on it. Other comments in this thread have pointed to at least one Typescript issue on it. At one point Previews supported a version of this but rather than using the file-type of the current package's emit it relied on the new paired TS file types: .ts => .js, .mts => .mjs, .cts => .cjs. If you imported a ".ts" it always assumed you were importing ".js" and if you imported a ".mts" it always assumed you were importing a ".mjs". There were a lot of complications even with that simple "one experience", but even that experience was terrible, fell down in complications with Node's loader and various bundlers, and had too many bugs. So it was pulled from Previews.

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

#200

Post by iainmerrick » Fri, Nov 04, 2022, 7:14 AM UTC

WorldMaker wrote: post #199

iainmerrick wrote: post #197

Earlier quoted context omitted.

If I’m in a TypeScript file and I import “foo.ts”, why can’t TSC just rewrite that to whatever filename TSC will emit when it compiles foo.ts? If you’re just using TSC to typecheck and not emitting code (which is what most people actually do in practice), it’s even easier -- just let me import “foo.ts” if that’s the name of a file that exists. The popular bundlers can all handle that just fine.

Because TSC isn't your bundler. It's job is different from a bundler. A bundler runs under the assumption that everything you import it has to find and handle. Typescript only needs to find a definition for an import. Typescript may have a complete view of a single project, in which case yes, it should know what file type it is emitting in that project , but then it has to track "in project" imports differently from…

I realise it’s not trivial, but it’s really hard to believe it’s that difficult!

When I look at the multiple(!) issues on TS GitHub asking “please, can we just import .ts files with a .ts extension? That would make life a lot easier”, the comments from the developers pushing back on it aren’t about Node integration issues, they’re about the unshakable principle that TS must never rewrite syntactically valid JavaScript at all.

Make it work within a single project, at least, and leave external projects for later.

Edit to add:

There were a lot of complications even with that simple "one experience", but even that experience was terrible, fell down in complications with Node's loader and various bundlers, and had too many bugs. So it was pulled from Previews.

Do you have a link handy for that discussion? I’d be interested to read it.