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

261–268 of 268 posts

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

#261

Post by hasanhaja »

aiiizzz wrote: post #254
hasanhaja wrote: post #252

Earlier quoted context omitted.

But don't you need to need to understand the platform you're building on, warts and all? How else can you fully grasp what's possible on that platform and the costs of different abstractions?

I don't think so. If your framework is high level enough, you've successfully outsourced the bad stuff to someone else.

But if you don't know the underlying platform, how can you be sure that your framework is high level enough or that it can do everything that's possible on the platform? You either have a framework with escape hatches (that'll require you to drop down to the bad stuff) or you have to wait until the framework catches up to the platform. Actually now that I think about it, React would fall in both camps.

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

#262

Post by aiiizzz »

hasanhaja wrote: post #261
aiiizzz wrote: post #254

Earlier quoted context omitted.

I don't think so. If your framework is high level enough, you've successfully outsourced the bad stuff to someone else.

But if you don't know the underlying platform, how can you be sure that your framework is high level enough or that it can do everything that's possible on the platform? You either have a framework with escape hatches (that'll require you to drop down to the bad stuff) or you have to wait until the framework catches up to the platform. Actually now that I think about it, React would fall in both camps.

You won't need to do "everything that's possible on the platform." You want to constrict yourself to the parts that work well.

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

#263

Post by kh_hk »

dannye wrote: post #237
kh_hk wrote: post #104

Earlier quoted context omitted.

Setting `client:load` and `client:visible` for (svelte) islands you want to run on the client ends up inlining script type modules all around the html. It looked like a big hack to me. On the positive side their use of web components is a nice bet.

>> On the positive side their use of web components is a nice bet. Web Components are a JavaScript/ECMAscript standard. So this is like saying: _Their use of Arrays is a nice bet_

Well I don't see other frameworks besides lit advocating for web components

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

#264

Post by jmloop »

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…

Oh no, go read about AJAX. You may be too young, there's no revolution here. I celebrate your curiosity, it's still a wheel. Changing the name it's still reinventing it.

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

#265

Post by zelphirkalt »

imilk wrote: post #259
zelphirkalt wrote: post #244

Earlier quoted context omitted.

And then come the WP plugin license fees, which easily quadrupel that cost, if not more. Just the other day I have seen a WP instance, that has >50 plugins installed, some of which cost 800 Euro per year. They are lock-in traps for hapless marketing and other non-technical people, who are convinced that they definitely need this super-duper plugin. And then come the legal fees for making the site actually conforming…

Well we have hosted 10 small business WP sites per $10 DigitalOcean droplet for the last decade. There are not additional plugin costs on any of them. And there has been no real maintenance needed. I'm not saying WP is great. Taking over a WP project from someone else can be daunting in tech debt and weird choices. But in terms of having a simple brochure website for businesses that get < 10k weekly visitors, it's pr…

Reality check: So you have no forms any user needs to input anything into, because if you had any, then you would need a spam protection, lest your customer gets tons of spam. Cheapest one is probably Askimet, but that costs money for a business. So either you are talking about little blogs, or not businesses. In any case, probably real small sites of purely informational character without user input, otherwise it would cost something. Or you are letting your customers get spammed.

No real maintenance? So either you let your PHP version and plugins become outdated, or you sooner or later have to fix things breaking. Maybe you simply did not notice any breakage, because you don't do maintenance for customers?

A brochure website? Does that mean people enter their e-mail to be sent a brochure? (Then paragraph 1 applies again) Or brochure meaning, that you merely display information on pages and that's it?

I think for small info sites what you describe can be true, but for anything slightly larger not, especially not for small businesses.

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

#266

Post by demetris »

aswerty wrote: post #99

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

> But the points it puts forward are fluff arguments like "it's a breadth of fresh air" or "it loads faster".

Fluff arguments do exist, but you can also measure. The site is static with minimal JS on the one page, and a bit more JS on the other page, so nothing surprising in the numbers, and nothing you can say was achieved thanks to the magic of Astro, but I wanted to shared them:

HOME PAGE

TTFB: .024s

SR: .200s

FCP: .231s

SI: .200s

LCP: .231s

CLS: 0

TBT: .000s

PW: 108KB

DEMOS PAGE

TTFB: .033s

SR: .300s

FCP: .281s

SI: .200s

LCP: .231s

CLS: 0

TBT: .000s

PW: 174KB

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

#267

Post by ffsm8 »

ASalazarMX wrote: post #218
hombre_fatal wrote: post #125

Earlier quoted context omitted.

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…

I'm sorry to go off-topic, but since when hydrating web pages with JavaScript became a thing? First time I've heard the term. 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.

Its definitely older. I remember hearing about it around a job I had in 2017-2020, but it was already an established term by that time.

Quote:

2013-2015: The concept of SSR in JavaScript frameworks emerged with React (released in 2013). Initially, it was referred to as "reconciliation" or "bootstrapping" — React would match the DOM with the virtual DOM.

2015: Around the release of React 0.14 and React 15 (2016), the term "hydration" began appearing in the React ecosystem to describe the process of attaching event listeners to server-rendered markup.

    The first known mention in React documentation and community discussions around 2015-2016 clarified that React would "hydrate" the HTML.

    This distinguished it from full re-rendering, which would discard the server-rendered DOM.

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

#268

Post by mediumsmart »

nchmy wrote: post #110
mediumsmart wrote: post #85

I have returned to the fundamentals of the web and there is no sign of Astro here let alone JavaScript.

What are you using?

html and css - rsync for deploy and jekyll for building. the last hurdle to leave js behind was the responsive nav toggle - that is now a page instead of an overlay and css driven.
Post reply on HN