Astro: Ship Less JavaScript
astro.build
astro.build
Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server (probably a VPS these days) somewhere, or publish it on GitHub/GitLab Pages.
I remember a time when people here would cite http://youmightnotneedjquery.com/ a lot. Modern browser APIs can do more than ever. I wonder if there’s a more recently-updated equivalent about how one might not need node tooling at all to build a static site.
These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.
You will not need a CMS unless you publish multiple articles per day (and even then...). That's far beyond anything the preceding posts were talking about, so it's not really relevant.
While at work, it has been mostly Java JEE/ASP.NET since they exist.
When I play around with WebGL, it is all JavaScript modules and script tags, nothing else.
No babel, no webpack, no npm, nothing, just browser standard capabilities.
Fully agree with your point of view.
It just feels great that I could just immediately start fixing things on any computer should an issue pop up next year or so, without worrying about dependencies or some build step being broken etc.
I guess younger generations get taught the cargo cult ways of SPAs, and aren't able to realise how much simpler it can be done, specially be letting the browser do the work, instead of replicating it on a dynamic language.
Except for my procrastination, it's a real pleasure to write this way, no frameworks, no libraries, no build systems with 10k dependencies, no preprocessors for content - just write plain HTML and be done with it, it's always forward compatible, you always have all HTML features and don't have to worry about some preprocessors capability... If I ever have a genuine need for some kind of build process, it will be a self contained script, I'm fed up with the fatigue of the churn of the web tooling world - i'll stuck to a script that will still run in 10 years.
I did make one choice to alleviate the tediousness of writing tags: 'white-space: pre-wrap', which allows you to avoid html tags for basic stuff like paragraphs. Also using fixed width font and ch units since it's mostly a coding blog so this fits well and allows ascii diagrams without extra work... authoring feels like mostly writing an old skool text file with some nice HTML/CSS upgrades.
I even do similar for a microblog: https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).
First we get a framework. That framework is missing some key functionality or features so we get plugins and eventually a meta-framework standardising the new behaviour and maybe introducing a slightly new paradigm. That meta framework gets unwieldy and we get a ground up rewrite (new framework) that trims the fat and uses the new evolved features as first class concepts.
This is exhausting only because of external and internal pressures to "keep up". I don't see anything inherently wrong with the evolution of ideas and concepts being explored in breadth and depth. Writing and publishing a new JS framework has a very low barrier which is a huge positive that I rarely see extolled compared to complaining that the ecosystem needs to constrain itself.
Svelte's compiler-first approach really fixes all of my problems with the JS ecosystem. Compile-to-JS langs aren't new, but learning a whole new language has non-0 overhead. HTML, CSS, and JS/TS in a .svelte file is awesome, and the syntactic sugar makes the ugly parts of JS (like state management and reactivity) extremely trivial to implement.
The first class support for Vanilla JS & Typscript is brilliant. Vite and ESBuild are incredibly fast and hassle free. The water has never felt nicer for me as a web dev!
I have Starter Templates with everything set up the way I usually like it if you want to check them out-
SvelteKit starter template: https://github.com/FractalHQ/frackit
Routify starter template: https://github.com/FractalHQ/fractify
The productivity gained from these Tools is worth it, even if some use cases could be solved without it.
So much content is published in Github READMEs (typically markdown) and while Github itself will have Javascript elements, it does demonstrate that you don't need Javascript heavy sites to publish content.
I honestly think half the time the front end best practices are based around what's more intellectually interesting for developers rather than what is genuinely a better website.
What you get? Routing, instant refresh, image optimization, and code optimization (your CSS could be smaller if you minify it).
You don't gain productivity using 500 libraries pulled off NPM unless it's write once read never.
The comparison was foolish then and just as foolish now.
You really are an extreme case of the dunning kruger effect in action.
I don't think you know what Dunning Kruger is. I have never claimed to be anything great. I only mentioned I wrote an application and other people used (continue to use) it.
And I am surprised that I have to point it out again: that you once wrote something which people used in java script says nothing whatsoever about your experience in frontend development.
In fact, it kinda confirms that you don't have any.
You sound like a grouchy old man that got left behind and loudly complains about it.
This is common, but it’s still very junior thinking.
The best way to minimize tech debt is to supply the most direct solution to a given problem and refactor along the way to bring similar solutions together into a single delivery. Decoration in the code is not that.
> I'd never hire you.
You probably couldn’t afford me.
Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.
[1] https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_i...
I think that's exactly what 'computer literacy' should enable laypersons to do.
And we as a profession should be teaching that and developing assistive tools (like htmltidy) rather than intrusive ones (like hugo or worse wordpress. Both or nice and helpful but intrusive nevertheless). Kids should learn this in grade 6 or so. Be it in school or elsewhere. Before they post pictures on inhumane and ignorant advertising platforms they should know that they can do otherwise.
If you can fix that problem all this excess tooling stupidity will largely fix itself.
Even people building personal blogs will be inclined to use enterprise tooling, and take on all of the overhead of tool-chains and configuration.
Sure. Then try to write a highly complex e-commerce frontend app with this approach and tell me how does it work out.
If notepad + HTML is enough tooling for your web development, you are not a potential user of such a framework.
Good news then, you can just ignore it!
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.
Next and Gatsby do too much for our use cases which are LOB applications. We've had to work around the idiosyncrasies of Next.js when we really don't need SSR nor its limited custom server support. Astro may be a closer fit for our needs.
It's nice to see more esbuild-based frameworks, sveltekit, astro ... The edit-save-refresh cycle is almost instanteous even on large projects. Something I can't say for Next.js.
If you use react or vue, you can plug components precisely anywhere on the page, you don't need to take over the page entirely.
In fact, with vue, you can even put the template in the HTML directly, and just hook the logic on to it, angularjs v1 style.
That's what I do, I love the simplicity of it and how it lets you render html pages server side, with the added JS for interactivity.
Maybe not the cleanest architecture but extremely straightforward.
What if data changes?
edit: Island architecture background info: https://jasonformat.com/islands-architecture/
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?
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.
Frameworks is not just some hyped up abstraction layer. Advanced frameworks offer advanced functionality for advanced projects. They really do.
They have standardized certain ways of doing things, structuring complex web applications and solving problems.
I completely agree about using a framework to build a personal blog is overkill in many ways, but don't blame the framework for that. Just like you shouldn't blame the saw for being bad at hammering in nails.
My favorite process right now is a git repository that can be cloned into production, requires no build process, and works out of the box, to be statically served by any HTTP server. I commit my React builds. To me, this is the modern incarnation of Sublime Text and SFTP to my shared LAMP.
Today, I use Ubuntu 20.04 LTS, with a minimal bootstrap.sh and do it on a lowendbox for under 11 USD/yr.
I use CDNs. I don't use Amazon AWS because they aren't small business friendly. Which means I still write my own bootstrap.sh provisioning scripts, and deploy VPSs by hand.
I don't want to use a JavaScript ecosystem with marketing. I would prefer that something came out and deterred all of the types of people, yes types of people that I don't want using the software I use. The type of person who thinks it's a good idea to use a technology for less than 10 years and eschews mastery and memorization.
I want to do 1 hour of work for 10,000 USD. Not 40 hours for 4,000 USD. But you cannot do that type of work grinding away never learning and building exponentially on an existing corpus of knowledge.
Less Docusaurus mentality, more man7.org.
Edit: Apparently some people can't connect the dots here and don't see how this is relevant to Astro. So, I'll spell it out:
This is another npm project that forces me to build, forces me to use npm, and forces me to use Astro-specific (whatever that is) knowledge to build web pages. I don't want that.
All of the little details about those decisions ripple out into everything else I've just talked about. If I build, I'm probably .gitignoring my builds. So my repo out of the box is worthless. Because my repo is worthless, I can't deploy straight to my target environment. Because the author already thinks my target environment shouldn't be graced by something that works out of the box, they probably don't care about the resources of those boxes. They probably don't deploy software to VPSs at all. Maybe they use Heroku or think, "that's not my problem."
I want technologies that understand the entire scope of what I'm trying to accomplish without trying to be the entire scope of what I'm trying to accomplish.
I love having a build because it automates a lot of useful, difficult work. Tree-shaking is a good example.
If you want to do a lot more work because of some hipster devotion to "craft" or whatever (I honestly can't understand your argument beyond its condescending tone), you do you.
This is a tool for people who like to make their lives easier by automating things, and you're not going to categorically change anyone's mind by tilting at windmills.
Tree-shaking is treating a symptom of not paying attention to what is in your front-end. It's purely daft to me. This sort of thinking alone is how you get karma.conf.js files with configurations built by 5 teams over 3 years who have no idea what the configuration is doing or why particular versions of Webpack are supposed to be used, or why you have to hire some senior software engineer to do nothing but comb over some gulpfiles across various projects for months at a time that haphazardly move critical shared client/server webapp files for a product moving 80% of your company's revenue, or why a simple front-end change actually requires two weeks of development time, oh and don't forget paying your QA engineer for testing this, for something requires a simple tag change but the build process is out of date, so now you have to fix that first.
You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns, whereas I have no idea what you're talking about. You know what's a lot more work? A build step. Oh and I've never seen a build process in npm take milliseconds across a large project. But one that has none to begin with doesn't have a creeping perf issue. Because if I do have a build process, it better finish immediately, without cache.
Because if builds don't finish immediately, it's just more overhead in my CI/CD that I don't want outside of testing, and now I have to watch it, because those times only ever grow unless someone cares enough to optimize them.
This isn't a tool for people who like to make their lives easier, because anyone who was in a position to hire wouldn't use tools like this. No one knows what Astro is.
You can't hire for it. If you did, it's a waste of engineering hours to get someone to screw around using this unproven tech versus a typical React stack.
I want tech that lasts for years and years and years that isn't PHP, so I can retain engineers who actually know what they're doing and aren't screwing around relearning something for the 10th time while I pay them 6 figure salaries.
I don't have to change anyone's mind. There are some people that work faster and produce more than others, while others ask themselves how they do it while they toil away relearning.
1) That a build step is a bad idea.
2) That this tool, Astro, is a bad idea.
I wasn't arguing against #2 and don't care to. I don't personally use new or niche build tools myself. Some people might have different tradeoffs, but I generally agree that 100% of niche build tools (and 90% of popular ones) end up being unmaintainable technical debt.
> There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps.
That's fine. People are free to waste enormous amounts of dev time doing things that build tools can do for them.
> You think this is some hipster cry, and yet everything I'm mentioned above is rooted in precise engineering and costs concerns
I believe you believe this, but it's not black-and-white.
The majority of the dev world (including the people making 7 and 8 figures at Facebook, Google, and Microsoft) has realized that JavaScript, HTML, and CSS are not good languages for writing web apps.
Building from other languages or DSLs (TypeScript, JSX, Svelte, Vue, etc.) allows people to have better developer ergonomics and still get code that can run in a browser. It's not really any different from using a compiler to get assembly.
If you don't build anything, you end up doing tedious optimizations in your code. Tree-shaking was an example I brought up, but there are many more possibilities: minifying, combining assets, etc. Worse, you might just be writing vanilla JS without the benefits of TypeScript or a completely separate language.
Using a poorly-maintained build tool (or an unpopular one) is definitely a problem, but throwing them all out because some of them require devs to spend some time learning them is ridiculous.
A few years back I chose Vue for supplementing the current little bit of web stuff I was doing because I could just include vue from a script to build a new page. The basic idea was
<html>
<head>
<script src="https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.min.js"></script>
</head>
<body>
<!-- Vue HTML components used here -->
<script>
// Vue page specific JS goes here
</script>
</body>
</html>
Web tech has gone a long way and gives us a ton of stuff for free, without the need to reimplement it all in JS. Though the apis themselves are often rather awkward.
Sadly, the biggest missing piece in all of it though is testing.
Seems they prefer php-style save-and-refresh workflow (at the cost of doing building at runtime on client device)
I do greatly enjoy no-buildstep projects for the same reasons as you've mentioned, but when working with others I've also seen them fail because of knowledge gaps in more junior engineers. Provisioning a server and CI/CD pipeline to build your projects is a lot easier than ensuring that everyone working on a project has all of the required knowledge to keep it nice and performant at runtime.
but what's that got to do with this?
What if only some components in my page require Javascript? Can the same "partial hydration" be achieved?
Vue3 can also ignore static parts which gives similar benefits.
In my case, the key breakthrough was reducing everything to arbitrary constrainted emitters with a topological sort.
--
The build uses a GraphQL database to store the results (Prisma/Postgresql because it's great with Typescript).
The whole site is defined by arbitrary Data Sources that read from 0+ other sources and write 1+ unit of data in the database. A source can do anything, the only constant is it must define at least one thing in the database.
For example:
- list of files generated by the webpack build of a specific runtime js
- JSON version of a specific page
- http response to serve when a specific url is requested
---
A topological sort uses the constraints to deduce in which order to render data, for example:
- a page showing the 5 most recent articles can't be rendered before the articles themselves
- the french translation of an article cannot be rendered before the settings of the french website are defined
---
This way, a specific page (or type of pages, or even every page of a site variant) can explicit state it needs a specific js runtime, and the build knows to bundle it before any page that needs it.
Something like a cookie banner would be used by every page whereas a 3d model viewer webcomponent would only be used in specific pages.
---
You end up with a static site as consequence of rendering the "http response to serve when X page is requested" sources, which in turn called all the other sources it required.
The resulting database could even be available in production for dynamic pages that cannot be pre-rendered.
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?
I see we’ve discovered the idea of DLLs for the web.
While I haven’t contributed yet (besides a slew of comments on issues/PRs), I’m stoked to take another stab at a Solid renderer plugin.
Really impressive work y’all. Can’t wait to see how it grows.
But I do need some JavaScript. What I want is just an easy way to drop excess packages from the webpack bundle ("tree shaking"). Seems a little manual with the default webpack process for that.
A great use case is if you like to work with an isomorphic component library, but you’re building a mostly-static site (in the sense that it’s mostly non-interactive). Tools like Next etc provide that DX, but they bundle/run that static content twice per page load. Astro only bundles the stuff you specifically mark as interactive.
This probably sounds trivial if you’re taking a more traditional approach to server/client responsibilities. But for anyone wanting to render on build and hydrate with the same component logic it’s a huge improvement over most of the current isomorphic approaches.
wait, what? I've built shopping carts that didn't need javascript... but that was probably 15 years ago...
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.
TIL: npm initializers, thanks!
The passage below, on the linked page, is a dead giveaway of what it does, no?
> - 100% Static HTML, No JS: Astro renders your entire page to static HTML, removing all JavaScript from your final build by default.
> - On-Demand Components: Need some JS? Astro can automatically hydrate interactive components when they become visible on the page. If the user never sees it, they never load it.
Also JS dev: Look, I've built another tool!
If you're confused, perhaps try not lumping everybody into the homogenous “JS dev”.