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

241–250 of 268 posts

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

#241

Post by zelphirkalt »

diggan wrote: post #185
zelphirkalt wrote: post #167

Earlier quoted context omitted.

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)])]) Basica…

What you have written, that's what SXML is, basically.

Have a look at: https://www.gnu.org/software/guile/manual/html_node/SXML.htm... or https://docs.racket-lang.org/sxml/SXML.html

And as you say, part of the language itself, which means no need to learn something different, and no need to learn a pseudo-HTML or lookalike like with JSX, which then needs to be actually parsed by the framework (or its dependencies), unlike SXML, which is already structured data, already understood perfectly in the same language and only needs to be rendered into HTML.

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

#242

Post by zelphirkalt »

gbalduzzi wrote: post #171
zelphirkalt wrote: post #161

Earlier quoted context omitted.

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.

Dysfunctional HTML in the sense that interactivity is disabled, but visually it is rendered and therefore you can see the proper webpage immediately. Just compare the two cases, assuming 100ms for the initial HTML loading and 200ms for JS loading and processing. With full JS, you don't see anything for 300ms, the form does not exists (300ms is a noticeable delay for the human eye). With frameworks such as Astro, afte…

Usually I write my HTML and CSS also in a way that I write it once and can then reuse it elsewhere. I do that by employing traditional template engines like Jinja2 (in Python) or using SXML in Lisps.

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

#243

Post by zelphirkalt »

rob wrote: post #88
pentagrama wrote: post #67

But it has a CMS? The author said that replaced WordPress sites with Astro, and on https://astro.build/ I see a comparison to WordPress. Astro brings a friendly UI to maintain and update the sites? Like the WordPress panel and editor.

It doesn't, which is why all these solutions breakdown long-term compared to things like WP for small biz brochure stuff. 5 to 10 years from now when you're no longer talking to your client who has absolutely no technical experience, they're not gonna know that their website code is in some random GitHub repository that needs to be compiled with vite and then you need to magically wait for Netlify/etc to pull in your…

For a small business that simply displays an informational site, but occasionally needs to add content, a post on a blog or a change in the text or similar, it is sufficient to build a simple infrastructure of reading some markdown files and let them SFTP some markdown files and have periodic backups. One could also go as far as automatically committing those user uploaded files to a repo. None of which is difficult to do. It does get more complicated, if the small business wants users to be able to message them through the website, not just via e-mail. Or if the business suddenly wants to have a shop functionality on the site. Then CMSs start to slowly become an option.

Many medium businesses don't even need that btw. In many instances marketing people just want to have control over websites, that they should not be given control over, since they usually are incapable of knowing the impact of what they are doing, when they add something like Google tagmanager to their site. They also tend to often break things, when using Wordpress, because they do not understand how it works under the hood, so that side of things is also not without hassle. And then the devs are called to fix what marketing broke. Even with Wordpress. At that point it would often be easier to let the devs build a non-Wordpress site, and any ideas about things that are not just content in markdown files need to be requests for the dev team to evaluate, and possibly work on, when deemed safe and lawful.

Sadly the power dynamics in businesses are often stacked against conscientious developers.

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

#244

Post by zelphirkalt »

bogwog wrote: post #199
pier25 wrote: post #111

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.

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 with the law, such as GDPR. Those fees are increased, because of people wanting to do stuff they need to declare to visitors of the site, for which they want reassurance, that all is well.

And then come the costs for paying a dev anyway, to fix things that they break or that become broken over time.

So no, 9.99$/month are very very far from a realistic price these businesses pay.

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

#245

Post by evklein »

oblio wrote: post #238
evklein wrote: post #231

Earlier quoted context omitted.

Give it another shot. Azure static web apps are no bueno when it comes to reliable hosting...

The second shot didn't go well :-) Edit: Ah, finally, it loaded after about 30 seconds. Edit 2: Fairly neat.

From what I understand static web apps have a 'cold start' where if they haven't been touched in so long they get killed. I need to just add a function app that pings it periodically so it never goes down.

Thank you! Appreciate you sticking around and trying it again :) I am fairly proud of it, even in its simplicity.

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

#247

Post by gbalduzzi »

zelphirkalt wrote: post #242
gbalduzzi wrote: post #171

Earlier quoted context omitted.

Dysfunctional HTML in the sense that interactivity is disabled, but visually it is rendered and therefore you can see the proper webpage immediately. Just compare the two cases, assuming 100ms for the initial HTML loading and 200ms for JS loading and processing. With full JS, you don't see anything for 300ms, the form does not exists (300ms is a noticeable delay for the human eye). With frameworks such as Astro, afte…

Usually I write my HTML and CSS also in a way that I write it once and can then reuse it elsewhere. I do that by employing traditional template engines like Jinja2 (in Python) or using SXML in Lisps.

You don't have any complex interactivity than, and therefore this solutions does not apply to your use cases

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

#249

Post by demetris »

diggan wrote: post #17
thibaultamartin wrote: post #9

I can only approve. To me Astro started as "it's just html and css but with includes." I used it for my personal website, and recently used it when reimplementing the Matrix Conference website. It's really a no-fuss framework that is a joy to use. Among the things I love about Astro: - It's still html and css centric - Once built, it doesn't require js by default - You can still opt-into adding js for interactivity h…

> - It's still html and css centric - Once built, it doesn't require js by default - You can still opt-into adding js for interactivity here and there I've never used Astro so forgive my ignorance, but isn't that just creating a .html file, a .css file and then optionally provide a .js file? What does Astro give you in this case? You'd get the same experience with a directory of files + Notepad basically. It's also e…

> I've never used Astro so forgive my ignorance, but isn't that just creating a .html file, a .css file and then optionally provide a .js file? What does Astro give you in this case? You'd get the same experience with a directory of files + Notepad basically. It's also even more optimized for speed, since there is no overhead/bloat at all, including at dev-time, just pure files, sent over HTTP.

Astro is super for completely static stuff too. Sometimes static stuff can be complex and there a modern framework like Astro shines.

I will share a couple of files to explain.

The site is almost completely static. It serves minimal JS for:

(1) Prefetching (you can block that and nothing will break)

(2) Mobile menu (you cannot make an accessible mobile menu without JS)

The site is for the docs and demos of a JS library. I want many demos on it, to be able to see what patterns the lib can handle and where things break down. I want to be able to add/remove demos quickly to try ideas. Straight HTML written in index.html files would not allow me to do that (but it is fine for the site where I have my CV, so I just use that there).

This is the Astro component I made that makes it super easy for me to try whatever idea I come up with:

https://github.com/demetris/omni-carousel/blob/main/site/com...

Here is one page with demos that use the component:

https://github.com/demetris/omni-carousel/blob/main/site/pag...

Basically, without a setup like this, I would publish the site with 3 or 4 demos, and I would maybe add 1 or 2 more after a few months.

Cheers!

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

#250

Post by hasanhaja »

steve_taylor wrote: post #98
hasanhaja wrote: post #77

Earlier quoted context omitted.

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

There are a lot of moving parts when building an application and the abstractions that Next.js provides doesn't cover the same stuff when compared to frameworks like Ruby on Rails, Django and Laravel. The narrow band of problems Next.js solves for you are things like data fetching, routing, bundling assets and rendering interactive UI. It leaves things like auth, interacting with a database, logging, mailing, crons, queues, etc up to you to build yourself or integrate with 3rd party services. When you work with one of those frameworks, they pretty much solve all of those problems for you and you don't have to leave the framework often to get things done.

This is fine generally because you have the choice to pick the right tool for the job, but in the context of "a single, cohesive unit" you can only get that with Next.js if you all that you care about are those specific abstractions and want your backend and frontend to be in the same language. Even then you run into this awkwardness where you have to really think about where your JavaScript is running because it all looks the same. This might be a personal shortcoming, but that definitely broken the illusion of cohesion for me.

> The static parts of the page are never client-side rendered, whereas before RSC they were.

Didn't the hydration performance issues start when we started doing the contemporary SSR method of isomorphic javascript? I think Islands are great and it's a huge improvement to how we started doing SSR with things like Next.js Pages Router. But that's not truly revolutionary industry wide because we've been able to do progressive enhancement long before contemporary frameworks caught up. The thing I'm clarifying here is the "before RSC" only refers to what was once possible with frameworks like Next.js and not what was possible; you could always template some HTML on the server and progressively enhance it with JavaScript.

Post reply on HN