Update on Next (Full SolidJS CSR Setbacks)

[n-ce]

Following up on my announcement #286 I wanted to share an update on the progress and some challenges I've encountered.

As you know, the plan involved using SolidJS for the core rendering logic of the application, moving away from the previous model which relied heavily on static HTML markup supplemented by individual Solid components. The goal was to leverage Solid's performance and reactive capabilities across a larger part of the application (specifically the area planned for /core).

During the development phase for this approach, I encountered some significant technical challenges, most notably a noticeable increase in memory consumption when SolidJS was tasked with rendering and managing a much larger portion of the UI compared to the original structure where 70% was static HTML. While SolidJS is highly performant and memory-efficient in many contexts, scaling its reactive runtime to manage such a broad area, replacing the browser's native handling of static markup, introduced a memory overhead that wasn't present before.

Furthermore, as I delved deeper into integrating SolidJS's reactive model and working with component instances beyond isolated components, I found that managing communication and state across the application created a layer of complexity that felt challenging to integrate seamlessly with the existing vanilla JavaScript parts of the codebase.

Due to these findings, I've been exploring alternative libraries that align with our core goals:

• Keeping a dominant vanilla TypeScript factor.
• Avoiding unnecessary complexity.
• Achieving efficient UI updates, memory usage, and small size.
• Enabling incremental adoption, fitting into our existing structure where a significant portion of the app is still handled by vanilla TS and static HTML.

One promising candidate that has emerged from this exploration is uhtml. It's a minimalist rendering utility that seems to integrate very well with vanilla code, has a tiny footprint, shows good performance and memory efficiency in benchmarks (including in non-keyed scenarios), and aligns with using a library primarily for rendering dynamic components within an existing structure. I've also found the syntax in the upcoming uhtml v5 particularly approachable and quite compelling!

My next step is to build a small, new application using uhtml to thoroughly evaluate its practical use, performance, and developer experience in a project context before considering it for the ytify rewrite.

I wanted to share this update for transparency and to keep everyone informed about the development path. The goal remains to build the most efficient, maintainable, and user-friendly application possible.