Ryan Carniato on SolidJS: “It Puts the Control Back in the Developer's Hands”

Choosing the right JavaScript framework can make all the difference in the success of your project. With so many options available, it can be overwhelming to decide which one is the best fit for your needs. Two popular frameworks, SolidJS vs React, are constantly compared and debated in the web development community. We heard from SolidJS founder Ryan Carniato on reactivity and how is it becoming the universal language of user interfaces,  the impact of the shift from the component model to the reactivity model, why is there a need for more granularity in modern frontend architectures and how SolidJS can smoothly support binding data to elements displayed on web pages. 

What exactly is SolidJS? 

Solidjs is a javascript library that helps you create the user interface. Instead of using a Virtual DOM, it uses reactive programming under the hood to update the DOM. In terms of performance and rendering, SolidJS has an optimized virtual DOM implementation and selective re-rendering. 

Solid is built with efficient reactive primitives you can use from your business logic to your JSX views. This unlocks complete control over what gets updated and when, even at the DOM binding level. With no Virtual DOM or extensive diffing, the framework never does more work than you want it to.

How is SolidJS different from React?

As much as Solid aligns with React's design philosophy, it works fundamentally differently. React's abstraction is top down component partition where render methods are called repeatedly and diffed. Solid, instead, renders each Template once in its entirety, constructing its reactive graph and only then executes instructions related to fine-grained changes.

Additionally, the SolidJS framework sets itself apart from React by removing the virtual DOM, giving developers greater control over state updates through direct interaction with building blocks. This approach is declarative and reactive, allowing for fine-grained updates and a set-and-forget mentality for rules creation. Unlike virtual DOM frameworks, SolidJS only updates the necessary components, resulting in a more efficient and granular approach to UI building.

SolidJS uses a system called fine-grained reactivity to write updates directly onto a webpage. In contrast, React updates a virtual DOM with its page changes. That virtual DOM and the current page’s DOM are compared, and only the differences are written.

The absence of component re-rendering in SolidJS introduces certain differences compared to frameworks like React, particularly in terms of the mental model and technical aspects. Simplification occurs when considering that components in SolidJS do not re-run. This eliminates the need to handle closures around state, as seen in React hooks. In SolidJS, it is the primitives or hooks that re-run, which is a significant departure from traditional examples. Unlike in other frameworks, where you may need to think about the lifecycle of a component and how a specific task should be performed once, in SolidJS, you can directly place the task within the component body itself. This is due to the fact that components in SolidJS run only once, providing a stark contrast to the repetitive execution of functions in other frameworks.

Why should a developer use SolidJS?

Think about this. What if instead of the most minimal reactive implementation which ties into components we could opt into granularly optimized updates? What if our reconciliation algorithms were larger but smarter? What if instead of implicit language features we allowed for explicit to better capture end-user intent? And what if we still could leverage all the same static analysis and aggressive feature detection? That's where Solid comes in.

The reactivity system lies at the heart of SolidJS, serving as a crucial mechanical component that efficiently manages changes and keeps things synchronized. From a developer's perspective, it offers several desirable aspects. However, it is essential to recognize that reactivity is just one facet of the system—a human-centric interface for efficient change management.

What are the challenges when it comes to awareness about reactivity and SolidJS?

The current state of execution in SolidJS is highly predictable yet dynamic. It leverages reactivity through automatic dependency tracking, allowing developers to write code in a manner similar to equations in a spreadsheet. Templating and value calculations are written in regular JavaScript, ensuring consistent results. However, there is a caveat that this approach requires familiarity with the reactive system from the start, which may pose a small learning curve, especially for React developers. Some developers may encounter difficulties when expecting components to re-render automatically, questioning why updates are not occurring. However, once the understanding is established that SolidJS functions run only once and primarily involve rule-setting, this challenge becomes less problematic.

What makes reactive systems intriguing is their ability to excel in expressing intent and facilitating language-based communication. Instead of focusing on low-level details like memoization or execution flow, developers can simply specify how data connects to specific points in the UI and when updates should occur. This creates a flow of interconnected nodes throughout the application, explicitly defining relationships and precise changes. This declarative approach is powerful, not only from a static analysis standpoint but also when translating abstract ideas into concrete implementations. It provides a defined language for conveying desired outcomes and relationships, allowing for more effective communication with both human readers and potentially AI systems.

What is the impact of the shift from the component model to the reactivity model on web development?

The Future is component-less. Not that we won’t write re-usable components or templates, just components will vanish, removing their impact on the output. That doesn’t require a compiler to start. We can move to make components no heavier than a simple function call. That is essentially Solid, but that is only one way to attack this.

We don’t need separation to accomplish this either. It is unnecessary to hoist all our state into a state management tool playing puppeteer to our renderer. I’m proposing aggressive co-location. Modern frameworks have that right. Whether JSX or SFC we’ve been pulling it together and should continue to do so.

Ultimately, if a compiler could look beyond the current file it was processing to use language to understand your whole app, think of the doors that would open. Our logic and control flows could solely define the boundaries. That’s not just unlocking levels of performance, but freeing ourselves of the mental burden of ever worrying about this again.

Wouldn’t it be amazing to recapture the pure declarative nature of something like HTML in authoring our sites and applications? The unadulterated cut and paste bliss? I’m not certain where this goes, but it starts here.

Why is there a need for more granularity in modern front end architectures?

I initially started using SolidJS because I enjoyed the experience of having precise control over updates without worrying about renders. This aspect has performance implications, as some libraries may not be suitable for certain scenarios, such as building 3D games where frequent re-rendering can be cumbersome. SolidJS, being a state library built from the ground up, eliminates the need to switch solutions for different use cases. Its granular approach to performance optimization benefits both the browser environment and considerations related to server-client relationships, including hydration and server-side rendering (SSR).

By leveraging reactive systems, we can further reduce execution costs and minimize the amount of code sent to the browser. As components become more fragmented, such as with partial hydration or React server components, the need for smarter communication between isolated app pieces becomes apparent. Reactivity provides an effective solution for orchestrating these isolated components and contributes to reducing JavaScript size and enhancing overall system coordination. Additionally, the focus on primitives and a reactive language in SolidJS holds value in terms of future tooling, such as advanced compilation, language design, and artificial intelligence integration.

Still curious? Meet the SolidJS creator in person

Ryan will be speaking at GOTO Chicago and will be showing a live demo on how SolidJS works. Find out whether SolidJS really lives up to expectations and its differences from React.

Meet him in person along with a bunch of other incredible speakers.