[HN Gopher] Astro: All-in-one web framework designed for speed
___________________________________________________________________
Astro: All-in-one web framework designed for speed
Author : thunderbong
Score : 141 points
Date : 2023-08-13 09:13 UTC (13 hours ago)
(HTM) web link (astro.build)
(TXT) w3m dump (astro.build)
| jakelazaroff wrote:
| 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.
|
| By default, there is _no client-side JS_.
| cuu508 wrote:
| Thanks.
|
| There are many static site generators around. Is there
| something that makes Astro special or different? What is its
| unique selling point?
| mplewis wrote:
| Astro is really good at rendering JS on the server out of the
| box, while letting you quickly fall back to dynamic content
| as needed.
| steveklabnik wrote:
| I chose Astro for my personal website because these things
| all aligned with my thinking in this space and desires for a
| tool: https://docs.astro.build/en/concepts/why-astro/
| _puk wrote:
| A big thing is support for island architecture [0].
|
| 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/
| threatofrain wrote:
| 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.
| magic_hamster wrote:
| In other words, it's a back end framework in JS.
| jakelazaroff wrote:
| 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.
| kmlx wrote:
| how does this compare to nextjs?
| mhoad wrote:
| For all of its marketing hype, Next is actually kind of dogshit
| when it comes to performance especially compared to something
| like Astro
|
| https://calendar.perfplanet.com/2022/mobile-performance-of-n...
| kmlx wrote:
| thanks. from my experience performance is tricky at best of
| times.
|
| what about APIs, rendering engines, technology stack,
| replacement for next/image... the juicy stuff...
| ohgodplsno wrote:
| 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.
| mhoad wrote:
| 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.
| 0dayz wrote:
| 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.
| mhoad wrote:
| 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.
| ohgodplsno wrote:
| 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) ?
| monooso wrote:
| 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.
| archibaldJ wrote:
| Do they scorll badly on firefox though? Have you tested your
| site on firefox?
|
| https://github.com/withastro/astro/issues/8055
| willio58 wrote:
| Yeah this is a great use case for Astro from what I've seen.
| If you need more of an app, next js would be just fine
| heresjohnny wrote:
| 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.
| pibefision wrote:
| I agree. And it's faster than Jekyll in terms of building and
| exporting in Cloudflare, GitHub, vercel, etc.
| l5870uoo9y wrote:
| A Nextjs competitor sponsored by Nextjs and with its features
| being integrated into Nextjs.
| [deleted]
| intended wrote:
| 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.
| Obertr wrote:
| 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
| aatd86 wrote:
| They have a react job to fund their side-project (/jk) :o)
| revskill wrote:
| That's the best feature of React: To pay the bill.
| fyzix wrote:
| 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)
| maccard wrote:
| 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.
| promiseofbeans wrote:
| Eternally rasing more VC money. The core devs were previously
| snowpack and skypack, both VC funded that never got bought or
| sold a product.
| NullPrefix wrote:
| designed for speed but showcase page is jankier than an electron
| app
| archibaldJ wrote:
| Are you using Firefox? Or mobile devices? I'm trying to debug
| this issue too.
|
| https://github.com/withastro/astro/issues/8055
| Alifatisk wrote:
| I hate the fact that I cannot link to specific sections in the
| page.
| nmcfarl wrote:
| Scroll to text fragments are your friend (though they are not
| in Firefox yet):
|
| https://astro.build/#:~:text=Learn%20more%20in%20our%20docs
|
| Docs: https://developer.mozilla.org/en-
| US/docs/Web/Text_fragments
| Alifatisk wrote:
| Damn it, I am using FF. But had no idea about this feature, I
| hope it gets implemented soon!
|
| 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
| nmcfarl wrote:
| The feature is pretty awesome - I just learned about it
| myself last week.
|
| And the link totally works! (I have no clue on Nuxt
| though.)
| sebastianconcpt wrote:
| How does it compare when you SvelteKit versus Svelte on Astro?
| fyzix wrote:
| Sveltekit has ISR, form actions and e2e type safety.
|
| Not sure how astro handles middleware and cookies on the server
| side but SK's hook system is very powerful and intuitive.
| russellbeattie wrote:
| 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.
| go_discover wrote:
| I don't see why I would use this over remix
| promiseofbeans wrote:
| Gotta apreciate the way the page icon changes to monochrome when
| you switch away from the tab.
| ohgodplsno wrote:
| 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.
| eis wrote:
| 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.
| gabereiser wrote:
| "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?
| microflash wrote:
| > still relies on other frontend frameworks like Svelte or
| React.
|
| 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/
| gabereiser wrote:
| > 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:
|
| - 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...
| Capricorn2481 wrote:
| 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
| gabereiser wrote:
| 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.
| albert_e wrote:
| Abstractions all the way down!
| [deleted]
| uxcolumbo wrote:
| Anybody else experiencing really bad scrolling performance?
|
| 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.
| archibaldJ wrote:
| I'm experiencing the same thing in Firefox too.
|
| Anyone knows why? I was thinking about giving Astro a try but
| this looks like a deal breaker
| archibaldJ wrote:
| I just submitted a Github ticket; hope it is an easily
| solvable problem.
|
| https://github.com/withastro/astro/issues/8055
| amelius wrote:
| Designed for speed, not latency.
| [deleted]
| tamimio wrote:
| 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.
| [deleted]
| kunley wrote:
| Their page is unclear and slow as hell, while they claim
| they're clean and superfadt. So, bullshit detector ernt over
| the scale for a lot of people.
| c-hendricks wrote:
| > I don't know why some people are hating in the comments
|
| HN gonna HN.
|
| > I'm assuming most are React devs ... hating
|
| > ...
|
| > I would choose that ... over the trashy React
|
| The irony is palpable!
| tamimio wrote:
| >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.
| c-hendricks wrote:
| I agree about React, I use it at my day job and the
| ecosystem is huge, but Solid is winning my heart these
| days.
|
| 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.
| Medicineguy wrote:
| The Firefox Mobile (Android) page is really slow which is ironic
| as they advertise speed prominently. iOS Safari and Android
| Chrome work great though...
| [deleted]
| t8sr wrote:
| Why is another web framework notable?
|
| 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?
| brianolson wrote:
| 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?
| sph wrote:
| It's a framework for hype driven junior developers. They have
| the staying power of a mayfly.
| have_faith wrote:
| 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.
| CharlieDigital wrote:
| 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.
| jakelazaroff wrote:
| What if you have a bunch of code written in one framework and
| you want to do a gradual migration to another?
| [deleted]
| lloeki wrote:
| > I guess it's focused on browser side
|
| 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?
| Capricorn2481 wrote:
| No, it allows ssr and JavaScript components from any
| framework
| nsonha wrote:
| it's an implementation of the micro-frontend idea:
| https://micro-frontends.org
|
| here is the key page:
| https://docs.astro.build/en/concepts/islands
| schemescape wrote:
| Thank you! I've seen Astro referenced and praised many times,
| gone to the homepage, and clicked around, etc.
|
| That second link is the only one I've seen that explains what
| Astro actually _does_.
| promiseofbeans wrote:
| 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.
| rado wrote:
| Astro is an all-in-one web framework powered by your
| favorite UI components and libraries
|
| Clear as mud.
| c-hendricks wrote:
| Nah not really.
|
| 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!
| rado wrote:
| "all-in-one"
| c-hendricks wrote:
| Yes, that is what it says.
|
| 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?
| sergioisidoro wrote:
| 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.
| ricardobeat wrote:
| 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
| c-hendricks wrote:
| 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).
| Mandatum wrote:
| Most web applications are businesses reliant on income, which
| is also reliant on organic discovery and growth for new
| customers.
| satvikpendem wrote:
| 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.
| qudat wrote:
| 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.
| victorbjorklund wrote:
| Astro is probably a bad choice for an app. It shines in
| creating content heavy sites: blogs, marketing pages, etc
| kkarimi wrote:
| 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
| 0dayz wrote:
| 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.
| sureglymop wrote:
| 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.
| drowsspa wrote:
| My phone is literally struggling to even scroll through this
| page.
| arcanemachiner wrote:
| Half the reason I keep my mid-range 2018 Android phone as a
| daily driver, is as a litmus test to see how poorly-optimized a
| website is.
|
| And this page is a very poor sales pitch in that regard.
| [deleted]
| sph wrote:
| 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!
| drowsspa wrote:
| 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.
| resonious wrote:
| Same. Very ironic given how hard they're peddling speed.
| Capricorn2481 wrote:
| I have a phone from 2017 and I can't say this scrolls any worse
| than hackernews does. Certainly no issues on my new phone.
| mlok wrote:
| 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)
| conradludgate wrote:
| I noticed the same on Firefox mobile, but Chrome worked better
| [deleted]
| jcalve wrote:
| I noticed the same, what's going on? Too much complex CSS?
| starlevel003 wrote:
| It doesn't even smoothly scroll on my desktop.
| eis wrote:
| 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.
| pmontra wrote:
| Yes I came here to write that it scrolls atrociously. If people
| take the hint that this is how an Astro site performs, oops!
|
| The docs site from the Get Started link scrolls fine.
| k__ wrote:
| I'm not a fan of the SSR hype.
|
| What frameworks would you recommend for building CSR apps?
| TDiblik wrote:
| 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
| kmlx wrote:
| react with any bundler out there?
| k__ wrote:
| Big fan of React.
|
| But it seems the frameworks around it are moving more and
| more into the SSR direction.
| floydnoel wrote:
| 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!
| kmlx wrote:
| yes, i have a project that uses it. it's pretty great,
| fast too.
| threatofrain wrote:
| 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.
| [deleted]
| beeburrt wrote:
| Preact
|
| https://preactjs.com/
| junon wrote:
| Surplus, if you want something lighter weight than most
| frameworks.
| ohgodplsno wrote:
| 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.
| Capricorn2481 wrote:
| That's exactly what AstroJS does though. It just makes it
| easier. It's not a super heavyweight framework
| sph wrote:
| 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.
| satvikpendem wrote:
| What I don't understand about Astro is, if I use React or NextJS,
| why would I need Astro at all? What does it do that the JS
| framework doesn't?
| danabrams wrote:
| 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)
| satvikpendem wrote:
| 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.
| Capricorn2481 wrote:
| 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.
| leerob wrote:
| 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.
| Capricorn2481 wrote:
| Yes, these are pretty new though and I hear some people
| are having issues with the app router. Astro came before
| this release
| leerob wrote:
| 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.
| danabrams wrote:
| 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.
| CharlieDigital wrote:
| 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.
| leerob wrote:
| 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!).
| stevage wrote:
| As a full time front end developer, reading the front page I
| still had basically no idea what it is or does.
___________________________________________________________________
(page generated 2023-08-13 23:01 UTC)