Live data from Hacker News

Astro 1.0 – a web framework for building fast, content-focused websites

astro.build

141–150 of 256 posts

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#141

Earlier quoted context omitted.

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.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#142

Earlier quoted context omitted.

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…

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.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#143

Earlier quoted context omitted.

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.

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.

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 ?

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#144

Earlier quoted context omitted.

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…

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.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#145

Earlier quoted context omitted.

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.

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

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#146

Earlier quoted context omitted.

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 use…

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.

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.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#147
One thing that's not too clear to me is if it's possible to use existing UI libraries. For example, to install Vue's Quasar component library I need to run

    import { createApp } from 'vue'
    import { Quasar } from 'quasar'
    app = createApp()
    app.use(Quasar)
But since astro abstracts away the root Vue application, I don't see how this is possible anymore.

Astro might make sense for a blog where you don't need a full blown component library but for any other web application, I'm skeptical of its capabilities.

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#148

How does Astro compare to QWIK https://qwik.builder.io/docs/overview ? Has anyone tried using both? It seems like they're both attempting to address the hydration problem from different angles

I haven’t done any serious work with either, but I’ve been following both closely (and have contributed a bit to Astro early on). So this isn’t the hands-on response you specifically asked for, and may not contain new information to you. I’m posting anyway in case it adds context for others.

Qwik City[1] is probably more directly analogous to Astro, Qwik being more analogous to Astro’s integrated renderers. But that highlights one of the key differences.

Astro’s compiler mostly focuses on server rendering of static content (.astro templates, MDX) and bundling client resources along with the logic necessary to hydrate islands. Astro defers to those renderers (and in some cases their own compilers) for any further optimization of the client bundle.

Qwik’s compiler optimizes the component code directly, serializing state into the HTML it renders server-side, for the client bundle to resume from that state. Its output is conceptually similar to Phoenix LiveView (which was mentioned in another sub-thread).

Both are compelling approaches. I think Qwik’s will probably (eventually) have an optimization advantage because that’s a core focus of the client library. Astro will likely have an adoption advantage because it’s client-library-agnostic.

Another framework in the space often gets passed over: Marko[2], which has been doing partial hydration for years at eBay. Marko is probably more similar in approach to Qwik (and as I understand it, getting more similar as they’re going resumable too), but like Astro has its own templating language which enables its compiler optimizations.

Also worth watching SolidJS[3] (whose creator has also worked on Marko), which is tracking partial hydration/resumability on its roadmap. I’m not sure what their approach will look like but there’s quite a lot of insight both in the issue and the creator’s tweets/replies on the topic.

Personally I think there’s a gap between all of these approaches which could leverage type-level analysis to go much further. But that isn’t really feasible when types being available or accurate isn’t a safe assumption.

1: https://qwik.builder.io/qwikcity/overview

2: https://markojs.com/

3: https://www.solidjs.com/

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#149
post #146

Earlier quoted context omitted.

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.

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

Re: Astro 1.0 – a web framework for building fast, content-focused websites

#150
post #72

Earlier quoted context omitted.

So they have moved all the previously frontend stuff to backend and output Hot-wired / Liveview / Livewire instead?

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.

Isn't that what Hotwire and StimulusJS is?
Post reply on HN