I've used Astro my company's landing page for the past year or so [0]. We write blog posts in Notion and port them right to the site and the experience has been fantastic. There are a few understanding quirks with regard to using React etc within Astro (it's SSR'd unless you add the "client" attribute, and counter-intuitively the Component Lifecycle doesn't run the same). For client landing pages, we'll use Astro too- occasionally they'll want a CMS to write their own blog posts without a Git / commit pipeline. In those cases, Netlify CMS plugs in seamlessly and has a generous free tier.
Netlify recently changed their pricing structure, so if you are using Netlify CMS (or just Netlify Identity) with a private repo, every contributor to the repository (committer) will be charged as full pro seat. This can get really expensive if you have a few users working with the CMS (and thus committing content to the repository). We will move a few pages from Netlify now because of this change.
Also, found out the hard way that "Enterprise" pricing (i.e. call us and we'll charge you an opaque amount based on whatever we think you can afford pricing) starts at 7 users.
Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late.
Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful.
I honestly can't find a good option in this space anymore... What happened?
> I honestly can't find a good option in this space anymore... What happened?
They took lots of VC money, got crazy valuations and picked up a few enterprise customers as the JamStack trend grew - and now have to try to generate a return.
You missed the point. Many businesses only need revenue (or EBITDA) to exceed expenses and you're profitable. Once you take VC money, you must exceed profitability and provide a return on VC money. Not all businesses must make a return on outside investment because they did not take outside investment.
Assuming that 7-10 users are FTE, the company is already spending more than $1M on salary and related costs. I imagine the annual Enterprise pricing for Vercel for that numbers of users would hover around 1/4 of an FTE's salary, which is reasonable considering the value provided.
The increase in value provided by these services is very much linear w.r.t. number of users. The 10x+ leap in cost with enterprise pricing is not at all justified by additional value provided.
I don't mind paying a fair, pre-disclosed price for services that provide value. I do mind opaque enterprise sales tactics that try to take full percentage points off my available runway for no discernable increase in value when I try to add one more user. Doubly so when they go to such lengths to cover it up as Vercel is currently doing.
Add me to the list of voices who are highly skeptical about Vercel.
I recall watching a video on their YouTube account a few months ago where their head of devrel tried to interview a famous personality from the “cloud native” community (Kelsey Hightower) as a way to introduce their “edge functions” nonsense.
The entire thing was a train wreck from about ten minutes in when he started asking questions about how it actually worked and what kind of trade offs it would imply.
I remember they had to do a bunch of obvious hard cuts presumably to remove the more embarrassing stuff and it always stood out as a snake oil company to me ever since then.
The fact that they also seem to rely on deceptive pricing and dark patterns for sales seems very on brand with what I recall thinking about them at the time.
I’m sorry you feel this way. I personally enjoyed the interview quite a bit (Kelsey is very knowledgeable about both the past and present of computing).
Yeah, because enterprise pricing is so nefarious. It's fine if having to negotiate a contract intimidates you, but there's nothing sinister in it. It's not possible to offer a simple tiered pricing plan that can accommodate every enterprise customer and their usage requirements. Maybe companies A and B have the same number of users, but B consumes 10x the bandwidth. Should B be paying more than A?
Companies can't stay in business if it costs more to service the business than the revenues coming in.
> Yeah, because enterprise pricing is so nefarious.
The cover up I was referring to was the 10 user limit before Enterprise pricing gets applied, hidden behind a tooltip deep in their pricing grid.
I thought it was obvious given that every one of these companies have enterprise pricing and advertise it front and center, but only Vercel hides the user limit. Assuming your post is in good faith and not a deliberate strawman, I concede that I could have been more specific.
You can use CF Pages with your own build infrastructure, it has "direct uploads" now. It's currently unlimited in the amount of deploys you can do a month. I don't think CF knows how to price it yet, so I wouldn't rely on this being free forever.
That's good to know! Would be nice to hear from someone from CF on how they plan on monetizing these "direct uploads" before we start investing in a migration.
It’s a really great tool I’ve been using since last year. I had previously attempted using Nuxt but that’s a real mess and I never actually got to writing anything. Now I’m using Astro and I’ve got a few articles and it’s a really pleasant developer experience. A lot of static site generators I have found needed more time configuring and writing code for leaving less time in the day for posts etc. I haven’t found this with Astro.
The ability to totally not send any JS at all apart from what you manually add such as framework specific components is really something.
It's not a shallow dismissal, it's the scourge of our industry; I can't wait to retire so that I would never have to look at it again. Give it a rest with virtue signalling.
X being a scourge does not make every X-comment deep. On the contrary, comments about scourges are often shallow and lame.
Edit: I just took a look at your recent comment history, and ouch—that makes it painfully clear that you don't want to use HN as intended. I've therefore banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation.
It seems like Astro's creators believe "content-focused" is a differentiator, but I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.
The one thing I like about Astro is the component island UI. With react you would need to re-render the entire UI on a UI change while in Astro you can signify which portions of your website are static and which dynamically should re-render upon data fetching or whatever.
It's just a faster way to build UI's that don't need the full complexity of a SPA and also don't need to come bundled with the entirety of react from what I've seen and used it for.
It's interesting their blog post doesn't mention some of the benefits. Neither does the doc page you linked—at least it doesn't do it succinctly.
Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in.
You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.
I wish. AFAIK it's just classic server-side rendering with full-page navigation. Mind you, that's the optimal solution in many cases. But a full-stack JavaScript web framework with something like Phoenix's channels and LiveView built in would be a killer combination.
I just started working on something like this. It's a VDOM implemented in Ruby and it streams updates to the browser via Server-Sent Events which are then applied by a tiny bit of JavaScript.
A basic counter component would look something like this:
initial_state do |props|
{ count: 0 }
end
handler(:increment) do |e|
update do |count:|
{ count: count + 1 }
end
end
render do
<div>
<p>Count: {state[:count]}</p>
<button on-click={handler(:increment)}>Increment</button>
</div>
end
There are some things I'm used to in the JavaScript world that I'm trying to introduce here. I got hot reloading which is pretty cool. And CSS modules... and static typing with Sorbet.
Events are handled on the server, so there's no need for an API... You could just talk to your database directly in your onsubmit-handler. I think that might be the largest benefit from using something like this.
If the app is deployed in a region close to you, you won't barely notice the latency.
Not getting it tbh. Why would you go nuclear and develop a React or Vue app and then not actually use it on the browser side? For content-oriented websites there are much simpler workflows based on SGML and other classic markup processing and content management practices. I mean the point of "content-oriented" and web sites in general really is that an expert in the field, rather than a web developer, can achieve useful results as an author.
Developer experience writing React is much nicer than using other markup languages. That's why I use it at least, the fact that it spits out a fully JS-free website at the end is the icing on the top.
Nothing about the developer experience of React seems better than any old HTML template language (and hardly better even than plain HTML), if you're not doing any interactivity and are just going to render once and spit out the HTML.
Have you used React before? It's miles above HTML templating. I honestly don't use frameworks that have regular templating anymore, like Vue or Svelte.
Yes. JSX is nice for escaping by default but encourages total spaghetti coding hiding app logic in the templates and various footguns like non-standard attributes className and breaking id. Running it on the server side mitigates the React performance hit somewhat but the selling point is interactivity.
What are you referring to? I am unaware of what “regular” templating you’re referring to or what react is achieving that is not available or cumbersome under react or svelte.
Think of JSX as a macro, rather than "regular" templating, which is typically string substitution.
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
Some day we have to stop repeating this nonsense. JSX requires much more learning than simple templating, there is no inherent benefit. Even a simple conditional is more complex than your average template.
The thing is, if you know JS, then a conditional is JSX is the same as in JS. Contrast that with every new templating language under the sun which might have its own way of doing conditionals and loops and control flow. That to me is much more annoying.
Separation of concerns is different from separation of languages.
PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.
Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.
JSX doesn't separate languages, you're mixing HTML with TypeScript. You can absolutely do database queries in your template. What is keeping you from doing `fetch('https://side-effect.ts').then(() => doSomethingHorrible())` in your template? Or invoking an `alert()`?
You can do those things, but you're not going to capture the effect that you want. Renders happen frequently, and the render process will complete before your `fetch` resolves. As for alert, the alert will pop up immediately before the render is applied to the DOM- and will likely pop up many times more than you thought it would, assuming you're popping it up based on some state variable.
In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.
Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.
Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.
This is a dubious claim, since JSX is limited to expressions. If you ask people for “a conditional in JS”, they’ll very probably go for `if (…) { … } else { … }` first, not `… ? … : …` (if you can even rewrite it as a ternary). Same deal with loops: you’re limited to expressions, so you can’t use the normal way of writing a loop (and this regularly leads to mild contortions as you deal with iterables of diverse types). Therefore I’d tend to (qualifiedly) describe JSX as doing its own thing too.
Plenty of people are taught that ternary operators are evil and should never be used.
Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.
That doesn't make either of those things true.
As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.
How so? Any expression is valid within JSX- ternaries, function calls, binary and unary operators are all valid. If you know JavaScript, you already know all of the control mechanisms that are valid.
I have used React. I'm a huge fan and I also prefer it over its most common "competitors" like Vue and Svelte.
But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
> Nothing about the developer experience of React seems better than any old HTML template language
Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
You have to be joking, surely? React/Vue as a mere static template languages? Dedicated static site frameworks such as Jekyll and Middleman are a much better experience. My favourite is still Perl's Template::Toolkit.
TypeScript, that's the differentiator. Having fully typed variables in the templates cannot be replicated in templating languages (well technically they might be able to but that's not as ergonomic as fact).
Talk about sledgehammer to crack a nut - honestly, why does anyone need type safety in a simple templating operation? Dynamic languages have their uses, you know. Type safety is a tool, not an ideology.
I basically never use dynamic languages anymore. If there aren't algebraic data types in a language I simply don't use it. Sometimes people think I'm exaggerating but it's truly great to use a language with ADTs that you get spoiled.
I like using Nim or Rust, or TypeScript, depends on the script. If it's just a few lines, sure I'll write it in bash, but if it gets a little larger, I convert it into a real programming language.
My bash scripts are often edited, I could not imagine using a compiled language where I would have to store the source as a separate file from the executable, then compile it each time.
I'd love to know your more specific use cases, if you don't mind. I'm always happy to learn something new. Could you share some Rust that most people would script in Bash as an example? What's your build and deploy (to ~/.local/bin I presume) strategy?
> where I would have to store the source as a separate file from the executable, then compile it each time
> What's your build and deploy (to ~/.local/bin I presume) strategy?
You can run scripts as you would with bash, you don't have to manually build and run the executable. For example, `cargo run (inside the script source folder)` and `sh script.sh` do basically the same thing, end user wise. `nim compile --run script.nim` is similar in that the language compiler will automatically compile and run it together.
> Could you share some Rust that most people would script in Bash as an example?
I was creating dotfiles the other day and I didn't want to use some dotfile manager program as I had some specific steps I wanted to follow, so I started it as a bash script. Well, it got kind of annoying so I made it into a Rust script with some nice features like interactive prompts, text coloring, etc with libraries like `clap`. You can do this in bash of course, but the Rust version was more ergonomic. When I need to run the script, I just did `cargo run` and it worked great.
I see, but then your scripts are not nice compact commands.
For instance, my most-used bash script takes a file as input and opens either VIM or Emacs depending on whether the file is a .md or .org (simplified example). I run it like so:
$ n foo.org
I can edit ~/.local/bin/n and update the file, and use it immediately. I actually have my whole ~/.local/bin in version control. Having to type out e.g.
$ nim compile --run n foo.org
...would make the whole experience far less fluent. I probably would never use it.
I'm asking because I'd love to rewrite this script in e.g. Rust, but I don't see any good way to deploy it to ~/.local/bin/n.
Just alias the command in your .bashrc? e.g. `alias n="nim compile --run n"`. I'm not sure what the issue is with longer commands because the benefits of writing in a strongly statically typed language definitely outweigh a few extra characters to type, which you don't even need to do with aliases.
For what it's worth, you need only type "nim r n". If "n.nim" is marked executable and begins with "#!/usr/bin/nim r" then you also need only type "n.nim".
For nim, you could use something like nimcr (https://nimble.directory/pkg/nimcr). You put a shebang in your script `#!/usr/bin/env nimcr` and then call it like a normal script.
But TypeScript doesn’t have ADTs which you stated was a hard requirement. It has some other features that can achieve similar things though, so maybe that’s good enough?
Kinda nitpicky. Sure ADTs are a pattern in Typescript rather than a first-class entity, but they're an extremely well-supported pattern, exhaustiveness checking and all.
type ADT =
| { case : 'a', a : Number }
| { case : 'b', b : string }
function f (c : ADT) {
switch(c.case) {
case 'a' : return c.a
case 'b' : return Number.parseInt(c.b)
// case 'c' : return 0 // compile error
// case 'b' : return c.a // also compile error
}
}
For sure. I'm a big fan of type safety in larger codebases with reasonably stable domains. But when a project's small or new enough to be relatively volatile, the overhead just isn't worth it for me.
because it's nice to know whether that `post` variable contains a property `createdAt` or `published` At without leaving the template. Arguing "I don't use it why should you" is unproductive.
Agreed, you get all the benefits of type inference even in a template. It's a pain to debug template variables that don't exist, I've written enough Handlebars to know.
There are "templating languages" such as SGML for generating type-checked markup ie. respecting the regular content model and lexical types expressed in DTDs and other markup declarations. This results in injection-free, HTML-aware templating ie. templating engines can properly quote/escape content in attributes, CDATA sections, etc. and can enforce content model rules (that eg lists consist of nothing but list items, that script elements aren't placed where forbidden as would be required in user content such as comments provided by your web site visitors, etc.) Much more powerful than programming language types, and needed in CMSs.
and what's your experience writing other markup languages that you base this statement on? I can definitely agree it is nicer for a data intensive sites, and with effort can be made somewhat equivalent in most document heavy sites, but there are definitely some scenarios I've encountered where the match of technology to use case was disastrously not in React's favor.
Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.
I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.
I can say that because I have built big solutions in both stacks, though.
I've used many, Handlebars, Pug, Vue's, Svelte's, Zola's, many. They're all somewhat similar in that they try to recreate loops and conditionals, all without strong type support unlike in JSX. I've never used SGML though, another commenter told me that it is more powerful.
Component-based UI frameworks and ecosystem has made building frontends much nicer, especially when you need some optional interactivity since you're already writing in JS.
Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.
Frameworks like Gatsby didnt have any special support for interactive islands. You can choose to have:
a. A completely static site with no frontend javascript and no client side hydration, or
b. client hydration in which case all the components needed in the page will need to be loaded in the client.
If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort.
Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.
I suppose it's just a different templating engine (plus some optional features for the client side). Probably as a front-end developer people are more familiar with that compared to Jinja for example? Though I think if the target is static web sites then it's simply overkill.
If you look at the project structure it uses that might help make it more clear the capabilities: https://docs.astro.build/en/core-concepts/project-structure/ Content-focused seems to highlight that you can just dump markdown files into it and spit out rendered pages, very much like content focused static site generators (hugo, jekyll, etc.). But in addition to that static content it has all kinds of hooks and capabilities to add dynamic components or even pages, kind of like more modern web application platforms like next.js.
For me it's the pre-rendering. I've used Next.js, Nuxt.js, Remix etc and they all server-render great. But for deploying SPAs to file-hosting (S3 + Cloud Front or Firebase Hosting) without a server runtime, you end up with empty HTML on request which is worse for SEO, social previews etc. There are solutions to pre-rendering for these stacks but they're more focused on deploying to Vercel or Netlify functions, or having a post-build script which opens the site in Puppeteer and saves the HTML into your build file! With Astro, all this is out of the box immediately. Try putting together an Astro site and look in your build directory; you'll see even for React components the HTML is already there
Yeah you can, but there's more configuration involved. The default `nuxt generate` output is an HTML page that just has a loading element and a bunch of JavaScript tags*. On my Astro apps all of components that don't explicitly have a "client" attribute are prerendered
* unless something changed since my last Nuxt project
That's what I find confusing in Astro's self-presentation: they talk a lot about MPA vs SPA and how nicely they blend, making it abundantly clear that by MPA, they mean server-rendered. But then there's all the talk about static file hosting and I think the project even started as a static site generator ("dev-machine rendered")? It would be super awesome if they tackled what might be called "three level partial hydration" (build time, server side, client side).
Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).
Responding to myself: documentation clearly seems to come from two different areas, one when everything was either client side or build time and another after astro introduced server side dynamism.
While Astro has a lot of impressive features I found that it was the "developer experience" (god I hate that term) that was superior compared to everything I've tried before.
With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.
Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.
Here are some of the things I love about Astro:
- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.
- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.
- The Astro themes (https://astro.build/themes/) are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.
This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.
Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience).
Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, it's hardly the only offender) is servers and services, and the users (other engineers) consuming those outputs can have a nice time. The DX of using Chef, though, can be ughh....
it is subjective and overused - perfect storm for industry jargon that takes up a lot of space without saying anything more than "this thing sparks joy"
It’s no more subjective than “user experience”, which is a term thrown around far more often than “developer experience”, without complaint (and of course, the DX of Astro-using devs is UX for the Astro creators)
It might be overused, that’s an opinion, I don’t agree.
100% agree with you that there's a lot of improvements to be done for a lot of the software we developers use on a daily basis. It's the term DX / Developer Experience in itself I dislike strongly. My sibling poster @swyx did a great job explaing my main gripe with using abbreviations like this.
I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)
> Honestly we need more DX improvements in this industry.
Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.
Have you used Next.js much? Next was the first (and so far, only) SSG I enjoyed using in the JS world. Just wondering if you have any comparisons. Markdown generation in Next was also a breeze.
I feel you, tbh as someone who has NextJS as my main tools, it's hard enough to choose Remix or Redwood as a starter project, when I needed backend it's either Django or Spring boot from time to time.
Not really sure when to play around with these new frameworks if it's not giving me enough reason to switch, especially since they're not adopted in big tech companies it makes it harder to justify the usage when I want to build somethjing
I think it makes the tradeoffs that are ideal for content-oriented sites rather than web apps.
> Next.js uses React to render your website. Astro is more flexible: you are free to build UI with any popular component library (React, Preact, Vue, Svelte, Solid and others) or Astro’s HTML-like component syntax which is similar to HTML + JSX.
> Both Next.js and Astro are frameworks for building websites. Next.js does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).
The winning point over other frameworks is the implementation of island architectures (streaming ssr static content + only load required js to run dynamic components) https://www.patterns.dev/posts/islands-architecture/
So excited for this. SSR with Astro is a gamechanger which opens up its usage to so many different avenues. Great strides with framework interop too. Named Slots really closing the gaps.
And of course any framework where SolidJS can shine so bright is going to be the top of my list.
It uses it to know what JS is needed for the client. If it sees <Section /> that means that no-JS is needed. But if it sees <Counter client:load /> it knows to build + bundle the Counter component and attach its JS to the page.
The reason why you don't know is that you've decided in advance that it's not actually needed.
.astro is not actually like MDX at all. MDX extends Markdown, Astro does not, it extends HTML. MDX is a variant of JSX, Astro is not, it supports things that JSX does not like void elements. Astro supports text inside of script and style tags, JSX does not.
If you think you can rebuild Astro with "a few extra preprocessor rules", then by all means go for it. But you're going to fail.
> If your project falls into the second “application” camp, Astro might not be the right choice for your project…
Plenty of applications in the second category (logged-in admin dashboards, to-do lists, etc.) have been developed using server-first frameworks, and some of us still prefer to develop web applications that way. Is Astro missing any key features for dynamic server-first applications, e.g. form submission and validation support? If not, I think the Astro developers might be selling Astro and MPAs short.
I agree some of their examples aren’t great, but I think what they’re saying is that Astro’s benefits become less relevant for apps which are highly interactive in the client. You can certainly use Astro to build those, but in many cases you may be just as well served (if not better) by using a more established tool oriented toward whichever client framework/libraries you choose (eg Next.js or Nuxt or SvelteKit etc).
That said, there’s quite a lot of space between that extreme and the mostly-static “web site” extreme, and I agree Astro would be a better fit than they let on, for a large chunk of that space. My suspicion is that this is intentional, to keep their current focus and explicit use-case commitments narrower. And I wouldn’t expect it to remain that narrow in the future.
Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update?
Inevitably, when a new "hot" SSG comes on the scene, I try it, and then go back to compare it to the old "hot" SSG from 2 years ago. Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times.
As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run.
And like all SSGs, I see no mention of sane SEO defaults on the homepage. Let me guess--with Astro I'm going to have to set all of this up myself?
It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc
The SEO defaults aren't perfect but they're easy enough to change in the software.
Have you checked out Hugo? It's builds are pretty fast, and it has a watch function for rapid dev work.
Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.
Use any SSG not written in javascript and you'll be fine. Hugo, Zola, Jekyll, etc. Though if I was starting from scratch I might avoid Jekyll just because of the Ruby dependency.
Yeah Hugo has the advantage that dep management for Go is 10000x simpler than JS, Ruby, Python, etc., particularly when you are someone who doesn't work in that language regularly.
Plus as sibling comment says you usually don't do anything but install hugo, `hugo [command]`
Honest q: what’s the problem with Ruby? Compile time? Gem management? I’m using Jekyll and sometimes wonder if I’m missing anything from the newer systems. My compile time is negligible, and once I figured out how to integrate Tailwind, I’ve had no issues.
I don’t see a reason to switch a site from one to the other if you and any collaborators are comfortable maintaining the runtime. The same goes for JS based tooling (I imagine), I just don’t node so good.
Personally, I use Hugo for new projects because it lowers the burden for content collaboration.
Templating is weird in Go, though if you’re working on themes. I like it now, but it’s procedural vertically and LISPish horizontally, if that makes any sense.
Usually it’s just me or me and another guy messing with that, and others often unfamiliar with anything except Java contributing vanilla markdown documentation. “Clone the repo, run this binary” is helpful there.
Personal preference mostly. rvm/gem/bundle is just a lot to set up and keep in your head compared to running a statically-linked binary. It feels like a relic of a previous era. Plus compiled languages are faster, and massively easier to set up if you have contributors running Windows.
But like sibling said, if you're happy with your setup, keep it.
As a counterpoint - the big benefit I see from Astro isn't that it has minimal dependencies, it's mainly that it seems like a very flexible foundation to build from. So I'd agree a landing page doesn't need this, but "the best tool" for a landing page is probably too specialized for general use in larger applications.
> Is there a static site generator out there that doesn't require a ridiculous build process every time I do an update?
I am experimenting with Caddy's template functionality [0] in my pursuit of making dependency-free and buildless websites. Caddy's templates are inspired by the Server Side Include (SSI) functionality in Apache and Nginx, except it uses Golang's syntax. I have made several websites in Hugo and find it pleasantly similar, only more bear-bones.
Although Caddy is serving static sites to the browser, it is technically more like using a dynamic scripting language like PHP on the server. I guess Caddy templates outperform PHP by a large margin because it is written in Golang and compiled, but I have never tested this hypothesis.
Funfact: Caddy's entire website is written with Caddy's template system and the source code is available [1] for those who want to take a look!
You could write your own plugin that calls out to your WASM layer if you want, but I'm not sure we need that built into Caddy. It would be extremely niche, I think.
We've used Eleventy on a project a year ago and it was super easy to get running. It is not tied to any frontend framework (but if you want an interactive part on the page, you will have to set it up yourself, in contrast to Astro's Islands [1]).
My overall impression is: use 11ty for a first version, use Astro when you have more moving parts on the frontend.
Little bonus for those coming from Python background (like me): 11ty uses Nunjucks, which is a JavaScript port of Jinja, so the templating system feels right at home.
Hugo (https://gohugo.io) maybe? I tried it for a small static site about internal documentation, and I'm very glad I did. The hardest part was reading the documentation, the installation, content generation and rebuilds were painless.
The hardest part of Hugo for me was creating my theme from scratch (docs are eh on this but I found some good 3rd party tutorials) but after that it's been an absolute breeze.
After spending a little time understanding Go templating it is really beautiful
Half way through customizing a Hugo theme, I suddenly realized that I don't need a theme at all. Hugo can be used themelessly, where you just write templates specifically for your site. Everything was so much easier from there.
That was my experience too. There is/was no formal standard for creating themes, just an empty dir (which they consider a feature). Even if they had one or two "official themes" that would have helped tremendously.
Instead we spent a week researching how popular 3rd party themes did things, and made a hybrid. Then we moved away completely. I really wanted it to work for us and we were so close. Hugo is so fast and is brilliant on a couple of things.... but barely missed.
I can't remember exactly but with what we were doing we were going to be heavily dependant on their Scratchpad, which felt like a hack. It's all just hacks, and they like it. Lack of solid conventions, and they LOVE it.
OK I see, but even though it's themeless you still have to follow the Hugo theming structure (_default, partials, index.html, etc). Mine is the same as that, it's just nested into the themes directory.
It's that theming structure that was a pain to figure out the first time for me
Yeah, that template look-up hierarchy is unavoidable. The benefit of being themeless is mostly organizational: one config file, one asset directory, etc.
Totally agree on this. Took me a bit to wrap my head around it vs other templating I’ve used.
Also figuring out the variable structure took me a bit, but now the docs make sense to me.
My theme is super simple. A few templates, 1 CSS file, and a tiny amount of vanilla JS. I just let Hugo + CSS do most of the lifting.
I think some folks have had bad experiences with themes that layer a JS framework on Hugo, though. That may be a better case for a completely JS ecosystem.
There’s a lot of good options. That’s a good problem to have. Just use what you like, I guess.
Much of the interesting and useful tooling today is in the JavaScript ecosystem, that you will still have a package.json, Node dependency, etc. Except they are not Hugo’s problem, they arrived via a theme you are using, and they are your problem.
Hugo itself is a pretty lean template system. That means it doesn't know much about building websites. All kinds of things you hope it will know about (SEO, how to plugin analytics systems, much much more), are sitting over in themes in the ecosystem… tangled up with the axis of what visual appearance you want.
So the notion of swapping themes to swap appearance doesn't work, because the theme you picked provides a bunch of functionality in addition to appearance, and a different one will not have the same functionality.
This isn't a complaint, it is a good piece of work with many well-thought-out ideas. But it is pretty far from what the poster was looking for.
Maybe it's too obscure, but I really like Metalsmith. Once it "clicks" it becomes ridiculously easy to make plugins and to operate, and it generally doesn't go out of date.
That said, it may require a bit of javascript knowledge to get a more customized build running. It does have YAML configuration and a set of useful plugins you can use without touching code, from what I know.
I liked Metalsmith because it was so simple that you could understand every single thing it did and why. Unfortunately, the dependency tree gets ridiculous quickly, especially since many of the plugins depend on different versions or implementations of libraries (e.g. path matching libraries). My site ended up with 200+ transitive dependencies.
Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times.
Pin your dependency versions and never suffer this problem again! Shrink-wrap your node modules and don't even download them again! Use Yarn's offline cache to share package tarballs between applications to save on disk space!
There are many options for this problem. And that's just in the JS ecosystem. Use something Ruby or Go based and it's even better.
As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run.
Except there really, really is. A static site generator is really an optimizing compiler for 4 or 5 different languages (html, css, js, markdown, a template language, etc), with a build tool chain, and often image optimization, and a server for dev, and usually some sort of semi-opinionated structure that scans a directory tree and magically turns that into something you can just throw up to a web server and have a working website. They're complex systems pretending to be "simple and easy" because the output is essentially HTML with a few whistles.
You certainly can build a site generator with far less code, but when people want a lot of flexibility just by tweaking a JSON config file that necessitates complexity. And in JS, that means more packages.
The beauty of tooling is that there are lots of alternatives if you feel you want to optimize for dependencies instead.
This is one of the reason I built Cigala [1], it's a single PHP script that let you build your website in the admin interface using a WYSIWYG editor (TinyMCE) that manipulates an SQLite database, and that produce static HTML pages for publishing. It only depends on PHP and SQLite which are available virtually everywhere for free (and in the worst case you can run it locally as the resulting static website can be copied to any static hosting).
I used a static site generator for all of these benefits in the past, but the rebuilding process is a total nightmare.
The site has about 20 categories, and each category has about 100 images. Every time the team adds a new image or category, the deployment/building task clones the repo and then the build process generates all the optimally sized images again and then re-uploads multiple gigabytes to the host. Is there a way around this type of problem with static site generators?
You might need ISR (incremental static regeneration). IIRC there are a couple standard SSG frameworks that support something like it. Usually only worth investing in if you are operating at a large enough content scale though.
To try Astro on your local machine, run npm create astro@latest in any terminal.
because it doesn't make it clear to me what to do before this command will actually do anything. No, running this command will not work in any terminal.
As long as you have npm installed it'll work. Npm create is an alias for the npm init command [1], which will look for a package with the prefix 'create-', install it, and run its bin file. It looks like this is the file that ends up being run: https://github.com/withastro/astro/blob/main/packages/create....
If you don't have npm installed, just stay as far as you can from this :D
Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies.
Exactly. PHP (like every other modern programming language) has its own dependency management tools. Node is actually better than many in this respect because npm comes bundled with Node — it's not something you have to install separately.
Ironically, Composer actually lists npm as one of its inspirations [1].
> "...Composer is strongly inspired by node's npm and ruby's bundler."
Well obviously you'll need npm to use a command that begins with npm. If someone gave you a terminal command to run that begins with curl, you'd be expected to have curl installed. This seems like pure pedantry.
Take a look for example at the rust installation steps [1]. They tell you to run the following command in your terminal: "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh". They don't tell you to first make sure you have curl installed (or sh for that matter).
I agree; the "in any terminal" part is paternalistically redundant - any software developer who recognizes the npm command will know what to do with it.
A few years ago when I was trying to understand the new JavaScript world with React and all its toys (moving from my background of PHP and other 'old-school' server-side rendered solutions), I hit problems similar to this.
This particular example isn't too bad -- looking at that line, it would be clear to me that I'm missing 'npm', and the solution is obvious -- find out what npm is, and get it installed. But the things that really bit me were tons of examples of JavaScript, which included strange lines like 'import', and I had no idea how to get my website's JavaScript to understand what an import is or any of the other syntax. Nothing would work! I didn't realise there was a whole ecosystem around how to build your code so that it can make use of these things. Every guide assumed I had things going, and I just didn't understand that I needed this other infrastructure in place first before I could do anything.
Some notes of things that have changed in the last five years:
- bundling is (almost) no longer needed for simple import/export as we now have a native module capability (esmodules). The biggest issue you’re likely to have here is waiting for any dependencies you have to upgrade from common js to esmodules.
- transpiling is not as necessary unless you explicitly have to support IE11, or require something in the latest ecmascript spec.
It really speaks to the maturation of front-end development that after five years that article is still fairly accurate.
About time too - I’m too old to put up with that level of churn anymore.
Been using this the last week to convert an 11ty website and really enjoying it so far. Very cool to just be able to use whatever JS framework you want for a component and just drop it in.
Sometimes all the frameworks that re-invent MVC (but in a detached fashion) and tout "server side rendering" just feel like we've come full circle where we're just serving a static view cache that was generated from models and data using a controller.
The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefit.
At this point, while all the renderers get better and simpler, we're still in a situation where complexity or writing code hasn't really gone away, it just shifted around to new places. Perhaps at some point we get to the HTML + WebComponents stage again (kinda like MDX and React mixing), and classic Apache Server-Side Includes become the new hot thing again.
I think edge computing and CDNs might be what is making this all more interesting. It is not just where you render (Server vs. Client), it is where you render (Dallas vs. Rio). If you can get your app to re render small sections and have the framework figure out that these sections are static and can chuck them in a CDN (or they are not and need an edge server, or a central server) then you can get lots of optimizations that way.
That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization.
I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.
I think that any view cache works fine with edge caching. Worst case your first request has to traverse the CDN network to your compute once every cache invalidation.
That said, none of the static site renderers really do anything special that is required to do anything on any edge. Considering the huge amount of storage and memory required to store a node_modules tree and re-render on demand, even classic MVC would easily do the same.
What would make a somewhat larger difference might be a combination of factors; something like centralised push and distributed compute via WASM. That means any logic could be compiled and packaged as-is without needing anything else. Somewhat similar to using cloud flare workers with something like Go or Zig.
Then again, like you described with the rails example, this is mostly a solved problem. Even a full server-side view with just classic HTML 4 and CSS output can do this, at very low latencies and very wide reach. After the first hit, the difference between this and static pre-rendered pages is almost irrelevant.
The biggest 'solves' one might get would be uncached always-computed content which needs to be executed on demand, and attack surface changes. But that gives us a different class of problem since we could also decide to simply offload all of the hard work to someone else and simply pay Squarespace and the likes ;-)
It provides themes; as does Next.js/Versel, mui, etc. Are seasoned developers usually forking from these provided designs? What value do you guys ascribe to provided themes?
Not to be "that guy", but could you please put the language in the title when posting stuff like this? We all have our language preferences, and I'd rather not have to go digging just to figure out if a project is relevant to me.
It says it's a "web framework" in the title. That generally means it's going to have some kind of templating system, plus html, css, JavaScript, and probably support for other things like markdown and json. Which of these did you want in the title?
Or if you mean what was astro itself written in, I think this post is aimed at users of the system, not potential contributors. Personally I dislike it when when a post says something like "Hugo, a static site generator (Golang)" because it incorrectly implies you need to write Go in order to develop with it.
When I see "web framework" I think Phoenix, Django, Spring, etc. Which do all require you to write in the associated language. If you said "Static Site Generator" then yes that doesn't imply you need write in a specific language.
255 comments
[ 2.3 ms ] story [ 194 ms ] thread[0] https://koptional.com
Vercel is not much better at 10 users, and they hide it deep within their pricing table behind a tooltip so you're not likely to realize this until it's too late.
Cloudflare Pages doesn't charge per user but limits concurrent builds which can get really painful.
I honestly can't find a good option in this space anymore... What happened?
They took lots of VC money, got crazy valuations and picked up a few enterprise customers as the JamStack trend grew - and now have to try to generate a return.
Otherwise called running a business.
I don't mind paying a fair, pre-disclosed price for services that provide value. I do mind opaque enterprise sales tactics that try to take full percentage points off my available runway for no discernable increase in value when I try to add one more user. Doubly so when they go to such lengths to cover it up as Vercel is currently doing.
I recall watching a video on their YouTube account a few months ago where their head of devrel tried to interview a famous personality from the “cloud native” community (Kelsey Hightower) as a way to introduce their “edge functions” nonsense.
The entire thing was a train wreck from about ten minutes in when he started asking questions about how it actually worked and what kind of trade offs it would imply.
I remember they had to do a bunch of obvious hard cuts presumably to remove the more embarrassing stuff and it always stood out as a snake oil company to me ever since then.
The fact that they also seem to rely on deceptive pricing and dark patterns for sales seems very on brand with what I recall thinking about them at the time.
The interview in question is here in case anyone is interested https://youtu.be/yuxd2kurpzk
I cut out parts of the interview to make it shorter. If you’d like to verify what I showed, you can deploy an Astro site with Edge Functions for free: https://vercel.com/templates/astro/astro-edge-functions
Open to feedback on how we can do better next time. Would you prefer more discussion about tradeoffs?
Yeah, because enterprise pricing is so nefarious. It's fine if having to negotiate a contract intimidates you, but there's nothing sinister in it. It's not possible to offer a simple tiered pricing plan that can accommodate every enterprise customer and their usage requirements. Maybe companies A and B have the same number of users, but B consumes 10x the bandwidth. Should B be paying more than A?
Companies can't stay in business if it costs more to service the business than the revenues coming in.
The cover up I was referring to was the 10 user limit before Enterprise pricing gets applied, hidden behind a tooltip deep in their pricing grid.
I thought it was obvious given that every one of these companies have enterprise pricing and advertise it front and center, but only Vercel hides the user limit. Assuming your post is in good faith and not a deliberate strawman, I concede that I could have been more specific.
and for private orgs https://www.netlify.com/pricing/private-org-repo-faq/
inevitable question that always can use answering - what can you share about Astro's company business plan/business model at this time?
The ability to totally not send any JS at all apart from what you manually add such as framework specific components is really something.
https://news.ycombinator.com/newsguidelines.html
Edit: I just took a look at your recent comment history, and ouch—that makes it painfully clear that you don't want to use HN as intended. I've therefore banned the account.
If you don't want to be banned, you're welcome to email hn@ycombinator.com and give us reason to believe that you'll follow the rules in the future.
Could you please explain the tradeoffs vs tools like Hugo and Docusaurus?
I acknowledge that this might be a PEBKAC situation, but I'd love to hear thoughts from people who used Next.js, Remix, or whatever and found Astro to be a revelation.
It seems like Astro's creators believe "content-focused" is a differentiator, but I find that confusing since content-focused sites are a popular use case for web frameworks that are also suitable for more complex apps.
Plus, both Next and Remix are tightly coupled with React, whereas Astro is trying to be more agnostic in that regard.
It's just a faster way to build UI's that don't need the full complexity of a SPA and also don't need to come bundled with the entirety of react from what I've seen and used it for.
Essentially Astro lets you build sites using a JS framework like React or Vue without requiring that framework to be loaded on the frontend. By default, components are just HTML content. Super nice for building very fast static sites using a technology you may already be fluent in.
You can still add interactivity to components if you'd like—just tag components that require interactivity and Astro will bundle the requisite JS for the client.
A basic counter component would look something like this:
There are some things I'm used to in the JavaScript world that I'm trying to introduce here. I got hot reloading which is pretty cool. And CSS modules... and static typing with Sorbet.Events are handled on the server, so there's no need for an API... You could just talk to your database directly in your onsubmit-handler. I think that might be the largest benefit from using something like this.
If the app is deployed in a region close to you, you won't barely notice the latency.
I mean if JSX is considered as something particularly powerful (not saying it does) doesn’t Vue actually do that https://vuejs.org/guide/extras/render-function.html ?
For static sites, this means that you get functions and objects the entire way through the render pipeline right up until there is a full tree built and the final output is rendered.
You still get all the separation powers of contexts, the component based reusability, etc, and it is all regular JavaScript / typescript except for the JSX macro itself and React's APIs (which are just JavaScript). Conversely, with templating engines like handlebars / erb / et al you need to learn the specific DSL of the template engine- custom loops and controls, imports for partials, and your custom helpers are limited to what they can do. Even Vue's render function has special markup for control (v-if, v-else).
PHP intermingled with HTML was bad because developers would do things like run database queries and other operations that caused side effects directly in the markup. Every templating system still has logic in it, and almost every templating system as a way to create custom helpers which are written in the host language.
Since API calls and calls to react's `setState` are asynchronous, and the rendering pipeline is synchronous, it is still obvious that you can't put code that makes an AJAX call in your html markup.
In short, you can do those things maliciously, but if you do them naively it is immediately obvious when you run the code that it's not correct.
Compare that to the original analogy to mixing raw PHP and HTML templates. Since the rendering process is blocking, you can easily stuff form handling, remote API calls, and database calls in amongst your markup, and can make it "work" even if it's not clean.
Even Laravel's blade components let you write custom components and helpers in PHP which can do all of those things from the template- you just don't see the actual SQL mixed with the HTML in the same file. The problem is still there, just now it is harder to see.
Plenty of people were also taught that proper architecture involved an AbstractGetterVisitorFactoryFactory.
That doesn't make either of those things true.
As a side note, if you find yourself wanting a loop but using `map` isn't sufficient, you should probably be preparing the values ahead of time and still using map. It'll be more efficient, and the code easier to read.
But React (like Vue and Svelte) are fundamentally about interactivity. If I had a project where I knew for sure that I only wanted to generate HTML sans JS on the server (or with a static build process) I wouldn't even consider using React.
It barely even makes sense. Your "React components" would just be JavaScript functions that take props and return some JSX. None of the interesting React features and hooks would even make sense, other than maybe context (and presumably most or all popular static HTML templating tools have comparable features).
They can also be async functions that process data independently. Whereas templates are commonly just passed in data from the controller.
https://github.com/dsego/ssr-playground/#jsx-partials
If you are building a growing design system with any degree of complexity, React is one of the best tools available.
Is that a joke? You get autocomplete from typescript and props to be fully typed functions, or any kind of object for that matter. That compares to autocomplete that's just some ad-hoc, bug ridden tools that locks you into some IDE or editor, and who cares because all the attributes have the same type (string) anyway.
My bash scripts are often edited, I could not imagine using a compiled language where I would have to store the source as a separate file from the executable, then compile it each time.
I'd love to know your more specific use cases, if you don't mind. I'm always happy to learn something new. Could you share some Rust that most people would script in Bash as an example? What's your build and deploy (to ~/.local/bin I presume) strategy?
> What's your build and deploy (to ~/.local/bin I presume) strategy?
You can run scripts as you would with bash, you don't have to manually build and run the executable. For example, `cargo run (inside the script source folder)` and `sh script.sh` do basically the same thing, end user wise. `nim compile --run script.nim` is similar in that the language compiler will automatically compile and run it together.
> Could you share some Rust that most people would script in Bash as an example?
I was creating dotfiles the other day and I didn't want to use some dotfile manager program as I had some specific steps I wanted to follow, so I started it as a bash script. Well, it got kind of annoying so I made it into a Rust script with some nice features like interactive prompts, text coloring, etc with libraries like `clap`. You can do this in bash of course, but the Rust version was more ergonomic. When I need to run the script, I just did `cargo run` and it worked great.
For instance, my most-used bash script takes a file as input and opens either VIM or Emacs depending on whether the file is a .md or .org (simplified example). I run it like so:
I can edit ~/.local/bin/n and update the file, and use it immediately. I actually have my whole ~/.local/bin in version control. Having to type out e.g. ...would make the whole experience far less fluent. I probably would never use it.I'm asking because I'd love to rewrite this script in e.g. Rust, but I don't see any good way to deploy it to ~/.local/bin/n.
eg:
edit:There's also the possibility of using nimscript, using nim e. It works similarly but you'd change the shebang line to something like
In config.nims:
In bash:Specifically I can think of parts of the websites' functionality is editing highly technical structured data documents by highly trained domain experts.
I mean basically where years of developer productivity was thrown down a React hole when it could have been months in SGML / XML based tooling for what was required.
I can say that because I have built big solutions in both stacks, though.
I'm not a web dev by trade but I have a website for a hobby project. I had taught myself React thinking I might make an app. (I never did.)
So now I want to maintain this thing on the side with not much effort using what I already know. And that keeps those skills fresh, which is great.
I'm very interested in Astro.
Having that productivity and flexibility without the SPA complexity and other JS cruft has real value.
a. A completely static site with no frontend javascript and no client side hydration, or
b. client hydration in which case all the components needed in the page will need to be loaded in the client.
If you want something in between, ie. only some sections need to be interactive, it requires jumping through some hoops eg. creating separate webpack entrypoints that call ReactDOM.render for specific DOM nodes. It is doable but more work and maintenance effort.
Astro simplifies handling for these kind of islands by using a server side templating language that is component aware and familiar to users already writing jsx.
I think this is the only selling point, given the "content-focused". It's not different than just writing HTML and vanilla js for some interactivity.
* unless something changed since my last Nuxt project
Might even sneak in a fourth level, "server side, but cached until marked dirty". For when you are set up for static rendering, but want to reduce backend load for rarely changing stuff. I'd expect that it would be quite powerful to have that capability inside the engine that handles rendering, on component level if necessary,and not just on some internal microservice boundary (where I think it's quite common?).
Apparently there has been quite a watershed moment, with the announcement merely a few months ago: https://astro.build/blog/experimental-server-side-rendering/
There is also this page comparing it with other tools: https://docs.astro.build/en/comparing-astro-vs-other-tools
With Hugo and Jekyll I always needed to go revisit the docs whenever I hadn't worked with it for a while. I never got to the "oh, I get this tool now" phase, where the content generation could just flow without issues.
Publii was cool, but trying to shoehorn everything into fitting in the "Blog" model never quite worked out for me. Also being forced to work in a new IDE wasn't to my liking either.
Here are some of the things I love about Astro:
- The docs are great. You can read through them all really quickly. I tend to prefer systems that are simple to grok, and Astro is just that.
- The lightweight Astro components (https://docs.astro.build/en/core-concepts/astro-components/) were great for me, because they delivered on being able to create reusable pieces of code very easily (without having to touch React).
- Being able to generate part of your site from markdown and part of it from precisely crafted HTML is a great way to be able to handle both repetitive and unique content.
- The Astro themes (https://astro.build/themes/) are a great way to start. Find something that's somewhat similar to what you want to build and study how they did it.
This is obviously very subjective, but for me Astro was the first SSG that I really enjoy using, and that I didn't feel like I had to fight against.
Why do you hate it? It's useful to have a term to differentiate between the experience of the person using the output of the tool (user experience) versus that of the people developing with the tool (developer experience).
Honestly we need more DX improvements in this industry. Especially look at DevOps - the user experience of Chef's output (I'm picking on Chef here, it's hardly the only offender) is servers and services, and the users (other engineers) consuming those outputs can have a nice time. The DX of using Chef, though, can be ughh....
It might be overused, that’s an opinion, I don’t agree.
I also hadn't had any coffee in way too long, so I have to admit I was a bit grumpy at the time of writing the comment :)
Nope, we need to roll back everything that happened in the last ~10 years. We at the very least need to stop sticking JS and the web stack everywhere. Use the right tool for the job, NOT pick up a shiny tool and try to do literally everything with it. NOT stumble upon solution and start looking for problems to it. Finally realize that software engineering is actual engineering that, like other forms of engineering, has a sizable impact on other people's lives. Unlike in other forms of engineering, the cost of a mistake might feel diminutive enough, but people do suffer trying to use modern software products. I wish I was joking.
Not really sure when to play around with these new frameworks if it's not giving me enough reason to switch, especially since they're not adopted in big tech companies it makes it harder to justify the usage when I want to build somethjing
> Next.js uses React to render your website. Astro is more flexible: you are free to build UI with any popular component library (React, Preact, Vue, Svelte, Solid and others) or Astro’s HTML-like component syntax which is similar to HTML + JSX.
> Both Next.js and Astro are frameworks for building websites. Next.js does best with highly dynamic websites (like dashboards and inboxes) while Astro does best with highly static websites (like content and eCommerce websites).
https://docs.astro.build/en/comparing-astro-vs-other-tools/#...
If you need backend api functions - https://github.com/serverless-nextjs/serverless-next.js/ AWS Lambda etc. Probably slightly more work I grant you.
I feel that this is what I was looking for https://docs.astro.build/en/concepts/why-astro/
This gives some more examples of what Astro offers https://twitter.com/matthewcp/status/1557103499724333057?t=8...
In fact Solid's creator has said Astro is probably the best way to do SSR with it.
And of course any framework where SolidJS can shine so bright is going to be the top of my list.
Congratulations on an amazing release.
The format looks identical to MDX
Open your browser devtools, pick a random tag on the page, add "client:load" to it, and then "console.log(yourEl.properties)"
I dunno why you need an entire custom filetype for behavior and semantics that are MDX with a few extra preprocessor rules
.astro is not actually like MDX at all. MDX extends Markdown, Astro does not, it extends HTML. MDX is a variant of JSX, Astro is not, it supports things that JSX does not like void elements. Astro supports text inside of script and style tags, JSX does not.
If you think you can rebuild Astro with "a few extra preprocessor rules", then by all means go for it. But you're going to fail.
Plenty of applications in the second category (logged-in admin dashboards, to-do lists, etc.) have been developed using server-first frameworks, and some of us still prefer to develop web applications that way. Is Astro missing any key features for dynamic server-first applications, e.g. form submission and validation support? If not, I think the Astro developers might be selling Astro and MPAs short.
That said, there’s quite a lot of space between that extreme and the mostly-static “web site” extreme, and I agree Astro would be a better fit than they let on, for a large chunk of that space. My suspicion is that this is intentional, to keep their current focus and explicit use-case commitments narrower. And I wouldn’t expect it to remain that narrow in the future.
Inevitably, when a new "hot" SSG comes on the scene, I try it, and then go back to compare it to the old "hot" SSG from 2 years ago. Yet, I can never get the old test site I set up running again without massive annoyances. This has happened multiple times.
As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run.
And like all SSGs, I see no mention of sane SEO defaults on the homepage. Let me guess--with Astro I'm going to have to set all of this up myself?
It's a static blog generator type thing, bit of a different concept to the framework posted. I've tried it a few times casually and it seems ok for non-devs to get something simple up and running. Bit of dev work can update templates etc
The SEO defaults aren't perfect but they're easy enough to change in the software.
[0] https://getpublii.com
Not sure how you'd get away from a build on updates though, it is called a static site __generator_. If you want to skip the build entirely, just write .html files and call it a day.
Commonly stated but not actually true. For example:
https://github.com/getzola/zola/blob/master/Cargo.lock
https://github.com/gohugoio/hugo (scroll to the bottom of the README)
Plus as sibling comment says you usually don't do anything but install hugo, `hugo [command]`
I don’t see a reason to switch a site from one to the other if you and any collaborators are comfortable maintaining the runtime. The same goes for JS based tooling (I imagine), I just don’t node so good.
Personally, I use Hugo for new projects because it lowers the burden for content collaboration.
Templating is weird in Go, though if you’re working on themes. I like it now, but it’s procedural vertically and LISPish horizontally, if that makes any sense.
Usually it’s just me or me and another guy messing with that, and others often unfamiliar with anything except Java contributing vanilla markdown documentation. “Clone the repo, run this binary” is helpful there.
But like sibling said, if you're happy with your setup, keep it.
I am experimenting with Caddy's template functionality [0] in my pursuit of making dependency-free and buildless websites. Caddy's templates are inspired by the Server Side Include (SSI) functionality in Apache and Nginx, except it uses Golang's syntax. I have made several websites in Hugo and find it pleasantly similar, only more bear-bones.
Although Caddy is serving static sites to the browser, it is technically more like using a dynamic scripting language like PHP on the server. I guess Caddy templates outperform PHP by a large margin because it is written in Golang and compiled, but I have never tested this hypothesis.
Funfact: Caddy's entire website is written with Caddy's template system and the source code is available [1] for those who want to take a look!
[0] https://caddyserver.com/docs/modules/http.handlers.templates
[1] https://github.com/caddyserver/website
You could write your own plugin that calls out to your WASM layer if you want, but I'm not sure we need that built into Caddy. It would be extremely niche, I think.
[0] https://www.11ty.dev/
My overall impression is: use 11ty for a first version, use Astro when you have more moving parts on the frontend.
Little bonus for those coming from Python background (like me): 11ty uses Nunjucks, which is a JavaScript port of Jinja, so the templating system feels right at home.
[1]: https://docs.astro.build/en/concepts/islands/
After spending a little time understanding Go templating it is really beautiful
Instead we spent a week researching how popular 3rd party themes did things, and made a hybrid. Then we moved away completely. I really wanted it to work for us and we were so close. Hugo is so fast and is brilliant on a couple of things.... but barely missed.
I can't remember exactly but with what we were doing we were going to be heavily dependant on their Scratchpad, which felt like a hack. It's all just hacks, and they like it. Lack of solid conventions, and they LOVE it.
My theme is so simple I think redoing it as themeless may be better
It's that theming structure that was a pain to figure out the first time for me
Also figuring out the variable structure took me a bit, but now the docs make sense to me.
My theme is super simple. A few templates, 1 CSS file, and a tiny amount of vanilla JS. I just let Hugo + CSS do most of the lifting.
I think some folks have had bad experiences with themes that layer a JS framework on Hugo, though. That may be a better case for a completely JS ecosystem.
There’s a lot of good options. That’s a good problem to have. Just use what you like, I guess.
Much of the interesting and useful tooling today is in the JavaScript ecosystem, that you will still have a package.json, Node dependency, etc. Except they are not Hugo’s problem, they arrived via a theme you are using, and they are your problem.
Hugo itself is a pretty lean template system. That means it doesn't know much about building websites. All kinds of things you hope it will know about (SEO, how to plugin analytics systems, much much more), are sitting over in themes in the ecosystem… tangled up with the axis of what visual appearance you want.
So the notion of swapping themes to swap appearance doesn't work, because the theme you picked provides a bunch of functionality in addition to appearance, and a different one will not have the same functionality.
This isn't a complaint, it is a good piece of work with many well-thought-out ideas. But it is pretty far from what the poster was looking for.
1. I've not yet had issues building old sites
2. Just in case you anticipate such issues you can just check the binary into your repo
https://gittup.org/tup/
https://github.com/kolypto/j2cli
That said, it may require a bit of javascript knowledge to get a more customized build running. It does have YAML configuration and a set of useful plugins you can use without touching code, from what I know.
Pin your dependency versions and never suffer this problem again! Shrink-wrap your node modules and don't even download them again! Use Yarn's offline cache to share package tarballs between applications to save on disk space!
There are many options for this problem. And that's just in the JS ecosystem. Use something Ruby or Go based and it's even better.
As far as I'm concerned, there's zero reason your landing pages and blog should require 3,000 dependencies to run.
Except there really, really is. A static site generator is really an optimizing compiler for 4 or 5 different languages (html, css, js, markdown, a template language, etc), with a build tool chain, and often image optimization, and a server for dev, and usually some sort of semi-opinionated structure that scans a directory tree and magically turns that into something you can just throw up to a web server and have a working website. They're complex systems pretending to be "simple and easy" because the output is essentially HTML with a few whistles.
You certainly can build a site generator with far less code, but when people want a lot of flexibility just by tweaking a JSON config file that necessitates complexity. And in JS, that means more packages.
The beauty of tooling is that there are lots of alternatives if you feel you want to optimize for dependencies instead.
If you don't want the trouble, don't chase the new hotness. Use what works until there's a compelling reason to switch.
Use Zola or Hugo. They have zero dependencies.
[1] https://code.up8.edu/pablo/cigala
The site has about 20 categories, and each category has about 100 images. Every time the team adds a new image or category, the deployment/building task clones the repo and then the build process generates all the optimally sized images again and then re-uploads multiple gigabytes to the host. Is there a way around this type of problem with static site generators?
[1] https://docs.npmjs.com/cli/v8/commands/npm-init
Exactly proving my original point.
Seriously, JS static website generators are the worst... use something written in any compiled language so you just download and run a single binary, no messing around with npm and millions of dependencies.
Take your pick here: https://jamstack.org/generators/
Ironically, Composer actually lists npm as one of its inspirations [1].
> "...Composer is strongly inspired by node's npm and ruby's bundler."
[1] https://getcomposer.org/doc/00-intro.md
Take a look for example at the rust installation steps [1]. They tell you to run the following command in your terminal: "curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh". They don't tell you to first make sure you have curl installed (or sh for that matter).
[1] https://www.rust-lang.org/learn/get-started
I agree; the "in any terminal" part is paternalistically redundant - any software developer who recognizes the npm command will know what to do with it.
This particular example isn't too bad -- looking at that line, it would be clear to me that I'm missing 'npm', and the solution is obvious -- find out what npm is, and get it installed. But the things that really bit me were tons of examples of JavaScript, which included strange lines like 'import', and I had no idea how to get my website's JavaScript to understand what an import is or any of the other syntax. Nothing would work! I didn't realise there was a whole ecosystem around how to build your code so that it can make use of these things. Every guide assumed I had things going, and I just didn't understand that I needed this other infrastructure in place first before I could do anything.
[1] https://peterxjang.com/blog/modern-javascript-explained-for-...
Some notes of things that have changed in the last five years:
- bundling is (almost) no longer needed for simple import/export as we now have a native module capability (esmodules). The biggest issue you’re likely to have here is waiting for any dependencies you have to upgrade from common js to esmodules.
- transpiling is not as necessary unless you explicitly have to support IE11, or require something in the latest ecmascript spec.
It really speaks to the maturation of front-end development that after five years that article is still fairly accurate.
About time too - I’m too old to put up with that level of churn anymore.
the reason node based documentation sucks so bad, is that generally by the time you read it, it's already deprecated.
s/
The big difference here (as with other JavaScript-based renderers) is of course the "use one tool/language for everything" aspect which to me is a bit of a 'meh'-benefit.
At this point, while all the renderers get better and simpler, we're still in a situation where complexity or writing code hasn't really gone away, it just shifted around to new places. Perhaps at some point we get to the HTML + WebComponents stage again (kinda like MDX and React mixing), and classic Apache Server-Side Includes become the new hot thing again.
That said, for most side projects and commercial projects the complexity may not be worth it. It probably makes the most difference to very high traffic sites where money is lost for each millisecond delay in giving you the page (or the ads). And in this sense it may be premature optimization.
I like using Next.js, but I often wonder if it is "too much" and adds complexity I wouldn't have otherwise. An old fashioned rails app, and some caching / CDN done in front of it as a separate concern is probably more than enough performance for most people.
You know what's old-fashioned way of doing this? Buy multiple VPS around the world and deploy website files using a script.
Let the experts deal with adding locations, location detection, DNS, redundancy and so on, for a very small price, relatively speaking.
I am not saying you need Astro: You can make the files yourself, then use a service like Netlify to do the CDN-ing for you.
That said, none of the static site renderers really do anything special that is required to do anything on any edge. Considering the huge amount of storage and memory required to store a node_modules tree and re-render on demand, even classic MVC would easily do the same.
What would make a somewhat larger difference might be a combination of factors; something like centralised push and distributed compute via WASM. That means any logic could be compiled and packaged as-is without needing anything else. Somewhat similar to using cloud flare workers with something like Go or Zig.
Then again, like you described with the rails example, this is mostly a solved problem. Even a full server-side view with just classic HTML 4 and CSS output can do this, at very low latencies and very wide reach. After the first hit, the difference between this and static pre-rendered pages is almost irrelevant.
The biggest 'solves' one might get would be uncached always-computed content which needs to be executed on demand, and attack surface changes. But that gives us a different class of problem since we could also decide to simply offload all of the hard work to someone else and simply pay Squarespace and the likes ;-)
But when I create a website now, I got to stick with Wordpress because they are easier to sell and non tech people can use it.
Or if you mean what was astro itself written in, I think this post is aimed at users of the system, not potential contributors. Personally I dislike it when when a post says something like "Hugo, a static site generator (Golang)" because it incorrectly implies you need to write Go in order to develop with it.
Simple to use, blazing fast results. JSX. Use another framework you like inside it (e.g. React, svelte).
> This vision of a better web is why Netlify is bullish on Astro
can't this horrible stock market and crypto bro lingo stay in the casino bubble.