DEV Community

Cover image for Introducing the SolidJS UI Library

Introducing the SolidJS UI Library

Ryan Carniato on March 26, 2020

SolidJS is a declarative UI library for building web applications, much like React, Angular, or Vue. It is built using brutally efficient fine-grai...
Collapse
 
macprogguy profile image
Eric Methot

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.

Collapse
 
prateekprshrnith profile image
PRATEEK PRASHER

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.

Collapse
 
ryansolid profile image
Ryan Carniato • Edited

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.

Collapse
 
prateekprshrnith profile image
PRATEEK PRASHER

I really appreciate your work. Thank you.

Thread Thread
 
trusktr profile image
Joe Pea

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

Thread Thread
 
devinrhode2 profile image
Devin Rhode

Svelte seems quite interested in smooth animations, I think that plays into Solid quite well too. I wonder how animations would be best written in solid and how that compares to other frameworks and their popular animation libraries.

Funny enough, I think Solid+Dart could steal some thunder from Flutter. Flutter is just gross, but, Dart is pretty nice TBH. Unfortunately there is the compiler aspect here, so it wouldn't be easy, but at some point any framework needs some answer to Native apps, in some way. NativeScript is interesting but Dart's VM is like WOW amazing. But then you inevitably see Flutter code and I just see all the horrors of Angular+OOP all over again.

Thread Thread
 
ryansolid profile image
Ryan Carniato

I was looking at NativeScript a little. Only my JSX is compiled so it's a matter of figuring out how to best output NativeScript from it. But.. yeah I haven't dug deep at all. If people are interested I'm sure things will go there. I've been a web first guy myself mostly (although I've created and supported a React Native app). I was secretly hoping PWAs would gain more ground quickly by the time I needed to worry about this. But doesn't quite seem like it.

Animations is a place I will need to do more work. Svelte has figured out how to compile it into the template. I can do some similar stuff here but I have less explicit hooks. Svelte basically constructs a minimal lifecycle based components that it uses to anchor different stages of a components life. Solid doesn't really acknowledge components exist and relies on the scheduling of the reactive system. So far I've created solid-transition-group which basically copies React or Vue's equivalent. I've done a few other simple demos with animations but as you can imagine they work today very similar to how they'd work in React or Vue. Using state changes to drive CSS or Web Animations or what ever library you want to use. It definitely isn't as packaged in as Svelte.

Thread Thread
 
devinrhode2 profile image
Devin Rhode

I actually don't know all that much about how Svelte does animations, only that animating in svelte was nice. I think mimicking the age old transition-group is great, since it's easier to migrate from react (idk what else people use for animating in react, again, not super well researched on animation libs).

Any thoughts on Dart in general? I've been envision TypeScript as a bridge to Dart, to be honest. I guess I don't know how to gradually convert a codebase to Dart, but my sense is that once you are comfortable with typescript, if you see the Flutter/Dart demo's, it's quite an appealing option over TypeScript. "Add these types, with a syntax built into the language, and get all these extra benefits of faster experience everywhere (super fast hot reloading, AOT compilation, etc)"

It'd be really great to be able to use Flutter Components inside a theoretical Solid.dart, but there might need to be a Flutter-Solid connecting thing akin to react-redux. I'd imagine that any level of HOC-ish Flutter component would be a no-go, however, since the semantics of updating the UI begin to clash (not sure how hard it would be to bridge the two, but surely it's possible in some way)

Thread Thread
 
devinrhode2 profile image
Devin Rhode

Dart even avoids any locks during garbage collection, which is amazing. As cool as concurrent mode is, Dart might make concurrent mode/suspense/etc a minor 1% improvement once the performance improvements from Dart are accounted for. Who knows. Just a fanboy.

Thread Thread
 
ryansolid profile image
Ryan Carniato

I honestly haven't had much of an opportunity/reason to look at Dart. TypeScript admittedly was mostly just a pragmatic choice since it seemed like a reasonable thing to do as a library author. It wasn't because of any personal like of TypeScript.

To be fair while the reactivity is a big part of what I do with Solid, my focus on the web came from knowing I could make a tangible difference there. Even SSR wasn't a place I was expecting have such success. I'm not sure how Solid would fit into Dart/Flutter ecosystem as it feels like they already have a good thing going.

Thread Thread
 
devinrhode2 profile image
Devin Rhode

I have fanboy'd over dart/flutter, google's presentations on dart/flutter show some amazing tech, but I think Dart is really the star of the show. I look at Flutter code and it's all the horrors of angular all over again.

What I really want is actually-native level performance (AOT compiled dart), great dev experience (dart dev compiler, ddc), BUT in a react/component/jsx paradigm.

Thread Thread
 
trusktr profile image
Joe Pea

Solid gives you that for sure. Also @lume/element gives you one more level higher: custom elements with templating powered by Solid.

I'm also planning to implement JSX for AssemblyScript unless someone else gets to it first, and the compile the implementations of my custom elements to WebAssembly.

The big milestone will be when we can also compile to native (run outside of the browser too, but with a web-first API that is easy for existing web developers).

 
ryansolid profile image
Ryan Carniato

To be fair I don't really consider CM a thing for raw performance. Unless you are maxing your CPU cycles scheduling is going to be slower for the raw performance. I think of it more of having a distributed way to model possible futures, without trying to coordinate everything directly in the parent.

Collapse
 
tombyrer profile image
Tom Byrer • Edited

Over 200ms is where people start noticing it, though I theorize if you can get over 70ms a few people will notice.

Rendering time does factor into SEO rankings, for both bot & hand-tested.

Though with SSR, perhaps none of this matters except for costs if your server time is metered.

Collapse
 
ngprnk profile image
Nischal Gautam

Solid's may be faster but the must important thing is that the solid's Dx is much more better than that of React. Solid feels more natural than react and just fits into my head. speed is an added advantage. Solid's reactivity system is much more elegant.

Collapse
 
yellow1912 profile image
yellow1912

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.

Collapse
 
ryansolid profile image
Ryan Carniato • Edited

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.

Collapse
 
hasnaindev profile image
Muhammad Hasnain

Vue is very unique and its ability to integrate with external HTML is why I love it. No other framework provides such capability.

Collapse
 
ryansolid profile image
Ryan Carniato

Yeah it's a hold out from the old days. KnockoutJS used to do that too with it's HTML string data-binding. AlpineJS and Stimulus do this sort of manipulation as well but only Vue of the modern frameworks offer both this ability and the modern built template setup. One of the benefits from still prescribing to data-binding that is completely HTML compliant.

Collapse
 
asashay profile image
Alex Oliynyk

Great work with the library! Coming from the React world it felt very easy to grab the essence. Was looking for a most performant library with Typescript, JSX and all other goodies and SolidJS hit all the bells. Will give it a try!

Collapse
 
aniketkk profile image
Aniket Kulkarni

This looks so good. Please promote it extensively. Also some good courses on platforms like Youtube and Udemy will help.

Collapse
 
tobbtec profile image
Bernard

Thanks, will try solidjs

Collapse
 
guitarino profile image
Kirill Shestakov

I love a lot of things about the library. Definitely going to check it out.

Collapse
 
adam_cyclones profile image
Adam Crockett 🌀

I wonder how it compares to lit-html

Collapse
 
ryansolid profile image
Ryan Carniato

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... https://medium.com/@ryansolid/the-fastest-way-to-render-the-dom-e3b226b15ca3?source=friends_link&sk=5ae1688dde789e46cecf5c976e708da5.

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.