Some of this wording confuses me and should probably be reworked:<p>> Snowpack is a O(1) build system… Every file goes through a linear input -> build -> output build pipeline<p>Seems like O(n) to me?<p>> 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<p>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.<p>Looks like an interesting project though.
I 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.
Okay, 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 <i>too</i> bad for the size of thing I'm working on.
For everyone who was as confused as me:<p>It's basically a tool that allows you to develop without bundling, but it still bundles for production via Parcel.<p>So it's not a Webpack/Parcel/Rollup killer.
I really don't get a sense of what snowpack exactly does from their website but I found this blog post useful: <a href="https://blog.logrocket.com/snowpack-vs-webpack/" rel="nofollow">https://blog.logrocket.com/snowpack-vs-webpack/</a>
I find this interesting. As a mainly desktop developer now doing web frontend work, the JS ecosystem has been so frustrating.<p>Bundlers struck me as unnecessary given JS now has native module support, and that is the premise of this project.<p>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.
Shameless plug for those of you who prefer video tutorials to written <a href="https://youtu.be/nbwt3A9RzNw" rel="nofollow">https://youtu.be/nbwt3A9RzNw</a> 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.
From other comments I understand Snowpack as:<p>Development: Creates many ESM-Files. Firefox/Chrome can load them.<p>Production: Bundles&Minimizes these ESM-Files.<p>One Question: There is a JS-Error, only occuring in IE11. "t._x is undefined". How do I debug that?
Sounds 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?
Having 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.<p>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.<p>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.<p>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.<p>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.<p>Or please just make webpack fast with incremental disk compiles. I would pay money for that.
I just tried it in a @microsoft/rush project of mine.<p>Added a new project with 1 dependency (which contains a single one-liner function to return a test string). No other dependencies.<p>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.<p>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`.<p>Snowpack in principle looks nice, but I think I need something else
Related from 4 months ago: <a href="https://news.ycombinator.com/item?id=21989967" rel="nofollow">https://news.ycombinator.com/item?id=21989967</a>
Is 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?<p>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.
Is 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.<p>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?
I 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.
In 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.
I had been avoiding bundling due to its effect on development, but this looks well worth a shot.<p>I do wonder though if it would be enough to turn on CloudFlare's minification for prod.
If you're bit confused by what this is (as I was) here's a simple TLDR conversation I had with them on Twitter [1]:<p>> 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<p>> 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.<p>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.<p>Really simply idea but effective.<p>1. <a href="https://twitter.com/lmatteis/status/1262126825427415044" rel="nofollow">https://twitter.com/lmatteis/status/1262126825427415044</a>