Live data from Hacker News

Pika/web: Web Apps Without the Bundler

pikapkg.com

11–20 of 85 posts

Re: Pika/web: Web Apps Without the Bundler

#11
post #5

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero . There is also a cognitive overhead of having to configure the server to push a…

You probably won't end up with a dependency tree. Remember development in 2007? Remember this?

    
Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published. There would be no reason to further run a bundler just to turn ~5 such pairs of files into one pair. Over HTTP2/3 that difference is negligible.

It's non-negligible for "thousands of dependencies", of course, but nobody would be doing that. "Thousands of dependencies" is for library development, not for library release packaging.

NPM (or Pika) is still useful under such a paradigm, for the same reason Cargo or Bundler or Pip or Mix or whatever other tools are useful: these tools let you specify your direct dependencies using symbolic version constraints, and then retrieve+update+lock those dependencies. This is helpful whether your direct dependencies are "baked-down" release packages or raw deep-dep-tree source.

Re: Pika/web: Web Apps Without the Bundler

#12
post #9

I haven't used native JS modules yet. I read through the linked page and it's not totally clear to me why you can't just import directly from node_modules. What Pika/web appears to do is find node_modules that use valid export syntax and copy them to a different dir. Is that correct? Am I missing something?

>I read through the linked page and it's not totally clear to me why you can't just import directly from node_modules.

Bingo

This is why it doesn't fully pass the smell test for me

Re: Pika/web: Web Apps Without the Bundler

#13
post #6
post #5

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero . There is also a cognitive overhead of having to configure the server to push a…

One major benefit is that for any given page in your application, you probably don't need the entire bundle. This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases. Just grabbing what you need can have significant benefits. I agree with the latency problem though, it would be nice to have a HTTP/2 or HTTP/3 server that has a basic understanding…

> This is not really true for SPA's, but I hope that's a trend that will eventually sizzle out again except for specialized cases.

I suspect we'll see the opposite, with people building desktop type applications and deploying through the browser (especially with the growth of wasm)

Re: Pika/web: Web Apps Without the Bundler

#14

Luckily, with native javascript modules, there is no need for any of this anymore. We switched our whole codebase to and it's such a joy now. Never going back to bundlers. Never going back to having a compilation step on the server.

Its a good thought, but you're excluding ~15% of all web users[0] from using your product.

[0] https://caniuse.com/#feat=es6-module

Re: Pika/web: Web Apps Without the Bundler

#16
post #14

Luckily, with native javascript modules, there is no need for any of this anymore. We switched our whole codebase to and it's such a joy now. Never going back to bundlers. Never going back to having a compilation step on the server.

Its a good thought, but you're excluding ~15% of all web users[0] from using your product. [0] https://caniuse.com/#feat=es6-module

Yup. We're going where the puck is going.

Re: Pika/web: Web Apps Without the Bundler

#18
post #9

I haven't used native JS modules yet. I read through the linked page and it's not totally clear to me why you can't just import directly from node_modules. What Pika/web appears to do is find node_modules that use valid export syntax and copy them to a different dir. Is that correct? Am I missing something?

>I read through the linked page and it's not totally clear to me why you can't just import directly from node_modules. Bingo This is why it doesn't fully pass the smell test for me

Because many modules don't use ES exports, especially the tiny annoying ones from people like sindresorhus that everything seems to rely on. ES modules are compatible with the browser, CommonJS modules are not.

Re: Pika/web: Web Apps Without the Bundler

#19

This feels like RequireJS all over again... But for srs, couldn't I achieve more or less the same effect by not putting node_modules in my .gitignore and then making aforementioned modules accessible via static content dir pathing?

Yeah that’s the general idea - except that in this case, re-use of the same public URLs means browsers can cache the dependencies. (So we finally won’t have to download 400kb of the same React library code on site we visit!)

Re: Pika/web: Web Apps Without the Bundler

#20
post #11
post #5

I'm not sure why this would be desirable. Sure, bundlers are slow, but that's what projects like pax [1] are for. Bundlers create one single file instead of the browser having to download your entire possibly huge dependency tree. Sure, with HTTP/2.0 and the upcoming QUIC or HTTP/3.0 overhead of this is minimized, but it's still not zero . There is also a cognitive overhead of having to configure the server to push a…

You probably won't end up with a dependency tree . Remember development in 2007? Remember this? Under ESM, each of your dependencies could go back to being a (CDN or /vendor-directory) hosted "release." The release would have been packed together into a single JS file + a single CSS file by its developer, when it was published . There would be no reason to further run a bundler just to turn ~5 such pairs of files int…

That's worse because you lose the ability to "tree-shake". It would go back to importing all of Underscore on a CDN versus bundling the few functions you need into the main bundle.
Post reply on HN