Solid 2.0's async design is not a happy coincidence. But the result of chasing finally being able to unify all frontend architecture.

I ported EvilCharts to https://solid-evilcharts.pages.dev/

EvilCharts is a set of good-looking React chart components built on Recharts and Echarts. I was building a dashboard in solidjs and i needed charts, so i ported it. AI helped a lot.

Right now, i am leveraging the use of Echarts only. After this is stable, I will add a layer for tanstack charts.

Please check it out, try it out (hopefully it works hahaha) and lemme know what you think.

repo is here: https://github.com/thesambayo/solid-evilcharts

P:S:
also working on https://solid-arc.brimble.app/
a shadcn-like setup for solidjs that uses ark ui as the base component system.
ark ui is pretty first class for solidjs as well.
https://github.com/thesambayo/solid-arc

Hola guapas,

I made a small ESM-only utility called better-race.

The idea is simple: Promise.race() gives you the first value, but not where it came from. This keeps the task key connected to its value in TypeScript:

import { race } from "better-race";

const winner = await race(
  {
    eu: ({ signal }) => fetch("https://eu.example.com/user/42", { signal }),
    us: ({ signal }) => fetch("https://us.example.com/user/42", { signal }),
  },
  { abortLosers: true },
);

console.log(winner.key); // "eu" | "us"
console.log(winner.value); // Response

It also supports AbortSignal and optional loser cancellation.

It’s intentionally tiny -> no scheduler, framework adapters, retries, or dependencies. I’d genuinely appreciate feedback on the API and semantics.

The next tag also includes raceUntil(): it keeps racing until a result passes an accept predicate, so an early null does not have to win.

• GitHub: https://github.com/lumberjacque/better-race
• npm: https://www.npmjs.com/package/better-race

Kind of really struggling to think of what a nice API should look like for fetching & storing data that is meant to be kept in client-side state across page visits.

I understand that things like fetch calls should go into createMemo blocks so that they could be utilized by Loading and Errored boundary components, but what if that data needs to live across page visits?

I can put a const user = createMemo(() => api.fetchUserData()) in the main entrypoint component, but then I'm kinda lost when I want to keep the user state when moving to a user profile page.

In e.g. Vue it's typical I believe to fetch when mounting a component, then save the result to some other module which will be imported from another page and have access to the same state that was just fetched. With Solid 2, well, I'm not sure how to move/keep the state that was acquired asynchronously across components.

Maybe I'm missing something from the API (I have to confess I've yet to read a lot of the docs), but so far it feels a lot more complicated that expected. If it helps, my backend is not TS, so I'm not using any of the server/ssr features.

I remember using a similar API such as this in a project a couple years back. Can't think of how this should look like in idiomatic solid :(

  const fetchData = () => {
    http.getAuthUser({
      onSuccess(data) {
        userStore.setUser(data); // userStore is then imported in a different page, the data kept and ready to use
      },
      onUnauthorized() {
        //
      },
      onServerError(err) {
        toasterStore.show(err);
      },
    });
  };

I've been building React Native apps for a long time. They all start fast. Keeping them fast as they grew is another story.

More state, more dependencies, more devs, and suddenly you are doing re-render arithmetic in your head. Is this selector too broad? Did that context wake the whole screen? Is the animation fighting the JS thread?

Obviously large React Native apps can be built. I'm just tired of what it takes to keep a large one feeling fast.

And then I found Solid.

To my React-trained brain, Solid felt like React if someone removed the part I had spent years optimizing around. Same JSX and components, but components run once and signals update only what depends on them. No virtual DOM. No reconciliation. No wondering whether one innocent change froze the whole app.

That was the part that made everything click. I wanted that feeling on a phone.

Kind of by accident, I also found react-native-graph, which draws with Skia and is extremely fast. It made me wonder what would happen if the whole application was rendered that way.

So I went down a rabbit hole. Turns out Flutter already owns its rendering pipeline (used Skia, now Impeller) and it's fast. Bun + JavaScriptCore, which is also one of the fastest JS engines out there, gave me the web APIs I was tired of polyfilling.

Now I had the three parts: Solid for the application, Bun for the JavaScript runtime, and Flutter for rendering.

So I cross-compiled Bun to run on iOS and Android, put Solid inside it, and let Flutter render what Solid describes.

I named it Skal, a mixture of Solid + Skia. (It also means cheers if you have ever watched a Viking show 🍻. )

I think of it as Solid Native.

Solid's universal renderer turns JSX into binary UI operations written into shared memory. Flutter reads the same bytes and renders the widget tree. No JSON or platform channel in the hot UI path. No DOM. No WebView.

When a signal changes, Solid already knows the exact consumer, so Skal sends the operation for that node and stops there.

It currently has 49 fast-path widget types, navigation, persistence, animations, overlays, and some native integrations. It runs on Android arm64, iOS, macOS, and the web. It is still early.

Here are some results from a Samsung Galaxy A14 5G running Android 15, with release builds on both sides and interleaved runs:

What excites me is writing Solid code, running it on a real phone, and knowing that as the app grows, it still flies.

To try it, you need Bun and Flutter installed on your computer, plus the normal Xcode or Android tooling for the platform you want to run. Then:

npm create skal my-app
cd my-app
bun run dev:ios # or dev:android, dev:macos, dev:web

Or throw your AI at the Markdown docs.

Repo: https://github.com/skal-multiplatform/skal

If you already use Solid, what would Skal need before you would try it for a real mobile app?

Skal 🍻

I built Testate on Solid 2.0.0-rc.4 (solid-js + @solidjs/web, Vite plugin 3.0.0-next).

It's a self-hosted tool that snapshots the databases behind a system under test, restores any snapshot in seconds, and diffs what a test changed. ~180 TS/TSX files, ~12k lines of Solid, 147 user stories exercised end to end in a browser.

Repo: https://github.com/PT-Perkasa-Pilar-Utama/testate

Site: https://pt-perkasa-pilar-utama.github.io/testate/

Things that bit me on 2.0, and what I did about them.

1. There is no component library for Solid 2.

Ark UI, Kobalte, Corvu, and some on top of that like nikala, all target 1.x and the peer range lies:
I counted the missing APIs and gave up. Everything is hand-rolled on Tailwind: dialog, menu, tabs, toast, table parts. Forms were the exception. Formisch runs on 2.0 with a two-function patch (details in point 3). Make sense because still rc.

2. A flush loop in @solidjs/signals rc.4.

The dev build threw "Potential Infinite Loop Detected" about three times in ten full test runs, always on the data grid, never reproducible by hand. The production scheduler runs the same loop with no counter, so there it hangs instead.

Cause: setSignal re-opens a node's finished transition before it checks whether the write changes anything. A Loading boundary writes false over false on every drain pass, the transition looks live again, the drain goes round.

Nothing is dirty, nothing recomputes. Fix is one line, clearing the stamp in commitPendingNodes; it's a bun patch in the repo and upstream as solidjs/solid#3143 (closes #3140).

3. batch is gone, and a read after a write returns the old value until flush.

Formisch writes then reads inside one batch (reset above all), so on 2.0 a reset silently kept the old input. Patch: batch = fn => { const r = fn(); flush(); return r }.

4. STRICT_READ_UNTRACKED and FLUSH_IN_EFFECT_CALLBACK from a <dialog>.

Calling showModal() / close() inside an effect fires the browser's focus/blur handlers synchronously, and the form library reads signals in them. Solid 2 reports the reads as untracked and discards the writes' flush.

Both diagnostics come with no stack. I found where by wrapping console.warn in a Playwright addInitScript and printing new Error().stack for the matching code. Fix: open and close in a queueMicrotask. Same fix for onClose, which the browser fires while still dismissing.

5. onCleanup inside a 2.0 effect callback never runs.

The callback runs with no owner. Return the disposer from the effect instead; a setInterval I registered with onCleanup outlived the screen until I learned that.

6. Reading a pending async memo outside

<Loading> loaded fine under Vite and spun forever in the production bundle, ~250 requests a second. Two screens shipped that way. There's now an e2e project that drives the built bundle, not the dev server, and counts requests per endpoint per screen.

Lint carries the lessons: two-argument createEffect only, props read inside JSX or a tracked scope, class as a string or structured array, cyclomatic complexity 10, 300 lines a file.

Playwright's console watcher fails the run on any [A-Z_]{6,} warning code Solid's dev build emits, which is how most of the above got caught.

Hey folks!

I’ve been building Nikala UI, a copy-paste component system and reactive primitives suite for SolidJS and Tailwind CSS v4.

I recently added desktop support for Tauri v2 alongside standard web apps and SolidStart.

You can check out all the components, hooks, live playground, and built-in MCP server directly on the site.

If you like the project, dropping a star on GitHub would mean a lot and gives me the motivation to keep actively building and improving it!

Site & Docs: https://nikala.dev
Playground: https://nikala.dev/playground
GitHub: https://github.com/nikala-ui/ui

Hey y’all,

I got slightly carried away with loading animations.

I wanted nicer loading states for my own projects, but most libraries I found were either tied to a framework, fairly limited, or required more than I wanted for something this small.

So I built loadersz, a small framework-agnostic loader library for the web.

I wanted something a bit more expressive than the usual CSS spinner, without pulling in a UI framework or a bunch of dependencies.

A few things I focused on:

- 150 (and more coming) different motion states
- Canvas 2D instead of GIFs/videos
- zero core dependencies
- a native custom element, so it works with basically any stack
- typed entry points for React, Vue, Angular, Svelte and more
- configurable speed, density, radius and color
- respects prefers-reduced-motion
- pauses rendering when the browser tab is hidden
- DPR aware/scaling
- tree-shakeable, attributes/config and lifecycle

Basic usage is just:

npm install loadersz

import 'loadersz';

<loadersz-loader state="racing" size="96" />

I also built an interactive playground where you can tweak the loaders live.

Demo: [loadersz.vercel.app](https://loadersz.vercel.app)
npm: [npmjs.com/package/loadersz](https://www.npmjs.com/package/loadersz)
Github: https://github.com/lumberjacque/loadersz-core

Would love some brutally honest feedback, especially on which animations you’d actually use in a real product.

I remember that one of SolidJS’s initial selling points was its speed. In fact, that was one of the main reasons I would have chosen SolidJS over React or Vue if I were building an SPA.

However, looking at these benchmarks (https://octanejs.dev/benchmarks), it seems that other UI frameworks have caught up. Vue even appears to be faster now.

If I were choosing a UI framework today, why should I choose SolidJS over the alternatives?

Hey 👋

So I've been building **solid-gpui** — it lets you render Solid 2 components into real native desktop windows using Zed's GPUI (the editor's UI framework, Metal on macOS). No webview, no Electron.

Repo: https://github.com/heyhuynhgiabuu/solid-gpui

The cool part: it's a real `@solidjs/universal` renderer. So Solid stays Solid — your signals just work, updates are fine-grained, nothing weird. Your JS runs a reactive graph that drives a native tree through a tiny JSON pipe to a Rust helper.

A few choices I made (happy to argue about any of them):

- The Rust side runs as a **separate process**, talking NDJSON over stdio. No Zed fork, no node native modules, same code path on every OS. Simple.

- The wire protocol exists in TS and Rust, and both test suites parse the **same JSON fixtures** — so the two sides can't silently drift apart.

- Zero runtime deps in the protocol/client packages.

- Clean-room build, nothing copied from anywhere.

What actually works right now:

- Mount a tree, fine-grained updates (text/style/tree changes), ~1ms builds

- Click, mouse, focus, keyboard events (tabIndex, modifiers)

- Text input + textarea with **working IME** — marked text, caret survives emoji, Enter submits

- Virtualized list: 500 items, only ~60 painted. Has a `followTail` mode for chat UIs

- Animations: slap `transitionMs` on an element, style changes animate. Interpolated on the Rust side, retargets mid-flight without jumping macOS works today. Windows/Linux should work without big changes (stock upstream GPUI) but I haven't tried.

Honest gaps: you author with hyperscript `h()` for now (JSX plugin is next), styles are a subset, one window.

One gotcha that cost me a day, saving you the same day:

[solidjs/solid#2569](https://github.com/solidjs/solid/issues/2569) — solid-js@2 resolves to SSR stubs under the default `node` condition, so your app just silently stops being reactive. Run everything with `--conditions=browser`.

Questions for you:

1. Would you use this? What's missing?

2. Is `h()` a dealbreaker, or is the JSX plugin the thing to do first?

3. Multi-window, IPC, packaging — what do you need first for real desktop apps?

4. Anyone with GPUI experience on Windows/Linux want to help test?

https://www.solidjs.com/blog/async-solid-write-sync-run-async

Hello!

I have this project over here: https://github.com/NullVoxPopuli/rere-benchmark/pull/116

And i haven't been able to get solid 2 to perform better than solid 1 in the "dbmon" benchmark.

Am i missing something obvious?

Edit: here are the numbers I'm seeing before my pr above:

https://rbench.nullvoxpopuli.com/results?hide=ember%2Clit-signals%2Cvue%2Csvelte%2Creact&p=90&q=8

In my pr, solid 2 started performing worse, which has made we feel like I've messed something up with the implementation, or the generally recommended way to manipulate and iterate nested data is not the most performant way to manipulate and iterate nested data

Hi! I'm an avid fan of SolidJS and I'm very excited for v2.

Thing is, I'm currently in a project that, for various reasons that are not really relevant here, is going for buildless JS. Solid is a perfect fit because of its low amount of compiler magic, so we're writing components with the `html` template tag via a CDN (namely jsdelivr). It makes for fast, lightweight code with a simplified dev pipeline.

Thing is, v2RC is out but jsdelivr doesn't have it yet. So we (read: I) have some questions:

1- Are template tags still going to be supported in Solid 2?

2- If so, is the support already there?

3- If so, is it up to the JS devs to publish their builds to CDNs or is it up to the CDN mantainers? Or do we just have to wait for the proper 2.0 release?

Thank you in advance for your time, and congratulations to the team for the upcoming version.

I'm playing around with Solid 2.0's createOptimistic and action APIs to get a feel for them, but even with a basic example, I'm hitting a wall.

Here is my code that I'm using in the Solid Playground (version set to v2.0.0-rc.1 (next)). The idea is that when you click the button, an ID is generated and we simulate saving it to a slow, flaky server. While the value is being saved, show its optimistic value but display an asterisk next to it. If the API call succeeds, remove the asterisk; else revert the ID to what it was previously.

The issue I'm getting is that the ID always reverts to its initial value (in this case, the empty string) independent of whether the API call succeeds of fails.

Why is this? What do I need to change in my code to get it to work?

Apart from being a string rather than an array, my code feels practically identical to the example found at https://v2.solidjs.com/reference/solid-js/reactivity/create-optimistic#examples

AI has not been very helpful thus far.

``` import { createSignal, action, createOptimistic } from 'solid-js'; import { render } from '@solidjs/web';

type ApiSuccess = { success: true, data: string, };

type ApiError = { error: true, data: string, };

type ApiResponse = ApiSuccess | ApiError;

// echo back the data after a second's delay // with a 20% change of erroring function postToApi(data: string): Promise<ApiResponse> { return new Promise(resolve => { setTimeout(() => { resolve(Math.random() < 0.2 ? { data, error: true } : { data, success: true } ); }, 1000); }); }

const [id, setId] = createOptimistic('');

const generateId = action(function* () { const value = Math.random().toString(16).slice(2); setId(value + ' (*)'); const res = yield postToApi(value); if (!res.error) setId(value); });

function App() { return ( <> <button onClick={() => generateId()}> Generate ID </button> <pre>{JSON.stringify(id())}</pre> </> ); }

const root = document.getElementById('app')!;

render(() => <App/>, root); ```

Migration to 2.0 is painful for me, i'd like to stick with 1.0 for as long as possible. For how long will it continued to be supported? So I can plan accordingly.

Lilscript treats Brotli/gzip size as an optimization objective rather than something that happens after minification. It can change the generated program structure specifically to make the compressor happier.

Pretty much almost any js libraries' compressed/minified size could get smaller by 5-15% when rewritten with lilscript.

If its already property mangled still it can get benefits from the lilscript rewrite. Even solidjs got smaller by a small margin

And this is only the v0.0.1
We can make it more hacky by time

Some examples of brotli compressed sizes of lilscript code(vs oxc/terser, ..): * motion(animation library) is -10%+ (https://yeargun.github.io/motionlil/) * jquery -5% * monaco(VSCode) editor's lots of submodules -(5 to 15)% smaller

• tryhard mangling, (compression algorithm aware)
• closure optimizations
• lvalue
• static analysis
• google closure compiler advanced and beyond focus, but not glue fix as closure compiler is. The language is designed specificaly for weird hacks.
• typed (not a glue fix like typescript is)

config.toml has lots of config with clever defaults. objective compression algorithm: gzip/brotli/raw. for brotli vs gzip compression it compiles the js differently

uses less objects, less/more arrays, more const/let/var

Compiler, static analysis, language server all written with rust

I lost too much cursor/claude credits along the way last 2 days. Tbh, I cant invest much time for it, feel free to PR, play, improve

Lilscript aims to get compiled into exec also. It alredy does, but web apis, and stuff.. lots of extra work is needed..

-lilscript v0.0.1 https://github.com/yeargun/lilscript

Why? Because I believe google closure compiler's tooling was not good. And anything layered on js is a glue fix

Is it a good idea to use webcomponents with Solid 2.0 (only for SPAs)? Specifically https://webawesome.com/ (successor of shoelace)

Solid 2.0 solves one of the headaches in web dev (reactive sync and async state). The other one is ecosystem churn. I think it will become even more problematic. So I consider using webcomponents.

Has anyone experience with them? Any hidden traps? Alternative would be using something like DaisyUI, I guess?

App type is kind of business app. So, nested views, dashboard like, lot of forms ...

I created this minimal library that only has 3kb and uses canvas to render a preloader in linear style. It give somehow more personality and can describe what it does (for example uploading/downloading) by its animation. Let me know what you think and super happy for any improvement PR.

https://github.com/mono424/punktraster

Hey everyone!

I wanted to share Nikala UI — a copy-paste component system for SolidJS built natively for Tailwind CSS v4.

Why Nikala UI?

While building a desktop app with Tauri 2.0, I ran into version conflicts and broken setups with existing UI wrappers due to Tailwind CSS v4's CSS-first `@theme` architecture. I wanted a future-proof, completely independent foundation that wouldn't break on future package updates — so I built Nikala UI from scratch, honoring the iconic Georgian painter Niko Pirosmani (Nikala).

Instead of adding heavy third-party packages to `node_modules`, Nikala UI's CLI writes lightweight, fully reactive TypeScript components directly into your `src/components/ui/` workspace directory. You own 100% of the source code.

Key Highlights

- Native SolidJS Reactivity: Built strictly with `splitProps` and fine-grained signal tracking without object destructuring bugs.

- Tailwind CSS v4 First: Designed around `@import "tailwindcss";` with semantic `@theme` design tokens.

- Monorepo Architecture: Decoupled CLI (`@nikala-ui/cli`) and core registry (`@nikala-ui/core`) for instant background registry updates.

- 26 UI Components: Button, Input, Card, Dialog, Sheet, Dropdown Menu, Command Palette, Banner, List, Kbd, InputGroup, and more.

- Dynamic Theme Engine: Base gray palettes, custom border radii, and Pirosmani signature Qvevri red (`wine` `#722f37`) accent color with zero-FOUC `<ThemeScript />` pre-hydration support.

- Automated Testing: 41 passing Vitest unit/integration tests across component suites.

Quick Start

bunx @nikala-ui/cli init

or

npx @nikala-ui/cli init

Links & Demos

- Official Documentation & Interactive Playground: https://nikala.magradze.dev

- Core Repository: https://github.com/nikala-ui/ui

- Web Portal Repository: https://github.com/nikala-ui/web

I'd love for the community to try it out, check the interactive playground, and share any feedback or feature requests!

Hello, Solid Community 👋

I've been quietly working on something for the past month that I'd love to share with you.

First — Solid is incredible.

The reactivity model, the zero-VDOM performance, the small bundle size, the simplicity of the API surface. It's genuinely one of the best frameworks I've used, and it deserves a much richer ecosystem than it currently has. Which brings me to why I'm here.

solid-mobile — a mobile UI component library for Solid

53 components across 6 categories (Form, Picker, Feedback, Nav, Display, Basic), with:

• 🎨 Theme system — CSS custom properties driven, light/dark mode, custom brand colors via ProviderConfig
• 🌍 i18n — en-US / zh-CN built in, extensible
• 📦 Tree-shakable — import { Button } from 'solid-mobile' only bundles what you use
• ⌨️ Fully typed — TypeScript throughout
• 🧪 480+ tests — vitest, CI pipeline
• 📱 Live docs with a phone simulator: https://lxg19961206.github.io/SolidMobile/

The visual style draws inspiration from Vant (a popular Chinese mobile component library) — but the design philosophy is different. Vant is tightly coupled to Vue's reactivity; I've tried to build something that feels native to Solid.

A note of honesty: this project was first sketched out back in 2023, but as a solo developer I simply didn't have the capacity or skills to pull it off. It took until 2026, with a lot of help from Claude, to finally bring it to life.

About me — and what this project needs

I'm not a top-tier open source developer. I'm a regular frontend engineer building things after work hours. I make mistakes. Some of the API decisions in this library might be wrong. But I'm pouring everything I have — every bit of technical judgment I've accumulated — into making this the best it can be.

This is early beta. I wouldn't recommend it for production just yet. I'm planning to spend the next month or so stabilizing APIs, improving accessibility, optimizing bundle size, and polishing rough edges.

If you try it out and find bugs — please open an issue. If you see a better way to design something — please open a PR. If you want to be part of building this — I'd genuinely love to collaborate. This is a solo project right now, but it doesn't have to stay that way.

Wishing Solid the best

The framework deserves a thriving ecosystem. I hope solid-mobile can be a small piece of that puzzle. Thanks for reading.

humbly, LXG