What is solid-js?
Solid.js is a declarative JavaScript library for building user interfaces. It focuses on fine-grained reactivity, which allows for highly efficient updates and minimal re-renders. Solid.js is designed to be fast and simple, providing a reactive programming model that is easy to understand and use.
What are solid-js's main functionalities?
Reactive State Management
Solid.js uses fine-grained reactivity for state management. The `createSignal` function creates a reactive state that updates the UI efficiently when the state changes.
import { createSignal } from 'solid-js';
function Counter() {
const [count, setCount] = createSignal(0);
return (
<div>
<button onClick={() => setCount(count() + 1)}>Increment</button>
<p>Count: {count()}</p>
</div>
);
}
JSX Support
Solid.js supports JSX, allowing you to write HTML-like syntax within JavaScript. This makes it easy to create and manage UI components.
import { render } from 'solid-js/web';
function App() {
return (
<div>
<h1>Hello, Solid.js!</h1>
</div>
);
}
render(() => <App />, document.getElementById('root'));
Component Composition
Solid.js allows for easy component composition. You can create reusable components and pass data to them via props.
function Greeting(props) {
return <h1>Hello, {props.name}!</h1>;
}
function App() {
return (
<div>
<Greeting name="Solid.js" />
</div>
);
}
Direct DOM Manipulation
Solid.js provides direct DOM manipulation capabilities. The `onCleanup` function allows you to perform cleanup tasks, such as clearing intervals, when a component is unmounted.
import { onCleanup } from 'solid-js';
function Timer() {
let timerId;
const [time, setTime] = createSignal(0);
const startTimer = () => {
timerId = setInterval(() => setTime(time() + 1), 1000);
};
onCleanup(() => clearInterval(timerId));
return (
<div>
<p>Time: {time()}</p>
<button onClick={startTimer}>Start Timer</button>
</div>
);
}
Other packages similar to solid-js
react
React is a popular JavaScript library for building user interfaces. It uses a virtual DOM and a component-based architecture. Compared to Solid.js, React has a larger ecosystem and community but may have more overhead due to its virtual DOM.
vue
Vue.js is a progressive JavaScript framework for building user interfaces. It features a reactive data binding system and a component-based architecture. Vue.js is similar to Solid.js in its reactivity model but offers more built-in features and a larger ecosystem.
svelte
Svelte is a compiler that converts declarative components into efficient imperative code that directly manipulates the DOM. Unlike Solid.js, Svelte does not use a virtual DOM and compiles components at build time, resulting in highly optimized and fast applications.
Website • API Docs • Features Tutorial • Playground • Discord
Solid is a declarative JavaScript library for creating user interfaces. Instead of using a Virtual DOM, it compiles its templates to real DOM nodes and updates them with fine-grained reactions. Declare your state and use it throughout your app, and when a piece of state changes, only the code that depends on it will rerun. Check out our intro video or read on!
Key Features
- Fine-grained updates to the real DOM
- Declarative data: model your state as a system with reactive primitives
- Render-once mental model: your components are regular JavaScript functions that run once to set up your view
- Automatic dependency tracking: accessing your reactive state subscribes to it
- Small and fast
- Simple: learn a few powerful concepts that can be reused, combined, and built on top of
- Provides modern framework features like JSX, fragments, Context, Portals, Suspense, streaming SSR, progressive hydration, Error Boundaries and concurrent rendering.
- Naturally debuggable: A
<div>
is a real div, so you can use your browser's devtools to inspect the rendering - Web component friendly and can author custom elements
- Isomorphic: render your components on the client and the server
- Universal: write custom renderers to use Solid anywhere
- A growing community and ecosystem with active core team support
Quick Start
You can get started with a simple app by running the following in your terminal:
> npx degit solidjs/templates/js my-app
> cd my-app
> npm i
> npm run dev
Or for TypeScript:
> npx degit solidjs/templates/ts my-app
> cd my-app
> npm i
> npm run dev
This will create a minimal, client-rendered application powered by Vite.
Or you can install the dependencies in your own setup. To use Solid with JSX (recommended), run:
> npm i -D babel-preset-solid
> npm i solid-js
The easiest way to get set up is to add babel-preset-solid
to your .babelrc
, babel config for webpack, or rollup configuration:
"presets": ["solid"]
For TypeScript to work, remember to set your .tsconfig
to handle Solid's JSX:
"compilerOptions": {
"jsx": "preserve",
"jsxImportSource": "solid-js",
}
Why Solid?
Performant
Meticulously engineered for performance and with half a decade of research behind it, Solid's performance is almost indistinguishable from optimized vanilla JavaScript (See Solid on the JS Framework Benchmark). Solid is small and completely tree-shakable, and fast when rendering on the server, too. Whether you're writing a fully client-rendered SPA or a server-rendered app, your users see it faster than ever. (Read more about Solid's performance from the library's creator.)
Powerful
Solid is fully-featured with everything you can expect from a modern framework. Performant state management is built-in with Context and Stores: you don't have to reach for a third party library to manage global state (if you don't want to). With Resources, you can use data loaded from the server like any other piece of state and build a responsive UI for it thanks to Suspense and concurrent rendering. And when you're ready to move to the server, Solid has full SSR and serverless support, with streaming and progressive hydration to get to interactive as quickly as possible. (Check out our full interactive features walkthrough.)
Pragmatic
Do more with less: use simple, composable primitives without hidden rules and gotchas. In Solid, components are just functions - rendering is determined purely by how your state is used - so you're free to organize your code how you like and you don't have to learn a new rendering system. Solid encourages patterns like declarative code and read-write segregation that help keep your project maintainable, but isn't opinionated enough to get in your way.
Productive
Solid is built on established tools like JSX and TypeScript and integrates with the Vite ecosystem. Solid's bare-metal, minimal abstractions give you direct access to the DOM, making it easy to use your favorite native JavaScript libraries like D3. And the Solid ecosystem is growing fast, with custom primitives, component libraries, and build-time utilities that let you write Solid code in new ways.
Show Me!
import { render } from "solid-js/web";
import { createSignal } from "solid-js";
const Counter = props => {
const [count, setCount] = createSignal(props.startingCount || 1);
const increment = () => setCount(count() + 1);
console.log(
"The body of the function runs once, like you'd expect from calling any other function, so you only ever see this console log once."
);
return (
<button type="button" onClick={increment}>
Increment {count()}
</button>
);
};
render(() => <Counter startingCount={2} />, document.getElementById("app"));
See it in action in our interactive Playground!
Solid compiles our JSX down to efficient real DOM expressions updates, still using the same reactive primitives (createSignal
) at runtime but making sure there's as little rerendering as possible. Here's what that looks like in this example:
import { render, createComponent, delegateEvents, insert, template } from "solid-js/web";
import { createSignal } from "solid-js";
const _tmpl$ = template(`<button type="button">Increment </button>`, 2);
const Counter = props => {
const [count, setCount] = createSignal(props.startingCount || 1);
const increment = () => setCount(count() + 1);
console.log("The body of the function runs once . . .");
return (() => {
const _el$ = _tmpl$.cloneNode(true);
_el$.firstChild;
_el$.$$click = increment;
insert(_el$, count, null);
return _el$;
})();
};
render(
() =>
createComponent(Counter, {
startingCount: 2
}),
document.getElementById("app")
);
delegateEvents(["click"]);
More
Check out our official documentation or browse some examples
Browser Support
SolidJS Core is committed to supporting the last 2 years of modern browsers including Firefox, Safari, Chrome and Edge (for desktop and mobile devices). We do not support IE or similar sunset browsers. For server environments, we support Node LTS and the latest Deno and Cloudflare Worker runtimes.
Come chat with us on Discord! Solid's creator and the rest of the core team are active there, and we're always looking for contributions.
Contributors
Open Collective
Support us with a donation and help us continue our activities. [Contribute]
Become a sponsor and get your logo on our README on GitHub with a link to your site. [Become a sponsor]
1.7.0 - 2023-03-30
Solid has experienced incredible growth in usage the last 6 months. Companies are using it to power production applications and SolidStart Beta has been a big part of that. As a natural part of this growth and increased use at scale we are continuing to learn what works well and what the rough edges in Solid are today.
This v1.7 release marks the beginning of the migration roadmap to v2.0. We are beginning to re-evaluate core APIs and will begin introducing new ones while reasonably deprecating older ones in a manner that eases breaking changes. Our intention is to ease the broader ecosystem into preparing for improvements that a major 2.0 will unlock for the whole community.
Improved TypeScript
Null-Asserted Control Flow
One of the pains of using Solid with TypeScript has been that JSX control flows can't really type narrow. This is true, but starting with the migration to explicit keyed
in v1.5 we now complete this story by introducing callback forms for <Show>
and <Match>
that work when non-keyed.
The main difference is the callback form instead of passing in the value as it does when keyed
, passes in a function that is type narrowed.
// keyed w/ callback - reruns full callback on change
<Show when={user()} keyed>
{nonNullUser => <div>{nonNullUser.name}</div>}
</Show>
// non-keyed w/o callback... - only updates the one expression, needs ! assertion
<Show when={user()}>
<div>{user()!.name}</div>
</Show>
// NEW!
// non-keyed w/ callback - only updates the one expression
<Show when={user()}>
{nonNullUser => <div>{nonNullUser().name}</div>}
</Show>
Keep in mind because we are non-null asserting the input signal so it won't expect null in closures that execute when the condition is no longer satisfied. For this reason the accessor from the callback is special and will throw when attempted to be accessed when the condition is no longer true. This may be unexpected but it is our best attempt to keep TypeScript strict and not present inconsistency in reactivity. Luckily this only applies to things like timers which you should be cleaning up anyway and not things like event handlers. We recommend using the original conditions source in those closures if you must.
Better Event Types for Input Elements
This has irked people for a while but we come by it honestly, target
is gives you a type of Element
rather than the specific element that is the target. That means no access to .value
or .checked
. The reason is there is no way to know at compile time what the target of an event will be. The currentTarget
will be the element you attach the event to but the target can be anything.
There is a way to work around this though, in that if we know the currentTarget
is of type that generates the event and that the currentTarget
is the the type of this element we can assume it is the target
as well. Not perfect logic but it is what React does and we do too.
Now onInput
, onChange
, onBlur
, onFocus
, onFocusIn
, and onFocusOut
all support more detailed target
when applied to HTMLInputElement
, HTMLTextAreaElement
, and HTMLSelectElement
.
Stricter JSX Elements
Strict JSX elements have been tricky because we have to acknowledge at a certain point that TypeScript is to serve our purposes rather than to represent all possible values that could work. For us the ambiguity lies in functions.
Solid's JSX needs to accept functions to handle dynamic insertion. However, in authoring it leads to awkward situations.
The first you hit the first time use Solid. You create that counter and don't call count
as a function and it works.
function Counter() {
const [count, setCount] = createSignal(1);
return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
}
This example works in some places and not others which might lead to the wrong conclusions.
The second place you might hit this is when you get a little further on your journey and decide you need a component to re-render and decide that you can just wrap the whole thing in a function:
function MyComp(props) {
return () => {
// look working early returns
if (props.count > 5) {
return <div>Maximum Tries</div>;
}
return <div>Attempt {props.count}</div>;
};
}
Again this seems fine, except the fact that every time count
changes you are recreating all the DOM Elements even when it resolves to the same conditional.
Eventually you might even not think twice about passing functions into children of arbitrary components:
<MyComp>
<MyComp2>
<MyComp3>{() => <div>{resource()}</div>}</MyComp3>
</MyComp2>
</MyComp>
But what does this do? When is the function called?
As it turns out removing functions from JSX.Element
type makes all of these scenarios error. Components only expect the values dictated by their types.
function MyLayout(props: { children: JSX.Element }): JSX.Element;
function MyFor<T, U extends JSX.Element>(props: { each: T[], children: (item: T) => U }): JSX.Element;
// valid
<MyLayout>Hello</MyLayout>
<MyLayout><p>Hello</p></MyLayout>
<MyLayout>{name()}</MyLayout>
<MyLayout>{name() && <p>Hello</p>}</MyLayout>
<MyLayout>{(() => {
return <p{name()}</p>
})()}</MyLayout>
<MyLayout>{untrack(() => {
return <p>{name()}</p>
})}</MyLayout>
<MyFor each={users()}>{(user) => <div>{user.name}</div>}</MyFor>
// invalid
<MyLayout>{name}</MyLayout>
<MyLayout>{() => <p>Hello</p>}</MyLayout>
<MyLayout>{() => "Hello"}</MyLayout>
<MyLayout>{() => name() && <p>Hello</p>}</MyLayout>
<MyFor each={users}>{(user) => <div>{user.name}</div>}</MyFor>
<MyFor each={users()}><div>Not a Function</div></MyFor>
The tradeoff here is that authoring components you can no longer just return a Signal or Memo without casting. If using JSX you can always return a Fragment.
If not you will need to cast to unknown as JSX.Element
.
Better Errors and Cleanup
catchError
replaces onError
Error Handling is complicated enough without having to try to guess how they propagate. onError
admittedly is a lower level primitive but fundamentally had this flaw. It worked by registering an error handler on the parent scope, but left it ambiguous how to handle siblings. Is it a queue? Are they independent?
As a result we are introducing catchError
in this release which introduces its own scope to catch any errors below it. The first argument in the primitive is similar to the try and the second argument is the catch.
catchError(
() => {
// do stuff
throw new Error("I've Errored");
},
err => console.log(err)
);
onError
will still be present until it can be removed in a future major version.
Standardized Errors
Error Handling has had many weird edge cases introduced by applications throwing unusual values. In v1.7 we wrap all thrown values that aren't of type Error
in a new Error
and attach the original thrown value as .cause
.
More Performant Dev Tools
Now that Solid Dev Tools have been stabilizing, we have a much better idea what support we need for them. In so we were able to remove the very costly serialization we were doing for generating unique identifiers. Conventions around naming and exports were streamlined and standardized as well.
Others
- Smaller compiled output, remove auxilary closing tags
- Support for
prop:
and attr:
in Spreads - Don't apply special props (like
readonly
) to custom elements - Introduced improved serializer, seroval
- Fixed quirks in Solid's treeshaking in Rollup
- Minify inline class and style attributes
- Update
solid-ssr
to type "module"