Hacker News new | past | comments | ask | show | jobs | submit login
Astro: Ship Less JavaScript (astro.build)
369 points by feross on June 8, 2021 | hide | past | favorite | 168 comments

I get it, I’m glad it exists, it’s Neat, and congrats, but it’s also amusing to me that we’ve reached the point of JS tooling where we’re making frameworks to deal with frameworks, build tool frameworks a few levels deep, etc. It just seems like so much…stuff. And now we have stuff to help us use less stuff, but it’s still stuff in itself.

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.

I felt this way when approaching my personal site. I was falling into the Gatsby trap and then realized all I needed were HTML, CSS, and a few JavaScript files. I think you see over-engineered solutions as a result of career driven development and the hype around these libraries/frameworks on forums/social media.

Problems start when you need to change the HTML structure, the CSS file name, or having a paginated list of your blog. If you do publish a lot, you'll need some sort of CMS.

These frameworks/libraries are trying to replace WordPress, because WordPress is also a mess to work with.

> you'll need some sort of CMS.

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.

or unless you build a site for somebody for whom editing Markdown files is too much

My personal website is still based on PHP, after using XML/XSLT for a short while, I rewrote it in PHP 5 shortly after it became available.

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.

The irritating thing is that this is often possible even with modern JS. I shipped a rather complex app (though still essentially CRUD that's used internally) this winter that is Vue 3 based. It's just the Vue library itself plus the app logic, directly included using script tags. No other libraries for Vue, no build steps and so on.

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.

Yeah, I really share the sentiment.

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.

Just from what I've heard about Deno - isn't this exactly what they are aiming for? Bring Node/JS back closer to the browsers and make use of ES modules etc?

I'm also making my blog in plain html/css/js with the goal of making it as minimal as possible - in fact the JS wouldn't exist if it wasn't for the fact that it includes some running code examples about demoscene stuff.

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.

This plus a CMS. Writing is a separate activity for me. I also like that it handles tags, metadata and pagination for me. Templating and thumbnail generation is also nice.

have a link?

I even do similar for a microblog: https://demo.mro.name/shaarligo - try without JS and look at the source (not the DOM).

There is an ebb and flow in the JS ecosystem.

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 has everything I need to build websites and apps. The performance, bundle size, and DX combo is unparalleled. All vanilla JS libs are plug-and-play. Building production-ready apps is incredibly fast, and done with less code than any other framework.

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 like Svelte a lot but haven't dived in deep yet. I'm currently waiting for SvelteKit to reach 1.0. What does your general setup look like for something relatively large and complex?

I use Routify for everything- the ecosystem of tools from it's creator Jake already takes care of everything Sveltekit aims to solve.

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

In your argument, you could replace HTML/CSS with Assembler and JS/React/whatever with C and everything that came after.

The productivity gained from these Tools is worth it, even if some use cases could be solved without it.

That's not really fair. A lot of static sites simply don't need JS at all but they're built with it because it's deemed "best practice". My latest website, for example, has zero Javascript in 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.

You can use NextJS to build a fully static website with no JavaScript at the initial loading. There are tons of libraries (I think around 300Mb) to compile your site, but if you do optimizations right, the final website should be as lightweight as you expect it to be.

What you get? Routing, instant refresh, image optimization, and code optimization (your CSS could be smaller if you minify it).

Hmm, I think 300mb is a lot...

> The productivity gained from these Tools

You don't gain productivity using 500 libraries pulled off NPM unless it's write once read never.

Completly unrelated, a page editor that writes pages in a WYSIWYG using only HTML and CSS, Dreamweaver style, can't be compared with using Assembly.

I remember a few years back, just before You Might Not Need jQuery became a site, any mention of not needing jQuery would immediately be met with some analogy to writing assembly.

The comparison was foolish then and just as foolish now.

Spoken like someone that has never actually created an webapp with significant scope. Reading your comments in this thread is a good reminder how strongly the clueless argue about things they don't understand.

I once created a language parser that supported over 40 languages and was used by over thousand other projects. It was interesting when I discovered it being used at my company. It wouldn't exist if I were crying about how hard life is without tools to do my job for me.

Thanks for confirming that you have no clue about frontend development and it's up- and downsides while running around with a big mouth claiming competence.

You really are an extreme case of the dunning kruger effect in action.

The application I mentioned is written in JavaScript and runs in both the browser and with node.

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.

Or maybe you have to little self awareness that you haven't even realized how heavily it applies.

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.

Imperative UI sucks. There is a very good reason everyone is using declarative UI frameworks these days

And not just because they’re declarative. I’m currently working in an ecosystem of ~decade old JS projects. The imperative DOM stuff is of course a hassle, but the data flow is (predictably) all over the place. It takes a lot more discipline to keep data flow reasonable in an imperative UI. Modern declarative frameworks are generally opinionated about data flow (sometimes that’s their only opinion!).

Because they are afraid of the DOM and yell at each other about code style?

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 am very familiar with the DOM and have no problem using the DOM apis. You seem to have no experience writing complex Web apps, and seem to give little thought to maintainability. I'd never hire you.

Complexity is bad. I prefer to write simple web apps. Less is more.

> I'd never hire you.

You probably couldn’t afford me.

I’m all for not having dependency hell and a million frameworks. I just want some UI controls like sortables lists, tables and not have to type everything out.

If I'm writing frontend code alone, I do it by hand. In a team, these heavy tools become important to keep some sort of cohesion. Even then, I'm not entirely sure.

Nonetheless I had a good cycle the other day when I had to pull 400 MB of Javascript to build a single static page.

I advocate for frameworks in almost all team projects, the tools act as a set of idioms and best-practices your team should know and use.

I don’t do a lot of front end dev. Just some personal projects here and there and I usually just slap Bootstrap on it to make things look reasonable. I had to do a bit for work and man, when I started actually reading the docs I was surprised to find things like form validation [1] out of the box! There were a few others that I forget now, but I was pleasantly surprised at how much I _didn’t_ have to do. I wound up needing no extra JavaScript.

[1] https://developer.mozilla.org/en-US/docs/Learn/Forms/HTML5_i...

> Nothing is stopping anyone from opening notepad and writing HTML with inline style, then using FileZilla to FTP/SCP that to a server

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.

The moment you don’t use the maximum number of tools possible or write any line of code that doesn’t call some framework method people will harass you about NIH. I see it nearly everyday online and used to see it at least monthly in the real world at work.

If you can fix that problem all this excess tooling stupidity will largely fix itself.


I think part of the issues is that the line between enterprise tooling and smaller site tooling has disappeared.

Even people building personal blogs will be inclined to use enterprise tooling, and take on all of the overhead of tool-chains and configuration.

> 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

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!

The exakt same thing happens in the backend. Kubernetes, docker, procfiles, apt, yum, various frameworks and languages...

Not everyone is building single page static html sites.

I think the weird weighting goes in the other direction though, more people are over-encumbered with tools they didn't need.

: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


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?

[1]: https://elderguide.com/tech/elderjs/

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

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.


> 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.

>>.. Demanding changes...

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.

This is not sustainable.

Plot twist: if it’s worth enough to them, make a living for yourself selling consulting services :)

> 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.

Is the Amazon forest a contract job? Would love to read more detail about that arrangement if you can make it work.

Sounds big enough you could also get an ongoing retainer for maintenance and support of their set up after the initial work.

Ummm. I thought I might have to put a disclaimer in there. But I figured it was over the top enough to be clear. I was wrong.

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.

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.


I feel like you have a point to make but I'm missing it completely.

Hey! Do you have any live demos or real(ish) apps made with Astro that we could check out?

There are a few sites in the wild already built with Astro that you can check out:

- https://www.snowpack.dev/ - https://divriots.com/

That snowpack site is definitely pretty %*(&ing fast :D

Wow snowpack.dev was blazing fast for me! Need to try this on one of our internal applications

The speed of snowpack is impressive. It's nearly as fast as loading plain text.

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?

Thanks again!

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.

Tracking issue for Lit support: https://github.com/snowpackjs/astro/issues/109

Very cool! Yeah I wish SSR was more of a thing in the web component world. Someday soon hopefully!

Stencil support is being worked on too: https://github.com/snowpackjs/astro/pull/266

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.

This looks super-exciting. Will you be building plugins or examples that show how to use this with other frameworks like Next.js/Nuxt.js?

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.

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/

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?

it seems like it's just an OSS project no need to make money

Since you're not shipping JS to the browser, you don't have to use it in the first place, right?

very interesting, i'm going to try it out with a vue project soon

New static site generator tool releases seem to have superseded new js framework releases. I like the direction things are moving.

It's good times :)

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.

Gatsby has a ton of magic... I use it but I rather skip it.

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.

Do you mean https://wasp-lang.dev/ perhaps?

Every time I see this I get so excited until I realize again that I still have to know how to code in React, Node.js and Prisma.

If you have a whole is running in a web worker client-side that’s hardly “static” anymore. A site is static when the page is built beforehand and served from disk — or at most built JIT on the server and then cached.

Alternatively, just don't write an SPA. Write a regular site, with just the few interactive elements you need.

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.

> 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.

Sometimes I wonder what was wrong with a mostly static pages in the first place. Even http://mail.google.com/mail/h/ works fine, even in a slower browser - and I would say 80% of the sites today are less complex than Gmail.

They don't look good on candidates that use github driven resume applications.

I forgot how great Gmail was before they started doing major redesigns to it, although I do hate to say it... but it could benefit from a little JS to dynamically update with new e-mails...

Resume driven development maybe

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?

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/

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.

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?

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.

Ok well it seems kind of cool, maybe I'll try it out. :)

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.

I like how many comments mention "you don't need a framework" and then mention how they wrote there personal bloggers in pure whatever.

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.

It seems a bit like a Phillips head screwdriver attachment for a hammer, because some people want to continue using their hammer to screw screws, rather than just learn to use a screwdriver.

I don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option, I use `"build": "npx babel --watch public/javascripts/src --out-dir public/javascripts/. --presets react-app/prod"` and that's it. I don't want create-react-app lock-in. Eject doesn't count. That's an illusion.

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.

You're welcome to not want a build step.

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.

There's about zero useful or difficult work I ever need to automate in front-end web development, even for large webapps. I'm curious: what is that difficult work that you're doing? Because if it's legitimately difficult, it probably shouldn't be done every single time you're building and deploying your webapp, should it? Because if you have a large webapp, "difficult" is slow, and you should be avoiding "difficult." "Busy work" is for "smart" projects. "No work" is for exceptional projects.

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.

You're conflating two separate arguments that you made.

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.

Do you own a company paying people 7 and 8 figures? Oh, OK.

What a weird part of my comment to take out of context and fixate on...

Nope, you’re just missing my point.

> don't want a build process. I don't want to have to use npm, but want the option if I desire, for something like React. And when I use React, because there is unfortunately no better option

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

      <script src="https://cdn.jsdelivr.net/npm/vue@2.6.10/dist/vue.min.js"></script>
      <!-- Vue HTML components used here -->
        // Vue page specific JS goes here
There was zero build process.

I would rather go with WebComponents and lit-html, but I share the same sentiment.

Alpine.js works well for this use case too.

Yes! Exactly.

Recently I went on a deep dive to test for myself if it’s even possible to write a modern looking web application with no build tools or dependencies, and turns out its very doable - https://github.com/ivank/vanilla-teuxdeux

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.

I don’t understand how any of this is relevant to Astro, beyond “JavaScript”.

The parent commenter means they didnt prefer to have a build step.

Seems they prefer php-style save-and-refresh workflow (at the cost of doing building at runtime on client device)

Counterpoint: build steps allow for the creation of batteries-included systems that magically do things right, instead of requiring the engineers to do it manually and know about it. This allows for horizontal scaling of workforces (just add more people and train them just enough to be proficient), and keeps knowledge requirements of new engineers low (e.g. they don't need to know about image minification and compression because the build steps takes care of that).

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?

Is it possible to achieve the same thing just with Svelte + SvelteKit and some configs?

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.


What if only some components in my page require Javascript? Can the same "partial hydration" be achieved?

No. Svelte are big proponents of the SPA pattern so I'm doubtful they would ever build something like this.

Svelte by its nature only generates JS for the dynamic pieces of the page, if you’re using SSR it’s already “partially hydrated”.

Vue3 can also ignore static parts which gives similar benefits.

I'm doing something similar because I was disappointed by the output of current static generators: everything gets prerendered to static markup, runtime JS only augments UX.

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.

How does your solution compare to Gatsby?

It fits my requirements, Gatsby didn't.

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?

>” 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.”

I see we’ve discovered the idea of DLLs for the web.

Lately I’ve been going back to basics for some of my projects. Vanilla HTML, CSS and JavaScript. It has been refreshing and has brought some joy to my life.

So excited to see this released, congrats! Astro is the closest thing to what I wanted (and a bunch more) when I started to get back into web dev and started building my personal site.

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.

Well.. I already have all my HTML in one file, and using plain JavaScript with actual template elements in this current application.

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.

Is Astro very different from using another SSG like Hugo, then adding JavaScript in places you need it like type ahead search box or an interactive map? Given that it’s possible to add JavaScript to an SSG made site already, I don’t get what Astro does that’s different.

The biggest difference is that the DX is more like Next/Gatsby type frameworks, where you develop build/client with the same tooling and components, but unlike those frameworks most of your components don’t get bundled or run in the browser.

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.

I see this tool as peak micro-intelligence and macro-stupidity of the whole web dev community. The tool itself is very interesting, and congrats to the authors. But needing this tool shows that in general we have no fucking clue what we're doing.

Wondering how this compares to Gatsby or other React-compatible static site generators...

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).

> 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...

Those non-js carts reload the page when we add/remove anything from it. Not a great UX in post-AJAX world.

It's sort of ironic that page loads 213kB of JavaScript from 8(!) separate scripts to show a large 0.

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.

I want some demos. One demo=thousand readmes.

Run `npm create astro` in any directory to load one of 4 starter demos!

Suspect that should be `npm init astro` or `yarn create astro`.

TIL: npm initializers, thanks!

I can't tell from the homepage or the blog post what this does and why it would make my life as a developer easier.

> I can't tell from the homepage or the blog post what this does

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.

Not really, I mean, it says No JS on one hand and then it says you can add JS, and you can even build your whole website using your favourite JS framework. So it is a little contradictory no? At least it does confuse me a little.

You can use your JS component library of choice, and decide whether a given component is rendered on the client or not (and certain conditions for what causes it to render). It doesn't render any of them on the client at all, by default.

The idea is if you built your site using a js framework but it turns out you don't need that much js, it will make as much of it into static html as possible and the leave the bits that simply must be dynamic as js.

How does it compare to SvelteKit which, AFAIK, also lets you ship no JS + hydration?

Would it work with typescript?

Templates for low coders like me?

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!

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”.

yeah in a way its kinda the anti-tool

Applications are open for YC Summer 2023

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact