from Hacker News

Snowpack: Build a web application without a bundler

by codecurve on 1/8/20, 9:52 AM with 232 comments

• by pcr910303 on 1/9/20, 12:58 AM

  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.

• by simplecto on 1/8/20, 11:17 PM

  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.

• by mstade on 1/9/20, 1:06 AM

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

• by keyle on 1/9/20, 12:42 AM

  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.

• by simonw on 1/8/20, 11:13 PM

  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.

• by MK_Dev on 1/9/20, 1:55 AM

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

• by sdnguyen90 on 1/9/20, 8:27 AM

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

• by systematical on 1/9/20, 4:48 AM

  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.

• by robertoandred on 1/9/20, 6:03 AM

  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.

• by Aeolun on 1/9/20, 12:30 AM

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

• by touchpadder on 1/9/20, 1:52 PM

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

• by plopz on 1/9/20, 2:26 PM

  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.

• by jijji on 1/9/20, 1:08 AM

  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.

• by rafaelvasco on 1/9/20, 6:53 PM

  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.

• by hqjs on 1/18/20, 11:33 AM

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

• by jillesvangurp on 1/9/20, 6:16 AM

  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.

• by muhammadusman on 1/8/20, 11:50 PM

  does anyone have experience using this?

• by typon on 1/9/20, 1:00 AM

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

• by pier25 on 1/8/20, 11:57 PM

  But this is only for importing JS modules, right?

  What about SASS, minification, etc?

• by ng12 on 1/9/20, 12:16 AM

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

• by progx on 1/9/20, 1:15 PM

  Does it make sense to use it with svelte?

• by djsumdog on 1/8/20, 11:38 PM

  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.

• by baybal2 on 1/8/20, 11:08 PM

  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

• by swiley on 1/8/20, 11:03 PM

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

• by gtmb on 1/8/20, 11:16 PM

  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.

• by andrew_ on 1/9/20, 3:28 AM

  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.

• by sergiotapia on 1/8/20, 11:33 PM

  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.