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.
I've been working on this after hours for a while now, and figured it's time to share where it is — and where it's heading.
solid-mobile is a mobile-first UI component library — buttons, dialogs, pickers, forms, tabs, calendars, that kind of thing. The visual design and component APIs are heavily inspired by Vant (a Vue mobile library with a design language I've always really liked), but the implementation is written from the ground up for Solid's reactivity model.
Why I think it's worth a look:
import { Button } from 'solid-mobile' only bundles what you use, zero runtime dependenciesWhat's happened recently:
ref APIimport { Card } from 'solid-mobile' failed for npm users. Shipped in v0.2.4Where it stands now: the feature set is basically frozen. All 55 components are in place and the API is converging fast — after 1.0 it's additive-only (new features yes, breaking changes no). The run from 0.2.x to 1.0 is a stabilization marathon: 0.01 at a time, grinding on test hardening, edge cases, and docs rather than piling on new features.
The docs site is now an independent project. Since the component set is stable, the docs don't need to track source changes in real time anymore — so I split them out of the library repo into their own repository that consumes solid-mobile as a real npm package (a local file: tarball during development, the published version in CI). That means every demo on the site double-checks the actual release artifact — exports, type declarations, styles — the kind of thing that only ever breaks for real users. If a demo renders correctly, the package works.
Links:
npm install solid-mobileA quick word about Solid.js — I picked it because its reactivity model is genuinely fun to work with. Signals, no virtual DOM, tiny runtime. It feels like what React hooks wanted to be. If you've only used React or Vue, honestly — give Solid a weekend. It keeps the familiar JSX syntax but strips away a ton of complexity, and the performance is no joke (no VDOM diffing, components run once). The ecosystem is still young, which is exactly why projects like this one need to exist.
That said, a lot of the design work here — the component APIs, the theme architecture, the CSS patterns — is framework-agnostic. If someone wanted to port this to Vue or React, the hard part (the visual design and interaction details) is already done.
This was first sketched back in 2023, but as a solo dev I didn't have the bandwidth to pull it off. Fast forward to 2026 and with a lot of help from Claude, it finally came together.
What I'm looking for: Honest feedback. The API is about to lock in, so now is genuinely the best time to poke holes in it — if you look at a prop and think "that's wrong," I want to hear it. If npm install breaks on your machine — please open an issue. If you like the idea and want to contribute — PRs are very welcome. This is a solo project right now and fresh eyes would make a huge difference.
Cheers :)
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.