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

91–100 of 268 posts

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

#91

Post by teekoiv »

dschuessler wrote: post #47
teekoiv wrote: post #20

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…

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

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

#93

Post by rubyfan »

skipchris wrote: post #58
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…

Agreed! Astro is fantastic, but the biggest barrier I had in learning it was getting my head around range of terms that developers who entered the workplace after 2010 have invented to describe "how the web works".

I really appreciate that innovation can sometimes reinvent things that exist out of pure ignorance and sometimes hubris. I’ve seen people turn mountains out of molehills that take on a lore of their own and then along comes someone new who doesn’t know or is a little too sure of themselves and suddenly the problem is solved with something seemingly obvious.

I’m not sure javascript islands is that but I appreciate a new approach to an old pattern.

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

#94

Post by diggan »

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.

> 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 yuckies, but seems like the same idea to me, just different syntax more or less. I'm not saying it was better back then, just seems like very similar ideas (which isn't necessarily bad either)

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

#95

Post by diggan »

Vinnl wrote: post #52
diggan wrote: post #21

Earlier quoted context omitted.

> Remember trying to debug with PHP on the frontend? I wouldn’t want to go back to that. I do remember that, all too well. Countless hours spent with templates in Symfony, or dealing with Zend Framework and all that jazz... But as far as I remember, the issue was debuggability and testing of the templates themselves, which was easily managed by moving functionality out of the templates (lots of people put lots of log…

Well, that's a way to manage server-side logic, but your progressively-enhanced client-side logic (i.e. JS) still wasn't necessarily easy to debug, let alone being able to write unit tests for them.

> but your progressively-enhanced client-side logic (i.e. JS) still wasn't necessarily easy to debug, let alone being able to write unit tests for them

True, don't remember doing much unit testing of JavaScript at that point. Even with BackboneJS and RequireJS, manual testing was pretty much the approach, trying to make it easy to repeat things with temporary dev UIs and such, that were commented out before deploying (FTPing). Probably not until AngularJS v1 came around, with Miško spreading the gospel of testing for frontend applications, together with Karma and PhantomJS, did it feel like the ecosystem started to pick up on testing.

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

#96

Post by omnimus »

rambambram wrote: post #66
api wrote: post #49

Earlier quoted context omitted.

This field (software) in general, and especially web stuff, has no memory. It’s a cascade of teens and twentysomethings rediscovering the same paradigms over and over again with different names. I think we are overdue for a rediscovery of object oriented programming and OOP design patterns but it will be called something else. We just got through an era of rediscovering the mainframe and calling it “cloud native.” Ev…

This. So much this. I'm not even 42 and I feel old when I read stuff like this. Like you say, there's no memory in the web software field.

Even if you are 10 years younger than you and youve been doing it webdev in your late teens you’ve seen like three spins of the concepts wheel to come back again and again.

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

#97

Post by teekoiv »

arminluschin wrote: post #36
teekoiv wrote: post #20

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’m also a big fan of static, and nextjs supports this: https://nextjs.org/docs/app/api-reference/functions/generate...

It doesn't. Those are executed build-time and you can't just set a wildcard so anything outside the given set results in 404.

As background, I wanted to make a PoC with NextJS bundled into a static CapacitorJS app somewhat recently and had to give up because of this.

You can try tricking NextJS by transforming the pages into "normal" ones with eg query parameters instead of path, but then you need complicated logic changing the pages as well as rewriting links. As you of course want the normal routes in web app. Just a huge PITA.

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

#98

Post by steve_taylor »

hasanhaja wrote: post #77
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.

> 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 How much of the frontend and how much of the backend are we talking about? Contemporary JavaScript frameworks only cover a narrow band of the problem, and still require you to bootstrap the rest of the infrastructure on either side of the stack to have somethin…

It can cover as much of the back-end that your front-end uses directly as you’d care to deploy as one service. Obviously if you’re going to have a microservices architecture, you’re not going to put all those services in the one Next.js app. But you can certainly build a hell of a lot more in a monolith that a personal blog serving a handful of .md files.

In terms of the front-end, there’s really no limit imposed by Next.js and it’s not limited to a narrow band of the problem (whatever that gibberish means), so I don’t know what you’re even talking about.

> How are we solving that today with Islands or RSCs?

Next.js/RSC solves it by loading JavaScript only for the parts of the page that are dynamic. The static parts of the page are never client-side rendered, whereas before RSC they were.

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

#99

Post by aswerty »

It's clear to me that the frontend conversation space is broken. Not even just the ecosystem being a mess.

Boiling down the conversation I see in the article, it just seems to be: the browser as a HMI vs the browser as a an application runtime. Depending on what you want to do one might be a better fit than the other. But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".

It's difficult to articulate the source of just how broken the discussion space is; nor have I made a particularly strong argument myself. But I think it's important to keep pushing back on conversations that position framework's like they are brands winning hearts and minds. Ala the fashion industry.

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

#100

Post by d42muna »

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.

That is a perfect description of it, released 1996. So far ahead of its time it’s not even funny. Still one of the best programming environments I’ve ever used almost 30 years later.

Post reply on HN