5 ms·

Just curious, have you seen Astro? I feel like it's the perfect SSG, but maybe you have some reservations that VanillaJSX solves.

newzisforsukas 2y ago
astro is nearly, if not as, "complex" as react, no?
- molszanski 2y ago
  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.
  - FractalHQ 2y ago
    That’s how I felt going from Astro to Sveltekit, but that’s a shorter distance to travel.
    - molszanski 2y ago
      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.
- shepherdjerred 2y ago
  It doesn't really make sense to compare React to a static site generator.
_heimdall 2y ago
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.
vips7L 2y ago
SSG?
- blackeyeblitzar 2y ago
  Static site generator, apparently
novocantico 2y ago
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.
- dimal 2y ago
  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.
- samtheprogram 2y ago
  So, I take it you haven't tried Astro then?
- shepherdjerred 2y ago
  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: * https://sjer.red/ https://sjer.red/ * https://github.com/shepherdjerred/sjer.red https://github.com/shepherdjerred/sjer.red

newzisforsukas 2y ago

astro is nearly, if not as, "complex" as react, no?

molszanski 2y ago
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.
- FractalHQ 2y ago
  That’s how I felt going from Astro to Sveltekit, but that’s a shorter distance to travel.
  - molszanski 2y ago
    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.
shepherdjerred 2y ago
It doesn't really make sense to compare React to a static site generator.

_heimdall 2y ago

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.

vips7L 2y ago

SSG?

blackeyeblitzar 2y ago
Static site generator, apparently

novocantico 2y ago

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.

dimal 2y ago
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.
samtheprogram 2y ago
So, I take it you haven't tried Astro then?
shepherdjerred 2y ago
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: * https://sjer.red/ https://sjer.red/ * https://github.com/shepherdjerred/sjer.red https://github.com/shepherdjerred/sjer.red