I tired Astro but not for me. I was upgrading my personal website from Jekyll to Astro couple of years back. It was a steep learning curve with lots of folders. Things used to break all the time. Then I switched to raw html and css
Astro is a return to the fundamentals of the web
181–190 of 268 posts
Re: Astro is a return to the fundamentals of the web
#182Earlier quoted context omitted.
No, just a human getting tired of things I type online being thought of as LLM spam.
This sounds like what a bot programmed to engage in HN would do, honestly.
I thought I would have more opinions from ivory, gated towers tbh, and maybe a fatter bank account.
Re: Astro is a return to the fundamentals of the web
#183The Island concept is really exactly what php is doing since decades
Re: Astro is a return to the fundamentals of the web
#184> 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…
>e.g. The probably doesn't work at all without the JS that takes it over.
What a value!
I guess I may be chomping at the bit to be cynical, but I have quite a bit of experience in these fields, and I don't think Astro sounds especially transformative.
Re: Astro is a return to the fundamentals of the web
#185Earlier quoted context omitted.
> 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.
Yeah, not a huge fan of either either to be honest, but probably JSX slightly before Twig only because it's easier for someone who written lots of HTML.
Best of them all has to be hiccup I think, smallest and most elegant way of describing HTML. Same template but in as a Clojure function returning hiccup:
(defn template [user]
[:html
[:head [...]]]
[:body
(when (:logged-in user)
[:div "Hello " (:name user)])])
Re: Astro is a return to the fundamentals of the web
#186Earlier quoted context omitted.
What? Astro needs to run on a server that can run node etc And php can equally have its html cached.
> Astro needs to run on a server that can run node etc It needs to run on your computer to generate the HTML, but you can just run npm run build then copy the contents from the dist folder to your apache server, or whether you want to host it. At least, thats how I do it. I haven't used PHP for about 20 years so I'm sure its changed a lot.
But what you're describing could be done for php, or any other backend language/framework... There's nothing unique to Astro in this regard.
Re: Astro is a return to the fundamentals of the web
#187Earlier quoted context omitted.
Interesting. You can set up the server to respond with 200.html as the catch-all so the requests would return 200. There was some issue with it—can't remember what—which is why I switched to 404.html. After the initial load though the subsequent navigations would go through pushState so I think they'd be cached. But I don't see this is as big of a problem. With this I can switch and choose—SSR dynamic pages or use ha…
I tend to agree that you could come up with a solution using server-side catch-all and custom 200/404 routes - and actually I do, as I use nginx with a single line of try_files customization. But this is optional. It shouldn't be required to mess with the server config, if you want a static deployment. Besides, if you catch-all to a 200.html page, how would you serve 404s? Yes, you can integrate a piece of JS in the…
It doesn't really matter from user's point of view if the response is 200 or 404 if the end result is the same. This is just a rendered web page after all. But yeah, you can get stuck in the semantics of it but I personally just use what works and move along.
Re: Astro is a return to the fundamentals of the web
#188Re: Astro is a return to the fundamentals of the web
#189It'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 misunderstood you, but I did dynamic routes/pages for Next and Astro static builds. Using contentful or storyblok as a CMS, where the editor defines the routes and the components/bloks per page. Basically, the projects had one slug like [...slug].
Routes and Components per Page are dynamically created while export Next or build Astro static pages. In both frameworks you create the pages / slugs via getStaticPaths. And if ISR/ISP is enabled, even new pages (that are not known during build time) are pre-rendert while running the server.
In Next it is called dynamic routes[1] and in Astro dynamic pages[2]. Catch all slugs in Next and Astro are [...slug] e.g..
[1] https://nextjs.org/docs/pages/building-your-application/rout...
[2] https://docs.astro.build/en/guides/routing/#example-dynamic-...
Re: Astro is a return to the fundamentals of the web
#190Could someone compare it like I'm 5 to static site generators like Hugo, Jekyll? Does it make it easier to throw in necessary JS (e.g. for comments)? Thanks.
Coming from Go, I don’t enjoy working with the Go or other template engine, I have comparing various 3rd party Go template libraries, and settle down with JSX-like syntax, which is just way easier.
You should try it out, not comparing.