I'm a bit baffled by the focus on SEO on the latest frontend libraries.
Sure it makes sense if you're building a store or marketplace that needs to be publicly indexed, but for most web applications SEO is only important for landing page.
If I make an e-commerce page, I definitely want SEO on those products. Why not be able to use my framework of choice while also having SEO? Keep in mind these frameworks are used for making websites like blogs as well as web apps.
I have been using it for an app and it’s perfectly fine. It supports middleware and doesn’t do too much magic, less complicated and more straight forward than next and the alternatives
That’s the balance swinging the other way. Since React came into the scene SEO and accessibility have been afterthoughts, but that didn’t stop millions of static* websites being built with it.
It’s still not possible to do partial hydration with the majority of popular frameworks, Astro brings that back.
* sites that should’ve been static but were built as an SPA
A few of the most recent JS frameworks have been scooped up by by San Francisco VC funded companies, at some point they have to align with their funding's values (generating income).
I totally agree. All the frameworks that are “popping off” are mainly for marketing / blogs / e-commerce. None of them are a fit for SPAs or “web apps.”
Vite, an API service of your choice, and a static hosting platform is pretty much all you need for web apps.
It’s actually a big reason why I’m building https://pgs.sh — to cut through all the fat of publishing web apps. This doesn’t have to be anymore complicated than adding a public ssh key for production features.
My phone is middle-tier but it is new. This website has probably the worst scrolling performance I've ever seen while using this phone. Can only imagine the dozens of megabytes of JS it is downloading once the "zero-JS part for SEO" is done.
And the result is total frustration, because everybody else is designing on their M2 Macbook, so everything is frustrating to use.
I have an entry-level iPad from 2018 that crashes on most media-heavy websites, though I also blame Apple because it is obvious that every iOS release uses more and more RAM than the previous one. CPUs don't get slower as they age, but it certainly feels like it!
Even on my Macbook with Firefox the site has a strange feel when scrolling. It's not exactly struggling but it feels unnatural and slightly off/slow/uneven. Like it's on the edge of struggling. Bit hard to describe. The effect gets worse towards the mid section of the page with the side scrolling logo circles. I removed that section via dev tools which helped with performance. When I have that part of the page in view I get 80-90% CPU usage of one core. But even after removing it I can saturate a core by scrolling around, especially towards the lower part of the page.
It is indeed one of the worst optimized CSS I've seen in a while. Weird for a project that is all about speed.
Weird, for me it scrolls perfectly smoothly on Brave/iOS Iphone 8. I wonder where the difference lies ? (I intend to use Astro, so I'd better know beforehand)
That’s true, which is annoying when all you might want is simple CSR. For that use-case, I have found that Vite works very well these days. It is exceedingly lightweight and fast also. Check it out!
The focus has indeed been on SSR but Next is still good for SPA. If you're okay going off the popular main road there's SvelteKit, SolidStart, or QwikCity.
None. Regular HTML, along with React/Mithril/Vue/Svelte/Preact/your favorite library, used only in the places that need it. 90% of your site is static content and 10% is a graph ? Don't render your entire site with react, just the damn graph.
There is no need for those heavyweight libraries to sprinkle some interactivity. These days I do mostly server side on a sane language plus StimulusJS which is a small, composable layer 1/20th the complexity of React or Vue.
Personally, I really like svelte. Either use a bundler + js library for redirects OR SvelteKit with static adapter (https://kit.svelte.dev/docs/adapter-static). Fyi I use the latter since it's easier to setup and bit more trouble-free to use overall :D
And this is why we don't let people with absolutely no knowledge on benchmarking do benchmarks. This isn't measuring Next.js's performance, it's measuring the performance of sites that use Next.js. I could run my website on a bare metal server with a custom made, SIMD compatible, Assembly-written web server that only returns contents.html, if contents.html is 45MB including 32MB of tracking JS that has to run synchronously, my performance is going to be dogshit.
Proper benchmarks of Next would come from using the exact same site setup, the exact same resources served and comparing various sizes and complexities against other tools.
And I say this as a notorious Next.js (actually, *.js) hater.
Strong disagree on this one. We are talking about the difference between theoretical performance (what you COULD do) vs performance in reality (this is a dataset that measures all the various nextjs websites across the web and then compares them along well established benchmarks against the rest of the internet across time).
One of those two things is infinitely more valuable than the other.
So, if I were to make a website using Next.js that looks like, say, Tiktok but runs fast, would you take this as a positive point for Next ?
Or more simply: compare this to any other website using any other framework. Do you see similar trends ? Are they websites of the same complexity ? If so, why is your initial data set an indictment of Next.js, but not simply of the lack of care most web developers put in nowadays, coupled with "business needs" (read: Google Analytics) ?
The issue with "out in the wild performance" is that in the web world you will be reliant on 3rd party scripts which 9/10 times are not written to take advantage of some framework specific feature (since it'll most likely be written for under the hood functionality like tracking).
Instead it's better to do synthetic tests and then deduce which performance metric is important for my website.
This is why you are comparing it against every other site in the same situation. At the end of the day based on the data it’s entirely fair to say Next is not a framework known for producing anything other than substantially below average outcomes when it comes to performance.
I converted a couple of small content sites from Next.js to Astro. The generated code is way smaller, and the site is so much faster. I also found it much nicer to work with.
I can't comment on how they compare for more interactive app-like websites.
In case you haven't seen the latest versions of Next.js, it now includes React Server Components – which can operate in a similar fashion to Astro. You can send dramatically less client-side JavaScript.
I am a Jekyll user that has switched to Astro. I like it a lot, since it provides me with simple templating, bundling, out of the box TypeScript, and Tailwind support. It can do much more (like embed multiple UI frameworks) but I haven’t found the need yet. For anything simple like a landing page, this has become my go to.
I really wonder how do those frameworks creators earn for living?
And why are there so many even if there are competitors like next.js who obviously hold the market
Today, I'm not sure. But a few years ago, you raised VC money, gained a user base, used that to raise more money, and then ran a 10 person team on $20m for a while. I think the next step is a docker desktop move,or a hashicorp move where you offer a managed offering on top of your open source project.
There no doubt that writing a popular frameworks boosts your status which could make it easier to get a job at VC funded startups. Vercel hired the top devs working on React and the creator of svelte. Netlify hired the creator of solid.
Some rely on donations from companies that use their frameworks. Eg: Evan You (creator of Vue)
If every site did that then it would be harder to quickly spot one in a long list of tabs. A neat trick but I don't think it is a particularily good idea.
No, thank you. Make alternative favicons a standard, and let my browser handle it. Like the other comment says, if all of my icons went grey in a sea of 100 tabs, I'd be royally fucked. Google is already confusing enough with all their icons being basically the same.
The homepage is all hype, I'm still not sure what Astro really _is_. From clicking through to GitHub I know you install it with npm, so I guess it's written in JavaScript. I guess it's focused on browser side but for 'all in one's I'd expect something server side too?
It's a static site generator (that can also run SSR sites if you need to update pages fast - e.g. for ecommerce) for conent focused sites + a custom templating language that lets you use UI components from any framework.
we could infer it doesn't run anything client side nor server side, so it looks like a neighbour comment would be right, this homepage is all about a fancy way of describing a static site generator?
It's a framework like NextJS. It focuses on static content generation first but allows you to make small parts of the page interactive (JS rendered) instead of making whole pages JS rendered in order to facilitate some interactive widget in the corner (hence the name Islands Architecture).
It also has an ability to mix and match components from different frameworks on the same page/site. I think this is mostly a gimmick though, no one should be pulling in multiple frameworks for a single page or site.
Definitely not a gimmick; it's not that most teams would pull in components from different frameworks, it's that teams can add targeted interactivity using the framework of their choice on one shared templating framework that can run on the server per request or generated once on build.
Astro is really, really neat, IMO and suitable for use cases that are content focused but still require encapsulated areas of interactive components.
You wouldn’t use Astro with NextJS, but you absolutely would with react.
Astro is an SSR more tuned to generate static sites than SSR with hydration. It uses the islands architecture instead of full page re-hydration. So if you’re generating a static site with a few react components sprinkled in, it’s a good thing to use.
Because of the islands architecture, you can also mix and match component libraries. So one component can be react, one can be vue, one can be svelte, etc.
Next and remix are both less focused on SSG than Astro. A lot of people are making very content driven sites using react or Next—sites that aren’t really or shouldn’t be SPAs—and this is a great tool for content driven sites that don’t benefit from SPA-level interactivity (which is probably most sites using SPA frameworks)
How are Next and Remix less focused on SSR, I thought that was one of their main selling points? As well as static site generation. For example I use Next for a blog site that is SSG, works fine.
The islands architecture is interesting but in practice I doubt I'd swap between multiple component libraries.
Astro SSG and Next SSG have vastly different outputs. Astro's image component output is a prime example compared to Next with Astro being much, much cleaner. Astro's output in general is much cleaner, more streamlined, and less JavaScript heavy.
With the island architecture, it's not that you would switch between different architectures, but that you can choose which component framework you want to use on top of the same templating framework. Of course, you can mix and match, but that's not really the point.
If you haven't checked out Next.js in awhile, the next/image output changed recently. It's just an img tag now, basically setting srcSet automatically on easy mode, plus the automatic optimization of images. Most of the props or modifications you can use are native <img> features. It's similar to Astro (which is great!).
Next JS hydrates the entire page as a react component, so it's SSR on initial site visit and then navigating from there requires rendering (and maybe you'll use SSR to get some props).
Astro is actually an MPA that allows some client side components, so it only requires you to render on parts of the page. I prefer that for content heavy sites because I'm not sure how much interactivity I need.
This is Next.js in the "Pages Router" world (e.g. everything prior to 13.4). Past 13.4, you can also use the "App Router", which is kind of like a framework in a framework. It uses React Server Components, which can run server-only without hydration. Thematically similar to islands.
Remix is entirely SSR, so not sure what they meant. Next.js is static first, but definitely still supports dynamic. It started out as a dynamic, SSR framework.
Sorry, there was a typo. Astro is more focused on SSG than SSR. This is what happens when trying to comment on a phone keyboard first thing in the morning.
I’m unhappy to see HN become a place where people just promote their projects, but it’s good if those projects are technical and novel. Another web framework isn’t, especially when the homepage clearly aims at the purchasing department, offers no technical details and the framework itself is built by people who don’t know how CPU cache works, but still like talking about “performance”.
In two weeks nobody will remember this exists and everyone will fawn over the next web framework. When that happens, can we please not have it on the front page again?
It needs to be stressed ASTRO is firstly an SSG (Static Site Generator) and MPA (Multi Page Application) instead of an SPA (Single Page Application) focused.
With that said, from my experience with ASTRO is very similar to say vue or svelte in how you structure the code and template which I've come to like a lot more than jsx.
The biggest negative are more that if you do use other front-end library, you end up with two layers of where bugs can appear (astro + front end).
Also getting custom library express reliant stuff was a non starter for me at least.
“All-in-one” frontend framework designed for load speed.
This is the hype train forgetting where the data comes from. I’m pretty sick of it actually. This isn’t all in one, unless you’re thinking about all your frontend dependencies being able to be built together. It completely neglects these aspects of web dev:
- Security (the biggest one)
- Data exposure APIs (how do you expose and query your data? If you say flat files, I’m ashamed).
- Real-time is completely missing.
- still relies on other frontend frameworks like Svelte or React.
So, what, exactly is Astro other than YACC like Vite? And why do frontend devs insist they have an “all-in-one” framework when they clearly don’t?
> It doesn't have to. You can use it without any frontend framework.
Thus defeating it's claims to be an all-in-one framework. It should instead say "non-opinionated" framework.
Also, the frontmatter, this is exactly the kind of stuff that should be data driven, the kind of stuff an "all-in-one" framework would fetch from a data source, be it an API or a REST integration with a backend. This post on the deno blog explains it pretty well [1]. To me, someone who has been through the web 1.0, web 2.0, from notepad to IntelliJ/VSCode, an "all-in-one" framework handles:
- Content (bundler, rollup, however you need to figure it out. web fonts, icons, images, video, sass, less, css, jsx, js, tsx, ts, coffeescript... (sorry @jashkenas))
- API's (I need to provide data to my app beyond what you hardcode in a json, and don't make me fetch across origins).
- Data (I need to model my data somehow, and map that to my storage, or dependent apis)
- Real-time communications (I want to communicate between processes, between workers, between client and server, and between servers, beyond the long-poll).
- Simplicity (all of the above should be done in a way that makes it simple and easy to build web applications).
I really can't even parse what you're saying. Yes, frontend frameworks can't do everything a server connected to your database can. This doesn't change regardless of what you're using
I think you just did. The claim of being an all-in-one web framework is really just a piggybacking frontend framework with telemetry.
Before the crazy train of web frontend frameworks that promised to bundle all the things - there were a couple “all-in-one” web frameworks out there. Rails being one of them. That handled all of the above mentioned issues, until frontend went SPA/CSR crazy. Now we are coming back to the idea that SSR isn’t as bad as we thought it was. We can have our cake and eat it too with web components and hydration (silly rebrand of an old XHR html concept, but modern) and still have things like data modeling, API’s, security, communication, etc without having to farm it out across my domain origin.
The Firefox Mobile (Android) page is really slow which is ironic as they advertise speed prominently. iOS Safari and Android Chrome work great though...
Lots of comments confused about what Astro does, and apparently their homepage is not the best testament to its performance, so let me explain. (No affiliation, but I’ve used Astro and I really like it.)
Astro is a JavaScript framework for building content-heavy websites, like blogs and e-commerce stores. It can be used as a static site generator or rendering pages dynamically on the server, or a mix of both. You can use it with any JS framework — React, Svelte, etc — or none at all.
Astro also does SSR. I'd say that Astro is special in the ecosystem because (1) they went all-in on MPA and (2) they support many component frameworks.
Not really. I use it as a static site generator. You also can have it generate client-side JS. Look at what the sibling commenters are saying about island architecture.
I see it as an "hybrid or un-opinionated web framework" because it doesn't force you to adopt certain patterns, Islands Architecture is the sauce for UI components where they are solving in a way I see that jQuery, React, Bootstrap, Tailwind as a tool for solving complexity in our projects.
We get first-class speed and assets optimizers for free!
I don’t know why some people are hating in the comments, I’m assuming most are React devs and this is similar of C++ devs hating on Rust as they would like to be in business and not feeling left behind after all years spent learning the old tool (React/C++ in this situation)?
I’ve used Astro years ago, Astro+Solid is one of the best combo for building fast sites, I would choose that (or Sveltekit) over the trashy React any day if I would have to choose, or better, no javascript at all.
If I got a penny for every time someone points out an “irony” when it isn’t.
Hating on a new tool right off the bat without going on an extensive testing because you feel “threatened” that your knowledge in the old tool won’t be needed anymore, isn’t like when you (or in this case myself) dislike the old tool because of how cumbersome it is after actually using it for a while, and you try to avoid using it as much as possible. The only reason React is still around is because it’s popular and mostly are looking for jobs, but it’s definitely not the best nor the fastest out there.
Prefer svelte/kit. Simple and quick and just generates quite simple websites you might have written by hand about 10 years ago. And Rich Harris seems to be a decent guy.
hoo boy. Astro, I wish I didn't have to know you, but I am even gladder that I don't know the rest of the SSG tools out there.
I needed a project to really kick the wheels of Gen AI as a tool for executing projects. I compounded this choice, by asking a more experienced dev what tools he would learn if he got into web dev today. He suggested Astro and vercel.
Chat GPT ended up helping far less than promised. Also if you want to build a ship in a desert, its not going to ask why, its going to tell you how. Apparently doing design, code, content and art from scratch isnt the optimal way to go. Who knew?
I suspect its significantly easier to pick up if you are working on web dev every day. The point of jumping through additional hoops didn't make sense until it finally clicked.
Once you wrap your head around it, your components start to just work. Ideally like lego. Does make maintenance and management easier.
Either that, Or I am simply sufferring from stockholm syndrome. I don't know.
I did wish there were more templates to learn from.
It took a day to write my own Node.js static blog generator in a single script. The over architecture of Astro and other similar projects is absolutely epic.
First, read a bunch of static text files. Throw them all into RAM. This is amazingly fast. If you include meta data in the files, you don't need a database or JSON index. I use my own HTML document editor so I start with that and use JSDOM to parse and add in stuff like scripts or tags, but if you're an MD fanboy, that would be just as simple. I then use an EJS template to update the index pages and an RSS library to crank out a feed and an exec call to sync to my S3 server with a command to cloudfront to invalidate the cache. Its not even slightly optimized, and yet I would have to have hundreds of pages for this to take longer than 30 seconds.
If you have enough JS knowledge to use Astro, then you've got enough to write this sort of script.
138 comments
[ 5.1 ms ] story [ 196 ms ] threadSure it makes sense if you're building a store or marketplace that needs to be publicly indexed, but for most web applications SEO is only important for landing page.
It’s still not possible to do partial hydration with the majority of popular frameworks, Astro brings that back.
* sites that should’ve been static but were built as an SPA
Vite, an API service of your choice, and a static hosting platform is pretty much all you need for web apps.
It’s actually a big reason why I’m building https://pgs.sh — to cut through all the fat of publishing web apps. This doesn’t have to be anymore complicated than adding a public ssh key for production features.
And this page is a very poor sales pitch in that regard.
I have an entry-level iPad from 2018 that crashes on most media-heavy websites, though I also blame Apple because it is obvious that every iOS release uses more and more RAM than the previous one. CPUs don't get slower as they age, but it certainly feels like it!
It is indeed one of the worst optimized CSS I've seen in a while. Weird for a project that is all about speed.
The docs site from the Get Started link scrolls fine.
What frameworks would you recommend for building CSR apps?
But it seems the frameworks around it are moving more and more into the SSR direction.
https://preactjs.com/
Or you can try my toy one :D https://github.com/kevinfiol/umai
https://calendar.perfplanet.com/2022/mobile-performance-of-n...
what about APIs, rendering engines, technology stack, replacement for next/image… the juicy stuff…
Proper benchmarks of Next would come from using the exact same site setup, the exact same resources served and comparing various sizes and complexities against other tools.
And I say this as a notorious Next.js (actually, *.js) hater.
One of those two things is infinitely more valuable than the other.
Or more simply: compare this to any other website using any other framework. Do you see similar trends ? Are they websites of the same complexity ? If so, why is your initial data set an indictment of Next.js, but not simply of the lack of care most web developers put in nowadays, coupled with "business needs" (read: Google Analytics) ?
Instead it's better to do synthetic tests and then deduce which performance metric is important for my website.
I can't comment on how they compare for more interactive app-like websites.
https://github.com/withastro/astro/issues/8055
Unlike Next.js, Astro isn't shipping a tonne of JS to the browser just to display some basic content; it's really just HTML and CSS.
(To reiterate, this is a very simple content-based site)
https://nextjs.org/docs/getting-started/react-essentials#why...
Some rely on donations from companies that use their frameworks. Eg: Evan You (creator of Vue)
Are you not sure what a framework is? Or are you confused by there being different UI components and libraries?
Either way both are pretty easy to look up!
all-in-one (new oxford dictionary): "combining two or more items or functions in a single unit"
Astro
- can do SPA
- can do MPA
- can use a variety of different view libraries
- can write endpoints to serve any data
So is your ill-defined issue with "all-in-one" the fact that it doesn't support every single view library?
hmm, doesn't look like so:
> Leverage Astro's unique zero-JS frontend architecture
combined with:
> Deploy anywhere, even to the edge
we could infer it doesn't run anything client side nor server side, so it looks like a neighbour comment would be right, this homepage is all about a fancy way of describing a static site generator?
It also has an ability to mix and match components from different frameworks on the same page/site. I think this is mostly a gimmick though, no one should be pulling in multiple frameworks for a single page or site.
Astro is really, really neat, IMO and suitable for use cases that are content focused but still require encapsulated areas of interactive components.
here is the key page: https://docs.astro.build/en/concepts/islands
That second link is the only one I’ve seen that explains what Astro actually does.
Astro is an SSR more tuned to generate static sites than SSR with hydration. It uses the islands architecture instead of full page re-hydration. So if you’re generating a static site with a few react components sprinkled in, it’s a good thing to use.
Because of the islands architecture, you can also mix and match component libraries. So one component can be react, one can be vue, one can be svelte, etc.
Next and remix are both less focused on SSG than Astro. A lot of people are making very content driven sites using react or Next—sites that aren’t really or shouldn’t be SPAs—and this is a great tool for content driven sites that don’t benefit from SPA-level interactivity (which is probably most sites using SPA frameworks)
The islands architecture is interesting but in practice I doubt I'd swap between multiple component libraries.
With the island architecture, it's not that you would switch between different architectures, but that you can choose which component framework you want to use on top of the same templating framework. Of course, you can mix and match, but that's not really the point.
Astro is actually an MPA that allows some client side components, so it only requires you to render on parts of the page. I prefer that for content heavy sites because I'm not sure how much interactivity I need.
I’m unhappy to see HN become a place where people just promote their projects, but it’s good if those projects are technical and novel. Another web framework isn’t, especially when the homepage clearly aims at the purchasing department, offers no technical details and the framework itself is built by people who don’t know how CPU cache works, but still like talking about “performance”.
In two weeks nobody will remember this exists and everyone will fawn over the next web framework. When that happens, can we please not have it on the front page again?
With that said, from my experience with ASTRO is very similar to say vue or svelte in how you structure the code and template which I've come to like a lot more than jsx.
The biggest negative are more that if you do use other front-end library, you end up with two layers of where bugs can appear (astro + front end).
Also getting custom library express reliant stuff was a non starter for me at least.
https://astro.build/#:~:text=Learn%20more%20in%20our%20docs
Docs: https://developer.mozilla.org/en-US/docs/Web/Text_fragments
I wanted to refer to the "Full speed" section and ask why Nuxt has such a low score?
I hope this works anyway.
https://astro.build/#:~:text=Full%20speed
And the link totally works! (I have no clue on Nuxt though.)
This is the hype train forgetting where the data comes from. I’m pretty sick of it actually. This isn’t all in one, unless you’re thinking about all your frontend dependencies being able to be built together. It completely neglects these aspects of web dev:
- Security (the biggest one)
- Data exposure APIs (how do you expose and query your data? If you say flat files, I’m ashamed).
- Real-time is completely missing.
- still relies on other frontend frameworks like Svelte or React.
So, what, exactly is Astro other than YACC like Vite? And why do frontend devs insist they have an “all-in-one” framework when they clearly don’t?
It doesn't have to. You can use it without any frontend framework.
> So, what, exactly is Astro other than YACC like Vite?
Selling point of Astro is the partial / conditional hydration; they call it Island Architecture. This is not unique to Astro, though[1].
It also does some neat stuff with frontmatter [2].
The biggest turn-off for me though is that telemetry is ON by default and you need to manually switch it off.
[1]: https://github.com/11ty/is-land and https://github.com/ElMassimo/iles also offer Islands.
[2]: https://docs.astro.build/en/guides/content-collections/
Thus defeating it's claims to be an all-in-one framework. It should instead say "non-opinionated" framework.
Also, the frontmatter, this is exactly the kind of stuff that should be data driven, the kind of stuff an "all-in-one" framework would fetch from a data source, be it an API or a REST integration with a backend. This post on the deno blog explains it pretty well [1]. To me, someone who has been through the web 1.0, web 2.0, from notepad to IntelliJ/VSCode, an "all-in-one" framework handles:
- Security (authentication/authorization/using-standards)
- Content (bundler, rollup, however you need to figure it out. web fonts, icons, images, video, sass, less, css, jsx, js, tsx, ts, coffeescript... (sorry @jashkenas))
- API's (I need to provide data to my app beyond what you hardcode in a json, and don't make me fetch across origins).
- Data (I need to model my data somehow, and map that to my storage, or dependent apis)
- Real-time communications (I want to communicate between processes, between workers, between client and server, and between servers, beyond the long-poll).
- Simplicity (all of the above should be done in a way that makes it simple and easy to build web applications).
[1]: https://deno.com/blog/the-future-and-past-is-server-side-ren...
Before the crazy train of web frontend frameworks that promised to bundle all the things - there were a couple “all-in-one” web frameworks out there. Rails being one of them. That handled all of the above mentioned issues, until frontend went SPA/CSR crazy. Now we are coming back to the idea that SSR isn’t as bad as we thought it was. We can have our cake and eat it too with web components and hydration (silly rebrand of an old XHR html concept, but modern) and still have things like data modeling, API’s, security, communication, etc without having to farm it out across my domain origin.
https://github.com/withastro/astro/issues/8055
Astro is a JavaScript framework for building content-heavy websites, like blogs and e-commerce stores. It can be used as a static site generator or rendering pages dynamically on the server, or a mix of both. You can use it with any JS framework — React, Svelte, etc — or none at all.
By default, there is no client-side JS.
There are many static site generators around. Is there something that makes Astro special or different? What is its unique selling point?
Essentially it only pulls in the JavaScript it needs to make an element interactive; you can mix frameworks on the same page, and it's very fast.
https://docs.astro.build/en/concepts/islands/
We get first-class speed and assets optimizers for free!
Just like in the PHP 5 days
I’ve used Astro years ago, Astro+Solid is one of the best combo for building fast sites, I would choose that (or Sveltekit) over the trashy React any day if I would have to choose, or better, no javascript at all.
HN gonna HN.
> I’m assuming most are React devs ... hating
> ...
> I would choose that ... over the trashy React
The irony is palpable!
If I got a penny for every time someone points out an “irony” when it isn’t.
Hating on a new tool right off the bat without going on an extensive testing because you feel “threatened” that your knowledge in the old tool won’t be needed anymore, isn’t like when you (or in this case myself) dislike the old tool because of how cumbersome it is after actually using it for a while, and you try to avoid using it as much as possible. The only reason React is still around is because it’s popular and mostly are looking for jobs, but it’s definitely not the best nor the fastest out there.
I just don't agree that it's React devs being curmudgeons, I think that's just HN being HN.
So to me, your feelings are ironic, maybe in an Alanis Morissette type of way.
I needed a project to really kick the wheels of Gen AI as a tool for executing projects. I compounded this choice, by asking a more experienced dev what tools he would learn if he got into web dev today. He suggested Astro and vercel.
Chat GPT ended up helping far less than promised. Also if you want to build a ship in a desert, its not going to ask why, its going to tell you how. Apparently doing design, code, content and art from scratch isnt the optimal way to go. Who knew?
I suspect its significantly easier to pick up if you are working on web dev every day. The point of jumping through additional hoops didn't make sense until it finally clicked. Once you wrap your head around it, your components start to just work. Ideally like lego. Does make maintenance and management easier.
Either that, Or I am simply sufferring from stockholm syndrome. I don't know.
I did wish there were more templates to learn from.
I'm using Firefox.
In Chrome it's a bit better, but still not smooth.
I wonder what causes the lag - the page doesn't look complicated.
Anyone knows why? I was thinking about giving Astro a try but this looks like a deal breaker
https://github.com/withastro/astro/issues/8055
First, read a bunch of static text files. Throw them all into RAM. This is amazingly fast. If you include meta data in the files, you don't need a database or JSON index. I use my own HTML document editor so I start with that and use JSDOM to parse and add in stuff like scripts or tags, but if you're an MD fanboy, that would be just as simple. I then use an EJS template to update the index pages and an RSS library to crank out a feed and an exec call to sync to my S3 server with a command to cloudfront to invalidate the cache. Its not even slightly optimized, and yet I would have to have hundreds of pages for this to take longer than 30 seconds.
If you have enough JS knowledge to use Astro, then you've got enough to write this sort of script.