211–220 of 268 posts
I spent a small amount of time looking into Astro and I didn’t get the difference with the Fresh framework created by the Deno team.. ? Fresh does this Island architecture already, and benchmarks on Astro website dont include Deno+Fresh to compare. So I’m still wondering what’s the benefit of using Deno+Astro vs. Deno+Fresh
There are plenty of differences. Eg Fresh can only run on Deno and can only use Preact.
My personal website is written with Astro. I love it! Admittedly I'm still a little trigger-happy with my JS usage, but overall the ability to write templated pages and utilize islands that don't require big dependencies is the most friendly web development experience I've had. https://evklein.com
Earlier quoted context omitted.
It would be cheaper to hire a dev to update some content than to pay a wp host for 5-10 years.
I just did a search for "wordpress hosting" and picked one of the first results without shopping around, and the (clearly overpriced) plan I saw was $9.99/mo. In ten years that'd be $1200. A WP deployment on a simple shared hosting plan like that could run itself without needed a dev or sysadmin.
Maybe in some cases but that hasn't been my experience at all (or the experience of all the devs I know IRL).
Just a couple of weeks ago one of my clients installed a plugin which didn't allow users to log in.
> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…
>Traditional frameworks hydrate Dear God. In 20 years people will hire HTML experts as if they are COBOL experts today.
It's baffling to me why more SSR frameworks, Astro and NextJS namely, can't adopt static pages with dynamic paths like SvelteKit. So for example, if you have a page /todos/[todoId] you can't serve those in your static bundle and NextJS straight-out refuse building your app statically. Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in C…
I partly agree with you, but it is a design decision that comes with a drawback. A URL /todos/123 cannot be resolved in a SPA in a hard-reload. I.e. if a user were to bookmark /todos/123 or press reload in the browser, the browser would ultimately ask the underlying HTTP server for that file. As you mentioned, you would need a 404 page configured to fetch that - but that requires a configuration in the HTTP server (n…
> use query params: /todo?id=123. This solves all the quirks of the above solution, and is exactly what any server-side app (without JS) would look like, such as PHP etc.
We had PATH_INFO in virtually every http server since CGI/1.0 and were using it for embedding parameters in urls since SEO was a thing, if not earlier. Using PATH_INFO in a PHP script to access an ID was pretty common, even if it wasn't the default.
By way of example, here's a sample url from vBulletin, a classic PHP application [0] where the section, subsection, topic id, and topic are embedded into the URL path, not the query string.
[0] https://forum.vbulletin.com/forum/vbulletin-sales-and-feedba...
> Traditional frameworks hydrate entire pages with JavaScript. Even if you've got a simple blog post with one interactive widget, the whole page gets the JavaScript treatment. Astro flips this on its head. Your pages are static HTML by default, and only the bits that need interactivity become JavaScript "islands." Back in my days we called this "progressive enhancements" (or even just "web pages"), and was basically…
You're making the opposite mistake: you're seeing someone's description of a tool's feature and confusing it with the way we've already done things without even checking if the tool is transformative just because it kinda sounds similar. Astro's main value prop is that it integrates with JS frameworks, let's them handle subtrees of the HTML, renders their initial state as a string, and then hydrates them on the clien…
Edit: according to WP history, around December 2020
https://en.wikipedia.org/w/index.php?title=Hydration_(web_de...
Second edit: "Streaming server rendering", "Progressive rehydration", "Partial rehydration", "Trisomorphic rendering"... Seems I woke up in a different universe today.
Earlier quoted context omitted.
Care to explain? Astro is trying to position itself in opposition to things like Next.js or Nuxt wich are specifically marketed as application frameworks? And the architecture is more suited to something like a content site, because of the content collections, built-in MDX support, SSR, image handling, and server routing?
Sure, but maybe you need to go first. What do you mean when you say "a content site"? To me, "content" == "literally anything that resides in the DOM". But, clearly we aren't talking about that (I hope).
It's baffling to me why more SSR frameworks, Astro and NextJS namely, can't adopt static pages with dynamic paths like SvelteKit. So for example, if you have a page /todos/[todoId] you can't serve those in your static bundle and NextJS straight-out refuse building your app statically. Whereas with SvelteKit, it builds happily and does this beautiful catch-all mechanism where a default response page, say 404.html in C…