18 ms·

Snowpack: Build a web application without a bundler

391 points by codecurve 7y ago

swiley 7y ago
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 7y ago
  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?
  - eerrt 7y ago
    requests per second
  - judge2020 7y ago
    Technically web SQL is a thing but is depreciated and not supported by FF. OP was talking about sqlite on the server side.
baybal2 7y ago
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
simonw 7y ago
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 7y ago
  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
- hqjs 7y ago
  Try https://hqjs.org/ https://hqjs.org/ It can do much more than that. It takes care of sass/ less, frameworks and polyfills
gtmb 7y ago
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.
- wongarsu 7y ago
  But if it's the right tool for a FAANG company surely it must be the right tool for my use-case /s
- meritt 7y ago
  > devoted to mega super over engineered Javascript solutions Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning! It'll be nice when people get back to solving real business problems.
  - bmiller2 7y ago
    Fall of NOSQL?
    - simonw 7y ago
      I feel like many experienced developers I know have gone back to defaulting to SQL databases again, because it turns out the trade-offs of NoSQL (schema-free, horizontally-scaled-but-eventually-consistent etc) weren't worth the trade-offs.
    - djsumdog 7y ago
      Is your shop still using it? Most NoSQL systems I've seen in the wild are pretty much just used as a caching store .. fancy Reddis really. All the big shops I've worked at still use Postgres for persistant storage. If they need speed; they'll add Elastic Search or Spark and have indexing services to make sure they stay up to date.
simplecto 7y ago
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.
- uncle_j 7y ago
  That intercoolerjs looks pretty decent. With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
- robertoandred 7y ago
  Huh? React tooling options have never been simpler. Literally one command and you're ready to go.
  - djsumdog 7y ago
    Does it download 200MB of tools? (Seriously asking; I've contributed to some React apps but have made one from scratch never).
    - zdragnar 7y ago
      Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc). Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
  - 7y ago
sergiotapia 7y ago
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 7y ago
  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.
djsumdog 7y ago
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 7y ago
  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 7y ago
    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 7y ago
      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.
muhammadusman 7y ago
does anyone have experience using this?
- why-oh-why 7y ago
  It was just announced
pier25 7y ago
But this is only for importing JS modules, right? What about SASS, minification, etc?
- bentpins 7y ago
  It does minify when using the --optomize flag https://www.snowpack.dev/#optimizing-for-production https://www.snowpack.dev/#optimizing-for-production I am curious about SASS and other loaders too.
- hqjs 7y ago
  Try https://hqjs.org https://hqjs.org it takes care of everything like sass, less, typescript and polyfills.
ng12 7y ago
What can I do with Snowpack that I can't with a CDN?
- foota 7y ago
  They seem pretty orthogonal to me. Snowpack is about builds, CDN is about serving. You could serve snowpack built JS dependencies with a CDN.
- julienb_sea 7y ago
  You can leverage dependencies that are not published to a CDN, such as local dependency code.
Aeolun 7y ago
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’.
keyle 7y ago
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 7y ago
  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.
pcr910303 7y ago
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.
- acemarke 7y ago
  Exactly. There's very good reasons why tools like Webpack and Babel exist. Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem: http://tinselcity.net/whys/packers http://tinselcity.net/whys/packers https://www.swyx.io/writing/jobs-of-js-build-tools https://www.swyx.io/writing/jobs-of-js-build-tools As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with: https://increment.com/development/the-melting-pot-of-javascript/ https://increment.com/development/the-melting-pot-of-javascr... https://www.swyx.io/writing/js-tooling/ https://www.swyx.io/writing/js-tooling/ For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic. (Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
  - dmix 7y ago
    Plus theres a ton of starter kits for newbies on Github to get rolling without having to figure out the details. They are like mini-frameworks. Plenty for react, vue, etc, every combination.
- deleted 7y ago
  [deleted]
- GiorgioG 7y ago
  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.
typon 7y ago
Tbh parceljs does make bundling a lot better to deal with. For example, how would I integrate wasm using this?
mstade 7y ago
> 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!
jijji 7y ago
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 7y ago
  You wasting your time with inventing the wheel again and again?
MK_Dev 7y ago
I was getting worried we haven't seen a new JS tool for a few minutes.
andrew_ 7y ago
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_ 7y ago
  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.
earthboundkid 7y ago
OK Boomer.
systematical 7y ago
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.
robertoandred 7y ago
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 7y ago
  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.
- hqjs 7y ago
  Try https://hqjs.org/ https://hqjs.org/ it works with big projects and typescript as well as sass, less and frameworks.
jillesvangurp 7y ago
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 7y ago
  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.
sdnguyen90 7y ago
Question for people unhappy about JS tooling: what's stopping you from just using vanilla JS?
- ChikkaChiChi 7y ago
  The problem is one of culture. A reliance on complicated tooling requires specialization to these tools, which slows down team building time. I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
- mekster 7y ago
  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.
- hipjiveguy 7y ago
  If you build components that use other components, without using a bundler, you constantly have to remember/know what uses what to get things to load. This may sound like not a big deal, but it doesnt take long at all and suddenly you've got loading issues!
progx 7y ago
Does it make sense to use it with svelte?
touchpadder 7y ago
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 7y ago
  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 7y ago
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.
rafaelvasco 7y ago
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.
hqjs 7y ago
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-live-server https://marketplace.visualstudio.com/items?itemName=hqjs.hq-...

391 points by codecurve 7y ago

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 7y ago
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?
- eerrt 7y ago
  requests per second
- judge2020 7y ago
  Technically web SQL is a thing but is depreciated and not supported by FF. OP was talking about sqlite on the server side.

baybal2 7y ago

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

simonw 7y ago

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 7y ago
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
hqjs 7y ago
Try https://hqjs.org/ https://hqjs.org/ It can do much more than that. It takes care of sass/ less, frameworks and polyfills

gtmb 7y ago

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.

wongarsu 7y ago
But if it's the right tool for a FAANG company surely it must be the right tool for my use-case /s
meritt 7y ago
> devoted to mega super over engineered Javascript solutions Hey now, let's not discount the rise and fall of NoSQL, reinventing of data analysis except using python and spark cause SQL is too boring, or discovering linear regressions using a fleet of GPUs under the banner of Machine Learning! It'll be nice when people get back to solving real business problems.
- bmiller2 7y ago
  Fall of NOSQL?
  - simonw 7y ago
    I feel like many experienced developers I know have gone back to defaulting to SQL databases again, because it turns out the trade-offs of NoSQL (schema-free, horizontally-scaled-but-eventually-consistent etc) weren't worth the trade-offs.
  - djsumdog 7y ago
    Is your shop still using it? Most NoSQL systems I've seen in the wild are pretty much just used as a caching store .. fancy Reddis really. All the big shops I've worked at still use Postgres for persistant storage. If they need speed; they'll add Elastic Search or Spark and have indexing services to make sure they stay up to date.

simplecto 7y ago

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.

uncle_j 7y ago
That intercoolerjs looks pretty decent. With regards to tooling I agree it is too complicated. I really wish that everyone would coalesce around a standard set of tools. But it would be the equivalent of cat herding.
robertoandred 7y ago
Huh? React tooling options have never been simpler. Literally one command and you're ready to go.
- djsumdog 7y ago
  Does it download 200MB of tools? (Seriously asking; I've contributed to some React apps but have made one from scratch never).
  - zdragnar 7y ago
    Create-react-app is pretty heavy, because it includes support for things you may not need or want (css modules, typescript, etc). Putting together your own light-weight system isnt hard if you are familiar with the problems these tools solve, but unless you have a site so simple that it shouldn't use react anyway, you'll want the power and features that these tools can provide (automatic source splitting for lazy-loading code on route changes, sane management of language files for internationalization, extensive linting rules for even non-js things like accessibility features in html / jsx, automatic image optimizatuon, etc).
- 7y ago

sergiotapia 7y ago

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

djsumdog 7y ago

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

muhammadusman 7y ago

does anyone have experience using this?

why-oh-why 7y ago
It was just announced

pier25 7y ago

But this is only for importing JS modules, right? What about SASS, minification, etc?

bentpins 7y ago
It does minify when using the --optomize flag https://www.snowpack.dev/#optimizing-for-production https://www.snowpack.dev/#optimizing-for-production I am curious about SASS and other loaders too.
hqjs 7y ago
Try https://hqjs.org https://hqjs.org it takes care of everything like sass, less, typescript and polyfills.

ng12 7y ago

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

foota 7y ago
They seem pretty orthogonal to me. Snowpack is about builds, CDN is about serving. You could serve snowpack built JS dependencies with a CDN.
julienb_sea 7y ago
You can leverage dependencies that are not published to a CDN, such as local dependency code.

Aeolun 7y ago

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

keyle 7y ago

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

pcr910303 7y ago

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.

acemarke 7y ago
Exactly. There's very good reasons why tools like Webpack and Babel exist. Here's two excellent articles that go over the history and use cases behind the JS tooling ecosystem: http://tinselcity.net/whys/packers http://tinselcity.net/whys/packers https://www.swyx.io/writing/jobs-of-js-build-tools https://www.swyx.io/writing/jobs-of-js-build-tools As a counter-point, there's also valid reasons why a lot of the JS tooling ecosystem is painful to work with: https://increment.com/development/the-melting-pot-of-javascript/ https://increment.com/development/the-melting-pot-of-javascr... https://www.swyx.io/writing/js-tooling/ https://www.swyx.io/writing/js-tooling/ For myself personally, I'm quite happy with the React ecosystem. For the kinds of "desktop-app-in-a-browser" apps I work on, it's fantastic. (Caveat: I'm a Redux maintainer, so I'm also a bit biased here.)
- dmix 7y ago
  Plus theres a ton of starter kits for newbies on Github to get rolling without having to figure out the details. They are like mini-frameworks. Plenty for react, vue, etc, every combination.
deleted 7y ago
[deleted]
GiorgioG 7y ago
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.

typon 7y ago

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

mstade 7y ago

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

jijji 7y ago

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 7y ago
You wasting your time with inventing the wheel again and again?

MK_Dev 7y ago

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

andrew_ 7y ago

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_ 7y ago
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.

earthboundkid 7y ago

OK Boomer.

systematical 7y ago

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.

robertoandred 7y ago

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 7y ago
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.
hqjs 7y ago
Try https://hqjs.org/ https://hqjs.org/ it works with big projects and typescript as well as sass, less and frameworks.

jillesvangurp 7y ago

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

sdnguyen90 7y ago

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

ChikkaChiChi 7y ago
The problem is one of culture. A reliance on complicated tooling requires specialization to these tools, which slows down team building time. I've rescued several projects where more time was spent on making the lives of the developers "easier" than actually solving the problems of the user. Bike shedding and navel gazing is a huge problem in our industry, even if we don't like to admit it.
mekster 7y ago
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.
hipjiveguy 7y ago
If you build components that use other components, without using a bundler, you constantly have to remember/know what uses what to get things to load. This may sound like not a big deal, but it doesnt take long at all and suddenly you've got loading issues!

progx 7y ago

Does it make sense to use it with svelte?

touchpadder 7y ago

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 7y ago
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 7y ago

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.

rafaelvasco 7y ago

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.

hqjs 7y ago

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-live-server https://marketplace.visualstudio.com/items?itemName=hqjs.hq-...