Why Build Another JS Framework?
Last year, creator Rich Harris and team overhauled Svelte so the team could incorporate “big ideas” into Svelte 5. Lawson’s issues with the Svelte 5 upgrade related to an emoji picker web component he created. While he said Svelte is a great framework and a pleasure to work with, a few things bugged him about the upgrade, specifically:
- It grew his emoji-picker-element’s bundle size by 7.1kB minified; and
- It dropped support for older browsers due to syntax changes; in particular Safari 12, which, he noted, is 0.25-0.5% of browsers depending on who you ask.
Lawson acknowledged these are relatively minor issues.
”Now, neither of these things really ought to be a dealbreaker,” he wrote. “7.1 kilobytes is not a huge amount for the average web app, and an emoji picker should probably be lazy-loaded most of the time anyway. Also, Safari 12 might not be worth worrying about (and if it is, it won’t be in a couple years).”
What He Built
Since his goal was a toy framework, he wanted to do the bare minimum to implement each foundational idea. He learned that the post-React frameworks all converge on the same three foundational ideas:
- Using reactivity — aka Signals — for DOM updates;
- Using cloned templates for DOM rendering; and
- Using modern APIs like
Proxy, which simplify the first two elements.
“Now to be clear, these frameworks differ a lot at the micro level, and in how they handle things like web components, compilation, and user-facing APIs. Not all frameworks even use
Proxys,” he noted in explaining his process. “But broadly speaking, most framework authors seem to agree on the above ideas, or they’re moving in that direction.”
What He Learned
While he was ultimately successful in building a custom, light framework for his emoji picker, he admitted that halfway through it, he felt stuck.
“I had a framework that worked, but it wasn’t really production quality yet,” he said. “So I thought that, maybe if the emoji picker rewrite fell through, I could still salvage the project as a blog post to help share what I learned.”
The first post detailed how he achieved each of the three foundational steps — and he thinks developers could learn from those steps.
“A lot of the concepts behind these frameworks were inherently interesting, and although there’s a lot of content out there trying to explain it, I didn’t feel like there was one single succinct summary of all the emerging patterns,” he said. “I do have to credit Ryan Carniato, though, who has a huge wealth of blog posts and video interviews on the topic, and who seems to have basically single-handedly shifted the frontend landscape with his work on Solid.js.”
Ultimately, the framework was successful in its planned goal: Providing a light footprint for the emoji picker component.
“This new framework is honestly only slightly more complex than what I sketched out in that [first] post — I ended up only needing 85 lines of code for the reactivity engine and 233 for the templating system (as measured by cloc),” Lawson wrote. “Of course, to get this minuscule size, I had to take some shortcuts.”
If he was going to release it into the world, he’d need to do more work to handle “a long tail of edge cases, perf hazards and gnarly tradeoffs,” he noted, but since it’s only designed to support one component, he felt he could afford to cut some corners.
“Building a toy framework is a useful exercise to learn how these things work under the hood,” Lawson told The New Stack. “And who knows: Maybe the next great framework author will start with something like the process in my blog post.”