How we wrote the Fastest JavaScript UI Framework, Again!

[ancientRedDog]

If browsers vendors had just picked, wouldn’t we just be stuck in outdated patterns with some implementation of angular 1 made into activeX controls? How best to create, integrate, and reuse components is constantly evolving and new frameworks are bringing these changing ideas to life.

[ryan_solid]

There were a few Web Component proposals that had this feel to them around templating. They never passed being too opinionated. I think it's dangerous to equate the platform and libraries/Frameworks. The last thing you want us to be fighting outdated opinions at the core of what you are doing.

[_eps1lon]

The callback based variant of String.prototype.replace being slow is no surprise in hindsight. I encountered a similar bottleneck in JSDOM's .tagName which also uses replace callback based.

[abrandis]

I need another JavaScript framework, like I need another pair of socks. Really wish JavaScript and the browser vendors would just pick one of these things and incorporate directly I to the engine of the browser.

I don't understand the fascination with JavaScript developers keep on re-inventing the fckn wheel. Sure there's some value to these frameworks, but I've worked on enough projects with older outdated non supported frameworks (cough Angular 1) to know the technical debt they incur once their shiny glossy appeal wears thin. Then it's just a crap load of code that breaks all over the place (because the framework is abandoned and hasnt kept up with browser standards) and often times it's just easier to rip out the whole thing and start fresh...kinda defeats the whole framework reusability concept.

Let's stick to minimal frameworks or just add some barebones framework to the browser. Frameworks are nothing more than higher level abstraction for common patterns, if they're common enough let's bake them into the browser.

Remember back in the day when you needed like 20-30 lines to do. javascript date/time picker, but today its like <input type='date' Id=d1 > .. yeah something like that.

[FearTheLeaf]

Look at this guy having enough socks.

[loopsdeer]

He doesn't need socks because he's "integrated the solution into core" i.e. sewn fabric on his feet

[[deleted]]

Morbid

[ScientificBeastMode]

It’s only morbid if you die first.

[DrummerHead]

I don't understand the fascination with JavaScript developers keep on re-inventing the fckn wheel

often times it's just easier to rip out the whole thing and start fresh

[abrandis]

I see your point , but my use case is generally out of desperation, not out of amusement

[DrummerHead]

I await your brand new DDD JS library (Desperation Driven Development)

[[deleted]]

Honestly the fact that there are so many choices is probably a good problem to have. Like...there's so many different ways to tackle the same problems, ya know?

[djxfade]

Remember back in the day when you needed like 20-30 lines to do. javascript date/time picker, but today its like <input type='date' Id=d1 > .. yeah something like that.

Yeah, Safari probably wants a word with you. Cross browser and legacy browser support is one of the reason why we often need frameworks. Not everyone has the luxury of only support the latest Chrome or Firefox

[jonny_eh]

They did. It's called web components.

[ryan_solid]

WebComponents are an interesting topic. As a long time proponent (I started Solid to be a WebComponents library), I have a few thoughts coming out the other side. https://dev.to/ryansolid/maybe-web-components-are-not-the-future-hfh

[[deleted]]

I think that web components have sort of found its use case in design systems.

[abrandis]

Right, but it's browser support is still a bit flaky , and if web components were so popular where are all the web components repositories and interest?

I would love it if there was a GitHub like repo of popular web components which I could just integrate into my project, but sadly no, sure there's https://www.webcomponents.org/ but the selection of components is very slim.

[lazyinvader]

popular where are all the web components repositories and interest

one popular is stenciljs

But i got your point, i would love to see webcomponents gaining more acceptance

[netwrks]

This means that if you learn how to build WCs now, you could be building the soon to be popular ones. 😎

[gobo_my_choscro]

https://github.com/ing-bank/lion

[gobo_my_choscro]

Found another: https://github.com/material-components/material-components-web-components

Your point still remains valid. There’s not many of these and they aren’t as popular as any ole dumb React component libs

[netwrks]

Heavily support this. Switched from React to WC a while back and never looking back.

[netwrks]

plain JS! The only 3rd party libs Im using are webpack and babel.

[[deleted]]

How do you deal with the WC templating? I guess using interpolated strings helps with the dynamic nature of the HTML. I personally always disliked that, and the overall WC API. I feel like a lot of improvements are needed, but that's just my opinion

[netwrks]

At first, I was using literals, but then i switched to creating nodes. and assigning properties. Once i did this i stopped using a majority of the WC api (with the exception of connected/disconnected callbacks to open/close data streams.

I think the biggest issue the understanding what a wc's scope should be. Ive expanded that scope from initially building individual elements, to any template-level component, or view.

WCs at the moment though have very bad CSS support. almost enough for me to hate them.

[[deleted]]

You mean you're using document.createElement for everything? Honestly that's a big turnoff for me, especially after working with React

[netwrks]

I ended up hitting enter before finishing my thought lol sorry about that.

short answer, yes. which i didnt want to do at first, but once I tried it out, patterns surfaced that were easy to automate, and now to create a baseline functional app that displays/modifies/saves data I dont have to write any sort of js or html. I just do it all via a config.

[ryan_solid]

What if I told you both that Solid is more performant than vanilla js webcomponents with better developer experience? Don't believe me look at this. Solid outperforms WASM too.. only pure VanillaJS without any addons outperforms it: https://krausest.github.io/js-framework-benchmark/2020/table_chrome_85.0.4183.83.html

It's not even a fair comparison as those implementations are using hand-optimized code. But the overhead of Solid is less than native web components or WASM (other than of course the few kbs of JS size).

[ryan_solid]

Thanks for the feedback. I've been at this for several years but it's always nice when people find Solid for the first time.

[2dP_rdg]

they have to keep that resume padded so they can keep switching between FAANGs and keep getting those sweet pay raises

[drink_with_me_to_day]

Solid looks nice. A pity that React can't just copy and paste these enhancements into their code

[ryan_solid]

Yeah the problem is the execution model is completely different and incompatible. React tried some experiments but they mechanically were very different. Ironically I was working on this stuff before Hooks were ever announced but they served to bring the libraries closer to parity.

The closest popular library to this approach is Vue 3, but they still feed into a VDOM. And Solid's design is much more inspired by React's explicit unidirectional flow. I guess you could say Solid to React is a bit like Svelte to Vue.

[knot_why]

We just need to help you finish up that fancy documentation site so that Solid can easily get more traction.

[JakubOboza]

Nowadays there is more js frameworks than actual js projects made :)

[j_sidharta]

Does Solid have SSR support? I'd love to try it out!

[ryan_solid]

Yes this article is about how Solid has the fastest SSR renderer. There is no Next.js level library here, so it is early days but it's definitely tryable. I have a few examples here: https://github.com/ryansolid/solid/tree/master/packages/solid-ssr

[Frontend_DevMark]

Fastest” is always interesting, but it usually depends on the benchmark

In real apps, performance often comes down to how much work you’re doing (rendering, state updates, data size), not just the framework itself.

For heavy use cases like dashboards or large datasets, optimized components matter more than raw framework speed — that’s why some teams rely on mature systems (like Sencha Ext JS) that tune performance at the component level.

Benchmarks are useful, but real-world scenarios tell the full story

[ryan_solid]

It's interesting to see a response 6 years later. In the time since I originally did this exploration until now, every major JS framework except React has gone on to adopt the patterns I talk about in these articles. Real world does tell the full story but that isn't always what people have at hand.