3 ms·

> still relies on other frontend frameworks like Svelte or React. It doesn't have to. You can use it without any frontend framework. > So, what, exactly is As

> still relies on other frontend frameworks like Svelte or React. It doesn't have to. You can use it without any frontend framework. > So, what, exactly is Astro other than YACC like Vite? Selling point of Astro is the partial / conditional hydration; they call it Island Architecture. This is not unique to Astro, though[1]. It also does some neat stuff with frontmatter [2]. The biggest turn-off for me though is that telemetry is ON by default and you need to manually switch it off. [1]: https://github.com/11ty/is-land https://github.com/11ty/is-land and https://github.com/ElMassimo/iles https://github.com/ElMassimo/iles also offer Islands. [2]: https://docs.astro.build/en/guides/content-collections/ https://docs.astro.build/en/guides/content-collections/

gabereiser 3y ago
> It doesn't have to. You can use it without any frontend framework. Thus defeating it's claims to be an all-in-one framework. It should instead say "non-opinionated" framework. Also, the frontmatter, this is exactly the kind of stuff that should be data driven, the kind of stuff an "all-in-one" framework would fetch from a data source, be it an API or a REST integration with a backend. This post on the deno blog explains it pretty well [1]. To me, someone who has been through the web 1.0, web 2.0, from notepad to IntelliJ/VSCode, an "all-in-one" framework handles: - Security (authentication/authorization/using-standards) - Content (bundler, rollup, however you need to figure it out. web fonts, icons, images, video, sass, less, css, jsx, js, tsx, ts, coffeescript... (sorry @jashkenas)) - API's (I need to provide data to my app beyond what you hardcode in a json, and don't make me fetch across origins). - Data (I need to model my data somehow, and map that to my storage, or dependent apis) - Real-time communications (I want to communicate between processes, between workers, between client and server, and between servers, beyond the long-poll). - Simplicity (all of the above should be done in a way that makes it simple and easy to build web applications). [1]: https://deno.com/blog/the-future-and-past-is-server-side-rendering https://deno.com/blog/the-future-and-past-is-server-side-ren...
- Capricorn2481 3y ago
  I really can't even parse what you're saying. Yes, frontend frameworks can't do everything a server connected to your database can. This doesn't change regardless of what you're using
  - gabereiser 3y ago
    I think you just did. The claim of being an all-in-one web framework is really just a piggybacking frontend framework with telemetry. Before the crazy train of web frontend frameworks that promised to bundle all the things - there were a couple “all-in-one” web frameworks out there. Rails being one of them. That handled all of the above mentioned issues, until frontend went SPA/CSR crazy. Now we are coming back to the idea that SSR isn’t as bad as we thought it was. We can have our cake and eat it too with web components and hydration (silly rebrand of an old XHR html concept, but modern) and still have things like data modeling, API’s, security, communication, etc without having to farm it out across my domain origin.

gabereiser 3y ago

> It doesn't have to. You can use it without any frontend framework. Thus defeating it's claims to be an all-in-one framework. It should instead say "non-opinionated" framework. Also, the frontmatter, this is exactly the kind of stuff that should be data driven, the kind of stuff an "all-in-one" framework would fetch from a data source, be it an API or a REST integration with a backend. This post on the deno blog explains it pretty well [1]. To me, someone who has been through the web 1.0, web 2.0, from notepad to IntelliJ/VSCode, an "all-in-one" framework handles: - Security (authentication/authorization/using-standards) - Content (bundler, rollup, however you need to figure it out. web fonts, icons, images, video, sass, less, css, jsx, js, tsx, ts, coffeescript... (sorry @jashkenas)) - API's (I need to provide data to my app beyond what you hardcode in a json, and don't make me fetch across origins). - Data (I need to model my data somehow, and map that to my storage, or dependent apis) - Real-time communications (I want to communicate between processes, between workers, between client and server, and between servers, beyond the long-poll). - Simplicity (all of the above should be done in a way that makes it simple and easy to build web applications). [1]: https://deno.com/blog/the-future-and-past-is-server-side-rendering https://deno.com/blog/the-future-and-past-is-server-side-ren...

Capricorn2481 3y ago
I really can't even parse what you're saying. Yes, frontend frameworks can't do everything a server connected to your database can. This doesn't change regardless of what you're using
- gabereiser 3y ago
  I think you just did. The claim of being an all-in-one web framework is really just a piggybacking frontend framework with telemetry. Before the crazy train of web frontend frameworks that promised to bundle all the things - there were a couple “all-in-one” web frameworks out there. Rails being one of them. That handled all of the above mentioned issues, until frontend went SPA/CSR crazy. Now we are coming back to the idea that SSR isn’t as bad as we thought it was. We can have our cake and eat it too with web components and hydration (silly rebrand of an old XHR html concept, but modern) and still have things like data modeling, API’s, security, communication, etc without having to farm it out across my domain origin.