
Pika/web: Web Apps Without the Bundler - beefman
https://www.pikapkg.com/blog/pika-web-a-future-without-webpack/#
======
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.

~~~
pier25
I've said before and I'll say it again, we wouldn't be in this mess if we had
a decent standard library and language to begin with.

~~~
preommr
The way it seems to work with JS is that the community develops a bunch of
stuff and the best rises to the top. This then influences the official
language spec. ES6 basically made a lot of the popular tools redundant because
it was heavily inspired by them.

This is so incredibly important because the main development of the language
is so poorly handled.

~~~
andreareina
And despite adding arrow functions, async/await, modules etc. we still don't
have sprintf and a Math.round that can specify the number of places to round
to.

I think that modern javascript is pretty good and I'm grateful for the syntax
extensions that have effected that, but the standard library is crying out for
some love.

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

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

~~~
ZenPsycho
I've never had an issue working with promises, but perhaps I'll have to give
that a try to see if it would make my life better.

------
TicklishTiger
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
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
Yup. We're going where the puck is going.

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

------
amnah
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
Javascript ecosystem as a whole.

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

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

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

------
leftyted
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
>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
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
[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

------
hitekker
> Complexity Stockholm Syndrome

A neologism that I can get behind.

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

