Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Pika/web: Web Apps Without the Bundler

pikapkg.com

Post reply on HN
Print view View original

21–30 of 85 posts

Re: Pika/web: Web Apps Without the Bundler

#21

Post by segphault »

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies.

The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fundamentally broken. Every single one of these tools is a raging dumpster fire because it's built on top of all of these layers of low-quality interdependent crap.

I'm increasingly moving towards module-type script tags and standard ES modules everywhere, with no build step during development. It's still challenging to use node-targeted modules in this fashion, so I really do appreciate that people are working on finding ways to make it work. I just wish that we could do it without pulling in so much third-party code and the large surface area for failure and security problems that go with it.

Re: Pika/web: Web Apps Without the Bundler

#22

Post by chrisweekly »

plausibilities wrote: post #7

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?

srs -> SSR (server-side rendering), just a typo, right?

Anyway, committing -- and directly serving -- all of a given project's transitive dependencies sounds like a tough sell; without decent tooling to dedup and tree-shake, it might go from inefficient to implausible.

Re: Pika/web: Web Apps Without the Bundler

#23

Post by plausibilities »

coolreader18 wrote: post #18
plausibilities wrote: post #12

Earlier quoted context omitted.

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

https://github.com/purtuga/esm-webpack-plugin + webpack libraryTarget

So I basically don't exclude node_modules, and set up a simple webpack config to suck in my deps and output them as ESM modules to a given static dir of my choice

Re: Pika/web: Web Apps Without the Bundler

#24

Post by plausibilities »

chrisweekly wrote: post #22
plausibilities wrote: post #7

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?

srs -> SSR (server-side rendering), just a typo, right? Anyway, committing -- and directly serving -- all of a given project's transitive dependencies sounds like a tough sell; without decent tooling to dedup and tree-shake, it might go from inefficient to implausible.

srs = serious

my bad

Re: Pika/web: Web Apps Without the Bundler

#25

Post by s_y_n_t_a_x »

plausibilities wrote: post #10
treve wrote: post #6

Earlier quoted context omitted.

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 specific…

No it's not just latency. In fact, that's not even the most important factor. On mobile devices if the script is too large, it will freeze while parsing.

Re: Pika/web: Web Apps Without the Bundler

#27

Post by simplify »

est31 wrote: 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…

How does pax compare to fastpack?

https://github.com/fastpack/fastpack

Re: Pika/web: Web Apps Without the Bundler

#28

Post by s_y_n_t_a_x »

bengotow wrote: post #19
plausibilities wrote: post #7

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!)

Yeah that was always a "benefit" of using a CDN for jQuery except it never really works out in practice when there's so many versions and then you're at the disposal of a public CDN, which can be the bottleneck, especially when it's critical code.

Sure you can fallback to local copies, but that just means your app hung there for X amount of time, and the added complexity of adding fallback logic.

Re: Pika/web: Web Apps Without the Bundler

#29

Post by MuffinFlavored »

segphault wrote: post #21

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…

> with no build step during development

and then what do you do for production, webpack?

Re: Pika/web: Web Apps Without the Bundler

#30

Post by segphault »

MuffinFlavored wrote: post #29
segphault wrote: post #21

This solution pulls in 155 packages from npm, including multiple versions of bullshit packages like "kind-of" that it can't deduplicate. One of the direct dependencies is a library that renders a loading spinner in command line interfaces, which itself pulls in over 20 transitive dependencies. The reason that JavaScript build tooling is so complex and introduces so much overhead is that the ecosystem's culture is fun…

> with no build step during development and then what do you do for production, webpack?

I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
Post reply on HN