Gil Tayar
@gil.tayar.org
software developer @ microsoft ⚜ dad ⚜ ENM ⚜ javascript fan ⚜ Builder of build systems http://github.com/giltayar/bilt ⚜ and lots of love ❤️
And this still doesn't take care of chunking, which would still be a manual process. While I can't think of a solution that makes the browser take care of downloading only what's needed. I wish there was such a thing.
November 7, 2025 at 4:27 PM
And this still doesn't take care of chunking, which would still be a manual process. While I can't think of a solution that makes the browser take care of downloading only what's needed. I wish there was such a thing.
Not just try entrypoints - the whole module graph. That's a lot of text. It could be thousands of modules.
November 7, 2025 at 4:24 PM
Not just try entrypoints - the whole module graph. That's a lot of text. It could be thousands of modules.
And I seem to remember an alternative proposal that had some kind of bundle that had a directory of files up front for the browser to use...? Tried looking it uo and couldn't find it.
November 7, 2025 at 4:13 PM
And I seem to remember an alternative proposal that had some kind of bundle that had a directory of files up front for the browser to use...? Tried looking it uo and couldn't find it.
I never understood why web bundles were abandoned. They seemed like the perfect solution to enable browsers to deal with when to load modules instead of having developers and bundlers deal (mostly badly) with chunking.
November 7, 2025 at 7:16 AM
I never understood why web bundles were abandoned. They seemed like the perfect solution to enable browsers to deal with when to load modules instead of having developers and bundlers deal (mostly badly) with chunking.
What Maestro said is true - we don't want that overhead for small projects. But even for bundlers - after they do DCE, I believe even there job would be less complex if they didn't have to take care of chunking and just supplied the browser with the bundle and let the b take care of loading.
November 6, 2025 at 12:13 PM
What Maestro said is true - we don't want that overhead for small projects. But even for bundlers - after they do DCE, I believe even there job would be less complex if they didn't have to take care of chunking and just supplied the browser with the bundle and let the b take care of loading.
What happened to the alternative suggestion that didn't use a new display type but rather created new properties under the grid display? If I remember correctly it was suggested by Apple.
October 29, 2025 at 2:26 AM
What happened to the alternative suggestion that didn't use a new display type but rather created new properties under the grid display? If I remember correctly it was suggested by Apple.
Interesting! It's why I found the move from Java and Scala to JavaScript so refreshing (TypeScript was in its early stages then).
I was wondering what discussions in the TS community you were referring to.
I was wondering what discussions in the TS community you were referring to.
October 28, 2025 at 11:34 AM
Interesting! It's why I found the move from Java and Scala to JavaScript so refreshing (TypeScript was in its early stages then).
I was wondering what discussions in the TS community you were referring to.
I was wondering what discussions in the TS community you were referring to.
Oooh! You work at Neon?! Yay! I am just trying out the Neon db for a home project of mine, and so far it's working nicely and the UX is really nice!
October 9, 2025 at 12:49 PM
Oooh! You work at Neon?! Yay! I am just trying out the Neon db for a home project of mine, and so far it's working nicely and the UX is really nice!
Because you were born in the wrong generation 😉
August 12, 2025 at 2:51 PM
Because you were born in the wrong generation 😉
1 for frontend projects
4 for backend
4 for backend
July 17, 2025 at 9:35 AM
1 for frontend projects
4 for backend
4 for backend
What about frameworks like htmx, unpoly, turbolink? Not sure that they constitute "HTML reuse strategies" but usually when those other options are mentioned (e.g. PHP, React, Web Compnnents), then so are they.
e.gh
July 16, 2025 at 6:29 AM
What about frameworks like htmx, unpoly, turbolink? Not sure that they constitute "HTML reuse strategies" but usually when those other options are mentioned (e.g. PHP, React, Web Compnnents), then so are they.
(The importance of preserving import execution is why I don't like how Vitest and Jest hoist some code above the imports, but that's another discussion entirely 😁)
July 8, 2025 at 5:26 AM
(The importance of preserving import execution is why I don't like how Vitest and Jest hoist some code above the imports, but that's another discussion entirely 😁)
While I agree with @rich-harris.dev that relying on that order is VERY problematic, I still think that being spec-compliant in this fundamental issue is important.
July 8, 2025 at 5:26 AM
While I agree with @rich-harris.dev that relying on that order is VERY problematic, I still think that being spec-compliant in this fundamental issue is important.
I have to agree with Devon here. The ES spec around ESM is very clear about execution order, and bundlers should preserve that order so that they are compliant around that, and are compliant with all the runtimes that are compliant in that regard.
July 8, 2025 at 5:26 AM
I have to agree with Devon here. The ES spec around ESM is very clear about execution order, and bundlers should preserve that order so that they are compliant around that, and are compliant with all the runtimes that are compliant in that regard.
Yes! That is exactly how I use it.
June 18, 2025 at 12:42 PM
Yes! That is exactly how I use it.
Thanks, everybody!
I'm writing a "TypeScript in Node.js" talk for NodeTLV (assuming it happens 😢) and this helped me a lot.
I'm writing a "TypeScript in Node.js" talk for NodeTLV (assuming it happens 😢) and this helped me a lot.
June 15, 2025 at 5:04 AM
Thanks, everybody!
I'm writing a "TypeScript in Node.js" talk for NodeTLV (assuming it happens 😢) and this helped me a lot.
I'm writing a "TypeScript in Node.js" talk for NodeTLV (assuming it happens 😢) and this helped me a lot.
NestJS is dependent on decorators, right?
June 15, 2025 at 4:47 AM
NestJS is dependent on decorators, right?
Which is probably why there's not a lot of enthusiasm?
June 14, 2025 at 5:01 PM
Which is probably why there's not a lot of enthusiasm?
Not sure. Decorators are a class construct and most frameworks I believe are not class oriented.
June 14, 2025 at 5:00 PM
Not sure. Decorators are a class construct and most frameworks I believe are not class oriented.
They've been for a while now...
What's holding them back?
What's holding them back?
June 14, 2025 at 4:46 PM
They've been for a while now...
What's holding them back?
What's holding them back?
Yeah, I thought that would be the answer. 😊
I wish there was a flag in @typescriptlang.org that disables decorators entirely (for some reason `experimentalDecorators: false` doesn't work...?) so that we could use TS to totally check TS code for Node.js runnability.
I wish there was a flag in @typescriptlang.org that disables decorators entirely (for some reason `experimentalDecorators: false` doesn't work...?) so that we could use TS to totally check TS code for Node.js runnability.
June 14, 2025 at 9:53 AM
Yeah, I thought that would be the answer. 😊
I wish there was a flag in @typescriptlang.org that disables decorators entirely (for some reason `experimentalDecorators: false` doesn't work...?) so that we could use TS to totally check TS code for Node.js runnability.
I wish there was a flag in @typescriptlang.org that disables decorators entirely (for some reason `experimentalDecorators: false` doesn't work...?) so that we could use TS to totally check TS code for Node.js runnability.