11 ms·

Pika/web: Web Apps Without the Bundler

198 points by beefman 8y ago

simplify 8y ago
What 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?
- fks 8y ago
  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.
pattisapu 8y ago
I guess every name is already taken for just about everything these days, but might as well note Pika CMS: https://pikasoftware.com https://pikasoftware.com
est31 8y ago
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 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. [1]: https://github.com/nathan/pax https://github.com/nathan/pax
- treve 8y ago
  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.
  - plausibilities 8y ago
    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.
    - s_y_n_t_a_x 8y ago
      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.
  - infinite8s 8y ago
    > 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)
  - Can_Not 8y ago
    nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.
plausibilities 8y ago
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?
- bengotow 8y ago
  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!)
  - s_y_n_t_a_x 8y ago
    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.
- chrisweekly 8y ago
  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.
  - plausibilities 8y ago
    srs = serious my bad
TicklishTiger 8y ago
Luckily, with native javascript modules, there is no need for any of this anymore. We switched our whole codebase to <script type=module> and it's such a joy now. Never going back to bundlers. Never going back to having a compilation step on the server.
- sgslo 8y ago
  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 https://caniuse.com/#feat=es6-module
  - TicklishTiger 8y ago
    Yup. We're going where the puck is going.
  - soperj 8y ago
    Even Microsoft is telling people not to use ie11.
  - miohtama 8y ago
    Yes and no. For many use cases, this might be justified. * You are hosting an internal enterprise application and you are forcing all of your employee desktops to use Chrome any case. * You are not serving a web site, but a business web app, which only works on a modern browser - because it is a business oriented app people are willing to switch the browser to use it. E.g. 3d modeler.
  - baroffoos 8y ago
    15% are only still on IE because it still works. If more devs start doing this you will be excluding 0% of users.
leftyted 8y ago
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?
- plausibilities 8y ago
  >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
  - coolreader18 8y ago
    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.
    - plausibilities 8y ago
      https://github.com/purtuga/esm-webpack-plugin 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
deleted 8y ago
[deleted]
amnah 8y ago
I still have no idea how to use this. The "simple" project is a bunch of files ... with no instructions on how to use it.
- sergiotapia 8y ago
  Javascript ecosystem as a whole.
segphault 8y ago
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.
- MuffinFlavored 8y ago
  > with no build step during development and then what do you do for production, webpack?
  - segphault 8y ago
    I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
    - anonytrary 8y ago
      Sorry if this is a dumb question -- but that means you don't write ES6?
      - Touche 8y ago
        It doesn't mean that, they might only support ES6 browsers (even IE11 has some ES6 support).
        8y ago
hitekker 8y ago
> Complexity Stockholm Syndrome A neologism that I can get behind.
ZenPsycho 8y ago
"Today, it’s nearly impossible to build for the web without using a bundler like Webpack." Is it? I've gotten by just fine, and webpack is a pretty all or nothing approach. Did everyone just forget how things were done before webpack and NPM overnight? What memo did I miss?
- GordonS 8y ago
  I think we're in a kind of awkward place right now, where browser support for ES6 is inconsistent, and TypeScript has stepped up to fill the "type gap" left by JavaScript in general. Sure, if you only use ES5 then you don't need Babel or Webpack - but devs are tired of this shit and really want to use ES6 or Typescript. So, "nearly impossible" is an exaggeration, but "would rather gouge my own eyes out" is perhaps not.
  - ZenPsycho 8y ago
    Tired of what shit exactly, though? typing the word "function"?, hacky workarounds to traditional "classy" style programming? Having to learn what deprecated features to avoid? Is it asynchronous programming? ES6 is nice, but the only real pain point I think it solves is standardising on a module system, which as this article proves, hasn't truly been solved yet, because now we're in the situation where we still have the legacy of competing mutually incompatible module systems hanging around. Everything else is programmers coming from other languages and believing that actually learning javascript is beneath their dignity, and persistently insisting javascript be more like whatever their fave is. I will say this though about build systems/bundling systems in general: Combined with linting and type checking, it can stop you from accidntally shipping a large class of bugs/mistakes. An out of place semicolon breaking a build is a better outcome than breaking a production website.
    - kaishiro 8y ago
      If you're actually looking for an answer, then you hit the nail on the head for me personally. For someone who spends 90% of their day working with Firebase/Cloud funcs, I really don't want to go back to promise handling. Call me lazy if it fits your narrative - but you can pry my async ES6 from my cold dead hands.
xrd 8y ago
I get the idea. But the title of this article is "how" not "why" yet the article doesn't ever really get to the how. I'm convinced of the why. I'm still excited to try it.
enno_au 8y ago
I found his opening analogy to be broken. In 1941 there were no clips and other things on the TV news because the tech to record and replay television signals hadn't been created. Until the 60's the only way to record TV was "telecine" which was, as the name implies to record the tv image on film. (The term also implied the reverse process of (re)broadcasting the filmed source material of course.) It wasn't that no one had thought of showing the dumpster fire (to use a quote from a earlier comment!) but simply that the tech wasn't there. A lot of the problems here are of the same nature. The right level of tech is yet to built and hopefully when it is it may also improve the nature of the media that gets bundled (much as telecine was pretty poor looking when compared to the video tape recording that supplanted it later). So trying new tools is good. But I haven't seen that paradigm altering shift yet.
fiatjaf 8y ago
Webpack is a big mess that always has some bug and shortcoming a new major breaking release upcoming, because it tries to do so much. Browserify does one thing and does it very well. I still would like to not have to use any of these, however.

198 points by beefman 8y ago

What 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?

fks 8y ago
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.

pattisapu 8y ago

I guess every name is already taken for just about everything these days, but might as well note Pika CMS: https://pikasoftware.com https://pikasoftware.com

est31 8y ago

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 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. [1]: https://github.com/nathan/pax https://github.com/nathan/pax

treve 8y ago
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.
- plausibilities 8y ago
  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.
  - s_y_n_t_a_x 8y ago
    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.
- infinite8s 8y ago
  > 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)
- Can_Not 8y ago
  nuxtjs and webpack4 are actually automatically bundling dependencies so that libraries are automatically included only on pages that use them.

plausibilities 8y ago

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?

bengotow 8y ago
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!)
- s_y_n_t_a_x 8y ago
  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.
chrisweekly 8y ago
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.
- plausibilities 8y ago
  srs = serious my bad

TicklishTiger 8y ago

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

sgslo 8y ago
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 https://caniuse.com/#feat=es6-module
- TicklishTiger 8y ago
  Yup. We're going where the puck is going.
- soperj 8y ago
  Even Microsoft is telling people not to use ie11.
- miohtama 8y ago
  Yes and no. For many use cases, this might be justified. * You are hosting an internal enterprise application and you are forcing all of your employee desktops to use Chrome any case. * You are not serving a web site, but a business web app, which only works on a modern browser - because it is a business oriented app people are willing to switch the browser to use it. E.g. 3d modeler.
- baroffoos 8y ago
  15% are only still on IE because it still works. If more devs start doing this you will be excluding 0% of users.

leftyted 8y ago

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?

plausibilities 8y ago
>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
- coolreader18 8y ago
  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.
  - plausibilities 8y ago
    https://github.com/purtuga/esm-webpack-plugin 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

deleted 8y ago

[deleted]

amnah 8y ago

I still have no idea how to use this. The "simple" project is a bunch of files ... with no instructions on how to use it.

sergiotapia 8y ago
Javascript ecosystem as a whole.

segphault 8y ago

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.

MuffinFlavored 8y ago
> with no build step during development and then what do you do for production, webpack?
- segphault 8y ago
  I use rollup with an extremely minimal configuration. No transpilers at all, just standards-based JavaScript.
  - anonytrary 8y ago
    Sorry if this is a dumb question -- but that means you don't write ES6?
    - Touche 8y ago
      It doesn't mean that, they might only support ES6 browsers (even IE11 has some ES6 support).
      - 8y ago

hitekker 8y ago

> Complexity Stockholm Syndrome A neologism that I can get behind.

ZenPsycho 8y ago

"Today, it’s nearly impossible to build for the web without using a bundler like Webpack." Is it? I've gotten by just fine, and webpack is a pretty all or nothing approach. Did everyone just forget how things were done before webpack and NPM overnight? What memo did I miss?

GordonS 8y ago
I think we're in a kind of awkward place right now, where browser support for ES6 is inconsistent, and TypeScript has stepped up to fill the "type gap" left by JavaScript in general. Sure, if you only use ES5 then you don't need Babel or Webpack - but devs are tired of this shit and really want to use ES6 or Typescript. So, "nearly impossible" is an exaggeration, but "would rather gouge my own eyes out" is perhaps not.
- ZenPsycho 8y ago
  Tired of what shit exactly, though? typing the word "function"?, hacky workarounds to traditional "classy" style programming? Having to learn what deprecated features to avoid? Is it asynchronous programming? ES6 is nice, but the only real pain point I think it solves is standardising on a module system, which as this article proves, hasn't truly been solved yet, because now we're in the situation where we still have the legacy of competing mutually incompatible module systems hanging around. Everything else is programmers coming from other languages and believing that actually learning javascript is beneath their dignity, and persistently insisting javascript be more like whatever their fave is. I will say this though about build systems/bundling systems in general: Combined with linting and type checking, it can stop you from accidntally shipping a large class of bugs/mistakes. An out of place semicolon breaking a build is a better outcome than breaking a production website.
  - kaishiro 8y ago
    If you're actually looking for an answer, then you hit the nail on the head for me personally. For someone who spends 90% of their day working with Firebase/Cloud funcs, I really don't want to go back to promise handling. Call me lazy if it fits your narrative - but you can pry my async ES6 from my cold dead hands.

xrd 8y ago

I get the idea. But the title of this article is "how" not "why" yet the article doesn't ever really get to the how. I'm convinced of the why. I'm still excited to try it.

enno_au 8y ago

I found his opening analogy to be broken. In 1941 there were no clips and other things on the TV news because the tech to record and replay television signals hadn't been created. Until the 60's the only way to record TV was "telecine" which was, as the name implies to record the tv image on film. (The term also implied the reverse process of (re)broadcasting the filmed source material of course.) It wasn't that no one had thought of showing the dumpster fire (to use a quote from a earlier comment!) but simply that the tech wasn't there. A lot of the problems here are of the same nature. The right level of tech is yet to built and hopefully when it is it may also improve the nature of the media that gets bundled (much as telecine was pretty poor looking when compared to the video tape recording that supplanted it later). So trying new tools is good. But I haven't seen that paradigm altering shift yet.

fiatjaf 8y ago

Webpack is a big mess that always has some bug and shortcoming a new major breaking release upcoming, because it tries to do so much. Browserify does one thing and does it very well. I still would like to not have to use any of these, however.