> 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!
A couple more for folks interested in prior/similar art:
- Marko, made and used by eBay, which had been doing islands/partial hydration for years
- Qwik, made (and I’m pretty sure used) by Builder.io (and one of the original Angular creators), which only loads/executes JS as needed for interaction. Not quite partial hydration, it resumes state serialized into the HTML (sort of conceptually similar client side to Alpine etc)
I get that you're trying to make websites faster, and it seems like you have some amazing technology, but I have to tell you in all honesty that you have a 1.5 Mb PNG on the linked page. If you want to optimize a website, then (as I'm sure you know) optimizing the images is about the first thing you need to do.
With minimum effort and without apparent loss of quality I could reduce that image to a 0.4 Mb PNG (by uploading to https://imagecompressor.com/), if I'd be willing to change to JPG you can even get it down to 0.2 Mb (https://photoshop.adobe.com/compress).
That's a significant improvement that will really reduce page load times. For me, personally, I would really want to address this if you are positioning yourselves in the website optimization space. Cheers!
How does this compare to Elder.js[1] which released a little while ago? You seem to have similar goals - mostly static site with small amounts of interactivity, minimum JS to achieve that - but Astro supports multiple frameworks, while Elder.js is restricted to Svelte. Are there any other big differences?
Hey Elder.js author here. Only browsed their docs but here are the things that stand out in very quick read:
- Framework agnostic but uses their own .astro language/filetype. Elder.js is Svelte only.
- Both support partial hydration and they appear to offer similar options as Elder.js
- Elder.js’ target isn’t building a small site but a large one. So data flow and making the data model pluggable via hooks and plugins really makes this possible in a way we haven’t seen other framework approach it. We’ve heavily dogfooded Elder.js for building major SEO assets. Fetch as the main way of getting external data in Astro where Elder.js leaves that up to you and gives you complete control allowing various database or filesystem sources.
- Unclear on their build process.
- Elder.js is express middleware (SSR) and a static site generator. Astro appears to just be a SSG. (Some of our sites are outgrowing SSG so the flexibility matters).
- No shortcode support, hooks, or plugins.
My take is that Astro might be a good fit for simpler use-cases but may stumble when you need more control or go against their model. Elder.js has similar opinions but tries to put you in full control. That comes at a complexity cost which Astro appears to do a good job of simplifying but I’d need to dig in deeper to see what tradeoffs were made in order to make things simpler.
Happy to see more people taking partial hydration seriously.
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.
Congrats on the release. For some reason when I heard of Astro, I thought it was a dynamic server-side rendering framework, not a static site builder. But I'm sure someone else will take on SSR with islands if they haven't already.
Also:
> Astro is and always will be free. It is an open source project released under the MIT license.
> We care deeply about building a more sustainable future for open source software. At the same time, we need to support Astro's development long-term. This requires money (donations alone aren't enough.)
Why make it harder for yourselves by choosing such a permissive license? Developers shouldn't be ashamed to not just ask for, but demand, compensation, for the software itself, by choosing a more restrictive license. Even if that means you can't call it free software or open source, e.g. a source-available license that requires payment for commercial use. By now we should be ready to accept that free software with no strings attached just isn't sustainable except for projects with big corporate backers.
Elder.js supports Islands with SSR. It is also MIT. I released it as an SEO experiment as much as anything else.
I’m enjoying the dev process and am committed to facilitating (myself or paying another) it’s maintenance for several years. I can do that because my prior successes can subsidize the cost.
If I had to do it again, I’d probably pick another license. As a first time maintainer of a project that is hitting the pit of success it is amazing the number of for profit companies taking the framework and demanding changes to suit their narrow business cases.
I literally LOL at some of the emails. I very much think the state of OSS isn’t sustainable. It has been an interesting rodeo.
> I very much think the state of OSS isn’t sustainable.
I'm perplexed by this. You wrote that Elder.js was an experiment. I sense that the stress you are feeling now is a result of trying to make it work for everybody else. But it doesn't have to work for anybody else.
OSS that is a slave to people who don't contribute may very well be unsustainable. OSS for the fun and use of it is perfectly sustainable. If Elder.js does what you need, that's great! If you're hoping it makes you the next DR Hipp or John Resig, maybe think about whether you really want that. If you do want that, that's fine, too. It just comes with a lot of demands.
Just an aside, this is why I enjoy playing with open-source music things and Arduino / ESP32 ecosystem stuff more than web tech in my free time. There are some commercial uses, but still a ton of hobbyists doing it for the love of the process and just for fun / because we can. A whole lot of cool stuff exists in these spaces. Definitely worth a look.
Your words or theirs? . I would have thought big companies looking for changes (new features?) is the perfect monetizing opportunity.
I mean, can't you just say "sure, I can add that for $2000." if it's not worth a couple grand to them, then it's not that important or worth your time.
One way to sustain the open source model is a pay-for-development approach.
Have you tried to convert those requests into one-off sponsorships to develop the feature they need? Sounds like a win-win. From my experience with procurement you just need a high enough number to make it worth their time.
This is exactly why there are so many companies who still want to use open-source (or source available) so end users (companies) can modify but are moving toward non "open source" licenses.
2 decades back people built things for fun and learning. We wanted to have the freedoms and pass it on. Now anything that has any commercial value gets most attention from developers whose day job does not encourage tinkering. They use your code, ask for more and pay nothing.
> By now we should be ready to accept that free software with no strings attached just isn't sustainable except for projects with big corporate backers.
That very much depends on who the authors of the software are and what their goals/motivations are. This is far too much of a blanket statement.
I agree that no one should be ashamed to sell software that they write. Also, those authors can and should be the ones to determine under what license the software is released (unless, of course, they are being paid by someone else to write it -- that's a different set of circumstances). But there are plenty of very useful open source projects that have been around for a very long time with no big corporate backers.
My little app to monitor and assess the growth and health of trees I just planted in my backyard is a hobby app. It's just for fun. I did it for me.
If you want to use it for your hobby, go ahead.
When the extension office down the road wanted to use it for their cactus farm, that was fine by me. I added some stuff specific to cactii that they wanted. They added some more stuff. No big deal. It works for them, I guess.
When the U.S. Forest Service expressed interest, I was surprised, but, hey, whatever. They added some features, but needed some small architectural changes for those changes to fit in. They were reasonable and easy, so it was ok. I have no idea where they use it or what they use it for, really. But if it works for them, great.
This latest contact out of Brazil, though, is different. They want me to fly down there for two months and completely re-work the app to monitor the entire Amazon forest. Thousands of species and tens of thousands of monitoring stations in a giant mesh network across much of a continent.
Should I ask them for a donation?
OSS can be a hobby. It can be a passion consuming a lot of time and energy. And it can be a job. If it is a job, you get paid.
Not sure what’s the point you are trying to make here. If you’re being hired (and flown) to extend the software it’s a consulting gig and not a “asking for a donation” situation, and you should quote accordingly. This is one of the traditional ways authors can benefit from OSS with permissive licenses.
Since you're only hearing from people who didn't pick up on it, I'm just going to say that I got your point and thought the Amazon example was plenty extreme enough to realize it was made up.
Hi, thanks a lot for this work! A possibly naive question from someone that dabbles in tech/web only for pleasure while working in a completely different realm:
I understand the how of using a site builder like yours, but not the why. I see you allow e.g. use of react or svelte - don't they already allow you to build static sites? And i know e.g. Hugo, Hexo & co that allow static site generation, but presumably don't need use of another framework.
What is it that Astro does beyond or better than those tools? Why and who would benefit from spending time learning and using it? E.g. if I start to learn svelte what benefit will it bring me to learn also Astro and make my hobby project dependent on it? Could you give a few use cases where it would or would not add value to use Astro, to help less informed people like me?
I have been using Skypack (and friends) as I am using Deno. Then I started getting interested in Snowpack. Today I read your first paragraph and I immediately felt there is something about Snowpack in here.
Embracing the ESM* route and some concepts from Deno and other efforts will greatly simplify the build process. Right now I feel overwhelmed in large frontend projects which have custom Webpack and lots of loaders and stuff.
Going HTML first and adding JS as needed is great, but I am curious if there is any way to not have a large chain of dependencies creep in. The moment a project has a decent developer size, this happens. How do you wish to tackle this?
How well do web components fit into astro pages? Do you get the same kind of partial hydration/load on first view semantics with them as it looks like you can do with React/Vue/Svelte components?
Not yet, Lit has support for SSR in prerelease and we've experimented with supporting it. Once it's ready it will be included. In the meantime you can of course use web components (with any framework) like you normally would, just without SSR.
Amusing to me to see the return to concepts that the dynamic web started with in the form of CGI, mod_perl, Cold Fusion, PHP, ASP.NET and all that. It’s the same, but different. Next we’ll be on to multi-tiered caching.
What’s the difference conceptually between islands and e.g. Hole-punching in Varnish? The result in each case seems to be a site that is mostly static with some dynamic portions.
Does this handle anything serverside at all, like if you need auth or if you need to read data from a database at request time? Or would you fall back to something like Next if you needed that?
Hi fks. Astro looks really compelling, but I’m already addicted to NextJS and deploying on Vercel. Any chance an Astro app will be deployable on Vercel or similar services?
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.
After reading the front page, I'm a little confused. How do you go from "compose your website using UI components from your favorite JavaScript web framework" to "a fully static website with all JavaScript removed from the final page" without losing functionality provided by those components? What's the purpose of using components without JavaScript?
I don’t use this, but I do something similar for my personal blog.
JSX (and components) is possibly the nicest templating language I’ve ever used. The problem with almost all others is that they are based on strings, so you lose type-safety (and more importantly completions) for the template parameters.
However, the current ecosystem makes it really hard to use JSX for just templating. There are libraries that do exactly that, but you end up wanting compatibility with React, because there are a ton of pre-made components that basically output only HTML (for my use case, react-fontawesome), which you miss out on by using a different library.
I'm sorry, but how is JSX a good templating language? I much prefer Svelte's approach where you have native HTML and script/css tags within which lives native (scoped) code.
Svelte being good doesn’t stop JSX from also being good.
I haven’t used Svelte (but I’ve given it a brief look), so some of these might be wrong.
Scoped CSS is nice but not a necessity by any means (I use Tailwind). Svelte is very restrictive, as it basically forces 1 component per file. Svelte also introduces new syntax to to handle conditional HTML and iterated HTML, which I personally don’t like. With JSX, everything is just Typescript. I’m a bit torn on slots, but I think I prefer JSX’s everything is a prop approach.
Thanks for all the hard work and open sourcing it!
Are there benchmarks/numbers for how Astro improves page load / page download size for a relatively complicated web app? I wasn't able to find it on the website or the README.
Any plans to add asciidoc support? This projects looks great, but markdown has severe limitations when authoring content. I really wish it would stop being used for anything but plaintext email and READMEs.
Hi, looks like a great development for developers and users alike. But I am curious how you intend to make money from this. Or is this a not for profit initiative?
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/
I would have hoped with a focus on security that we'd be moving to front ends that run less untrusted code on the client.
I would use a framework that did the majority of its magic on the back end and emitted either zero code that needs to run on the client or completely gracefully degrades when the client refuses to run untrusted code.
Every day it feels more and more like the web is a tracking framework with the lowest effort content that will keep the cattle clicking than an actual platform that provides real value. Being able to switch off executing remote code but be left with a functioning web experience would go a long way to providing real user privacy, which is, of course, why I have zero hope of it actually happening.
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.
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.
Even TypeScript having to compile down to JS for the browser just feels fundamentally wrong. Why write something in some new, domain-specific language that compiles down to an inferior language to run in the browser?
Hopefully with WASM we see the rise of client-side frameworks that bypass all of this bullshit entirely and give us a clean slate to develop on that picks up the best of the 90s low-code projects and makes them cloudworthy. There's no reason why 99% of the UI that most sites need isn't just assembled from a nice list of stock UI widgets.
JS _is_ the native language for browsers. Therefore, it's reasonable to target it.
While it's entirely possible to compile your language interpreter of choice to WASM and run that in a browser, you're now in sort of the reverse position that folks complain about with Electron: adding tons of extra bloat, overhead, and complexity, just to duplicate some other runtime environment into a place it wasn't particularly intended to be used in the first place.
In addition, with most "compile other language to WASM" demos I've seen so far, they end up just drawing things on canvas, thus losing all the accessibility aspects that are built into the DOM already. (Yes, I know WASM has some DOM interop abilities and more coming, but that's not generally what I'm seeing done atm.)
What's _really_ needed is way better UI elements built directly into HTML, but those are sadly lacking.
There's been some discussion of making things like a virtual scroller available under an "std" global namespace [0], and the Chrome/Edge teams recently did a refresh of just the visual appearance of the standard built-in HTML inputs [1] (which, frankly, I think look even worse now).
Beyond that, nothing meaningful is happening. Even the input types defined as part of the HTML5 spec are still barely supported [2], and if browsers can't manage to implement decent date/time/range/color inputs, there's no way of getting more complex components designed and standardized.
Of course, the other aspect of that is, anything that is part of the web API is there forever, which means bugs and mistakes aren't really fixable. So, there's some benefits to having a purely community-driven ecosystem instead.
What framework-agnostic HTML UI component library would you recommend? Most of the options I have seen either have framework-specific dependencies (React, Polymer, Aurelia, Angular, Vue) or are just low-level frameworks for building your own UI/web components.
Are you actually going to write WASM by hand? Or are going to use a ... you know... compiler to generate the WASM from your source file? If you compiled Typescript to WASM instead of js, would that somehow be a different development experience?
1. WASM is not a replacement for JS. You still need javascript glue code to actually load and run the WASM.
2. You're not writing WASM by hand, exactly like how you don't write assembly by hand. There's little semantic difference of compiling from <your_language> to WASM versus transpiling from typescript to javascript.
A question for you: I see the site mentions using Snowpack with Vue but there's no guide like there is for React. Can you point me at some sort of "getting started" guide, blog post, or example repo for using Snowpack with Vue?
> 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).
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.
