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

Astro is a return to the fundamentals of the web

websmith.studio

Post reply on HN
Print view View original

161–170 of 268 posts

Re: Astro is a return to the fundamentals of the web

#161

Post by zelphirkalt »

hombre_fatal wrote: post #125
diggan wrote: post #10

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

What is the value in first sending dysfunctional HTML and then fixing it with later executed JS? If you do that, you might as well do 100% JS. Probably would simplify things in the framework.

Sending functional HTML, and then only doing dynamic things dynamically, that's where the value is for web _apps_. So if what you point out is the value proposition for Astro, then I am not getting it, and don't see its value.

Re: Astro is a return to the fundamentals of the web

#162

Post by paradox460 »

ksec wrote: post #120
archerx wrote: post #35

Earlier quoted context omitted.

I remember when it was called AJAX. We have completely lost the plot.

I remember it was called DHTML. ( And the code never works perfectly on IE and Netscape / Mozilla )

DynamicDrive my beloved

Re: Astro is a return to the fundamentals of the web

#163

Post by littlecranky67 »

teekoiv wrote: post #148
littlecranky67 wrote: post #127

Earlier quoted context omitted.

Not sure why you gave up. All you need to do, is use query params: /todo?id=123 and use `const { id } = useSearchParams()` in your code. Yes, the urls won't be that pretty, but I don't know if this is a road block. I have a NextJS webapp up and running that is 100% SPA (no SSR, full static export) and uses a C#/.NET REST Backend for data [0]. Works (almost) flawlessly. [0]: lockmeout.online

No. I disagree, you have to refactor all the pages from using [pathId] folder pattern and change all the links including switching to useSearchParams. It's just a huge change, especially if I want to keep the old routes in my web app.

Yes it would, and I can see with an existing app that it is work. But we are probably talking less than a days work? Not even using AI, but this is straightforward string replacements.

Re: Astro is a return to the fundamentals of the web

#164

Post by paradox460 »

steve_taylor wrote: post #30
diggan wrote: post #10

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

Back in your day, there wasn’t a developer experience by which you could build a website or web app (or both) as a single, cohesive unit, covering both front-end and back-end, while avoiding the hydration performance hit. Now we have Astro, Next.js with RSC, and probably at least a dozen more strong contenders.

WebObjects and ColdFusion come from the 90s

Re: Astro is a return to the fundamentals of the web

#166

Post by pier25 »

hasanhaja wrote: post #130
pier25 wrote: post #114

Earlier quoted context omitted.

Using old school template partials is a massive downgrade in dx compared to Astro components.

What about DX in terms of template execution speed? There are many implementations of template fragments on various platforms like Go and Rust [1], which might arguably perform better than their JavaScript counterparts. Wouldn't quicker execution give you a faster feedback loop when developing, and also give you a faster UX? [1] https://htmx.org/essays/template-fragments/#known-template-f...

> Wouldn't quicker execution give you a faster feedback loop when developing, and also give you a faster UX?

Yes, I've used stuff like Templ for Go or Razor Pages for .NET.

Even if the raw HTML rendering performance is significantly better, there are other factors to consider in terms of dx.

1) Most backend languages will not hot reload modules in the client which is what Vite gives you.

Very often the whole backend application needs to be recompiled and restarted. Even with something like the .NET CLI which does have a hot reload feature (and it's absolute garbage btw) the whole page needs to be reloaded.

PHP has an advantage here since every request typically "runs the whole application".

But even with PHP, JS and CSS assets do not have hot reload unless you're also running Vite in parallel (which is what Laravel does).

With Astro you can run a single Vite dev server which takes care of everything with reliable and instant hot reload.

2) With Astro you will get islands which are simply not feasible with any non-JS backend. Islands are so much more powerful than old school progressive enhancement techniques. When we were using eg jQuery 15+ years ago it was a massive pain to coordinate between backend dynamic HTML, frontend JS code, and CSS. Now with islands you can encapsulate all that in a single file.

3) You also get CSS co-location. Meaning you can write an Astro server component with its own CSS scoped to the particular piece of markup. Again, CSS colocation is a huge win for dx. These days I write vanilla CSS with PostCSS but with Astro it's trivial to integrate any other CSS workflow: Tailwind, SCSS, etc.

4) Finally, you have to consider bundling of frontend assets. I don't think it's an exaggeration to say that solutions like Vite are really the best you can get in this space. Internally it uses Go and Rust but it's all abstracted for you.

If you have a use case where you really need exceptional HTML rendering performance in a monolithic application, Astro (or really anything in JS) is definitely a bad fit. But you can easily run an Astro server app on eg Cloudflare Workers which could would work in many of those use cases too and reduce latency and adapt dynamically to load.

Re: Astro is a return to the fundamentals of the web

#167

Post by zelphirkalt »

diggan wrote: post #94
steve_taylor wrote: post #30

Earlier quoted context omitted.

Back in your day, there wasn’t a developer experience by which you could build a website or web app (or both) as a single, cohesive unit, covering both front-end and back-end, while avoiding the hydration performance hit. Now we have Astro, Next.js with RSC, and probably at least a dozen more strong contenders.

> build a website or web app (or both) as a single, cohesive unit, covering both front-end and back-end, while avoiding the hydration performance hit. Isn't that basically just what Symfony + Twig does? Server-side rendering, and you can put JS in there if you want to. Example template: [...] {% if user.isLoggedIn %} Hello {{ user.name }}! {% endif %} The syntax is horrible, and seeing it today almost gives me the yu…

I find that syntax more palatable than what is going on in JSX to be honest. I actually like having a separate declarative syntax for describing the tree structure of a page. Some languages manage to actually seamlessly incorporate this, for example SXML libraries in Schemes, but I have not seen it being done in a mainstream language yet.

Re: Astro is a return to the fundamentals of the web

#168

Post by shepherdjerred »

teekoiv wrote: post #91
dschuessler wrote: post #47

Earlier quoted context omitted.

Maybe I am misunderstanding you, but isn't this what Astro's `getStaticPaths`[0] function is for? [0]: ` https://docs.astro.build/en/guides/routing/#static-ssg-mode

Yeah, what the other commenter said. getStaticPaths still requires you to define the rendered routes build-time

https://astro.build/blog/live-content-collections-deep-dive/
Post reply on HN