loading...
Cover image for Introducing the SolidJS UI Library

Introducing the SolidJS UI Library

ryansolid profile image Ryan Carniato Updated on ・4 min read

SolidJS is a declarative UI library for building web applications, much like React, Angular, or Vue. It is built using brutally efficient fine-grained reactivity(No Virtual DOM), an ephemeral component model, and the full expressiveness of JavaScript(TypeScript) and JSX. While understandably no one is really in the market for a new JavaScript UI library, Solid is exceptional, a true standout amongst its competition. These are the 5 reasons you should be at least aware of SolidJS.

1. It's the fastest...

Feb 2020 ResultsJS Framework Benchmark Feb 2020

Bold claim, and sure some small experimental renderers can pull better numbers in certain cases but Solid is a benchmark king. It's been at the top of the JS Frameworks Benchmark for over a year now, neck and neck with the most optimally hand-written plain JavaScript implementation. This includes surpassing the fastest low-level Web Assembly implementations and this is with a declarative UI library.

And I'm sure at this point you are like what about ____. Go take a look, everyone's there. Solid outpaces Inferno, LitHTML, Svelte, Vue 3.0, React, Angular, you name it.

2. It's the smallest...

Realworld Bundle SizeRealworld Demo Initial JS Bundle Size

While it won't win size in toy demos and benchmark where everything happens in a single Component, that honor probably goes to Svelte, when it comes to larger actual applications Solid has almost no overhead on Components (more like a VDOM library rather than a Reactive one). In so it scales exceptionally. For example, SolidJS currently is the smallest implementation of the renowned Realworld Demo. It's initial JS payload is 11.1kb. This implementation doesn't leave anything out using Context API and Suspense. Svelte's version is 33% larger at 14.8kb. Solid's compiler does a great job of managing tree shaking, its codebase built off the same powerful primitives as the renderer make the runtime small and completely scalable.

3 It's expressive...

Solid apps are built using JavaScript(TypeScript) and JSX. The compiler optimizes the JSX but nothing else. This means you have the full language at your disposal. You are not limited to premade helpers and directives to control how your view renders (although Solid ships with some). Neither Vue and Svelte offer this level of control. You don't get to rewrite v-for the way you write a component. With Solid if you don't like how <For> works, write your own. Solid's renderer is built on the same reactive primitives that the end-user uses in their applications.

Solid's reactive primitives manage their own lifecycle outside of the render system. This means they can be composed into higher-order hooks, be used to make custom Components, and store mechanisms. It is completely consistent whether working in local scope or pulling from a global store.

4 It's fully featured...

Solid still considers itself a library rather than a framework so you won't find everything you might in Angular. However, Solid supports most React features like Fragments, Portals, Context, Suspense, Error Boundaries, Lazy Components, Async Rendering, Implicit Event Delegation, SSR(although there is no Next.js equivalent yet). It supports a few things not yet in React like Suspense for Async Data Loading, and SSR with Suspense.

For the reasons mentioned above, it has taken less effort to develop these more advanced features with Solid given its reactive foundation. React clones like Preact and Inferno would require significant changes to their VDOM core to offer the same so it has been a much longer road. And the same is true with new directions React has been doing in its experiments as async rendering and multiple roots are trivial with Solid. In general Solid's approach lets it adapt easily, as it becomes a matter of granularity so it can apply similar diffing as VDOM libraries as necessary and not where it is not.

5 It's familiar...

import { createState, onCleanup } from "solid-js";

const CountingComponent = () => {
  const [state, setState] = createState({ counter: 0 });

  const interval = setInterval(
    () => setState({ counter: state.counter + 1 }),
    1000
  );

  onCleanup(() => clearInterval(interval));

  return <div>{ state.counter }</div>;
};

While a new UI library is supposed to jump out and break the mould. Solid doesn't stand out when it comes to API's or developer experience. If you've developed with React Hooks before Solid should seem very natural. In fact, more natural as Solid's model is much simpler with no Hook rules. Every Component executes once and it is the Hooks and bindings that execute many times as their dependencies update.

Solid follows the same philosophy as React with unidirectional data flow, read/write segregation, and immutable interfaces. It just has a completely different implementation that forgoes using a Virtual DOM.

Too good to be true?

It's the real deal. Solid has been in development for over 4 years. But it is still in its infancy when comes to community and ecosystem. I hope you agree there is great potential here. It's always difficult to stand out in an overcrowded space, and more so for Solid as it doesn't look very different on the surface. But I hope this article gives you insight into why SolidJS is secretly the best JavaScript UI library you've never heard of.

Check it out on Github: https://github.com/ryansolid/solid

Posted on by:

ryansolid profile

Ryan Carniato

@ryansolid

Frontend performance enthusiast and Fine-Grained Reactivity super fan. Author of the SolidJS UI library.

Discussion

markdown guide
 

I've been using this library for a big project at work and I much prefer it to React.

  • SolidJS has a cleaner API (though similar) than React.
  • It's reactive computation model is clean, simple and efficient.
  • It's easier to integrate 3rd party libraries with SolidJS than with React

Although for most of the app the extra speed did not change much, It did make a big difference for screens with large tables or large graphs (drawing dependency graphs with D3). I will be using it
again for another app that I'm starting now.

So my hat goes to you @ryansolid for this wonderful library.

 

Thank you for a gentle introduction to the library Ryan. I have a quick question about how being fast / slow affects the end user experience, pragmatically? Is it really perceivable to end users? There has to be boundary beyond which everything will be similar for an end user.

 

Thank you for taking the time to respond. I don't think that in general raw speed is very noticeable in typical cases on typical systems. There has been a decent amount of talk about bundle sizes and low power devices, and even there 10-20kb is only a couple hundred milliseconds. So what difference is it that say Solid renders a 5000 dom elements on a page 50ms faster than React on a Core I7. Sure it's more like 300ms on my Core I5 laptop. Realistically you are only going to notice this on initial load. And then maybe not. What's the difference between 1.4 seconds and 1.7 seconds perceptually? Almost nothing. In the Realworld Demo the gap between Solid and React Redux, the slowest library I tested, was only about 800ms on resource loading under 3G simulation and CPU throttling. Mind you TTI(Time to Interactive) differed upwards of 4 seconds.

Performance is an easy metric, only easier one is kb weight. I started working on Solid because I liked fine grained reactivity as found in libraries like KnockoutJS which had these patterns a decade ago. When I saw React basically copy it with React Hooks (and the Vue crowd finally acknowledge they had these primitives all along), I knew it was a good time to start promoting the approach as IMHO it is much better at doing very similar things by any metric. I created a library DOM Expressions to allow any reactive library(MobX, KnockoutJS, among others) benefit from my work but continued to develop Solid as the pinnacle of this approach.

So while I acknowledge leading with performance sort of cheapens it I hope that if anyone spends the time to look at Solid will see that we have a very well designed and thoughtful approach to effectively build user interfaces.

 

I really appreciate your work. Thank you.

It may be the best library to use if you want to make a declarative first-person shooter, where performance really matters if you want the best graphics and gameplay mechanics. :D

 

How does it work with legacy apps? The beauty of vuejs is that it can work nicely with apps that have html separated and generated by the server code and also support loading dynamic html to certain extent. When we moved from angularjs 1.x, vuejs was the only option with that kind of support.

 

I mean Vue does make that easy so it broadcasts it as a use case but any modern library is up to the task as you can set the entry point. You can have a statically rendered site in PHP and then have React control 5 independent parts of the page by importing the bundle and calling render after page load on those 5 locations. The reason I imagine we don't hear people talking about this is the build process. Vue lets you just import a script tag and start writing some components. Solid's Tagged Template literals allow you to skip the build process as well.

Here's a quick codepen of Solid with no compiler running completely in the browser. codepen.io/ryansolid/pen/KKprxBN.

Although I built Solid with modern browsers in mind. So without polyfills it is not supporting Internet Explorer. Obviously it's pretty easy to make a build with that in mind it just hasn't been a priority. Certain features like proxies are not easily polyfilled so they would not work in that environment anyway.

 
 

I wonder how it compares to lit-html

 

In what aspects? There are a lot of considerations. More than I highlighted in this article. I did look for a lit-html Realworld demo when I worked on a previous article but the only one I found was Lit Element + MobX which doesn't seem representative. In a handful of micro benchmarks I've done Solid is smaller but that is inconclusive. Pure performance definitely favours Solid as highlighted in the benchmark above. I've separately done benchmarks where I've shown even out of non-compiled tagged template approaches Solid's tagged template version is faster than libraries like lit-html lighterhtml etc... medium.com/@ryansolid/the-fastest-....

Of course there are other things that make comparison difficult as lit-html is a library designed to handle rendering and doesn't worry about components and state management so feature sets are not equivalent. Lit-html has close relationship with Polymer and supported by Google so already a huge leg up. The author also works closely with those working on standards so it is very aligned with the future of the platform. More stars on Github, larger community, and already stable 1.0 release all favourable. Definitely a good library to be looking at.