
Snowpack: Build a web application without a bundler - codecurve
https://www.snowpack.dev/
======
djsumdog
Although I've contributed to some React projects, the last time I had to do
user-facing web frontend stuff was with the original Angular. Looking at this,
I'm really glad I don't do frontend anymore.

I've touched some vue.js too, but I just hate the direction everything is
going. These projects are just insanely complex. Component frameworks may be
easier to develop with, but they add so much damn bloat and crazy amounts of
tooling. I get frustrated enough with Jekyll and that's just a static content
generator.

I really miss the simplicity of plain old jQuery and some backend.

~~~
fks
Frontend over-complexity is exactly the problem that this is trying to solve
for! You can think of this as a simple post-install tool that removes a huge
chunk of the complexity (bundling) from your stack, without limiting what you
can build.

If this direction of simplified web development is something you're interested
in, you'll enjoy this post I wrote back when we started this project (and it
was called @pika/web): "A Future Without Webpack" \-
[https://www.pika.dev/blog/pika-web-a-future-without-
webpack/](https://www.pika.dev/blog/pika-web-a-future-without-webpack/)

 _Disclaimer: I created Snowpack & Pika (pika.dev)._

~~~
core-questions
Adding more tools to abstract and hide away the complexity doesn't actually
make the complexity go away, though, does it? It doesn't make it easier to
reason about the end result. Just hides it under a veneer.

I think what the guy you're responding to is after is similar to what I'd like
to see: a front end that isn't composed of 20 years of hacks layered on top of
each other because of poor initial choices.

~~~
fks
That's whats so cool about this: Unlike Create React App or other "starter
apps" that try to hide complexity from you, Snowpack actually removes that
complexity entirely. If you didn't want to use a single other tool, you could
use Snowpack to build a fully modern web app by shipping your source code
directly to the browser (cue the "View Source" nostalgia :)

Luke Jacksonn is someone who's done some interesting work in this space with
zero-build-tooling sites: [https://perf.link](https://perf.link) \-
[https://github.com/lukejacksonn/perflink](https://github.com/lukejacksonn/perflink)

[https://www.pika.dev](https://www.pika.dev) is built with Babel and
TypeScript, so it's not technically "zero-tooling", but we still get almost
instant iteration by skipping a "bundle" step during development.

~~~
core-questions
Even TypeScript having to compile down to JS for the browser just feels
fundamentally wrong. Why write something in some new, domain-specific language
that compiles down to an inferior language to run in the browser?

Hopefully with WASM we see the rise of client-side frameworks that bypass all
of this bullshit entirely and give us a clean slate to develop on that picks
up the best of the 90s low-code projects and makes them cloudworthy. There's
no reason why 99% of the UI that most sites need isn't just assembled from a
nice list of stock UI widgets.

Disclaimer, am old and miss 90s desktop apps

~~~
acemarke
Gotta nitpick here.

JS _is_ the native language for browsers. Therefore, it's reasonable to target
it.

While it's entirely possible to compile your language interpreter of choice to
WASM and run that in a browser, you're now in sort of the reverse position
that folks complain about with Electron: adding tons of extra bloat, overhead,
and complexity, just to duplicate some other runtime environment into a place
it wasn't particularly intended to be used in the first place.

In addition, with most "compile other language to WASM" demos I've seen so
far, they end up just drawing things on canvas, thus losing all the
accessibility aspects that are built into the DOM already. (Yes, I know WASM
has some DOM interop abilities and more coming, but that's not generally what
I'm seeing done atm.)

What's _really_ needed is way better UI elements built directly into HTML, but
those are sadly lacking.

~~~
brylie
Now that web components are maturing, is there any working group that is
chartered to improve the standard HTML UI compnent library?

~~~
acemarke
There's been some discussion of making things like a virtual scroller
available under an "std" global namespace [0], and the Chrome/Edge teams
recently did a refresh of just the visual appearance of the standard built-in
HTML inputs [1] (which, frankly, I think look even worse now).

Beyond that, nothing meaningful is happening. Even the input types defined as
part of the HTML5 spec are still barely supported [2], and if browsers can't
manage to implement decent date/time/range/color inputs, there's no way of
getting more complex components designed and standardized.

Of course, the other aspect of that is, anything that is part of the web API
is there forever, which means bugs and mistakes aren't really fixable. So,
there's some benefits to having a purely community-driven ecosystem instead.

[0] [https://github.com/WICG/virtual-
scroller](https://github.com/WICG/virtual-scroller)

[1] [https://blogs.windows.com/msedgedev/2019/10/15/form-
controls...](https://blogs.windows.com/msedgedev/2019/10/15/form-controls-
microsoft-edge-chromium/)

[2] [https://www.smashingmagazine.com/2019/01/html5-input-
types/](https://www.smashingmagazine.com/2019/01/html5-input-types/)

~~~
brylie
What framework-agnostic HTML UI component library would you recommend? Most of
the options I have seen either have framework-specific dependencies (React,
Polymer, Aurelia, Angular, Vue) or are just low-level frameworks for building
your own UI/web components.

~~~
lamplightdev
Any UI library based on web components is your best bet for a 'framework-less'
solution. Some more popular ones are:

\- Material Design Web Components, [https://github.com/material-
components/material-components-w...](https://github.com/material-
components/material-components-web-components)

\- Vaadin, [https://vaadin.com/components](https://vaadin.com/components)

\- UI5,
[https://sap.github.io/ui5-webcomponents/](https://sap.github.io/ui5-webcomponents/)

------
pcr910303
Seriously, people in this thread should really stop complaining about
'complexity' in the web space if they really haven't written & maintained a
jQuery application. Most of JS tooling stems from 1. different browsers and 2.
(the once) nonexistent module system. Until very recently, 2 didn't have any
solutions (so Browserify, Webpack, Parcel, and various different bundlers
exist) and 1 still doesn't (and so Babel exists).

These tools aren't the simplest things, but so is everything, everywhere.
Complexity needs to exist somewhere, and using an abstraction to hide them is
something natural. Do people think we shouldn't use compilers because we 'can'
write binary ELF files directly? Same goes to JS.

~~~
GiorgioG
I disagree. I spend most of my time at work in an Angular app and it sucks.
The compile times suck, the developer experience sucks and it's not getting
better, it's only getting worse. I had a chance to do some side work and
decided against building a SPA. I wound up using ASP.NET Core Razor Pages
(templated pages) and it's been a breath of fresh air - I haven't enjoyed
myself this much writing web software in ages because I can get stuff done in
very short order. If I need some more complex interactivity then I might
sprinkle in something lightweight but I expect that to be the exception not
the rule.

Death to complexity on the frontend for complexity's sake.

~~~
pcr910303
> I spend most of my time at work in an Angular app and it sucks. The compile
> times suck, the developer experience sucks and it's not getting better, it's
> only getting worse.

> I wound up using ASP.NET Core Razor Pages (templated pages) and it's been a
> breath of fresh air - I haven't enjoyed myself this much writing web
> software in ages because I can get stuff done in very short order.

Okay, so I've never worked in Angular, so I can't really speak (maybe there
are Angular killer features that justifies using Angular?), but... If it looks
like it'll be simpler in ASP.NET pages, go for it!

Everybody likes lighter pages, if your app is simple * doesn't need to be a
heavy Angular SPA, you shouldn't be using them.

~~~
GiorgioG
Most apps are simple, no I’m not talking about Facebook. The problem is
templated pages apps are not considered sexy, so we build SPAs so we can look
good (and pad the resume,) to the detriment of productivity.

~~~
misterman0
At my day job, the meme that won and now dominate is "the percieved
performance of a SPA is greater than that of a non-SPA". My calls for making
our backend more performant are ignored (and probably ridiculed, because of
how out-of-the-loop I seem). React for the win!

I hardly belong anywhere, it sometimes seems.

------
simplecto
I really enjoyed react when it first came out and there was little fussing
with browserify (3-4 years ago).

But now this tooling is out of hand. I threw up my hands and found sanity
again in simplicity (my username namesake).

    
    
      * Django
      * jquery
      * intercoolerjs (https://intercoolerjs.org)
      * plain old docker
    

It is like war-games. The only winning move is not to play.

Now I deploy apps with no more than 100 lines of JS.

Again, not prescriptive, just my own journey.

~~~
vmsp
If you're a fan of this type of libs, you should also check out
[https://stimulusjs.org/](https://stimulusjs.org/) and
[https://umbrellajs.com/](https://umbrellajs.com/).

~~~
jturpin
These both look cool. I've learned some Vue in the past but I strongly prefer
these kinds of small, self contained libraries for my Flask + PicnicCSS + very
simple JS apps.

~~~
brylie
I mentioned this library in a previous comment, but LiteDOM might be
interesting to you as it is somewhat similar to Vue:

[https://litedom.js.org/](https://litedom.js.org/)

------
mstade
> Who Should Avoid Snowpack?

> \- Anyone who loves tooling-heavy development! This isn’t sarcastic, I
> promise! By dropping the bundler, you can’t do the magic that Webpack is
> famous for. Using import to load CSS, Images, and other non-JS resources is
> non-standard and unsupported in the browser (for now). You may appreciate a
> dev environment that is true to what standard JavaScript browsers support.
> Or, you may find this annoying.

\---

I like that they make this a point, and I'm very much in the "let's not
overload the standards" camp so I appreciate this as a feature, not a bug.
This convinces me to give this tool a go!

------
keyle
The top comments are all about the complexity of front ends nowadays and X and
Y comparison.

But they're missing the point, this is a really good idea.

~~~
austincheney
Consider the series of bad decisions that allowed such complexity to ooze in
the first place. It all eventually boils down to developers putting their
needs and concerns ahead of the product/user. I am not convinced this new tool
will solve for bad/undisciplined developers.

I used to use _1000 NPM packages_ as a sarcastic example about bad decisions
and death by dependency overkill then I installed Angular which pulls in 1100
packages alone. The end user doesn’t care about your framework choice,
favorite language, tech stack, or build process. They just know your
application is slow, clumsy, and riddled with defects.

------
simonw
This is really exciting to me. I've been meaning to try and get my head around
how to start using ES modules with modern JavaScript stuff but it's tough
because pretty much every tutorial assumes you'll be using Webpack. Snowpack
looks like it might be the tool I've been missing.

~~~
spankalee
I would also check out es-dev-server[1] from the open-wc.org project.

It's basically just a static file server that can automatically rewrite bare
module specifiers using Node module resolution. It's the minimal transform you
can apply to npm-installed JS modules that import dependencies via package
name.

Yes, you get a waterfall of loads during development, but I haven't had this
slow things down in practice, and once you get to development you can use
Rollup to bundle modules, but unlike Webpack, it can bundle to standard module
output.

[1]: [https://www.npmjs.com/package/es-dev-
server](https://www.npmjs.com/package/es-dev-server)

------
baybal2
I've been waiting for something like that for ages.

Really, setting up and fixing js tooling breakage often take more time than
actual development for smaller projects

------
MK_Dev
I was getting worried we haven't seen a new JS tool for a few minutes.

------
sdnguyen90
Question for people unhappy about JS tooling: what's stopping you from just
using vanilla JS?

~~~
mekster
Not exactly unhappy but why vanilla? By using transpiler and bundler, you get
to,

\- Use better JS (TypeScript) to be sent as ES5 (down to IE6 supoort) without
waiting for people to upgrade their browsers to the latest, which is forever.

\- Upgrade to latest specified version of libraries without having have to
check every site and download the min.js or change the script tag url manually
and dependencies are resolved automatically.

\- Get to use stuff like stylus which is already far better than CSS 3 syntax
and again, no need to wait for people to upgrade their browsers.

\- Bundle all JS and CSS as a single file (and place all the other assets like
images at a specified location automatically), which can be cached for instant
load from second page, unless your frontend code is so fat, a single file
becomes too huge for it.

\- If your server side is node.js, you get to use a completely same language
(TypeScript) for backend and frontend.

------
robertoandred
These guys are vastly exaggerating the time it takes to update a dev
environment on save. It’s usually ready before you switch back to the browser.

~~~
khalilravanna
For large projects, especially ones with TypeScript, this is definitely not
true from my experience. Not sure if this a tool that’s suitable for those
large projects but just saying that it definitely is a problem that would be
nice to solve.

------
systematical
I'm hoping some sanity is brought to front-end development. I had a project
which legitimately did require a slice of the site to be SPA. I didn't do the
full site, just the piece that needed it. When I looked at using React I was
confused that it seemingly didn't want me to actually write HTML. Maybe I
misread something, but it seemed like it wanted me to return HTML from
JavaScript...this made little sense to me. I ended up using VueJS because it
was far easier to learn. It did the job.

Webpack certainly is confusing too. I did a side project with some webpack and
es6 stuff. It was kinda fun, but man, front-end development has sucked
forever. I remember back in the day having to fight with IE6. Here we are,
thirteen fucking years later and shit seems to have gotten only MORE complex.

I look at server-side programming for comparison. PHP for instance certainly
is more complex with some of the frameworks you can use now and of course
composer. But those are WAY simpler than the shit I had to deal with when
coding the front. I just don't understand how things have gotten more complex
on the front-end, brutal.

It got me thinking about playing around with WebAssembly for building front-
end applications. Maybe that doesn't fit all use-cases and maybe the grass is
always greener, but I wonder if programming in sane ecosystem would be the
sane thing to do...?

Put me in the camp that if there isn't a use-case slapping me in the face,
choking me, and yelling at me to do a SPA then I'll avoid the shit like a
plague. I'll just go with server-side render pages and sprinkle in some very
basic jQuery as needed. I actually did that for a CRM two years ago and the
thing is so damn simple to program in, because JavaScript is only used if it
ACTUALLY provides a benefit to the user. There is a site-wide script that is
maybe 100 lines of code. Then some page-specific things that load in stuff
using RequireJS, but the most complex JS out of those is maybe 300 lines. The
vast majority of the site doesn't really use much JavaScript. Just plain old
MVC.

As always, please BURN YOUR JAVASCRIPT STICKERS.

------
Aeolun
I think this is cool, but it’s hard to do any development in the current
ecosystem without a lot of the magic of webpack.

I can’t count the number of times the solution to a problem we had was
described as ‘just add these lines of magic to your webpack config’.

------
touchpadder
This project looks like [http://vanilla-js.com/](http://vanilla-js.com/) to
me. It's already possible to load modules without any library with <script
type="module"...

~~~
hipjiveguy
Snowpack looks like it works with any 3rd party module, doesnt it? It looks
like vanilla-js is more of a jquery style lib + optional addons?

------
plopz
You would definitly need http/2 to use this, I've tried using imports in
vanillajs with supported browsers its sloooooooow. I do wonder whether you
could leverage server push for this and whether that would help.

------
jijji
I do all web development without any bundles, it just adds more complexity and
dependencies to the application, too many things that can go wrong, too much
bloat, possible security issues, etc.

~~~
progx
You wasting your time with inventing the wheel again and again?

------
hqjs
There is an alternative that can do much more and require less effort. Check
it out [https://hqjs.org](https://hqjs.org) plus vscode plugin
[https://marketplace.visualstudio.com/items?itemName=hqjs.hq-...](https://marketplace.visualstudio.com/items?itemName=hqjs.hq-
live-server)

------
rafaelvasco
Use cases of front end are getting more and more complex so the tools are as
well. One could argue that we are trying to do so much with a platform that
offers so little by default. Maybe that's the inherent culprit. Don't know. I
really prefer frontend dev to backend (when I started it was all the same
really), but I have to admit frontend complexity can scale pretty fast.

------
jillesvangurp
The added value of build tools is that javascript are increasingly the
assembly of the web and more of a compilation target than something you deal
with natively (using the term loosely here since we are talking extensive
interpreter and compiler hacks that are needed to make this interpreted
language feel fast-ish).

With web assembly maturing, interacting with this mess is becoming
increasingly optional. Also languages like typescript and kotlin that compile
to javascript add layers of much needed sanity. IMHO any project not using
that is doing it wrong at this point. I'm very aware that this is opinionated
and even offensive to some but after 2 decades of "maybe this will fix it"
type innovation in the javascript world, I have very little patience left for
that. The less I'm exposed to that smelly pile of manure, the better IMHO.

So, my recommendation: avoid this tool and use a sensible compile, verify,
test, minify, and package it up style tool chain like all the grown ups do
these days. I agree, tools for this are very much a cluster-fuck in terms of
complexity, lack of any sane defaults that are actually good enough,
usability, and performance but they're better than nothing.

In an ideal world, you'd not have to download hundreds of MB of layers of
tools around tools that try to fix and work around each other. But there's no
good technical reason to skip using them entirely. There's no sane excuse to
skip sanity checks, type checks, static code analysis and running tests (and
designing such that you can actually do this in a sane way, which seems to be
hard with JS). Skipping that is immature and irresponsible. I don't tolerate
it in my own projects and have no patience for self styled full stack js
ninjas claiming their code is fine. It's not anywhere near fine.

~~~
goatlover
Or use whatever tool is best for the task at hand. No need to overly
complicated making a website if you don't need to transpile and combine a
bunch of libraries. Even just use jQuery or plain JS with a minimal backend if
that's all you need for a simple website.

Also, my guess is JS still predominates as the web language being used by
developers, provided that React syntax is included.

------
muhammadusman
does anyone have experience using this?

~~~
why-oh-why
It was just announced

------
typon
Tbh parceljs does make bundling a lot better to deal with. For example, how
would I integrate wasm using this?

------
pier25
But this is only for importing JS modules, right?

What about SASS, minification, etc?

~~~
hqjs
Try [https://hqjs.org](https://hqjs.org) it takes care of everything like
sass, less, typescript and polyfills.

------
ng12
What can I do with Snowpack that I can't with a CDN?

~~~
foota
They seem pretty orthogonal to me. Snowpack is about builds, CDN is about
serving. You could serve snowpack built JS dependencies with a CDN.

------
progx
Does it make sense to use it with svelte?

------
gtmb
The joys of the javascript ecosystem: (1) creating complex solutions for
problems no one has or (2) creating complex solutions to fix the problem of
complex solutions that didn't need to exist in the first place

It is an endless loop.

The first dot-com bubble resource wastefulness was spending so much money on
networking gear. Every one had oversized expensive Cisco gear.

This dot-com bubble resource wastefulness is so many hundreds of thousands of
engineering hours devoted to mega super over engineered Javascript solutions.

~~~
rictic
I get framework and tooling fatigue, but it seems misaimed here. This project
is an attempt at minimizing complexity, not adding onto it. There's a
fundamental problem with writing JS for the browser: how do you expresses your
dependencies?

jquery-era code solved this by just putting the dependencies in the README of
a project (e.g. "this project requires jQuery and jQuery UI version 3! load
them before loading this script!"). It worked, but it was error prone and
manual.

More recent code has solved it by writing code that used abstract specifiers,
like require('jquery'), which meant that you needed to use a complicated and
often hyperconfigurable bundler to run in the browser (because the browser
can't go searching the filesystem to figure out where the code for the
'jquery' package is)

With ES modules we're almost there, browsers can import files now, but they
still need a bit of additional info to tell them how to resolve underspecified
modules like 'jquery' (as opposed to './utils.js' which they can handle with
no problem). You can write your code with fully specified imports, but the
difficulty is that that code doesn't travel well, e.g. if you write `import
'../node_modules/jquery/jquery.js'` that won't work if someone uses your
package as a library, because jquery.js will actually be at
'../jquery/jquery.js' because your package lives in the node_modules
directory.

~~~
core-questions
> how do you expresses your dependencies?

because literally just putting them in a folder somehow became insufficient
for any number of reasons, some of which seem to have to do with JS's lack of
an include() function like every other interpreted language has had since
forever

like, how about i don't need 20,000 dependancies, and just use an application
stack that includes normal things like trimming a string

~~~
ratww
_> some of which seem to have to do with JS's lack of an include() function_

This has been solved by ES Modules, which is already in all major browsers.
Only IE is lagging behind (but there are polyfills).

------
andrew_
Avoiding the FUD and "this vs. them" on posts like these is nearly impossible.
Snowpack is an awesome utility and I'm glad it exits. In fact, Snowpack is a
great compliment to Rollup for development - because Rollup <3 ES Modules.

I'm a core contributor on Rollup. Rollup is surging, and we've been seeing a
ton of interest and new contributors. We're doing some awesome things to
improve it, and if you'd like to help advance ES Modules and tooling, we'd
love your help.

~~~
andrew_
It would have been great to see some replies from those who downvoted. I'm not
sure how that message isn't positive, but it I'd welcome some outside
perspective on that.

------
sergiotapia
I thought this was going to be an article showing you how to build modern
websites without the cancer that is /node_modules/ but it's Yet Another
Webpack Killer. Imagine my face as I wince at the JS ecosystem as a whole.

~~~
mpeg
This isn't really a webpack competitor, it's the same functionality of webpack
(production-ready js builds) but leveraging modern web standards (ESM)

It's almost like comparing jQuery to web components, maybe you can achieve
similar things to both, but one is a feature with native browser support.

------
swiley
Man you can already build web applications without bundlers! go with sqlite
will give you a single binary you just run!

Also if your needs are simple you can just write a cgi script (provided you
don't need too many RPS.)

~~~
dhritzkiv
I'm not sure what this means… sqlite isn't available to use in any browser.
Not to mention, it has nothing to do with JavaScript on the web.

Snowpack is for bundling ES modules to build web applications. Nothing
mentioned in your comments works to build a client-side web application. If
this your comment was some sly remark, it's totally lost on me.

Also, what's RPS?

~~~
judge2020
Technically web SQL is a thing but is depreciated and not supported by FF. OP
was talking about sqlite on the server side.

