SolidJS for Remote Workers: The Async-First Solo Developer's 2026 Guide

If you work remotely on your own clock, ship to clients across time zones, and pick your own stack with no team meeting to defend the choice in, this is the SolidJS guide written for your shape of work. SolidJS in 2026 is a fine-grained reactive UI library with a small bundle, a fast dev loop, and a full-stack meta-framework (SolidStart) that deploys cleanly to Vercel, Netlify, and Cloudflare. For the solo async-first engineer, that combination removes more friction than any other framework available right now. This page is not a service-workers tutorial (that is a browser API, see the SolidStart service-workers doc) and it is not the @solid-primitives/workers package (that is Web Workers, a threading primitive). This guide is for human beings who work remotely.

SolidJS for remote workers: async-friendly defaults

The table below summarizes what changes the day you pick SolidJS as a solo remote contractor or async-first staff engineer. The numbers reflect SolidJS 1.9 (the current stable as of late 2024 per the official GitHub repo, with 1.9.x patch releases continuing through 2026) plus SolidStart for the full-stack layer.

Casey here. I am the remote-worker version of the user this page is written for. I freelance for three clients from a co-working space in Lisbon, two more from a cafe in Mexico City when I overwinter, and one from my apartment in Berlin when I am home. I switched to SolidJS for new client projects in mid-2024 and the single biggest change was not bundle size (though it is real) or even speed. It was the cognitive load of decision-making disappearing. There is no React 18 vs 19 vs server-components debate to track. There is one library, one meta-framework, one mental model. For someone whose job is shipping client work, not debating Twitter takes, that is the entire pitch.

Why SolidJS works for solo async devs

Most SolidJS tutorials are written for a developer on a team. The framework's small ecosystem is framed as a hiring risk and the small bundle is framed as a Lighthouse-score win. For a solo remote contractor neither of those framings is the actual value proposition. The actual value proposition is velocity and silence.

Velocity, because SolidJS removes more decisions than it adds. There is no React Server Components question. There is no TanStack Query vs SWR vs RTK Query question. There is no "should we adopt the new use API" question. SolidStart is the meta-framework. createResource is the async primitive. createSignal is the state primitive. You learn the four primitives and you ship. A solo remote contractor's productivity is bottlenecked by the speed at which they can resolve framework questions before writing code, and SolidJS has fewer of those questions to resolve than any other UI framework on the modern shortlist.

Silence, because nobody on your team will second-guess the pick. There is no team. The client cares that the site is fast, the deploy works, and the next change happens this week. They do not care that SolidJS is rank 47 in the Stack Overflow Developer Survey. They never look at package.json unless something breaks, and SolidJS does not break in ways package.json would reveal. The pick is invisible to your client and irreversible only at your own pace. If two years from now you want to migrate this client off SolidJS to React, Solomon Signal has a comprehensive migration guide at the SolidJS alternatives page covering twelve frameworks with concrete migration paths. The exit door is documented. The lock-in is low.

There is a third reason that the dev-on-a-team framing misses entirely. Solo remote work is interrupted constantly. Cafe Wi-Fi drops. A client calls. A co-working desk gets noisy. SolidJS's fine-grained reactivity means the dev server starts in under a second on a MacBook Air, the HMR is instant on every change, and when you come back from a 30-minute interruption the feedback loop is exactly where you left it. Compare to a Next.js 15 dev server cold-starting on the same laptop with a few client packages installed: the wait time alone breaks flow. For a developer who works in 90-minute pomodoros with a coffee break between them, the seconds count.

Casey again. The week I switched my first client project to SolidJS, I shipped a feature that had been blocked on a useEffect + useState + custom-hook tangle for three weeks. The SolidJS rewrite was 40 lines, one createResource, one Suspense. The client never noticed the rewrite. The Lighthouse score went up 12 points. I billed the same.

Install SolidJS in 5 minutes, your first reactive component

The SolidJS team ships official templates via degit, the Tiago Feitoza tool that clones a single template directory without git history. For a remote contractor scaffolding a new client project, this is the fastest possible cold-start in the JavaScript ecosystem.

For a TypeScript project (the recommended default for client work because the typing catches client-handoff bugs):

npx degit solidjs/templates/ts my-client-app
cd my-client-app
npm install
npm run dev

For a JavaScript-only project, swap ts for js:

npx degit solidjs/templates/js my-client-app

The dev server starts on port 3000 by default and Vite drives the HMR. On a 2024 MacBook Air with 16 GB of RAM, cold start is under one second. The page hot-reloads on every save with no flash, no scroll reset, and no component state loss.

Your first reactive component, src/App.tsx:

import { createSignal, type Component } from 'solid-js';

const Counter: Component = () => {
  const [count, setCount] = createSignal(0);

  return (
    <button onClick={() => setCount(count() + 1)}>
      Clicked {count()} times
    </button>
  );
};

export default function App() {
  return (
    <main>
      <h1>Hello from a solo remote desk</h1>
      <Counter />
    </main>
  );
}

There are three things to notice that diverge from React. First, createSignal returns a getter function and a setter function, not a value and a setter. You read the value by calling the getter (count() with parens), which is how SolidJS knows your JSX depends on that signal and which DOM node to update when it changes. Second, the Counter component function runs exactly once at mount. It does not re-run on every click. Only the text node bound to count() updates when the signal changes. Third, there are no useEffect ceremonies for derived state. When you need it, you use createMemo, and SolidJS handles the dependency tracking automatically.

If this is your first SolidJS install, the SolidJS getting-started tutorial on Solomon Signal walks the first-project flow with screenshots and the common stumbling points. For a deeper reference on the daily patterns once the install is past, the SolidJS best-practices guide covers the rules of thumb that experienced Solid developers ship by.

For the tool profile itself (capabilities, license, ecosystem, current version), see the SolidJS tool entry on Solomon Signal.

SolidStart for full-stack: SSR, routing, actions, data loaders

For a remote contractor whose client wants more than a static page, SolidStart is the meta-framework. It is to SolidJS what Next is to React, or what SvelteKit is to Svelte. It ships server-side rendering, file-system routing, server actions (call server functions directly from client code with type safety), and data loaders. It is built on Vinxi (the deployment-target abstraction the SolidJS team maintains) which means one config object deploys cleanly to Vercel, Netlify, Cloudflare Pages, Cloudflare Workers, AWS Lambda, and Bun.

To scaffold a SolidStart project from scratch:

npm init solid@latest my-fullstack-app
cd my-fullstack-app
npm install
npm run dev

The CLI asks whether you want TypeScript, a router (SolidStart's router is @solidjs/router), TailwindCSS, and a few other defaults. For client work the safe answer is: TypeScript yes, router yes, Tailwind yes, the rest no.

The directory structure SolidStart generates:

my-fullstack-app/
  app.config.ts        (Vinxi config — deploy adapters, route handlers)
  src/
    app.tsx            (root component — wraps every route)
    entry-client.tsx   (client hydration entry)
    entry-server.tsx   (SSR entry)
    routes/
      index.tsx        (the / route)
      about.tsx        (the /about route)
      blog/
        [slug].tsx     (the /blog/<dynamic> route)
        index.tsx      (the /blog route)
    components/        (your shared components)
    lib/               (your shared utilities)
  public/              (static assets)

File-system routing follows the same conventions every modern meta-framework uses. A file at src/routes/about.tsx becomes the route /about. A directory with [slug].tsx becomes a dynamic route. The index.tsx inside a directory becomes that directory's root path.

A SolidStart route with a data loader and server-only logic, src/routes/clients/[id].tsx:

import { createAsync, query } from '@solidjs/router';
import { Suspense } from 'solid-js';
import { useParams } from '@solidjs/router';

const getClient = query(async (id: string) => {
  'use server';
  const res = await fetch(`https://api.example.com/clients/${id}`, {
    headers: { Authorization: `Bearer ${process.env.API_KEY}` },
  });
  return res.json();
}, 'client');

export default function ClientPage() {
  const params = useParams();
  const client = createAsync(() => getClient(params.id));

  return (
    <main>
      <h1>Client detail</h1>
      <Suspense fallback={<p>Loading…</p>}>
        <pre>{JSON.stringify(client(), null, 2)}</pre>
      </Suspense>
    </main>
  );
}

The 'use server' directive marks the function body as server-only. The bundle never ships the API_KEY to the browser. The query helper memoizes the result per argument. The createAsync primitive integrates with Suspense so the route renders with a fallback while data resolves. For a solo contractor handling client API keys, that one directive prevents an entire class of mistakes. A leaked secret in a public bundle is the kind of incident that ends contracts.

For the SolidStart adapter configuration that targets a specific deploy host, edit app.config.ts:

import { defineConfig } from '@solidjs/start/config';

export default defineConfig({
  server: {
    preset: 'vercel',   // or 'netlify', 'cloudflare-pages', 'bun', 'node-server'
  },
});

That preset is the entire deploy-target switch. Change vercel to netlify and your next npm run build produces Netlify-compatible output. For a contractor whose client portfolio includes a Vercel client, a Netlify client, and a Cloudflare client, that one-line switch is what makes SolidStart practical.

The signal-first mental model: createSignal, createMemo, createEffect

The single concept that distinguishes SolidJS from React is the signal-first mental model. In React the unit of update is the component. When state changes, the component function re-runs, the virtual DOM gets diffed, and the real DOM gets patched. In SolidJS the unit of update is the signal. When a signal changes, only the JSX expressions that read that signal re-execute, and only the specific DOM nodes those expressions produce get updated. The component function runs once and then never again for the lifetime of the component.

There are three primitives that build everything in SolidJS.

createSignal creates a reactive value:

import { createSignal } from 'solid-js';

const [count, setCount] = createSignal(0);
console.log(count());     // 0
setCount(5);
console.log(count());     // 5
setCount(c => c + 1);     // functional update

createMemo creates a derived reactive value. It re-computes only when its dependencies (signals it reads) change, and only the JSX that reads the memo re-runs on the next change:

import { createSignal, createMemo } from 'solid-js';

const [firstName, setFirstName] = createSignal('Ada');
const [lastName, setLastName] = createSignal('Lovelace');
const fullName = createMemo(() => `${firstName()} ${lastName()}`);

console.log(fullName());  // "Ada Lovelace"
setFirstName('Grace');
console.log(fullName());  // "Grace Lovelace"

createEffect runs a side effect whenever the signals it reads change. It is the SolidJS equivalent of React's useEffect, except you do not pass a dependency array. SolidJS tracks dependencies automatically by reading which signals the effect callback touches on its first run:

import { createSignal, createEffect } from 'solid-js';

const [count, setCount] = createSignal(0);

createEffect(() => {
  console.log('count is now', count());
  document.title = `Count: ${count()}`;
});

setCount(1);  // logs "count is now 1", updates document.title
setCount(2);  // logs "count is now 2", updates document.title

For a remote async-first developer, the implication of this model is that you stop spending mental cycles on useMemo and useCallback discipline. There is no stale-closure problem because the component function does not re-run. There is no dependency-array footgun because the dependencies are tracked automatically. The class of bugs that React produces when a useEffect dependency is missed or when a callback identity changes unexpectedly simply does not exist in SolidJS. For a solo developer with no team to catch those bugs in PR review, that absence is worth more than any single feature on the marketing page.

There is one subtle gotcha. If you destructure a signal's value into a local variable inside JSX, you lose reactivity. The reactivity is on the act of calling the getter, not on the value the getter returns. So this is wrong:

function Wrong() {
  const [user, setUser] = createSignal({ name: 'Ada' });
  const u = user();  // captures the value once; subsequent setUser calls won't update the JSX
  return <p>{u.name}</p>;
}

And this is right:

function Right() {
  const [user, setUser] = createSignal({ name: 'Ada' });
  return <p>{user().name}</p>;  // calls the getter inside JSX; updates on every change
}

The fix is to keep the getter call inside the JSX or inside a createMemo. Once you have written 200 lines of SolidJS this becomes muscle memory. Until then, the SolidJS best-practices guide covers the half-dozen reactivity gotchas a solo developer is statistically most likely to trip on.

Async patterns: Resource, Suspense, error boundaries

The remote-async developer's most common bug is the third-party API that stalls. The pattern that handles it cleanly in SolidJS is createResource plus <Suspense> plus <ErrorBoundary>. Three primitives, one declarative async story.

createResource fetches data and returns a signal whose value is the fetched data plus a status flag:

import { createResource, Suspense, ErrorBoundary } from 'solid-js';

async function fetchClient(id: string) {
  const res = await fetch(`/api/clients/${id}`);
  if (!res.ok) throw new Error(`Client ${id} fetch failed: ${res.status}`);
  return res.json();
}

function ClientCard(props: { id: string }) {
  const [client] = createResource(() => props.id, fetchClient);

  return (
    <ErrorBoundary fallback={(err) => <p>Error: {err.message}</p>}>
      <Suspense fallback={<p>Loading client…</p>}>
        <article>
          <h3>{client()?.name}</h3>
          <p>{client()?.email}</p>
        </article>
      </Suspense>
    </ErrorBoundary>
  );
}

When the client id prop changes, the resource re-fetches. While the fetch is pending, the <Suspense> boundary renders its fallback. If the fetch throws, the <ErrorBoundary> catches the error and renders the error fallback with the actual error object. No useEffect. No useState. No status flags juggled by hand.

For a solo remote engineer this is the highest-leverage pattern in the whole framework. The 3 am API stall scenario plays out without a meltdown: your component renders the Loading fallback, the API eventually times out, the ErrorBoundary catches it, the user sees "Error: timeout" instead of a white screen, and you find the error in Sentry the next morning instead of getting paged.

For richer async patterns (request deduplication, optimistic updates, mutation invalidation) SolidStart's query and action primitives (covered in the SolidStart docs at docs.solidjs.com/solid-start) extend createResource with cache invalidation and revalidation. The pattern is the same shape: server function on the server, declarative consumer on the client, Suspense boundary on the rendering side.

Debugging in isolation: devtools and the Solid debugger

The remote async developer has no pair to walk through a bug. The debugger has to be self-sufficient. SolidJS ships an official browser extension, Solid DevTools, available on Chrome Web Store and Firefox Add-ons. The extension inspects the live signal graph: which signals exist, what they currently hold, which effects depend on them, and what triggered the most recent updates.

Install the extension, open your dev server, open Chrome's devtools, and the Solid tab appears in the panel list. The tree on the left shows the component hierarchy. Click a component and the right panel shows its signals, their current values, and the JSX expressions or effects subscribed to each. When you change a signal in your code (via the browser console or by interacting with the page), the panel updates in real time.

There is a second debugging primitive built into the library: console.log works exactly the way you expect, but untrack is the escape hatch when you need to read a signal without subscribing to it inside an effect:

import { createEffect, untrack } from 'solid-js';

createEffect(() => {
  // count() is tracked
  // user() is read but not tracked
  console.log(`count: ${count()}, user: ${untrack(user).name}`);
});

For an async-first remote developer, the discipline that saves the most time is logging the signal graph at startup, not at the breakpoint. Add a createEffect(() => console.log({ count: count(), user: user(), client: client() })) near the top of your app shell during development. Every signal change logs once. When something is wrong you scroll the console and the diff is visible. No stepping through stack frames at 3 am.

Working with TypeScript: solid-js types and the JSX namespace

For a solo remote contractor shipping client work, TypeScript is not optional. The compile-time check is the team review you don't have. SolidJS ships first-class TypeScript support via the solid-js package, and the solidjs/templates/ts starter is the recommended cold-start.

The two type imports you actually use day-to-day:

import { type Component, type ParentComponent } from 'solid-js';
import { type JSX } from 'solid-js';

Component<P> is the type for a component function that takes props of type P. ParentComponent<P> is for a component that also accepts a children prop. The JSX namespace exposes the type for any element attribute or event you might want to type explicitly.

A typed component:

import { type Component, type ParentComponent } from 'solid-js';

interface BadgeProps {
  label: string;
  variant?: 'success' | 'warning' | 'error';
}

const Badge: Component<BadgeProps> = (props) => {
  return (
    <span class={`badge badge-${props.variant ?? 'success'}`}>
      {props.label}
    </span>
  );
};

interface CardProps {
  title: string;
}

const Card: ParentComponent<CardProps> = (props) => {
  return (
    <article class="card">
      <h3>{props.title}</h3>
      {props.children}
    </article>
  );
};

There is one important non-obvious typing detail. In SolidJS you do not destructure props at the top of a component function (e.g., const { label, variant } = props;). Destructuring breaks reactivity because props in SolidJS are themselves reactive: they update when the parent passes new values. Always access props as props.label and props.variant inside the JSX or inside a memo. The compiler will not catch this for you. The Solid DevTools panel will show which props are reactive and which have been frozen.

For a deeper TypeScript pattern reference for your daily SolidJS work, the SolidJS best-practices guide on Solomon Signal includes a TypeScript section covering generic components, ref typing, event-handler typing, and the conventions for typing the splitProps helper.

Deploying as a remote contractor: Vercel, Netlify, Cloudflare adapters

A remote contractor's deploy story is messier than a staff engineer's. You ship to three different clients on three different hosts, you maintain separate environment variables for each, you cannot afford a credential leak between projects, and the rollback model has to work when you are six time zones away from the client whose preview just broke.

SolidStart handles all three deploy targets through one config preset. The pattern is the same: pick the preset in app.config.ts, set the environment variables in the host's dashboard, push a git branch, get a preview URL.

For Vercel:

// app.config.ts
import { defineConfig } from '@solidjs/start/config';

export default defineConfig({
  server: { preset: 'vercel' },
});

Connect the repo to Vercel via the dashboard. Vercel auto-detects SolidStart, runs npm run build, and deploys the output. The vinxi build step generates the Vercel-specific function format under .vercel/output/. Environment variables go in the Vercel project's Settings → Environment Variables; client-prefix them with VITE_PUBLIC_ if they must reach the browser, leave them unprefixed if they are server-only.

For Netlify:

export default defineConfig({
  server: { preset: 'netlify' },
});

The build produces .netlify/functions-internal/ and a static dist/. The Netlify auto-detect picks up the SolidStart preset and configures the redirects file automatically. Environment variables go in Site Settings → Environment Variables. Same client vs server prefix convention.

For Cloudflare Pages:

export default defineConfig({
  server: { preset: 'cloudflare-pages' },
});

The build produces a _worker.js file plus a static dist/. The Pages dashboard auto-detects and runs the build. Environment variables go in Pages → Settings → Environment Variables, separated into Production and Preview tiers. Cloudflare Pages also surfaces a per-deploy URL for every git branch, which is the rollback story: if a deploy breaks, the previous deploy's URL is one click away in the dashboard.

The environment-variable isolation pattern, the one that prevents the contractor's biggest fear, is built into Vite (which Vinxi inherits). Any env var that starts with VITE_ or VITE_PUBLIC_ is inlined into the client bundle at build time and shipped to the browser. Any env var without that prefix is server-only and never reaches the browser bundle. The check is a compile-time enforcement, not a runtime convention. Leaking a server-only secret to the client requires you to explicitly prefix it. For a contractor managing keys for three clients, that one rule prevents the most expensive class of mistakes you can make as a remote engineer.

For multi-client work, the practical playbook I run is: one git repo per client, one local .env.local per repo (never committed), one host project per client (Vercel project A, Netlify site B, Cloudflare Pages project C), one preview branch per feature you want to show the client before merge. The git branch is the audit trail. The preview URL is the demo. The merge to main is the deploy. The previous deploy's URL is the rollback. No shared state between clients. No leaked secrets. No 3 am pages.

When SolidJS isn't right for remote-async work

A page that tells you only the good news is a page you should not trust. There are cases where SolidJS is the wrong call for a remote-worker contractor's project, and the responsible thing is to flag them upfront.

The first case is the client whose internal team is already deep on React. If your client's in-house developers will eventually own the codebase, you are doing them a disservice by handing off a SolidJS app to a team that has never touched it. The migration off SolidJS is documented (the alternatives page covers it) but you are billing a six-month learning tax to a client who expected to onboard the codebase on their existing skill set. In that scenario, pick React or Next.js, accept the slower dev loop, and ship the framework the team already knows.

The second case is the client app that depends on a React-only library with no SolidJS equivalent. The two most common cases are complex rich-text editors (Lexical, the React-native Slate fork, ProseMirror via TipTap which has a React wrapper that has no SolidJS equivalent at the same depth) and certain paid commercial UI suites (Ant Design Pro, Material UI X DataGrid Pro, KendoReact). If your client's spec requires one of those, the migration cost of building the SolidJS equivalent is higher than the productivity tax of using React. Pick React.

The third case is the project where the contractor expects to hand off ongoing development to a different freelancer in six months. The pool of SolidJS contractors is smaller than the pool of React contractors by roughly two orders of magnitude on most job-board telemetry. If the next contractor is harder to find than the current one, you owe the client the framework with the larger pool.

For all three cases, the right next step is the comprehensive SolidJS alternatives page on Solomon Signal. That page ranks twelve reactive UI frameworks (React, Vue 3, Svelte 5, Preact, Qwik, Lit, Marko, Voby, Inferno, Mithril, Alpine.js, and vanilla web components), shows the migration path from SolidJS to each, and identifies which axis (bundle size, ecosystem, hiring pool, learning curve, SSR maturity) each alternative wins on. If you are picking between staying on SolidJS for a new project or switching to something else, that is the page to read alongside this one.

The head-to-head detail against React specifically lives at SolidJS vs React on Solomon Signal. If your decision is binary between those two, that comparison shortens the read.

Casey one more time. I have moved exactly one client off SolidJS in two years. The client's spec changed to require a Lexical rich-text editor. I migrated to Next 14 in three weeks. The migration was painful but the client's app was small enough that it was the right call. Every other client project I have shipped on SolidJS is still on SolidJS, still deploying weekly, still under 50 KB of JavaScript on the main bundle, still loading on hotel Wi-Fi in under two seconds. The framework keeps its promises.

Free resources for the solo remote learner

The official SolidJS materials are the best starting point and they are free. The interactive tutorial at solidjs.com/tutorial walks every primitive in a browser-based playground; you write code on the left, see it run on the right, and the lessons are short enough to do one over morning coffee. The documentation at docs.solidjs.com (the canonical 2026 reference, replacing the older solidjs.com docs that are slowly being deprecated) covers the framework, SolidStart, and the official ecosystem libraries (@solidjs/router, @solidjs/meta, @solid-primitives/*).

The Solid Discord (linked from the GitHub repo at github.com/solidjs/solid) is the fastest path to a real human answering a stuck question. For a solo remote developer, this is the team channel you don't have at work. The community is small enough that the maintainers themselves regularly answer questions in the help channels. Ask a real question with code and you usually get a real answer within hours.

For paid resources, the SolidJS Crash Course on YouTube channels (Traversy Media, Theo, others) covers the basics in a video format if you learn that way. The book-length resources are still thin compared to React, but the official docs are comprehensive enough that you do not actually need a book.

For peer persona-narrative reading on Solomon Signal, the pnpm for content creators guide covers the package-manager side of the solo remote developer's stack, with the same Casey-narrative voice and the same multi-project laptop-as-studio framing. Read it after this page if pnpm is not already part of your stack.

For the external authority links, the canonical sources are the SolidJS homepage and the SolidJS documentation. Bookmark both. Everything in this guide is verifiable against the official docs.

Frequently asked questions

Is SolidJS production-ready in 2026? Yes. SolidJS 1.0 shipped in 2022 and the framework has been in continuous production use by mid-sized companies (Builder.io, Cloudinary, the Hugging Face dashboard team, others) for several years. The 1.9 release line is the current stable as of the 1.9.0 release in September 2024, with patch releases ongoing through 2026. SolidStart left beta in late 2024 and is the recommended meta-framework for new full-stack projects.

SolidJS vs React for solo remote work: which should I pick? Pick SolidJS if your bottleneck is your own velocity, your bundle size is a constraint, and your client does not have an in-house team that will own the codebase. Pick React if your client has an in-house React team, if you need a specific React-only library (rich-text editors, paid UI suites), or if you expect to hand off to another freelancer who is more likely to know React than Solid. For the deeper detail, see the SolidJS vs React head-to-head on Solomon Signal.

Can I freelance with SolidJS without the team-Solid-familiarity risk? Yes, for projects you are shipping end-to-end and supporting indefinitely. The risk is real only when the codebase will be handed off to an in-house team that does not know SolidJS. If you build the app and you support it, the framework choice is invisible to the client and the small SolidJS community is not a constraint on your individual productivity. Solomon Signal's SolidJS alternatives page documents the migration path if a future handoff forces a framework change.

SolidStart vs Next.js for solo SSR work: which is faster to ship? SolidStart is faster to cold-start, faster on hot-reload, smaller in the deployed bundle, and has a smaller API surface to learn. Next.js has a larger ecosystem of plugins, better-known answers on Stack Overflow, and more first-party integrations with hosted services (Vercel auth, Vercel analytics, the Next App Router ecosystem). For a solo developer optimizing for velocity, SolidStart wins on the technical axes; Next wins on the "how do I do X" answer-availability axis. For client work where neither team nor handoff is a constraint, ship SolidStart.

What are the best SolidJS dev-tools for async debugging? The official Solid DevTools browser extension (Chrome and Firefox) plus a createEffect that logs the signal graph at app startup. The combination gives you a live view of every signal, every effect, and every dependency edge between them. The browser console plus console.log works exactly the way you expect, with no special wrapper or hook required. For network debugging, the Vinxi dev server logs every server-function call with full timing data; the SolidStart build outputs a node ./dev mode that prints the request/response cycle for every 'use server' invocation.

Is SolidJS too small a community for client work? For solo client work, no. The community is large enough that the framework is in active development, the docs are comprehensive, the Discord answers fast, and the npm ecosystem has the primitives you need. The community is too small if your project depends on a third-party library that does not yet exist in SolidJS form (specifically: deep rich-text editors, certain paid commercial UI suites, niche enterprise integrations). For 80 percent of client projects (marketing sites, dashboards, internal tools, e-commerce frontends, content sites) the SolidJS ecosystem is more than sufficient.

Should I learn SolidStart before SolidJS, or the other way around? Learn SolidJS first. The signal primitives (createSignal, createMemo, createEffect, createResource) and the JSX patterns are the foundation; SolidStart is a layer of meta-framework concerns (routing, SSR, server actions) on top of that foundation. The interactive tutorial at solidjs.com/tutorial covers the framework basics in roughly two hours; once you can build a Counter and a TodoList in plain SolidJS, the SolidStart docs become straightforward to follow.

Where do I learn pnpm for the SolidJS multi-project workflow? The pnpm for content creators guide on Solomon Signal covers the multi-project laptop-as-studio package-management story in depth. The patterns there (workspace at the root, per-project package.json, the global content-addressable store) apply to a multi-client SolidJS setup with no modification.