21–30 of 91 posts
if you keep your site on github, i found keystatic to be a really nice authoring experience: https://github.com/Thinkmill/keystatic
Thanks for the link. I prefer the simplicity of .mdx files for now. My use case is very basic and Astro already handles it well.
It’s very easy to build a static website with zero js, or pick the desired framework you want to work with.
Pair it with TypeScript and you get almost 100% type safe templating and resulting websites.
Astro is a step in the right direction. But I wonder why in 2024 we still have to deal with proprietary component languages? I would like something like Astro with web components. Perhaps with the help of lit. With this the pure markdown content could be easily enriched with components.
I even found standard declarative shadow dom style components to be a pain in the ass in Astro which left a bad taste in my mouth since that’s literally just stock standard HTML.
I remember going down a day long rabbit hole to understand why, and it boiled down to content layer, MDX and NextJS using different, incompatible module loaders, bundlers or transpilers of some kind[1][2][3]. Ridiculous. And don’t get me started on the image component.
In the end, Astro just works. No need for React (unless you want it), it’s simple, fast and produces a static site you can use without JavaScript.
Data fetching is also utterly trivial, so you can have a fully static site with “live” data pulled in at compile time.
I recommend it to anyone with frontend fatigue.
1. https://stackoverflow.com/questions/63957018/how-to-use-imag...
2. https://mmazzarolo.com/blog/2023-07-30-nextjs-mdx-image-sour...
3. https://github.com/contentlayerdev/contentlayer/issues/11
I am still not over the collapse of Gatsby (for reference i nearly joined the company in 2017, was saved only by my own character flaws). They rode the highs - being the default docs tool for React, and building a massive ecosystem of integrations you could install out of the box. But too many abstractions, divided goals between cloud and OSS, and the better stewardship/design of Nextjs brought it down. There were th…
It was truly a testament of times
I am still not over the collapse of Gatsby (for reference i nearly joined the company in 2017, was saved only by my own character flaws). They rode the highs - being the default docs tool for React, and building a massive ecosystem of integrations you could install out of the box. But too many abstractions, divided goals between cloud and OSS, and the better stewardship/design of Nextjs brought it down. There were th…
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking
I don’t love js/ts but Astro is so nice. Don’t have to fiddle with react or graphql. Just upgraded to 5 beta and nothing broke. Really well managed project. Oh, and page load speed is insane.
If you don't love js/ts maybe you'd like Civet, which transpiles to js/ts and has Astro integration. (No relationship, I've just been looking at it myself.) https://civet.dev
Earlier quoted context omitted.
Thanks for the link. I prefer the simplicity of .mdx files for now. My use case is very basic and Astro already handles it well.
keystatic supports editing mdx files. keystatic is basically a frontend to update files on github, so if e.g. you want to write a blog post from your phone it can let you do that kind of thing.
Earlier quoted context omitted.
I felt the same way! But I came around. Take a look at the source code for a component [1]. The .astro format is pretty much just TS, CSS, and HTML. I don't even need React anymore. Way less glue code and dependencies than with Gatsby. There is a configuration file and some abstractions for things like collections, but almost everything is opt-in. [1] https://github.com/jwngr/jwn.gr/blob/master/src/components/b...
It looks great, but that's a DSL I must learn and re-use nowhere else.
Earlier quoted context omitted.
My bet is on Remix (which will eventually just be React Router). I think it's just the right amount of abstraction over native web functionality with a nice, simple API that doesn't deviate too much from web standards. I also think the full stack approach just makes sense for developing on the web.
> which will eventually just be React Router how strongly do you believe this. because ive just read both docs and i think they have different goals/audiences (tho obviously same owner). i think react router will be a poorer project if it starts to require serverside components like it is looking