> Hi everyone! Sorry for not posting the announcement here, too. I can confirm that we’re going to add Astro support in v2023.1. We will keep you posted on our progress once we start working on the issue and will ask you to give Astro support a try and share your feedback with us. Please keep monitoring the issue for updates.
Shameless plug: Astro supports Alpine.js and is a great dev environment for trying out Alpine for the first time. It runs in the browser as well, via Stackblitz!
Yup, static site means you can pretty much deploy anywhere! Just configure Vercel to point to the final destination build directory when you set up your project.
Elder is great! We're definitely fans. both Elder and Astro deliver Partial Hydration and the same "0kb JS by default" story. We wanted something less Svelte-specific and more pluggable, along with some other neat features mentioned in the README that couldn't fit in the launch post.
> TL;DR - Snowpack removes the need for bundlers (Webpack, Parcel, Rollup) in a traditional application build process by leveraging the ESM syntax you're already writing. Keep using your favorite web frameworks (React, Preact, Vue, Svelte) & build tools (Babel, TypeScript).
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 :)
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.
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/
Really sad to see this, I remember relying on cdnjs at a few old jobs over the years. Hope they get this sorted.
If anyone is looking for alternatives, I created Pika CDN as a modern alternative for cdnjs/jsdelivr/unpkg. It runs off of npm (so no approval bottlenecks) and is 100% modern ESM (so you can `import` every package directly in the browser without a bundler).
https://www.pika.dev/cdn
Similar to what would happen today when a package exports both ESM (web) & CJS (node): frontend gets ESM via @pika/web, while node would use CJS via require. A Babel plugin comes bundled with @pika/web which can help you resolve imports correctly in the web build.
Although at that point, where your app needs to reliably run in both Node & the browser, there’s a good case to be made for bundling. All that complexity is giving you something valuable, which is the point that the article tries to make:
in 2019, use bundling because you want to and not because you have to.
> By default, @pika/web will install all package.json dependencies with an ES "module" entrypoint to the web_modules/ directory. @pika/web is able to handle any legacy Common.js/Node.js transitive dependencies in your dependency tree, however the top-level dependencies (the ones that you import directly) must have a "module" entrypoint.