Learn More by Building Your Own Custom JavaScript Framework

This isn’t a story about yet another JavaScript framework. Or rather it is, but not in the way you’re thinking.

It can get a bit confusing and frustrating, keeping up with all the JavaScript frameworks. That’s part of the reason web developer Nolan Lawson (no relation) built his own framework — but he won’t be releasing it.

Why Build Another JS Framework?

Lawson works on the framework LWC, but he didn’t want to add yet another JavaScript framework to the plethora of existing ones. He wanted to perform a paired down experiment in creating a pared-down “toy” framework. Why?

“Part of it is that I work on a JavaScript framework, so I was doing basic competitive analysis of other frameworks to see which ideas we could pilfer,” Lawson told The New Stack. “The other part is that I had a side project, an emoji picker, which had been written in Svelte a few years ago, and I was a bit miffed about the Svelte v5 upgrade process, so I wondered if I could just write my own 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

Lawson wanted to build a modern post-React framework that was not server-first, similar to Lit, Solid, Svelte and Vue (as opposed to server-first frameworks such as Astro, Marko and Qwik, he added).

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:

1. Using reactivity — aka Signals — for DOM updates;
2. Using cloned templates for DOM rendering; and
3. Using modern APIs like template and 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.

His post provides a size comparison between the bundle with Svelte 4, Svelte 5 and the custom framework. The custom build managed to trim about 15% off the original Svelte 4 bundle.

Still, he doesn’t recommend every developer write a framework to ship to production, although he found building a toy framework to be useful in understanding modern JavaScript frameworks.

“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.”

Loraine Lawson is a veteran technology reporter who has covered technology issues from data integration to security for 25 years. Before joining The New Stack, she served as the editor of the banking technology site Bank Automation News. She has...

Read more from Loraine Lawson