Hi HN, I wanted to share my React/Vite micro-framework that I have been building for the past few years.

There is a lot of sentiment lately that React is becoming too unwieldy or complicated.

I agree, as I started using React when it was still marketed as the V in MVC. Lately, that isn't the direction that the React community seems to be heading, so I needed an alternative.

I had also grown weary of the constant major version updates to the routers available in React. The new versions introduced breaking changes, but my apps still worked the same before and after. It wasn't compelling updates, just pointless busywork.

I love to touch browser APIs directly, and I wanted to see how many lines of code it really took to build a router. It really only took a few lines of code. At that point I started fleshing it out for in my side projects and fixing issues.

The newest addition that I'm really excited about is the static site generator (the first version exclusively used prerender for SEO support, but it can be flaky for some providers). It is built as a custom Vite plugin, because the existing static site generation plugins didn't address my needs around routing, SEO, social previews, sitemap.xml, and robots.txt. I iterated with SEO tools and Google PageSpeed Insights until getting perfect 100 scores for both SEO and Best Practices categories.

I wanted to try some radical ideas with this project.

- Firstly was to prevent supply-chain attacks by keeping extra dependencies to zero. There are some testing dependencies and peer deps like React.

- I fit all of the router code into one JSX file, so users could easily vendor the code and customize it to their needs. This kept me from adding too much, quite a few times I had to cut back the scope to keep it focused. Of course I added a second file for the SSG portion, and there are lots of test files, etc.

- Another ideal I wanted to try was to stick with plain anchor tags for links. I didn't think the router should dictate user application architecture or constraints too much.

- I also wanted the library to cover everything a user needed to build a working site and have best practices for React without including dozens or hundreds of dependencies. Lots of little details went in to getting the feel right, such as scrolling back to the top on page transitions. We've all seen sites where changing pages leaves the user scrolled halfway down the new page. I wanted to avoid that amateur feeling wherever possible without requiring more work from developers.

- Maybe the most radical idea that I came up with was to ensure the sites were usable with Lynx and `curl`. I added a low-quality image placeholder (LQIP) processing step which means when you curl a page you can see the inlined base64 images in the html if you save to a file and open locally in a browser. With much thanks to `ffmpeg` for processing the placeholders during the build process.

One thing I'm still trying to figure out how to improve image sizes. The best practices are clear but how to accomplish the result with minimal work from the users is the hard part as I discovered while building so far. I tried processing an image source set myself but when the client hydrates it wipes out any changes I might put in the build, and the browser ends up loading the image twice. Image size is largely responsible for Performance category hits on PageSpeed, so if that could be solved it would be perfect. Seems like it will have to involve client code changes, but I'm going to keep working on ideas.

If this might be useful for you, please leave a comment or send me a message! I would be happy to answer any questions and help set your project up.