Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

astro.build

Post reply on HN
Print view View original

231–240 of 256 posts

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

#231

Post by usrusr »

usrusr wrote: post #204
jackconsidine wrote: post #31

Earlier quoted context omitted.

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

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

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.

Apparently there has been quite a watershed moment, with the announcement merely a few months ago: https://astro.build/blog/experimental-server-side-rendering/

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

#232

Post by cercatrova »

dotancohen wrote: post #229
cercatrova wrote: post #227

Earlier quoted context omitted.

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

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

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.

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

#233

Post by acoard »

tomnipotent wrote: post #128
pbowyer wrote: post #92

Earlier quoted context omitted.

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

> and now have to try to generate a return Otherwise called running a business.

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.

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

#234

Post by zdragnar »

ricardobeat wrote: post #176
zdragnar wrote: post #152

Earlier quoted context omitted.

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

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.

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.

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

#235

Post by zdragnar »

9dev wrote: post #209
cercatrova wrote: post #182

Earlier quoted context omitted.

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.

But you’re aware JSX is just plain old PHP files, code intermingled with HTML? It’s the exact same thing, and it breeds the exact same bad behaviour.

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.

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

#236

Post by oneplane »

quickthrower2 wrote: post #156
oneplane wrote: post #59

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'-benefi…

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

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

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

#237

Post by eins1234 »

tomnipotent wrote: post #195
eins1234 wrote: post #142

Earlier quoted context omitted.

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

> so when they go to such lengths to cover it up 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. Sh…

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

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

#238

Post by aliswe »

CharlesW wrote: post #10

I'm looking at https://docs.astro.build/en/concepts/why-astro/ and I still can't tell what's interesting and unique about this as compared to other options in this space. 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…

forgive my ignorance but these front end based, non server rendering frameworks, how are they getting indexed by Google?

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

#239

Post by UlisesAC4 »

dfabulich wrote: post #108

Here's the link to their "Astro vs. X" page. https://docs.astro.build/en/comparing-astro-vs-other-tools/ They compare Astro to Docusaurus, Elder.js, Eleventy, Gatsby, Hugo, Jekyll, SvelteKit, Next.js, Nuxt, Remix, VuePress, and Zola. (For some reason, this page doesn't appear linked anywhere from their documentation's table of contents, and isn't even linked from the "Why Astro?" page. It's almost like they're trying…

I didn't really like that comparison as one big page. It is not complete at all.

As an avid user of Gatsbyjs I can say that people don't see that the graphql usage in that tool is the medium not the end for the sake of having graphql.

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

#240

Post by [deleted] »

acoard wrote: post #233
tomnipotent wrote: post #128

Earlier quoted context omitted.

> and now have to try to generate a return Otherwise called running a business.

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.

[deleted]
Post reply on HN