DEV Community

loading...
Cover image for 5 Reasons why we chose to transpile to SolidJS instead of React

5 Reasons why we chose to transpile to SolidJS instead of React

chris-czopp
Lead JS full-stack engineer and co-owner of GlueCodes
・2 min read

Choosing a relatively young framework with a limited support over Facebook's giant may seem like craziness. As a core developer at GlueCodes Studio, I was the one pushing towards taking the risk. The decision has been mainly driven by Solid's build-time DOM diffing flavoured with a very simple API. I really believe it's a natural replacement of Virtual DOM. I always believed that taking the compromise of re-rendering the whole tree when the app state changes just for a "developer's convenience" is a matter of time. There was Svelte on radar, but I'm rather in favour of JSX, especially because we already provide an abstraction layer for templating using HTML with our meta-framework specific directives. So, I thought it would be awesome to write UIs with this higher level of abstraction and export to more flexible JSX and if you wish, continue development out of our tool. Check out the docs for more info.

Here are the 5 points:

  1. It does DOM diffing at build-time.

  2. It's function-first and it has a very clean API. Much of it is similar to React.

  3. It doesn't recursively call the component every time the app state changes. I mean the body of the function which returns JSX is called just once, making local state management simpler and more natural.

  4. It is primary made for JSX, but there is also HyperScript available which can be handy if you need DOM diffing at run-time. In our case, it was useful for Live Preview without compilation.

  5. A component returns a DOM element!

💪 Bonus: It's owned by the community and the core team is very open and responsive.

Links:

SolidJS

GlueCodes Studio

Let me know what you think.

Discussion (0)