:wave: Hey everyone, one of the Astro creators here! Happy to talk Astro or answer any questions you have about what we're building.
Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro
Our README has a bunch more info that we couldn't fit into the release post: https://github.com/snowpackjs/astro
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!
- 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.
Edit: formatting
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.
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'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.
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.
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.
This is not sustainable.
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.
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.
Sounds big enough you could also get an ongoing retainer for maintenance and support of their set up after the initial work.
There is no app. No cactus farm. No Forest Service. No Amazon.
Edit: Ok, fine! The U.S. Forest Service does exist. So does the Amazon. But the story is fiction.
Cheers.
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?
Thanks again!
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?
Tracking issue for Lit support: https://github.com/snowpackjs/astro/issues/109
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.
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 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.
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.