8 ms·

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 A

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.

reilly3000 4y ago
Their homepage https://astro.build https://astro.build has a nice summary of its approach and benefits.
ksec 4y ago
So they have moved all the previously frontend stuff to backend and output Hot-wired / Liveview / Livewire instead?
- mwcampbell 4y ago
  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.
  - cercatrova 4y ago
    Isn't that what Hotwire and StimulusJS is?
  - quechimba 4y ago
    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.
  - floodfx 4y ago
    Check out https://liveviewjs.com https://liveviewjs.com
tannhaeuser 4y ago
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.
- 4m1rk 4y ago
  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.
- cercatrova 4y ago
  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.
  - tshaddox 4y ago
    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.
    - cercatrova 4y ago
      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.
      - acdha 4y ago
        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.
Existenceblinks 4y ago
> using a technology you may already be fluent in. 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.

reilly3000 4y ago

Their homepage https://astro.build https://astro.build has a nice summary of its approach and benefits.

ksec 4y ago

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

mwcampbell 4y ago
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.
- cercatrova 4y ago
  Isn't that what Hotwire and StimulusJS is?
- quechimba 4y ago
  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.
- floodfx 4y ago
  Check out https://liveviewjs.com https://liveviewjs.com

tannhaeuser 4y ago

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.

4m1rk 4y ago
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.
cercatrova 4y ago
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.
- tshaddox 4y ago
  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.
  - cercatrova 4y ago
    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.
    - acdha 4y ago
      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.

Existenceblinks 4y ago

> using a technology you may already be fluent in. 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.