Earlier quoted context omitted.
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).
Astro 1.0 – a web framework for building fast, content-focused websites
151–160 of 256 posts
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#152Earlier quoted context omitted.
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 ?
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).
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#153Earlier quoted context omitted.
Also out of the box: - Tailwind support - Optional choice of UI framework (React, SolidJS, Svelte etc...) - Partial hydration. Generates _actual HTML_ on the server-side rather than JS blobs (which is what some other frameworks call SSR). It really does work nicely. It's very fast, minimal config required.
As someone who started building web pages in the 90s, the "islands architecture" (generating HTML server-side) of Astro and others makes me laugh because it's literally what we used to do with XMLHttpRequest in IE 5/6 20+ years ago. We generated page partials (or used static ones) and pulled them in with "Ajax" (for the oldies out there) and then inserted them in the right place on the page using innerHTML. There's n…
And it's not quite the same thing - we're not talking about injecting server-side HTML snippets into other HTML pages (which never actually went away). This is more like optional, self-contained but fully-featured web applications that load after the full HTML renders. You could use that to fetch static HTML, or you could use it to provide an interactive client-side experience that only operates on a portion of the page, up to whatever complexity you like. And if the user has JS disabled the rest of the site still renders correctly.
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#154Earlier quoted context omitted.
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.
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#155I'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…
> 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/#...
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#156Sometimes 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…
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.
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#157Re: Astro 1.0 – a web framework for building fast, content-focused websites
#158Earlier 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.
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
Count: {state[:count]}
Increment
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.
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#159Earlier quoted context omitted.
> As long as you have npm installed it'll work. Exactly proving my original point.
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. Take your pick here: https://jamstack.org/generators/
Re: Astro 1.0 – a web framework for building fast, content-focused websites
#160Publishing with a SSG is so complex (and for many good reasons, as other comments mention). When anything gets this this complex, I pine for an end to end optimization targeting simplicity. And I don't think the static site generator is the driving force for complexity here. The web ecosystem really seems nuts when you step back. When it comes to publishing on the web, I would really like to see something simpler gai…
That same thinking is what led me to build [Primo]( https://github.com/primodotso/primo ) - a SSG in a desktop/server CMS. It’s the only thing me or anyone I know who’s uses it uses to build normal websites anymore bc it’s so much faster to get a site up and easier to write code/content.