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?
Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro