I'm a big fan of Astro, though I could see it being a bit more of an adjustment for JSX users than Svelte users since Astro's syntax was originally based on Svelte.
That said, JSX can be used easily with Astro as long as you get used to at least a bit of The `.astro` syntax for wrapper components and pages/layouts.
For all "have you tried ___" questions, the answer is the same. I've been trying all these new techs for the past 10-15 years, regularly, as soon as they come out, for the first few years with much with excitement, and later with disillusionment and less regularity.
Another user below said
> We've recently moved one service from next to Astro and it was just removing a ton of boilerplate and 'dance around' code.
And I get why it happens. When you first try out a new framework, you allow yourself to learn and add its inherent complexity, knowingly and intentionally. You say to yourself, "it's part of the dream, it's going to work out; there's a vision, just trust the process." This is true with literally all frameworks.
But they never deliver. The complexity is never worth it, and in the end, the intentionally added complexity is always intentionally and gladly removed when it becomes clear that it was unnecessary complexity. This is what I am glad to have learned so thoroughly that I no longer try to learn new frameworks when I initially see its complexity, imagine adopting it in view of my experience, and recognize that its almost always not worth it.
Look at the code on vanillajsx.com. Besides JSX and types, it's plain JavaScript and DOM manipulation. Translating it to document.createElement would add almost no lines of code. There's no unnecessary complexity. That's the whole point of the site. The simplicity of discovering and removing unnecessary complexity is wonderful and refreshing, and I think a lot of people agree.
I think you're misunderstanding the poster you quoted. They're indicating a positive experience with Astro.
> We've recently moved one service from next to Astro and it was just removing a ton of boilerplate and 'dance around' code.
---
> And I get why it happens. When you first try out a new framework, you allow yourself to learn and add its inherent complexity, knowingly and intentionally. You say to yourself, "it's part of the dream, it's going to work out; there's a vision, just trust the process." This is true with literally all frameworks.
I am quite picky and have strong opinions. I've used Astro for more than a year and still love it. There is complexity (especially if you use SSR), but for the use case of "I just want a static site" it is wonderful.
> Look at the code on vanillajsx.com. Besides JSX and types, it's plain JavaScript and DOM manipulation. Translating it to document.createElement would add almost no lines of code. There's no unnecessary complexity. That's the whole point of the site. The simplicity of discovering and removing unnecessary complexity is wonderful and refreshing, and I think a lot of people agree.
I don't disagree, but this doesn't replace what you might want for SSG. For one, this requires JS on the client. Astro compiles to static HTML despite using JSX-like syntax.
As an example, here's my Astro site and source code:
My framework (imlib[1]) is actually more of a framework akin to Astro than what's showcased on vanillajsx.com, which itself is built with imlib.
It just runs your code in a node.js process, and translates your JSX expressions into jsx() calls. On the node.js side[2], jsx() returns a string from its tag/attrs/children. On the browser side[3], jsx() returns DOM elements.
Combined with a little bit of architecture, it becomes something extremely well suited to creating static sites. I guess SSG is an outdated term now, maybe it's a framework? Or a platform?
In any case, it seems to do something similar to Astro, but in a significantly simpler way. The only "bundle" it needs in the browser is /@imlib/jsx-browser.js [4] which in itself is just jsx-dom.ts (its impl is overridable by the "framework" user). And on the node.js side, it's implemented as a very small "vm" of sorts [5].
I'm not against Astro, I just get all the same benefit people here are saying Astro has, but with orders of magnitude more simplicity imo.
I've used imlib to make a relatively large website [6], in fact imlib was developed as this website and extracted from it over the past year. I have absolutely no difficulty breaking down my site into various reusable and encapsulated JSX components, both on the ssg-side and the browser-side. Development time is lightning fast. IDE support is essentially automatic. The site loads instantaneously in the static parts, and as quickly as reasonable in the dynamic parts.
I like your thinking. Things have gotten far more complex than they need to be. We've been piling abstractions on top of abstractions for too long and there needs to be a culling. If we get rid something that we really did need, that's better than the alternative. It's best now to ditch it all and see what we really need.
As person who has been doing “react” since 2016 I would say that it removes so much of the “react” complex BS that I am surprised it is not x100 times more popular.
We’ve recently moved one service from next to Astro and it was just removing a ton of boilerplate and “dance around” code.
Oh, but you are moving out of React. And svelto IMO is waaay friendlier and "sane" than "typical" react. Svelte reactive model (observables and computed) are very friendly and simple to use.
