babel-plugin-macros VS astro

One of the more promising alternatives is twin.macro - a Babel macro that processes Tailwind classes to generate JS objects understandable by various CSS-in-JS libraries. The developer experience (DX) of using it is amazing as you not only get all of Tailwind’s features without much change to your code, but you also get much more flexibility - all that on top of the traditional benefits of CSS-in-JS. Here’s an example code:

For example with Babel you could use babel-plugin-macros to execute this file at compile time and replace the file contents with the result of the computation. So appSettings would only have the configs for the current environment and nothing more and your source wouldn't need to change much.

It does require babel-plugin-macros which should also help with keeping things nice and performant in production. The package is part of a larger initiative im trying to achieve which is to create file-system based routing for all mainstream React and React Native routing packages. I have done everything I can to keep it as boilerplate free as I can. To give an example

MacroError: The macro you imported from "undefined" is being executed outside the context of compilation with babel-plugin-macros. This indicates that you don't have the babel plugin "babel-plugin-macros" configured correctly. Please see the documentation for how to configure babel-plugin-macros properly: https://github.com/kentcdodds/babel-plugin-macros/blob/master/other/docs/user.md

Yes, it also does that. https://github.com/kentcdodds/babel-plugin-macros

babel-plugin-macros

I also wanted to try Astro for a while. I kept hearing it was great for content-heavy sites because of how little JavaScript it ships by default. A converter site felt like the perfect use case — mostly static pages with one interactive tool on each.

We use Astro because its islands architecture makes "zero JavaScript" the default instead of an optimization:

I simply searched for a Typescript Static Site Generator and Astro's name came up. I was already familiar with the name, just not what it does, so it was an easy choice. After going through the themes available with Astro, I chose the Astro Paper theme.

The short version — WordPress is a brilliant tool — it's also the wrong tool for a site that's nothing but articles, calculators, and a sitemap. Tinkernotes has no logins, no comments, no checkout, and no database it can't live without. So it's an Astro site built as static HTML and served from Cloudflare Pages. The result is a site that costs £0/month to host, ships almost no JavaScript, and can't be hacked the ways WordPress sites get hacked. If you're a WP dev sitting on a content project, this is the build I'd push you towards.

Astro for the shell

Astro supports all the features we need to make our content performant and easily accessible.

⭐ withastro/astro — 59,040 stars, 3,420 forks

I have been meaning to upgrade my personal site to Astro 6 for a while. The release notes sat in my open tabs for weeks, and every time I sat down to do it, I found an excuse to work on something else. This week, I finally ran out of excuses. I carved out an afternoon, ran npx @astrojs/upgrade, crossed my fingers, and expected a smooth ride.

Astro already supports dynamic endpoints that return binary responses. The Astro ecosystem also ships @resvg/resvg-js, a native rasteriser for SVG-to-PNG. Between those two things, every piece we need is already in the toolbox.