Pika/web: Web Apps Without the Bundler
pikapkg.com
Pika/web: Web Apps Without the Bundler
1–10 of 85 posts
Re: Pika/web: Web Apps Without the Bundler
#2What does the SSR story look like with pika/web? If I have code that has something like `import x from 'lib'`, can I make `lib` point to node-specific code on the server, and browser-specific code on the client?
Re: Pika/web: Web Apps Without the Bundler
#3I guess every name is already taken for just about everything these days, but might as well note Pika CMS:
Re: Pika/web: Web Apps Without the Bundler
#4What does the SSR story look like with pika/web? If I have code that has something like `import x from 'lib'`, can I make `lib` point to node-specific code on the server, and browser-specific code on the client?
Similar to what would happen today when a package exports both ESM (web) & CJS (node): frontend gets ESM via @pika/web, while node would use CJS via require. A Babel plugin comes bundled with @pika/web which can help you resolve imports correctly in the web build.
Although at that point, where your app needs to reliably run in both Node & the browser, there’s a good case to be made for bundling. All that complexity is giving you something valuable, which is the point that the article tries to make:
in 2019, use bundling because you want to and not because you have to.
Re: Pika/web: Web Apps Without the Bundler
#5I'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 all the deps to clients otherwise you have constant back & forth where the client is fetching a file, then the server is answering, then the client is finding out it needs those other files, etc etc. Unless you are using global CDNs, expect latencies to be > 50ms for each such step, if not hundreds of ms, and this times the depth of your dependency graph. Bundlers also do dead code analysis.
There are really two solutions to this: either avoid using js dependencies, at which point you won't need npm or pika or whatever, or use bundlers.
Re: Pika/web: Web Apps Without the Bundler
#6I'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 of the JS dependency tree and preemptively push the entire tree.
Re: Pika/web: Web Apps Without the Bundler
#7This 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?
Re: Pika/web: Web Apps Without the Bundler
#8Luckily, 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.
Re: Pika/web: Web Apps Without the Bundler
#9I 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?
Re: Pika/web: Web Apps Without the Bundler
#10I'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…
Here's the problem I'm struggling with:
1. Typically, you only ever care about minimizing bundle size in cases where latency is consistently questionable
2. In those cases, whatever UI you're supporting is likely then not meant for latency-sensitive operations, and thus the overall workflow tends to have low state complexity
3. Just how much actual value is added in those scenarios by having the ESM workflow specifically in conjunction with importable NPM modules?
I'm sure you can think up some contrived use cases but I'm just not seeing any particularly compelling ones.