22 ms·
Snowpack 2.0
- simonebrunozzi 6y agoTell me what it is exactly, before starting with a list of features, 50ms start, etc.
- mgoetzke 6y agoI just tried it in a @microsoft/rush project of mine. Added a new project with 1 dependency (which contains a single one-liner function to return a test string). No other dependencies. Takes about 30s to start. Not sure whether the fact that my dependency is a link with many siblings due to rush and pnpm is an issue, but it is a far cry from 50ms. Also I did not get it to reliably pick up when the dependency has changed (cache invalidation most likely has an incompatible strategy with `npm link`/`pnpm`. Snowpack in principle looks nice, but I think I need something else
- KaoruAoiShiho 6y agoIs Svelte really now a tier 1 library compelling enough to put in advertisements like this?
- tylerchilds 6y agoI'd say it's S Tier, but the casuals aren't on board with the pro meta.
- cgidriver 6y agoDoes anyone know when is webpack 5 getting released?
- matthewhartmans 6y agoCongrats on V2 and everyone involved!
- yesion 6y agoSo Vite is already dead? Geez!
- gavinray 6y agoVite and Snowpack are a little different, though definitely similar in many regards. There's some good info here: https://github.com/vitejs/vite#how-is-this-different-from-snowpack https://github.com/vitejs/vite#how-is-this-different-from-sn... The salient points seem to be: 1. "Vite is more opinionated and supports more opt-in features by default - for example, features listed above like TypeScript transpilation, CSS import, CSS modules and PostCSS support all work out of the box without the need for configuration." 2. "Both solutions can also bundle the app for production, but Vite uses Rollup while Snowpack delegates it to Parcel/webpack. This isn't a significant difference, but worth being aware of if you intend to customize the build."
- yesion 6y agoThanks, that's useful!
- dandelany 6y agoI know you're being facetious, but as someone who used to follow "the new hotness" JS libraries constantly coming out, I'd advise caution with this way of thinking. There is a tendency for developers to see every new library/framework/tool as "the new way" which obsoletes the old - often because the new tool advertises itself based on distinctions/improvements made over existing libraries. Browserify, Webpack, Parcel, Rollup, Vite, Snowpack: people use all of these for different reasons & they all have their own advantages & drawbacks. It often doesn't make sense to abandon a stable solution for one which promises speed/magical features but may be full of bugs/untested (not saying this is true of Snowpack, but you can't just trust the claimed feature list as an accurate representation of the tool). I mention this simply because I've been in so many situations where a dev casually denigrates someone else's work because it was built using an "old" solution, without engaging with the core functionality of the code. Like "oh, they're using Webpack, they must not have heard of Rollup." It's good to be re-evaluate the tools you use from time to time, but don't let the "new hotness" make you think the old tried-and-true ways are any less valid - many yaks have been shaved and bikes shedded this way.
- taneq 6y agoThankyou for putting, nice and prominently at the top, what Snowpack actually is! (“Snowpack 2.0: A build system for the modern web.“)
- XCSme 6y agoSounds interesting. It's a bit unclear for me what the "runs in 15ms" means. I think in my projects, the TypeScript compilation is what takes the longest, so although I use parcel and it's pretty fast, I still have to wait 1-2 seconds for TypeScript to compile changes. If it does not bundle, and still uses all the external transformers (TypeScript, Babel, etc.), what exactly does it do? Does it somehow optimize the execution of those transformers/transpilers?
- genuine_smiles 6y ago> I think in my projects, the TypeScript compilation is what takes the longest, so although I use parcel and it's pretty fast, I still have to wait 1-2 seconds for TypeScript to compile changes. The build result doesn’t need to wait on the results of the type checking. TypeScript or Babel transpiling can happen even if there is a type error. > If it does not bundle, and still uses all the external transformers (TypeScript, Babel, etc.), what exactly does it do? Does it somehow optimize the execution of those transformers/transpilers? It skips the bundling step, and does aggressive caching.
- XCSme 6y ago> The build result doesn’t need to wait on the results of the type checking. TypeScript or Babel transpiling can happen even if there is a type error. I do run TypeScript async with Parcel, but I still wait for it to finish before I start working on a different task as I do want to know if I have any TS errors before proceeding. > It doesn’t optimize the transformers/transpilers; but it does only run them against the modules that have changed. But isn't this how other bundlers work too? They cache results and only run transformers on the changed files?
- genuine_smiles 6y agoI tweaked my comment a little. I’m not sure exactly how webpack is doing it’s work, but I think you’re right. I think the big optimization is skipping the bundling. If you want to wait on type checking results, and that’s the slowest part, then I don’t see how this could speed up your builds.
- pvg 6y agoRecently: https://news.ycombinator.com/item?id=21989967 https://news.ycombinator.com/item?id=21989967
- orf 6y agoSome of this wording confuses me and should probably be reworked: > Snowpack is a O(1) build system… Every file goes through a linear input -> build -> output build pipeline Seems like O(n) to me? > Snowpack starts up in less than 50ms. That’s no typo: 50 milliseconds or less. On your very first page load, Snowpack builds your first requested files and then caches them for future use So you can open a socket in 50ms? Seems disingenuous to imply anything takes 50ms when really you’re just waiting until the first request to do anything. Looks like an interesting project though.
- Humphrey 6y agoI believe they are saying O(1) since it only builds the single file that you just changed and will never just build all your files. They also mention that it only builds the files as requested by the browser, so in terms of the compiler it would be O(1), however it would effectly become O(n) the first time you use it if you include all the individual requests the browser makes as a single unit.
- doovd 6y agoIndeed, there's nothing O(1) about this and is precisely still O(n) ¯\_(ツ)_/¯
- aphextron 6y ago>Seems like O(n) to me? As the number of files grows, so does the speed of your builds? O(n) effectively approximates O(1) with sufficiently low values of n
- deleted 6y ago[deleted]
- adtac 6y agoIf we're just going to make up new definitions for existing terminology, why even bother discussing anything?
- XCSme 6y agoI think you confused some definitions, what you are saying sometimes applies for O(constant), for example you can consider O(57) to be O(1), if the number "57" never changes even though the input size changes. O(n) by defition means that execution time grows lineary with input size.
- stefan_ 6y agoI don't think they understand what O(1) even means.
- adtac 6y agoNot just that: >Some bundlers may even have O(n^2) complexity: as your project grows, your dev environment gets exponentially slower They seem to not understand the difference between exponential and quadratic either. This is appalling.
- XCSme 6y agoIt seems like they're spamming a lot of O(buzzwords).
- mekster 6y agoSometimes I wonder why people cannot simply replace technical expressions with plain English words.
- phist_mcgee 6y agoEh, so what, they're not using the correct mathematically term for complexity. Do most developers care if it is quadratic or exponential? I don't care, because they're both varying degrees of bad. It's just one gets worse faster than the other.
- tpxl 6y agoOne gets bad at 10, the other at 10000. There's quite a difference.
- sbarre 6y ago> This is appalling. Your /s is (hopefully) missing.
- ascotan 6y agoIt seems like the author is implying there is a flat constant time for compilation which can't be true because it's dependent on the number of changed files.
- 0az 6y agoHow does Snowpack compare to Rollup? I use Rollup because it's light-weight and dependency-free.
- k__ 6y agoAFAICT It allows you to develop without bundling, but for production it still bundles with Parcel.
- dgoldstein0 6y agoIt uses rollup with a bunch of plugins internally.
- orra 6y agoI find this interesting. As a mainly desktop developer now doing web frontend work, the JS ecosystem has been so frustrating. Bundlers struck me as unnecessary given JS now has native module support, and that is the premise of this project. Some out of memory issues when bundling certain dependencies, and slow "npm start" times with React, has only strengthened my initial impressions. So again, this could be a welcome impovement.
- atrilumen 6y agoYou'll likely still want to bundle for production, though, for the optimizations like minification, dead code elimination, module splitting, etc. But yeah, JS is Crazy Town. It can be very frustrating. ( Be wary of dependencies. )
- elpool2 6y agoI started using Snowpack just last week, but I'm not even using the dev server or the bundler part. All I really needed was its ability to convert npm packages into single-file ES modules. Once everything is an ES module you can just let the browser load them all, no bundler or dev server needed at all in your dev cycle. The only dev-time conversion needed is the compilation from typescript to JS, which my IDE already does instantly whenever I save. Previously this worked fine for all our own code but not for dependencies, so I'm pretty happy Snowpack was able to solve that problem.
- _bxg1 6y agoHow does it work with shared dependencies? Does each direct npm dependency get bundled with its own copy of each shared dependency, or do those get re-wired to point to a shared module?
- elpool2 6y agoI haven't run into it yet so I'm not sure about this, but I believe it does have a way to combine shared dependencies into a single shared js file.
- dgoldstein0 6y agoUnder the hood it's using rollup. So it's benefiting from rollup's code splitting for those cases.
- gavinray 6y agoSnowpack's web_modules build step produces a single-file ESM bundle for each NPM lib? I wasn't aware of this, that's actually a pretty cool feature and incredibly useful. A bit unlearned on ESM modules, how are they different from the isomorphic browser/Node single-file bundles produced by Webpack/Rollup?
- RobertKerans 6y agoThey're actual ES modules (so with the `export` syntax on their end, allowing `import` with `<script type="module">` in compliant browsers). Most NPM modules aren't ESM and aren't usable in that way. This allows it, it's a really good thing! Hopefully pushes things towards much wider usage of modules in the browser, which would make a life a bit more sane in FE world.
- koolba 6y agoIn my experience using webpack, once you’ve configured incremental builds, the only slow part is TypeScript type checking. That’s solved by doing it async and having the dev build be compile only. Even a huge project builds after a single file change faster than you can notice.
- john_miller 6y agoCould you share a link or keyword about async type checking and 'compile only'?
- koolba 6y agoSee the sibling comment.
- bdefore 6y agoCan you elaborate on how to configure TS to run type check asynchronously?
- koolba 6y agoHere's the plugin: https://github.com/TypeStrong/fork-ts-checker-webpack-plugin https://github.com/TypeStrong/fork-ts-checker-webpack-plugin
- flanbiscuit 6y agoI really don't get a sense of what snowpack exactly does from their website but I found this blog post useful: https://blog.logrocket.com/snowpack-vs-webpack/ https://blog.logrocket.com/snowpack-vs-webpack/
- gavinray 6y agoWebpack/Parcel: Save file changes, app bundle gets regenerated to hot-reload, this takes a bit of time. Snowpack: Run a module build script one time (or again when adding new NPM libraries) on project to generate some assets, but no re-bundling time between changes.
- mekster 6y ago> takes a bit of time. Parcel's incremental build is < 100ms, so I'm not sure how SnowPack feels any better for me.
- _bxg1 6y agoFrom what I can tell it's a wholesale replacement for Webpack + Babel + whichever other loaders you're using. If you're not from the JS ecosystem and that description doesn't make sense to you, I can see why it might be unclear.
- archgoon 6y agoNot quite; it's intended only to replace webpack for development. Snowpack explicitly recommends you continue using bundlers for production. "Snowpack treats bundling as a final, production-only build optimization. By bundling as the final step, you avoid mixing build logic and bundle logic in the same huge configuration file. Instead, your bundler gets already-built files and can focus solely on what it does best: bundling."
- renewiltord 6y agoOkay, this is really cool but I don't want to "create a snowpack app". I just want a "If you're using webpack + babel and want more speed, do this" thing. With the webpack dev server builds aren't too bad for the size of thing I'm working on.
- cactus2093 6y agoThat’s basically what the rest of the docs are for. I’ve been playing with it recently, and there is a learning curve but probably less than learning webpack from scratch. I also found it useful to look through the code in create snowpack app, it’s not very dynamic or complex, the config files are written in a simple way and they get copied over or extended by the app that the tool creates for you.
- k__ 6y agoFor everyone who was as confused as me: It's basically a tool that allows you to develop without bundling, but it still bundles for production via Parcel. So it's not a Webpack/Parcel/Rollup killer.
- mekster 6y agoAnd by that, I take it that it requires ESM module support from the browser, so it really is for development purpose and cannot just be kept used in production that requires wider browser support.
- Yaggo 6y agoIt makes production builds for legacy browsers (such as IE11). Only during development is modern browser required. https://www.snowpack.dev/#legacy-browser-support https://www.snowpack.dev/#legacy-browser-support
- vanderZwan 6y agoMaybe I'm overlooking something, but that sounds like it's not possible to both debug legacy browsers and reap the benefits of this approach at the same time, defeating the point. (I presume that people supporting legacy browsers generally have to deal more with their website breaking on those browsers than with things breaking on modern ones)
- jnwr 6y agoFYI, Snowpack uses rollup for its production bundling
- k__ 6y agoAh okay.
- keb_ 6y agoCan you elaborate on that or provide a link to where you learned this? According to there site, they only maintain two official plugins for production builds (Webpack & Parcel). I'm coming from using Rollup, so I would prefer to use Rollup instead. https://www.snowpack.dev/#snowpack-build https://www.snowpack.dev/#snowpack-build
- m00dy 6y agoWhat if a file depends on another file. So, I think it is O(n)
- fwip 6y agoIf one file is changed, one file is reprocessed, no matter how many other files depend on it.
- it 6y agoI had been avoiding bundling due to its effect on development, but this looks well worth a shot. I do wonder though if it would be enough to turn on CloudFlare's minification for prod.
- dang 6y agoRelated from 4 months ago: https://news.ycombinator.com/item?id=21989967 https://news.ycombinator.com/item?id=21989967
- malandrew 6y agoI came here hoping this was related to figuring our avalanche conditions when backcountry skiing.
- gremlinsinc 6y agoReddit is that way --------------------->
- malandrew 6y agoSnow science is fascinating and absolutely par for the course for HN. Your comment is far more HN worthy than mine.
- mavsman 6y agoShameless plug for those of you who prefer video tutorials to written https://youtu.be/nbwt3A9RzNw https://youtu.be/nbwt3A9RzNw It's an intro to Snowpack v1 but it'll still give you a good idea of what Snowpack does and how it differs from Webpack. I would agree that Snowpack isn't quite there for production projects, mostly due to the fact that many projects still don't ship their modiels as ES modules.
- CyberDildonics 6y agoWould it have killed them to actually say what it is in the title of their self promotion?
- julius 6y agoFrom other comments I understand Snowpack as: Development: Creates many ESM-Files. Firefox/Chrome can load them. Production: Bundles&Minimizes these ESM-Files. One Question: There is a JS-Error, only occuring in IE11. "t._x is undefined". How do I debug that?
- chrismatheson 6y agoI would assume the flow to be the same for debugging post bundled Production output from most tooling, use source maps and hope that the bundler produced accurate ones :)
- MatekCopatek 6y agoIs anyone using this in combination with a plain ole' server rendered app? All the examples seem to build on a SPA example where you have a single index.js entrypoint for your entire app. What about a Rails/Django project where each page loads a few scripts it needs? That usecase has been stuck with the "global jQuery plugins" approach for ages and it feels like <script type="module"> + something like Snowpack would really improve it.
- Kovah 6y agoI actually tried this, and failed. Gave up after like three hours of trying to wrap my own non-React scripts with that Snowpack stuff. It seems the tool is not capable of handling those simple use cases, which is quite sad.
- iddan 6y agoOnce create React app will use it by default it will be fun
- sktrdie 6y agoIf you're bit confused by what this is (as I was) here's a simple TLDR conversation I had with them on Twitter [1]: > Me: Would you say Snowpack is mainly about generating ESM files (and their common code) for each import statement? Curious how that is different from webpack's code splitting strategy perhaps together with an ESM plugin > Snowpack: Snowpack's dependency installation is a form of bundling + code-spliting: your entire dependency tree is bundled together and then split into one-file-per top-level package. In other words: they're a code-splitting strategy where they "don't touch your code", they only look at it to find the dependencies and then they generate files (ESM modules) from the dependencies information. Then they serve that and let the (modern) browser do the rest. Really simply idea but effective. 1. https://twitter.com/lmatteis/status/1262126825427415044 https://twitter.com/lmatteis/status/1262126825427415044
- PunksATawnyFill 6y agoWhich is... ?
- dreen 6y agoI guess Im different to most JS developers, because I prefer to work with HMR off about 95% of the time. Its good for UI prototyping (which I dont do much tbf), but it tends to get in my way when doing anything else. Maybe in total it makes me loose a minute or two but thats not an issue.
- Etheryte 6y agoThis is interesting, what's the upside of working without HMR? There are changes where HMR fails to figure things out and you have to hard reload, but other than those it has served me very well otherwise. Interested in hearing the other side of the story, if there is one.
- dreen 6y agoHard reload takes marginally longer, but has no potential to fail - its peace of mind. I have had cases when small changes to dev tooling or maybe something in state management causes a failure during HMR reload. And if you dont realise this quickly enough, you might waste a lot more time than HMR saves you. As I said its still quite useful for working just on UI, so its not all bad, but ideally I prefer to work on UI components separately to the app anyway, eg using something like Storybook.
- ecmascript 6y agoIs it just me, or is the build time pretty much never an issue? Usually when I develop stuff builds/recompiles faster than I can switch to my browser to try it out. How is this such a big problem for people that people need to write yet another build tool, instead of improving the one everyone already use?
- cactus2093 6y agoI promise you this is a very real problem, every company I’ve worked at with even a moderate sized codebase has had to battle webpack at various points and try to hack in various types of only semi functional 3rd party caching tools and such to make development more manageable. If you’re a solo dev working on mostly new codebases I imagine it’s not a problem for you though.
- nojvek 6y agoHaving the browser make one request per npm bundle sounds awful. It’s great if client has fast internet and server is close by, or mostly localhost, but latency will play a far bigger role than the 50ms startup time. That’s not a good metric to look at. The metric that corresponds to user experience is cold compile + page reload time, incremental compile + page reload time i.e. How long before I press enter on a command and I see something usable in a browser to devloop on. If you let the browser load the first file, parse and figure out the next file to load, a large project could have 100s of roundtrips. That’s why JS bundlers were created in first place. To avoid the cost of a long critical chain. Using a device from Africa (Uganda) to connect to US servers, one feels how bad an experience latency can make. More and more development is done on cloud machines or remote host, so this isn’t a rare usecase. What I do hope for is if there is a new bundler, it can use the webpack plugin ecosystem. It’s massive and anything new has to foster a similar ecosystem of tooling. Or please just make webpack fast with incremental disk compiles. I would pay money for that.
- WorldMaker 6y agoHTTP/2 and HTTP/3 both go long ways to mitigating the costs of multiple requests over single large bundled requests. It's still early days in HTTP/2 and HTTP/3 adoption, of course, but we're almost to the point where HTTP itself takes care of many of the reasons bundling used to be needed. (Especially as you get into more advanced features like Server Push.) Also, several of the restrictions baked into the ESM module format are specifically designed so that browsers don't need the full file to load, and can use an optimized import parser that doesn't need to wait for the full JS parser run to find the next modules to load. (I've seen benchmarks where modern browsers have discovered/loaded the entire module graph before the HTML parser has even finished building the DOM and signaled DOM Ready.) That said, reading the site, Snowpack's focus on one ESM per npm bundle is primarily just for the dev experience where you are on localhost and latency isn't an issue. It takes several approaches to further bundling for Production intended builds, including directly supporting webpack as an option (and thus webpack's plugin ecosystem).