[HN Gopher] Astro: Ship Less JavaScript
___________________________________________________________________
Astro: Ship Less JavaScript
Author : feross
Score : 133 points
Date : 2021-06-08 20:46 UTC (2 hours ago)
(HTM) web link (astro.build)
(TXT) w3m dump (astro.build)
| m1117 wrote:
| I want some demos. One demo=thousand readmes.
| fks wrote:
| Run `npm create astro` in any directory to load one of 4
| starter demos!
| tchetwin wrote:
| Suspect that should be `npm init astro` or `yarn create
| astro`.
|
| TIL: npm initializers, thanks!
| fks wrote:
| :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
| zanethomas wrote:
| very interesting, i'm going to try it out with a vue project
| soon
| superjan wrote:
| 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?
| gmmeyer wrote:
| it seems like it's just an OSS project no need to make money
| whelming_wave wrote:
| 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?
|
| [1]: https://elderguide.com/tech/elderjs/
| fks wrote:
| 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.
| nickreese wrote:
| 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.
|
| Edit: formatting
| mwcampbell wrote:
| 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.
| nickreese wrote:
| 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.
| camdenlock wrote:
| 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?
| fks wrote:
| 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.
| exacube wrote:
| 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.
| fks wrote:
| No benchmarks yet, but I'll look into adding some. In the
| meantime there are a few sites in the wild already built with
| Astro that you can check out:
|
| - https://www.snowpack.dev/
|
| - https://divriots.com/
| jacobsimon wrote:
| Hey! Do you have any live demos or real(ish) apps made with
| Astro that we could check out?
| fks wrote:
| There are a few sites in the wild already built with Astro
| that you can check out:
|
| - https://www.snowpack.dev/ - https://divriots.com/
| virgil_disgr4ce wrote:
| That snowpack site is definitely pretty %*(&ing fast :D
| qbasic_forever wrote:
| 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?
| MatthewPhillips wrote:
| 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.
|
| Tracking issue for Lit support:
| https://github.com/snowpackjs/astro/issues/109
| qbasic_forever wrote:
| Very cool! Yeah I wish SSR was more of a thing in the web
| component world. Someday soon hopefully!
| MatthewPhillips wrote:
| Stencil support is being worked on too:
| https://github.com/snowpackjs/astro/pull/266
| r6203 wrote:
| At the moment I'm using Gatsby but the client side js bundle
| turns me off. However, one thing I really like about Gatsby is
| the dynamic image component.
|
| Is there any way (or are there any plans) for generating
| responsive images when using Astro? As Astro is framework
| agnostic, I don't think so, right?
| hnal943 wrote:
| This is neat. The last site I built in Next.js we turned off the
| SPA, but needed to then write all the client side js in a
| separate workflow. Seems like this could be progress.
| ecmascript wrote:
| I read "how astro works" but I don't really get it. How can this
| work for dynamic content? Does it render every possible scenario?
|
| What if data changes?
| MatthewPhillips wrote:
| Currently you build a static site like you do with Gatsby or
| Jekyll or any other static site generator. In the future it
| will support dynamic server rendering.
| ecmascript wrote:
| Ok so it is a static site generator. Wasn't really obvious
| from the landing page.
|
| Doesn't almost every large front end framework have a static
| site generator? I think Vue for example has it built in for
| example.
|
| Why would anyone use this over the already existing one in
| their current ecosystem?
| MatthewPhillips wrote:
| I can't speak for every frameworks' SSG tool but most of
| them load a full SPA on the client and have poor
| performance. Go pick out a random website for Gatsby's
| showcase page and see how much JS is loaded (spoiler: a
| lot).
|
| Astro focuses on partial hydration where you only load the
| JS for the specific components that need to run in the
| client. Very few tools and none of the framework SSG's that
| I'm aware of do this.
|
| There's also a variety of other features that Astro brings,
| the blog post talks about them.
| ecmascript wrote:
| Ok well it seems kind of cool, maybe I'll try it out. :)
| qbasic_forever wrote:
| Check out the islands architecture info, or search around for
| info on partial hydration. It's similar to how things worked in
| the jQuery days--you serve up plain old HTML and have a JS
| function that runs on page load to attach all the event
| handlers (onclick, etc.) to your dynamic elements (i.e.
| 'hydrating' the static HTML into dynamic HTML + JS components).
| The thing with frameworks like Astro is that they try to
| automate and manage all of that hydration for you, which is
| nice because for complex sites with lots of different
| components it becomes a huge, error prone chore to manually
| wire things up.
|
| edit: Island architecture background info:
| https://jasonformat.com/islands-architecture/
| aligray wrote:
| New static site generator tool releases seem to have superseded
| new js framework releases. I like the direction things are
| moving.
| z3t4 wrote:
| Next biggest thing will be a framework for a static site to
| generate a React app, that generates a static site, inside a
| web worker.
| dasb wrote:
| Is it possible to achieve the same thing just with Svelte +
| SvelteKit and some configs?
|
| (I genuinely don't know, since I'm a Svelte begginer)
| miltonsopus wrote:
| Yes, with SvelteKit you can use the static adapter to generate
| static html files for your routes. It's also possible to
| control this on a page by page basis.
| nielsbot wrote:
| Wondering how this compares to Gatsby or other React-compatible
| static site generators...
| MatthewPhillips wrote:
| Most of those tools are focused on giving you a full SPA on the
| client (and therefore load a lot of JS). Astro is focused on
| sites that are mostly static with "islands" of interactivity.
| To that end every component is server rendered only, by
| default, and you opt-in to client render when you need it (with
| different loading strategies).
| jypepin wrote:
| JS dev: I'm burnt out by having to keep up with all the tools
| that are releasing all the time!
|
| Also JS dev: Look, I've built another tool!
| wizzwizz4 wrote:
| This tool undoes a lot of harm of tool proliferation. It's one
| of the few JavaScript tools I'll actually approve of.
|
| If you're confused, perhaps try not lumping everybody into the
| homogenous "JS dev".
| krmmalik wrote:
| Templates for low coders like me?
| kissgyorgy wrote:
| https://dayssincelastjavascriptframework.com/
| bdibs wrote:
| It's sort of ironic that page loads 213kB of JavaScript from
| 8(!) separate scripts to show a large 0.
| jeroenhd wrote:
| To be fair (but not too much), the devs did compress and
| minify their JS and host everything on the same domain, so
| with HTTP/2 the network impact should not be too high in
| comparison.
|
| In comparison to a "normal" web page that loads 213KiB of
| script that's not necessary because the HTML already shows
| the big zero regardless. At least the CSS is fairly minimal.
|
| The web is a terrible place. Google should rank
| Javascriptless websites higher in search results to push for
| less scripting, it's the only way I can see this situation
| improving.
| 0xbadcafebee wrote:
| > Of course, sometimes client-side JavaScript is inevitable.
| Image carousels, shopping carts
|
| wait, what? I've built shopping carts that didn't need
| javascript... but that was probably 15 years ago...
___________________________________________________________________
(page generated 2021-06-08 23:00 UTC)