But first, the elephant in the room: Solid is not React. It looks like React, and that's both a blessing and a trap.

The one thing you need to internalize

In Solid, the component function is a constructor, not a render function.

In React, your component function re-runs on every state change. Every. Single. Time. Hooks, variables, derived values - all re-evaluated. In Solid, the component function runs once. It sets things up, wires the reactive graph together, and never runs again. All subsequent updates happen through signal subscriptions that surgically update the specific DOM nodes that care about the change.

Once you truly get this, every other difference clicks into place. Signals are getter functions because you need live references. Effects auto-track because they subscribe at call-time. Props can't be destructured because that reads values eagerly outside a tracking scope. <Show> and <For> exist because there's no virtual DOM to diff.

Let that sink in. Now let's get practical.

Solid vs. React: the primitives

On the surface, Solid and React feel similar - which is a good thing if you're coming from React land. Both use JSX to output HTML. But the similarities are surface-level. How they handle state, effects, iteration, conditional rendering, and lifecycle is fundamentally different.

Let's go through each, side by side.

1. State: useState vs createSignal

React:

function Counter() {
  // This entire function re-runs on every setCount call
  const [count, setCount] = useState(0);
  console.log("rendered"); // fires every time

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

Solid:

function Counter() {
  // This function runs ONCE
  const [count, setCount] = createSignal(0);
  console.log("setup"); // fires exactly once

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

The gotcha that'll bite you first: count is a function in Solid. You call count() to read the value. Writing {count} without the parentheses will render the function reference itself - not the number. This is, by far, the most common mistake React developers make when starting with Solid.

2. Effects: useEffect vs createEffect

React requires you to manually declare dependencies. Solid tracks them automatically.

React:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    let cancelled = false;
    fetchUser(userId).then(data => {
      if (!cancelled) setUser(data);
    });
    return () => { cancelled = true; }; // cleanup via return
  }, [userId]); // manual deps - forget this and you have a bug

  return <div>{user?.name}</div>;
}

Solid:

function UserProfile(props) {
  const [user, setUser] = createSignal(null);

  createEffect(() => {
    // Solid auto-tracks props.userId - no deps array
    const controller = new AbortController();
    fetchUser(props.userId, { signal: controller.signal }).then(setUser);

    onCleanup(() => controller.abort()); // cleanup via onCleanup()
  });

  return <div>{user()?.name}</div>;
}

Key differences to watch for:

• No deps array. Solid tracks what you read inside the effect automatically. If it reads props.userId, it re-runs when that changes. Period.

• Cleanup uses onCleanup(), not a return value. Import it from solid-js.

• No empty deps array pattern. In React, useEffect(() => {...}, []) means "run once on mount." In Solid, use onMount() for that.

• Timing is different. createEffect runs synchronously after the reactive graph updates - closer in spirit to React's useLayoutEffect than useEffect, though the exact timing relative to browser paint depends on when the signal change was triggered. If you need explicit dependency control, Solid has on():

import { on } from "solid-js";

createEffect(on(count, (value, prev) => {
  console.log("count changed from", prev, "to", value);
}));

3. Memos: useMemo vs createMemo

React's useMemo is a performance optimization, not a semantic guarantee - React may discard cached values. Solid's createMemo is a reactive primitive that creates a derived signal. It's guaranteed to be lazy and cached.

React:

function FilteredList({ items, filter }) {
  const filtered = useMemo(
    () => items.filter(i => i.category === filter),
    [items, filter]
  );
  return <ul>{filtered.map(i => <li key={i.id}>{i.name}</li>)}</ul>;
}

Solid:

function FilteredList(props) {
  const filtered = createMemo(() =>
    props.items.filter(i => i.category === props.filter)
  );

  return <ul>
    <For each={filtered()}>{i => <li>{i.name}</li>}</For>
  </ul>;
}

Same deal: createMemo returns a getter function - call filtered(), not filtered.

4. Conditional rendering: ternaries vs <Show>

In React, ternaries work because the virtual DOM diffs everything anyway - it papers over the cost for you. In Solid, there's no virtual DOM hiding that cost. Raw ternaries can cause DOM nodes to be torn down and recreated on every toggle. <Show> gives you efficient conditional rendering without the diffing overhead.

React:

function Greeting({ user }) {
  return (
    <div>
      {user ? (
        <h1>Welcome back, {user.name}!</h1>
      ) : (
        <h1>Please sign in.</h1>
      )}
    </div>
  );
}

Solid:

function Greeting(props) {
  return (
    <div>
      <Show when={props.user} fallback={<h1>Please sign in.</h1>}>
        {(user) => <h1>Welcome back, {user().name}!</h1>}
      </Show>
    </div>
  );
}

The callback child form {(user) => ...} gives you a narrowed, guaranteed-truthy value. But note: user is a getter function in Solid, hence user().name.

For multiple conditions, <Switch> / <Match> is your friend:

<Switch fallback={<p>Not found</p>}>
  <Match when={state() === "loading"}><Spinner /></Match>
  <Match when={state() === "error"}><ErrorView /></Match>
  <Match when={state() === "ready"}><Content /></Match>
</Switch>

5. List rendering: .map() vs <For>

In React, .map() recreates the virtual DOM array every render, then diffs with keys. In Solid, <For> tracks each item by reference - only affected DOM nodes get created, moved, or removed.

React:

function TodoList({ todos }) {
  return (
    <ul>
      {todos.map(todo => (
        <li key={todo.id}>{todo.text}</li>
      ))}
    </ul>
  );
}

Solid:

function TodoList(props) {
  return (
    <ul>
      <For each={props.todos}>
        {(todo, index) => <li>{todo.text}</li>}
      </For>
    </ul>
  );
}

A couple of things:

• No key prop needed. <For> tracks by reference automatically.

• index is a signal. Call index() to get the number. The item itself (todo) is not a signal - it's the raw value.

• Using .map() in Solid works - it won't crash your app - but it creates a non-keyed list that re-renders everything on every update. Essentially, it makes Solid behave like a slow React app (and if you do, I have questions). <For> is the correct tool for the job.

6. Refs: useRef vs… just a variable

This one's refreshingly simple.

React:

function AutoFocus() {
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  return <input ref={inputRef} />;
}

Solid:

function AutoFocus() {
  let inputRef;

  onMount(() => {
    inputRef.focus(); // no .current - it IS the element
  });

  return <input ref={inputRef} />;
}

No .current indirection. No hook. Just a variable. Since Solid components run once, a plain let persists for the component's lifetime. This also means you don't need useRef as a "mutable box" - any let variable already serves that purpose.

7. Props: the destructuring trap

This is the gotcha that bites hardest, because it works perfectly in React.

React - destructuring is totally safe:

function Greeting({ name, age }) {
  return <p>{name} is {age} years old</p>;
}

Solid - destructuring BREAKS reactivity:

// BAD - values captured once, never update
function Greeting({ name, age }) {
  return <p>{name} is {age} years old</p>;
}

// GOOD - reactive access through the props proxy
function Greeting(props) {
  return <p>{props.name} is {props.age} years old</p>;
}

Why? Solid props are a Proxy. Accessing props.name inside JSX creates a reactive subscription. Destructuring eagerly reads the values during component setup (which runs once), severing the reactive connection forever.

When you need defaults or to split props for forwarding, use mergeProps and splitProps:

import { splitProps, mergeProps } from "solid-js";

function Button(props) {
  const merged = mergeProps({ variant: "primary", size: "md" }, props);
  const [local, rest] = splitProps(merged, ["variant", "size"]);

  return (
    <button class={`btn-\({local.variant} btn-\){local.size}`} {...rest}>
      {props.children}
    </button>
  );
}

8. Building your own primitives

This is where Solid's "primitives, not frameworks" philosophy really pays off. In React, custom hooks are functions that call other hooks - but they re-run on every render, so you're always thinking about memoization and stale closures. In Solid, a custom primitive is just a function that wires up signals - it runs once, and the reactive graph handles the rest.

Here's a practical example: a createFetch primitive that handles loading, error, success, and data states.

import { createSignal, createEffect, onCleanup } from "solid-js";

function createFetch(urlFn) {
  const [data, setData] = createSignal(null);
  const [error, setError] = createSignal(null);
  const [loading, setLoading] = createSignal(true);

  createEffect(() => {
    const url = urlFn(); // tracked - re-runs when URL changes
    const controller = new AbortController();

    setLoading(true);
    setError(null);

    fetch(url, { signal: controller.signal })
      .then((res) => {
        if (!res.ok) throw new Error(`\({res.status} \){res.statusText}`);
        return res.json();
      })
      .then((json) => {
        setData(() => json);
        setLoading(false);
      })
      .catch((err) => {
        if (err.name !== "AbortError") {
          setError(() => err);
          setLoading(false);
        }
      });

    onCleanup(() => controller.abort());
  });

  return { data, error, loading };
}

Use it in a component:

function UserProfile(props) {
  const { data, error, loading } = createFetch(
    () => `/api/users/${props.userId}`
  );

  return (
    <Switch>
      <Match when={loading()}>
        <Spinner />
      </Match>
      <Match when={error()}>
        <p>Error: {error().message}</p>
      </Match>
      <Match when={data()}>
        {/* data() is the resolved JSON */}
        <h1>{data().name}</h1>
        <p>{data().email}</p>
      </Match>
    </Switch>
  );
}

Notice what's not here: no dependency arrays, no memoization, no stale closure bugs. The URL is a getter function (urlFn()), so it's tracked automatically. When props.userId changes, the effect re-runs, the previous request is aborted, and the new one fires. All of this wired up in a reusable primitive that composes like a building block.

This is the pattern you'll reach for constantly in Solid - extract reactive logic into composable primitives that return signals. The Solid Primitives community library is built entirely on this idea.

Quick reference cheat sheet

Next.js vs SolidStart: the metaframework layer

With the primitives covered, let's zoom out. You're not just migrating from React to Solid - you're migrating from Next.js to SolidStart. That means routing, SSR, server-side code execution, API endpoints, data fetching, and all the other metaframework concerns. This is the part where I could just give you a table and call it a day. But some of these differences are subtle enough so that it warrants drawing a clearer line between the two.

Routing

Both frameworks use file-based routing, but the conventions differ.

Next.js (App Router):

app/
  page.tsx            → /
  blog/
    page.tsx          → /blog
    [slug]/
      page.tsx        → /blog/:slug
  (marketing)/
    about/
      page.tsx        → /about
  layout.tsx          → root layout
  loading.tsx         → loading UI
  error.tsx           → error boundary

Next.js uses special file conventions - page.tsx, layout.tsx, loading.tsx, error.tsx, not-found.tsx - each with specific roles. Route groups use parentheses (group). Layouts are implicit: a layout.tsx wraps all pages in its directory and below. Dynamic segments use [param], catch-all uses [...param].

SolidStart:

routes/
  index.tsx           → /
  blog/
    index.tsx         → /blog
    [slug].tsx        → /blog/:slug
  about.tsx           → /about
  blog.tsx            → layout for /blog/*

SolidStart keeps it simpler. A file's name is the route - no page.tsx convention. Dynamic segments use [param], optional params use [[param]], catch-all uses [...param]. Layouts work by naming a file the same as a directory - blog.tsx alongside a blog/ folder makes blog.tsx the layout. Child routes render via props.children:

// routes/blog.tsx - layout for all /blog/* routes
export default function BlogLayout(props) {
  return (
    <div class="blog-wrapper">
      <nav>Blog nav here</nav>
      {props.children}
    </div>
  );
}

Route groups use parentheses (group)/, same idea as Next.js - directories wrapped in () that organize routes without affecting URL structure.

The key difference: Next.js has more special files with implicit behavior (loading states, error boundaries, not-found pages are all file-convention driven). SolidStart gives you the routing structure and lets you compose <Suspense>, <ErrorBoundary>, and <Show> yourself. Fewer conventions to memorize, more explicit control. 8/10 physicians agree that less magic in your code can have a positive impact on one's mental health.

SSR and rendering modes

Next.js gives you a buffet of rendering strategies:

• Static (SSG) - pages pre-rendered at build time

• Server-side (SSR) - rendered on each request

• Incremental Static Regeneration (ISR) - static pages that revalidate after a set time

• Partial Pre-rendering (PPR) - static shell with streaming dynamic holes (React 19.2)

• React Server Components - components that run on the server and ship zero client JS

The rendering mode is determined by what you do in the component. Use "use cache"? Cached. Read cookies() or headers()? Dynamic. Five rendering strategies, and you don't pick one - the framework infers it from your code. What could possibly go wrong.

SolidStart is more straightforward:

• SSR is on by default (ssr: true). Every route is server-rendered.

• SSG/prerendering is opt-in via config:

// app.config.ts
export default defineConfig({
  server: {
    prerender: {
      routes: ["/", "/about"],
      // or: crawlLinks: true
    },
  },
});

• SPA mode if you want it: ssr: false.

• Streaming SSR is supported out of the box - <Suspense> boundaries become streaming boundaries automatically.

No ISR, no PPR, no implicit mode switching. You pick a mode and that's what you get. If you need per-route control, you handle it with server functions and caching primitives, not framework magic.

Server-side code execution

This is where the philosophies diverge most.

Next.js has three main mechanisms for running code on the server:

1. Server Components (the default in App Router) - your component function runs on the server. It can await data, touch the filesystem, query databases. The rendered output streams to the client as RSC Flight payload. The client never sees the component's JavaScript.

// This is a Server Component by default
async function ProductPage({ params }) {
  const { id } = await params;
  const product = await db.products.find(id);
  return <ProductDisplay product={product} />;
}

1. Server Actions - functions marked with "use server" that handle mutations. Invoked from forms or client code, executed on the server.

"use server";
export async function addToCart(formData) {
  const productId = formData.get("productId");
  await db.cart.add(productId);
  revalidatePath("/cart");
}

1. Route Handlers - traditional API endpoints in app/api/*/route.ts files.

The boundary between server and client is managed by directives: "use client" marks a component as client-side, "use server" marks a function as server-only. The mental model of what runs where is the number one source of confusion in the App Router, per community surveys.

SolidStart uses a single, consistent mechanism: server functions.

Any function annotated with "use server" runs on the server. That's it. No Server Components, no implicit server/client boundary - you explicitly opt into server execution per function.

// A server function for reading data
const getProduct = query(async (id) => {
  "use server";
  return await db.products.find(id);
}, "product");

// A server function for mutations
const addToCart = action(async (formData) => {
  "use server";
  const productId = formData.get("productId");
  await db.cart.add(productId);
});

On the component side, you consume these with createAsync:

function ProductPage(props) {
  const product = createAsync(() => getProduct(props.params.id));

  return (
    <Show when={product()}>
      {(p) => <ProductDisplay product={p()} />}
    </Show>
  );
}

The difference in mental model is significant. If you've ever stared at a Next.js component wondering whether it runs on the server, the client, or both depending on the phase of the moon - yeah, that goes away. In SolidStart, all components run in the same context (SSR'd on the server, hydrated on the client) - you only think about which functions run on the server. One boundary to manage instead of two.

Data fetching

Next.js:

// Server Component - just await (server only)
async function Posts() {
  const posts = await db.posts.findMany();
  return <PostList posts={posts} />;
}

// With caching (v16+)
"use cache";
async function CachedPosts() {
  const posts = await db.posts.findMany();
  return <PostList posts={posts} />;
}

// Client-side - use SWR or TanStack Query
"use client";
function LivePosts() {
  const { data } = useSWR("/api/posts", fetcher);
  return <PostList posts={data} />;
}

Next.js has gone through three caching models in three major versions. v14 cached fetch() calls aggressively by default (which confused everyone). v15 removed default caching. v16 introduced "use cache" as an explicit opt-in. On top of that, there are four distinct cache layers: Request Memoization, Data Cache, Full Route Cache, and Router Cache. If you've ever felt like you needed a PhD in cache invalidation just to fetch a list of blog posts, you're not alone.

SolidStart:

// Define a cached query with a key
const getPosts = query(async () => {
  "use server";
  return await db.posts.findMany();
}, "posts");

// Preload in route config
export const route = {
  preload: () => getPosts(),
};

// Consume in component
function Posts() {
  const posts = createAsync(() => getPosts());

  return (
    <Suspense fallback={<Loading />}>
      <For each={posts()}>
        {(post) => <PostCard post={post} />}
      </For>
    </Suspense>
  );
}

One caching primitive (query), one consumption primitive (createAsync), explicit cache keys, and <Suspense> for loading states. Mutations go through action(). Cache invalidation targets specific keys. That's the whole model.

Cache invalidation, cookies, and revalidation

Three things you'll need almost immediately after setting up data fetching:

Invalidating cache from an action:

When a mutation succeeds, you want to bust the relevant cache. In Next.js, you call revalidatePath() or revalidateTag(). In SolidStart, you use revalidate() with the cache key:

import { revalidate, action } from "@solidjs/router";

const addPost = action(async (formData) => {
  "use server";
  await db.posts.create({
    title: formData.get("title"),
    body: formData.get("body"),
  });
  revalidate("posts"); // bust the "posts" cache key
});

The cache key is the second argument you passed to query(). This is why explicit cache keys matter - you can surgically invalidate exactly what changed.

Cookies and cached queries:

In Next.js, reading cookies() or headers() inside a cached function implicitly makes it dynamic - the cache key includes the cookie values, but this behavior is invisible and easy to get wrong.

In SolidStart, if your server function reads cookies (via the request event), you need to be aware that query() caches by arguments only. The cookie value isn't automatically part of the cache key. If different users should see different data, pass a user identifier as an argument to the query, or use revalidate() on auth state changes:

const getUserData = query(async (userId) => {
  "use server";
  const session = getSession(); // read from cookie
  if (!session) throw redirect("/login");
  return await db.users.find(userId);
}, "userData");

Revalidation timing:

Next.js has ISR with revalidate: 60 for time-based cache expiry. SolidStart doesn't have a built-in time-based revalidation primitive. Your options:

• Explicit invalidation via revalidate() in actions (the recommended approach)

• revalidate() on the client to force a refresh of specific cache keys

• HTTP cache headers on your server functions if you want CDN-level caching:

const getPosts = query(async () => {
  "use server";
  const event = getRequestEvent();
  event.response.headers.set("Cache-Control", "s-maxage=60, stale-while-revalidate");
  return await db.posts.findMany();
}, "posts");

This is more explicit than ISR, but it's also more predictable - you know exactly what's cached and for how long.

API endpoints

Next.js uses Route Handlers:

// app/api/posts/route.ts
export async function GET(request: Request) {
  const posts = await db.posts.findMany();
  return Response.json(posts);
}

export async function POST(request: Request) {
  const body = await request.json();
  const post = await db.posts.create(body);
  return Response.json(post, { status: 201 });
}

SolidStart uses API routes in the same routes/ directory:

// routes/api/posts.ts
import { type APIEvent } from "@solidjs/start/server";

export async function GET(event: APIEvent) {
  const posts = await db.posts.findMany();
  return Response.json(posts);
}

export async function POST(event: APIEvent) {
  const body = await event.request.json();
  const post = await db.posts.create(body);
  return Response.json(post, { status: 201 });
}

Pretty similar on the surface, but there's an important difference hiding underneath. SolidStart uses the standard Request/Response Web APIs directly. Next.js also uses them in Route Handlers, but in practice you'll quickly run into NextRequest and NextResponse - extended wrappers that add things like nextUrl, cookies(), and geo. They're not standard, they don't exist outside Next.js, and they leak into your code in ways that make it non-portable. If you've ever tried to extract a Route Handler into a standalone function or test it without the Next.js runtime, you've felt this pain.

SolidStart gives you the event object with some extras (locals, request, response headers), but it's all built on Web APIs. The main difference is that SolidStart's API routes live alongside your page routes - no separate api/ directory convention needed (though you can organize them that way if you want).

Middleware

Next.js 16 introduced proxy.ts as the recommended path for heavy server-side logic - auth, redirects, rewrites - running on the Node.js runtime. The old middleware.ts isn't fully deprecated, but it's now specialized for Edge Runtime only. For self-hosted setups (think Hetzner, Coolify, Docker), proxy.ts is what you want.

SolidStart has createMiddleware:

import { createMiddleware } from "@solidjs/start/middleware";

export default createMiddleware({
  onRequest: [authMiddleware, loggingMiddleware],
  onBeforeResponse: [metricsMiddleware],
});

One important caveat with SolidStart's middleware: it does NOT run during client-side navigation. Only on the initial server request. So don't use it as your sole auth check - put auth logic in your server functions too. Next.js has the same nuance with proxy.ts, but it's less obvious.

What about after()? Next.js 15 introduced after() - a way to schedule work (logging, analytics, cache warming) that runs after the response has been sent to the client. SolidStart doesn't have a direct equivalent. Your best options are firing off a non-awaited promise in your server function (the response won't wait for it), or using the onBeforeResponse middleware hook to queue background work. If you're on a platform that supports it (like Cloudflare Workers with waitUntil()), you can tap into that directly via the platform's API. It's less ergonomic than after(), but it works - and you're not locked into a framework-specific API.

A note on auth in middleware: this is a broader anti-pattern that's worth calling out. Vercel spent years implicitly encouraging auth checks in Next.js middleware (their templates did it, their docs showed it), then pivoted to "we never said to do auth in middleware" when the Edge Runtime limitations became undeniable. The reality is that middleware auth is fine if it's asymmetric - checking a JWT signature or reading a session cookie without making additional network requests (no database lookups, no token introspection calls). The moment you need to hit an external service to validate, you're adding latency to every single request and creating a single point of failure. Put the real auth logic in your server functions where it belongs, and use middleware only for cheap, fast checks like redirecting unauthenticated users to a login page.

Deployment

Next.js works best on Vercel (unsurprisingly). Self-hosting has improved - the Build Adapters API is now stable, and Node.js/Docker deployments are better supported than before. But some optimizations are still Vercel-specific, and Turbopack remains Next.js-only - not the general-purpose bundler it was initially marketed as.

SolidStart deploys anywhere Nitro can target - and that's a long list: Node, Deno, Bun, Cloudflare (Workers, Pages), Netlify, Vercel, AWS Lambda, Deno Deploy, and more. Switch targets with a single config line:

export default defineConfig({
  server: {
    preset: "cloudflare_pages", // or "netlify", "node", "deno", etc.
  },
});

No vendor lock-in. Vite is framework-agnostic with a massive ecosystem. This is the "primitives, not frameworks" philosophy applied to infrastructure.

Metaframework cheat sheet

Primitives, not frameworks

Before we get into the "why bother" section, it's worth understanding the philosophy behind Solid. There's a mantra in the Solid community: "Primitives, not frameworks."

A note on origins: the phrase itself was actually coined by Werner Vogels, AWS CTO, in the context of cloud infrastructure during a Re:Invent keynote. Ryan Carniato ran with it and applied it to UI frameworks, where it's taken on a meaning of its own. It's a bit of an appropriation - Vogels was talking about composable cloud services, not reactive UI primitives - but the core idea translates well: give developers building blocks, not opinionated monoliths.

The idea is simple: instead of giving you a monolithic framework with opinions about every layer of the stack, Solid gives you small, composable, reactive building blocks that you combine however you need. To paraphrase Ryan's approach: here are a few powerful concepts - learn them, combine them, build on top of them. That's the whole thing.

This shows up everywhere in the ecosystem:

• Solid Primitives - a community library of composable building blocks organized by domain (inputs, media, browser APIs, network, animation). Each one is tree-shakeable, SSR-safe, and individually useful.

• SolidStart's architecture - v2 replaced its custom server layer (Vinxi) with Vite 6's Environment API, leveraging an existing ecosystem primitive rather than maintaining bespoke infrastructure.

• The plugin model - features like image optimization are opt-in plugins, not baked into the framework. You compose what you need.

Contrast this with React's trajectory. React 19 shipped with Actions, useActionState, useOptimistic, use(), Server Components, Server Actions. React 19.2 added <Activity> (for hiding UI while preserving state and unmounting effects) and useEffectEvent. The React Compiler hit v1.0, auto-memoizing your code at build time. And that's before you add Next.js 16 on top with "use cache" directives, proxy.ts for server-side logic, Turbopack, and Build Adapters.

It's a lot. The React Compiler is genuinely impressive engineering - it makes React faster without changing the fundamental model. But in a sense, it's a patch on an architecture that other frameworks have moved past. Solid solves the performance problem at the architectural level via fine-grained reactivity, making a compiler unnecessary. Angular, Vue, and Svelte have all moved toward signals too. React is the outlier choosing to solve it with tooling rather than primitives. (Though it's worth noting that React itself has moved to an independent foundation under the Linux Foundation - a governance change that may influence its future direction.)

Neither approach is "wrong." But they lead to very different developer experiences.

Why bother? Performance and DX

So, that's a lot of "this works differently." Why go through the trouble?

Bundle size

Solid's core clocks in at ~7KB min+gzip. React + ReactDOM sits at ~45KB min+gzip. That's roughly a 6x difference at the framework level, and the gap compounds in real-world apps as you add routing, state management, and other dependencies. Less JavaScript shipped means faster load times. Simple math.

No virtual DOM overhead

React diffs a virtual tree on every state change, even with the Compiler auto-memoizing what it can. Solid compiles JSX to direct DOM operations. When a signal updates, only the specific DOM nodes that read that signal get touched. No diffing, no reconciliation, no wasted work. This is why Solid consistently ranks at or near the top of the JS Framework Benchmark, performing close to vanilla JavaScript.

The DX angle

Next.js has grown into a complex beast. Four layers of caching, three different caching models across three major versions (v14's aggressive implicit caching, v15's opt-out, v16's "use cache" opt-in), the server/client boundary dance, the middleware-to-proxy.ts migration… the State of JS 2025 survey showed Next.js with the largest satisfaction drop of any meta-framework (from 68% to 55%), landing as both the 13th most-loved and 5th most-hated project - uniquely polarizing. A commonly cited complaint? "Too complex." (paraphrased)

And then there was React2Shell (CVE-2025-55182) - a CVSS 10.0 critical RCE vulnerability in the React Server Components Flight protocol. A single malicious POST request to any server function endpoint could execute arbitrary code. Default create-next-app deployments were vulnerable out of the box. It was patched across all React 19.x lines (19.0.1, 19.1.2, and 19.2.1 - make sure you're on the right patch for your minor version), and Next.js shipped corresponding fixes. But the architectural debate about the Flight protocol - and the attack surface of running component deserialization on the server - remains a valid concern when evaluating RSC-heavy architectures.

SolidStart, by contrast, is refreshingly lean. File-based routing, "use server" directives for server functions, query() for cached data fetching, action() for mutations, and Vite under the hood. It leans on the web platform and doesn't try to reinvent every wheel. You write the reactive primitives we covered above, and the metaframework gets out of your way.

That said - SolidStart's ecosystem is smaller. You won't find the same breadth of third-party integrations, and the community, while active and growing (35K+ GitHub stars, ~1.5M weekly npm downloads), is not React-sized. It's a tradeoff worth being honest about - however, in my personal experience, that hasn't been a big deal. I've already shipped 5+ Solid-based projects of various complexity levels. I can't say the ecosystem size was a huge problem.

Can LLMs help with the migration?

Short answer: yes, but trust and verify.

LLMs like Claude, ChatGPT, and tools like Cursor are genuinely useful for the mechanical parts of migration. They'll convert useState to createSignal, swap className for class, strip out React.memo and useCallback (neither are needed in Solid), and handle the basic boilerplate. For a large codebase, that saves real time.

But here's the catch: LLMs are trained on way more React code than Solid code. Their muscle memory defaults to React patterns, and the places where they fail are exactly the places where Solid differs most:

1. Props destructuring - the #1 failure. Every LLM will write ({ name, onClick }) by default. In Solid, this kills reactivity. You need props.name or splitProps().

2. Control flow - LLMs leave .map(), ternaries, and && in JSX instead of converting to <For>, <Show>, and <Switch>/<Match>. The JS patterns "work" but defeat Solid's fine-grained updates.

3. The "runs once" model - LLMs generate code that assumes the component function re-runs on state changes. It doesn't in Solid.

4. Async in effects - LLMs will happily write createEffect(async () => {...}), which breaks reactive tracking after the first await.

There's a documented case of ChatGPT confidently telling a user that a bug in their <Show> usage was a Solid framework bug. It wasn't. The LLM just didn't understand Solid's reactivity model.

Making it work

The good news is you can steer LLMs in the right direction:

• SolidJS now ships an official llms.txt that you can feed to your AI tool as context. If you're using Cursor, add it via @Docs.

• solidjs-context-llms is a community-maintained, LLM-optimized documentation suite organized by domain (reactivity, routing, SSR, primitives).

• Cursor users can grab SolidJS-specific .cursorrules files that enforce the right patterns.

• Claude Code users can add Solid rules to their CLAUDE.md to prevent the common mistakes.

But the real safety net is eslint-plugin-solid. Run it after every AI-assisted conversion. It catches reactivity violations that LLMs introduce: destructured props, conditional logic outside JSX, incorrect imports. Think of it as the linter that keeps the AI honest.

My recommended workflow: convert one component at a time, review the output for the known failure patterns, and run the linter before moving on. LLMs get you 70-80% of the way there. The last 20% is where understanding the mental model matters, and that's something you have to bring yourself.

A note on SolidStart v2

If you're evaluating SolidStart right now, you should know where things stand. SolidStart v2 is in late alpha and already being deployed in production by early adopters. The big change: it replaces Vinxi (v1's custom server layer) with Vite's Environment API, giving you a leaner, more debuggable stack that leverages Vite's existing ecosystem. Nitro 3 integration is a separate effort, still in progress.

The migration from v1 to v2 is minimal - mostly config changes. Your component code and server functions stay the same. Everything in this guide covers the fundamentals that apply to both versions.

Where to go from here

If you want to get your hands dirty:

• SolidJS docs - genuinely well-written

• SolidJS Tutorial - interactive, takes about an hour

• SolidStart docs - for when you're ready to build an app

• Solid Primitives - community library of composable building blocks

• SolidStart v2 status - late alpha, heading toward beta, already deployed in production by early adopters

Takeaway

Migrating from React to Solid isn't a find-and-replace job. The JSX similarity is a double-edged sword - it makes the syntax feel familiar while hiding a fundamentally different execution model. But once the "runs once" mental model clicks, you'll find that Solid's approach is simpler and more predictable. And on a personal note, it makes my brain hurt less.

We're also witnessing a convergence on fine-grained reactivity as the right model - Angular adopted signals, Vue has ref() and reactive(), Svelte 5 moved to runes. Solid has been doing this from day one. The primitives are mature, the metaframework is production-ready, and the philosophy of composable building blocks over monolithic abstractions means you're not fighting the framework - you're using it as intended.

Whether you're moving away from Next.js for practical reasons, performance reasons, or just because you're curious about what fine-grained reactivity feels like in practice - give SolidStart a shot. The learning curve is real but short, and the payoff is worth it.

Happy hacking!

Originally published at darko.io by Darko Bozhinovski. Licensed under CC BY 2.0.

No one has accounting as a hobby. There is no cool project in accounting you can share with your friends, and there aren’t any interesting or thought provoking conferences or meetups where the topic is accounting. Was there ever an accountant speaking at TED? I haven’t check, but if there was he/she was probably speaking about something else.

So what has this have to do with software engineering? To use Don McMillan’s funny diagram, we are now seeing a shift away from problem solving in software engineering. Instead of solving problems we are writing markdown documents that tell agents to solve a problem. And, even in these early days we see projects popping up with default .md files to do a certain tasks, or write in certain language. I think it is not before long we see a standard .md file to build an R package, or to build a FastAPI, or something else, with complexity of the problem being solved increasing over time.

There is a trajectory in which agent skill will become something akin to International Financial Reporting Standards. I think we are not far away from having the big companies producing “verified” skill (as I went to LinkedIn to post this I was greeted by a post by Anton Abyzov that talks about a verified skill tool :) to do certain things in their ecosystem. Think for example “AWS verified skills for infrastructure”, and maybe these will start to come with a price tag on a tier level, or even on regional level around the world.

Then if you are a company working in software auditing, you will probably have a skill that will instruct your agent to audit the work of another agent. I would not be surprised if the Big 4 are already thinking about this.

Where does this leave software engineers? No more problem solving, more OCD? I think it is not difficult to imagine future work being mostly reading .md files and trying to catch inconsistencies that slip through spell checkers or similar tools. Think someone typing cat instead of car in some .md file, and someone else trying to figure out where is the error coming from. That to me sounds much closer to tracking the stray balance mismatch on the balance sheet, than to improving a poorly implemented function that sometimes crashes the user’s computer.

Is this good or bad? I guess it depends on being good or bad for whom or what. I think that even if this trajectory takes place, it will probably not affect the current generation of software engineers.

However, not thinking about the other issues being raised (such as overall environmental concerns, employment outlook, and the stock market bubble), I think over time we are very likely to witness tragedy of the commons unraveling in the free software world.

Then maybe a lot of the software becomes like the cheap umbrellas you buy on the street form ad-hoc sellers when it suddenly starts to rain, and then they break after the second use and you toss them away. And maybe a lot of the software becomes a problem similar to the plastic in the oceans and some engineers re-skill to deal with that.

For the current generation I think it will put pressure on community building around software, hobby projects, and events. Think about it: why would I want to come to a meetup if we are to discuss your latest .md file? It is not meant for people anyway. Or why would I bother with reporting a bug or offering a pull request on a project that is largely build by a coding agent? The intrinsic motivation to help and be involved with people is simply gone. I would even say there is no motivation to send my agent subscription to do a pull request on your agent driven project. What would my lighting talk be at the next conference: how to format your .md file in 10 easy steps? There is a skill for that too.

After all have you ever heard of an accounting community?

Now, while the tool was 100% AI generated with very minor tweaks from my side, this post was 99% human written, 1% being the titles for more manageable reading, I'm by no means a good writer, if you want to read the story, thank you, and go right ahead!

You can find me on the Base42 Discord if you want to chat about the blog, the universe or anything.

Step 1: You Just Need a QR Code

Picture this - you're building promotional materials for your event, venue or whatever, you have your design ready to go, a placeholder in the middle for a QR code, your guests will scan it and learn more about your event, it will be great!

You, being the well-prepared designer that you are, prepare your media materials months ahead, painstakingly designing and detailing everything, "It's perfect!" you exclaim, then you remember that you still have a placeholder in your QR code slot, so you do what anyone would do:

1. Type in QR code generator into google.com

2. Paste your link

3. A popup comes up prompting you to sign in

   1. It has Login with Google available, so why not

   2. You login

   3. You click free plan or something

4. Download the QR code

5. You get your QR Code

6. ???

7. Profit

Victory! Now that whole side quest is complete, you put the cherry on top, your QR code is finally placed into the placeholder, the whole picture finally tied together, feng shui in place and all that. Being the diligent designer that you are, you test it and validate it works, huzzah!

Ship it! You send it to the print company, they print it and a few days later, you have your beautiful designs ready to be passed around as fliers, stickers or whatever other physical media may be. A week or so later you start your campaign and the flyers get passed around, people are scanning, conversions are happening, yay!

The Hostage Email

Then a few days later, you get this:

Oh yeah, that QR code you generated, plopped into your design, shipped to printing and paid the invoice for - it's being held hostage by one of the many predatory QR code generators out there, all of which seem to rank pretty high on Google. I could write an entire blog post on the predatory tactics and dark patterns they use to cling onto any desperate attempt at monetizing something that is at best a single use app. Sure, they provide tracking and analytics, but that's not what you need every time, and it should certainly not be the default.

To continue, pay up, friend:

Just $9.99/month, what a steal!

I'll Build My Own, With Clankers and Prompting

If you've been following Base42, you know what we are - a hackerspace, where people hack on different projects, experiment and so on. If you're following us on socials, are in the Base42 Discord server, or just maybe stumbled upon Vasilaki's last post you would know that last month we held NSND, a sort of un-conference, where you just come, talk about random stuff and maybe something comes out of it.

So we did. Someone mentioned generating a QR code and immediately triggered flashbacks of every time I've fallen victim to this exact hustle.

One Wish, One Hour

There's this magic black box called AI that you can throw your wishes into, something clanks along and voila, you have your very own app, vibes and all. That's what I did - while everything else was happening during NSND, people showing off home infrastructure setups, talking about what we'd host on the new Base42 server rack and so on, I put my wish into the wishing well that is a coding agent.

Here's what my wish was:

"Build a QR code generator, should work fully in the browser, make it available as a PWA, no server, make no mistakes"

And it did. Very little mistakes, pretty much a 1-shot from the get-go, and around 1h in it was fully deployed.

Meet QR Canvas

I present to you QRC - let's call it QR Canvas, the pronunciation makes it funny.

It supports everything you would need and more - fully customize your QR code, add a logo, pick from templates, all for free, all within your browser. You can even install the PWA on your phone, tablet, laptop and take it with you offline.

There's even support for adding a logo!

Goes without saying, it's Open Source

The code is all there if you want to poke around, contribute, or just verify that yes, it really is just a browser and nothing else. Fork it, improve it, make it yours. Heed my warning though, the codebase IS AI SLOP, essentially, but it's AI slop that totally works, does the job and doesn't need further updates as far as I'm concerned. If you have a better coding agent that would like to rewrite this in the JS framework dejure, go ahead and open a PR, I'll tell my AI to check your AI's work! 🤣

github.com/42dotmk/qrc

Go Use It

No account. No popup. No hostage email three weeks from now. Just qr.42.mk - open it, generate your code, download it, done.

If you find a bug, fix it yourself.

Macedonian NSND has it's own wiki, where you can learn more about what it is and what has happened over the years in each city it was held in(reading back it seems pretty fun and I am sure there were crazy adventures).

Shortly, it's a gathering of tech enthusiasts and geeks from the Balkan region, but sometimes there are guests from abroad, there aren't predefined/predetermined topics nor speakers, everything happens on the spot. People come, introduce themselves, say what they can speak and listen to about and after a vote, the talks/workshops start.

It's like an organized chaos, breeze of fresh air for the people that are used to structured talks and events.

Skopje 2026 NSND

We voted for the topics we proposed at the start of the event and the second most anticipated topic was mine:

Decrypt LUKS through SSH

SSHing into the machine before the system is booted to decrypt the LUKS-encrypted drive

When the drive is decrypted, the drive boots and runs the installed operating system into which we can practice the normal everyday SSHing(remotely accessing).

Motive

We started working on a 3D printer server @ Base42(more on that in some other upcoming blog), but stumbled upon a challenge. Few times, in the course of three days, the server was unplugged from the power outlet and couldn't be accessed remotely via SSH even if immediately plugged in, soooo annoying. You may ask why? - LUKS is the answer.

If you want your entire disk to be encrypted for security and privacy, on Linux, that's done using Linux Unified Key Setup(LUKS). You must be in front of your computer to unlock LUKS-protected disks by providing a passphrase at boot time. However, the machine I was working with was not at my premise, so I wasn’t able to unlock and boot it, at least that's what I thought at first.

The old workflow went like this:

1. server was working properly(normal SSH would work) → someone unplugs the cable(SSH timing out on my machine)

2. I would need to come physically → decrypt the LUKS

3. system boots, SSH works again → go to step 1

Because I was furious about it, I said to myself-"There must be a way to remotely do this. I am sure the DevOps of big companies are not coming physically to the encrypted servers everytime they restart them just to decrypt them", so I searched the internet for my thought, and there it was again, someone else did it, the usual.

There are always exceptions(sad), as in our case, if the cable is left unplugged, I MUST come physically to the server.

PLEASE DON'T LEAVE THE CABLES UNPLUGGED IN BASE42

Execution

When I read that there's such thing as remote unlocking a LUKS encrypted drive, as every hobby project, I said-"I am going to do this one day" and it just waited for the right moment.

The perfect moment was NSND.

But I wasn't prepared for it. I just proposed the topic, it was voted, but I didn't know how to do it exactly.

Luckily, that's what the unconference was about-everyone was involved into it and wanted to help to do it. After seeing that it will take a lot of time, more than a quick talk, we decided to make it like a separate workshop, projected to the secondary projector @ Base42.

The biggest credit goes to Damjan Georgievski.

And here's what we learned from the process:

Choosing the SSH server

TinySSH and Dropbear are both lightweight SSH servers designed for embedded systems and minimalist environments, but they prioritize different goals.

Dropbear is more feature-rich and compatible, supporting password authentication, older algorithms, and scp/sftp, making it a better general-purpose OpenSSH replacement and is perfect for routers, IoT, and embedded Linux with limited resources.

TinySSH focuses on extreme security/simplicity by supporting only modern, secure cryptography (Ed25519/ECDSA, no RSA/DSA), has extremely small codebase aimed at minimizing attack surface and is ideal for highly secure, modern initramfs unlocking.

TinySSH looked like the exact tool we need.

initramfs

What if I told you that there's a full second operating system(although very small) that runs before your known main OS, I am using Arch, btw.

Well, that happens in the early boot of a Linux machine, where the only directory that's not encrypted by default is the /boot/.

This secondary OS is not accessing the LUKS-encrypted drive/s, is loaded from a compressed archive file in /boot/ called initrd, which stands for “initramdisk”, which is another word for our initramfs system and it contains all the boot-related things for the system, of which most important for us to have are the drivers and the ssh server.

It is ran from RAM, that's why it's called initramfs (initial RAM filesystem).

In it, a copy of systemd is running and its state is passed to the state in the primary OS, so that means we can install a whole collection of stuff in mkinitcpio-systemd-extras (mkinitcpio is the tool Arch uses to regenerate initramfs).

Here's a link to see what's available: https://github.com/wolegis/mkinitcpio-systemd-extras. Since it's AUR, use your prefered way to add them to your Arch packages.

Of those, we need two: sd-tinyssh and sd-network. They are added in the /etc/mkinitcpio.conf's HOOKS, where its comment reads:

The HOOKS control the modules and scripts added to the image, and what happens at boot time.

Order is important, and it is recommended that you do not change the

order in which HOOKS are added.

Here's our HOOKS:

HOOKS=(base systemd autodetect microcode modconf kms keyboard keymap sd-vconsole block mdadm_udev sd-network sd-resolve sd-tinyssh sd-encrypt filesystems fsck)

To ensure the tinySSH server only decrypts the LUKS, we have created the file /etc/mkinitcpio.conf.d/tinyssh.conf with the content:

SD_TINYSSH_COMMAND="systemd-tty-ask-password-agent --query --watch"

For the tinySSH to work, we need the public keys into /root/.ssh/authorized_keys.

In our case, I also needed to edit /etc/systemd/network/en.network to put the leased static internal IP address via DHCP Reservation, because when we used the default DHCP=yes, the tinySSH server was given a different IP address every time and wasn't accessible:

[Match]
Name=en* eth*

[Network]
Address=192.168.x.x/24
Gateway=192.168.x.1
DNS=8.8.8.8

Finally, run mkinitcpio -P to rebuild the initramfs.

Result

Disclaimer: I am using alias commands( printon/ printonLuks), you would need to use your own parameters e.g. ssh -p {server_ssh_port} -i "{path_to_private_ssh_key}" {user}@{server_ip_address}

From looking around, I was unable to find any existing pixel art online for the majority of the techs I needed, and I hope with this project, future adventurers don't run into the same issues as me 😊

I drew pixel art of a few logos, made a custom badge and stars, and created a Python script that generates a badge with the desired logo and the specified rating underneath. I created a web API so anyone can make their own badges for whatever they desire, profile, portfolio, home page, game project, etc.

With all the different badge material, technology and rating options, there are over 4000 possible badge combinations. If we include the different scale options, this number jumps to over 80,000.

Implementation

The project implementation is quite simple and consists of a Vanilla JS frontend (as there is nothing fancy going on there), and a FastAPI backend.
The backend loads all the sprites from the assets folder initially and from then onwards they are stored in-memory, with an additional (protected) endpoint existing if I need to reload the loaded files.
Further optimizations were considered with caching, but ultimately skipped because of the sheer number of badge combinations.

Usage

The project is currently hosted here, and has an interactive live badge editor.
For API users, the endpoint for getting the list of technologies is https://badge.deathunter.com/techs,
and the list of badge backgrounds is: https://badge.deathunter.com/materials

There are over 100 different techs, each one being hand-drawn, including (but not limited to):
- Programming languages
- Frameworks
- Engines
- Tools/apps
- Browsers
- Operating Systems
- Website logos
- Company logos

There is a traditional marketing rule that says you should publish your yearly recap sometime in early January, ideally when everyone is still pretending they will stick to their New Year’s resolutions. As a hackerspace that lives in a garage and occasionally bends the laws of physics, we decided to ignore that rule completely. Instead, we are publishing our 2025 recap at the end of the Chinese New Year, as a small tribute to our lovely Asian community, Pagoda, which is an essential part of the Base42 story.

This year is the Year of the Fire Horse, a sign that appears only once every 60 years, last seen in 1966. The Fire Horse is associated with boldness, speed, high energy, and the potential for dramatic change. Honestly, that sounds suspiciously like our event calendar. Also, today is the Lantern Festival, which marks the official end of the New Year season before life returns to daily routines. The wish behind it remains simple and universal: peace and happiness for family and friends. Considering the state of the world, that wish feels more relevant than ever.

So this is officially our last chance for a recap. Let’s do it properly.

🛠 About Base42

Base42 is a basement hackerspace, born in a garage and named after The Hitchhiker's Guide to the Galaxy. As you may remember, 42 is the answer to life, the universe, and everything. Inspired by Douglas Adams, we decided that if 42 is the answer, then we might as well dedicate ourselves to building the question together. Our core principle is simple: together we are building the meaning, trying to create something good for society, for our friends, and for the open-source community.

The probability of success for a garage full of geeks attempting to influence the local tech culture was approximately 0.00000042 percent. The actual result was somehow, undeniably, yes.

The purpose of Base42 has never been just to host events. It is to create moments that make a difference, generate positive energy, and leave a lasting impact. It is a place with chill vibes and informal energy, the kind that reminds you why you fell in love with technology in the first place. It takes you back to the first time you built something from scratch, learned a new skill, or fixed a bug at 3 a.m. and felt proud to belong to the geeky world.

🎮 Global Game Jam

We started 2025 the only logical way: with Global Game Jam organized by MGI, because many of us entered the world of technology through games in the first place. Before we were engineers, designers, cybersecurity experts, we were players trying to understand how things worked. Games were our first debugger and our first design document.

For 48 intense hours, around one hundred participants filled the garage with laptops, cables, caffeine, and dangerously ambitious ideas. Mechanics were invented at 2 a.m., redesigned at 4 a.m., and heroically patched at 7 a.m. It is the kind of event where you start by asking deep philosophical questions about gameplay, narrative, and whether 42 is truly the answer to life, the universe, and everything. By hour 36, however, the real question becomes whether the answer is actually a hot shower and six uninterrupted hours of sleep.

Somewhere between those two questions, magic happens. Strangers become teammates, ideas become prototypes, and exhaustion becomes a shared badge of honor. And by the end, when you stand there presenting something that did not exist 48 hours earlier, you remember exactly why you fell in love with building things in the first place.

The energy from that weekend could power a small country, or at least keep us motivated until the next registration opens.

🎨 UX/UI Conference

Shortly after that, we helped organize the first major UX/UI conference together with the amazing crew from UXplore, led by a powerhouse team of brilliant ladies and supported by a few brave gentlemen who successfully survived rooms full of strong design opinions. With more than 250 participants, it marked a milestone for the design and tech communities in our country. Developers and designers shared one stage, and for a brief, beautiful moment, everyone agreed on spacing, typography, and user flows. We can confidently say the conference itself had excellent user experience, which might be the highest compliment a room full of designers can give.

💔 A Difficult Spring

As spring arrived, the tone of the year shifted. In March, tragedy struck Kochani, and the entire country was left in shock. Nearly 70 lives were lost, most of them young people, and for weeks it felt as if time itself had slowed down. In the face of tragedy, technology, events, and everyday discussions suddenly felt small in comparison to the weight of reality.

In May, together with the Macedonian .NET Community, we helped organize a humanitarian Global Azure Day in honor of the victims and in support of the affected families and survivors. Around 200 participants gathered not only to discuss cloud technologies and modern architectures, but also to donate and contribute in a meaningful way. It was powerful moment when the tech community came together not for networking or innovation, but for solidarity and compassion. It reminded us that behind every line of code, there are people — and that community matters most when it shows up for each other.

🤖 Meetups, AI & Tech Communities

Throughout the year, Base42 ran at full capacity with monthly meetups. PyData alone hosted nine gatherings, with artificial intelligence and large language models dominating the conversations. We discussed how AI is changing the way we build software, how to use it responsibly, and how to stay curious instead of scared. Some people were experimenting with fine-tuning models, others were integrating APIs into real products, and a few were just trying to explain to their parents that no, ChatGPT does not actually “know everything.”

And while AI sounded futuristic and complex, somehow the real drama still came from Python versions and broken environments. It turns out that even in the age of machine learning, the most powerful force in the universe might still be a properly configured virtual environment.

BeerJS, .NET meetups, cybersecurity sessions, AWS talks, Google Developers Group events, Angular Macedonia gatherings, ProdACT meetups, Microsoft Dynamics discussions, Advent of Code, and many more filled the calendar. Somewhere along the way, we stopped asking whether we should host another event and started asking how many chairs we needed this time.

Many weekends throughout the year, Base42 quietly transformed into a global Capture The Flag battleground. A dedicated group of cybersecurity enthusiasts gathered with one mission: compete at the highest level. Their focus and persistence paid off with impressive accomplishments and high scores on the global leaderboard. We are incredibly proud of this crew. They achieved impressive results and high rankings in global competitions, proving that a small garage can produce world-class talent.

💻 Doniraj Kompjuter & Open Source

One of our favorite communities, Doniraj Kompjuter, donated nearly 4,000 computers this year, helping bridge the digital gap and give devices a second life in the hands of students and families who truly need them. If you have an old laptop or computer collecting dust, bring it to Base42. We will make sure it finds a better purpose. On top of that, Doniraj Kompjuter donated an incredible server rack with 1TB of RAM to our space, which instantly upgraded our definition of “overkill” and “future-proof.”

With the new rack in place, we launched open-source projects into the wild, built a QR code generator, a competitive programming platform, a text editor, a new mobile application, and even worked on a drone project. Of course, there are also a few projects that are technically still not finished. They are not abandoned. They are simply in extended beta. Possibly waiting for the right alignment of planets. Or a free weekend.

🎲 Gaming, Tabletop & Community

Somewhere between all of this, a new community rolled into Base42. Warden Gaming brought trading card games and board games into the garage with a simple but powerful mission: shuffling cards and making friends. What began as a few decks on a table became regular gatherings full of strategy, laughter, and very serious debates about rules that were absolutely interpreted correctly.

Every weekend, Warhammer armies are carefully assembled, painted with monk-like precision, and deployed across tabletops like miniature sci-fi operas. Strategies are calculated with the seriousness of production deployments, and dice rolls are treated like high-stakes system calls. Alongside the Warhammer battles, Zandana sessions brought even more tactical energy to the tables, while Dungeons & Dragons campaigns opened portals to entirely different worlds. Character sheets were studied as intensely as documentation, and storytelling blended seamlessly with strategy.

It turns out that whether we are optimizing code, tuning AI models, or planning battlefield formations in a fantasy universe, geeks will optimize everything.

🎤 What The Stack 2026

Did we forget about the biggest event? No. We organized the biggest developer gathering of the year, an event that honestly deserves its own blog post. Together with DevEd, Angular Macedonia, and the entire IT community, we helped create a conference that brought together more than 800 people. There were four stages, 32 speakers, great coffee, beer (because engineers) music, and a game corner showcasing titles from Macedonian publishers. The afterparty escalated beautifully with rock and metal music by Why Not, and when speaker Domagoj unexpectedly grabbed a guitar and joined the stage, it became one of those legendary moments no schedule could have predicted. Students, senior programmers, engineers, and gamers all shared the same space, proving that the community is united by passion more than anything else.

🎮 Game Dev Rev & Milestones

Later in the year, we proudly supported Game Dev Rev, the first national game development conference organized with MGI and the local gaming community. The event brought together regional studios, indie developers, industry veterans, and representatives connected to the European gaming ecosystem. North Macedonia officially became part of The European Games Developer Federation. It is still slightly surreal that a small garage basement helped contribute to such a milestone. Apparently, even big federations sometimes start in small rooms.

🎨 Art, Podcasts & Workshops

Art found its permanent home in the garage as well. Three new graffiti pieces transformed the walls, thanks to Nikola. Pagoda organized four Gunpla workshops, which absolutely count as precision engineering. They organized a cyberpunk art exhibition and promoted Kalajdziev’s book. We welcomed two 3D art exhibitions and presentations by Zafir. Base42 became a place where soldering irons and spray cans coexisted peacefully.

Podcasts were recorded within our walls, including episodes by Debeli Gikovi, and we quietly started preparing our own geeky podcast. The studio is already painted, the microphones are set, and we are currently in the extremely complex process of choosing the name. As every developer knows, naming things is one of the hardest problems in computer science. Let’s just say, it is coming soon.

The year wrapped up with another game jam organized by Galactic Omnivore and MUGI, themed around white hats. During that same intense month, we organized an electronics workshop that sold out in a single day, with half of the participants being women, which made us especially proud.

We also hosted two cybersecurity workshops with Bozidar. The first sold out immediately, and the second lasted four full days with six trainers guiding participants deep into ethical hacking and digital defense. Neon lights. Hacking. Mind-blown.

🧠 Hackathons & Ecosystem Support

There were so many events happening that at times the calendar looked like a production server under heavy load. Among them, we hosted the Strip Trip Hackathon, where participants were pushed to think creatively under pressure and make things that were anything but ordinary. It was intense, chaotic in the best possible way, and full of ideas that refused to stay inside the box.

At the same time, we proudly supported our friends who organized the Ecommerce Conference and the AI Summit. Because for us, community is never competition. When one event grows, the entire ecosystem grows with it.

Some prototypes almost worked. Some projects definitely worked. A few experiments violated at least three known laws of physics. Thousands of humans and possibly a few aliens visited Base42. Thousands of coffees and beers were consumed. One arcade machine remains broken but emotionally supported. There was also at least one solution that mysteriously only worked on Fridays, and we decided not to question it.

🚀 Looking Ahead

In 2026, we will continue our primary mission: figuring out the right questions. As Deep Thought once calculated, finding the ultimate answer takes time. Fortunately, we are patient, slightly chaotic, and well supplied with snacks.

We are already three months into 2026. We have organized new events: LAN party, Trivia Night, monthly meetups, chess tournament, internships for high school students who will end up teaching us…Many surprises are on the way. The universe is clearly not done with us yet.

Base42 remains a small garage with a jacuzzi and sauna unused for their original purpose, but it is also a living, breathing organism made of communities, ideas, experiments, friendships, and late-night discussions. It proves that you do not need a shiny building or a perfect marketing strategy to create impact. You need people, curiosity, courage, effort, and maybe a towel.

So thank you to every community that called Base42 home in 2025. Thank you to those who trusted us with your ideas, your events, and your time. Thank you to our friends who built conferences and invited us to support them. Thank you to everyone who shuffled a card, rolled a dice, wrote a line of code, painted a miniature, plugged in a server, recorded a podcast test episode, or stayed late just to help move chairs.

The universe may still be calculating the ultimate question, but one thing is clear: it is much more fun when we calculate it together.

And yes, the answer is still 42. ✨

Of course, there are various solutions for this - right in your terminal:

• jq for JSON formatting and processing

• qrencode for generating QR codes

• uuidgen(Unix) and New-Guid (Windows) for all your UUID needs

And you can always just google what you need and use some web app instead. I did that too, who am I to judge? But this is all too fractured and inconsistent.

I personally use some of these tools myself. And I’ve noticed a common trend among my colleagues: many default to web-based tools, even though terminal apps are often faster and easier once you get the hang of them. I sometimes recommend some specific CLI tool, but it rarely sticks. And with CLI tools there’s also the issue of compatibility across platforms, you can use one tool on your Linux system, but when you switch to Windows you need to suppress that muscle memory and write another command in PowerShell instead. It’s just too frustrating and fragmented.

Wouldn’t it just be easier to have a single tool, that you could install once on your system, would work across different platforms? No need to remember and install different tools, or search for alternatives for your Windows machine. Imagine it all centralized: jack json, jack qr, jack uuid generate, jack jwt - all just working, in a single package, across platforms.

That’s why I decided to make a sort of Swiss Army Knife tool for developers that’s portable and accessible. Initially, I actually named it factotum - a word for a general handyman. Then, my friend Nikola Dinevski came over and suggested jack - as in, jack of all trades. I thought that it was perfect! It’s exactly what it is, a multi-tool for all trades - but a master of none. What’s often omitted from that saying though, is that it’s oftentimes better than a master of one! Besides, jack is a pretty memorable name and easy to type in your terminal.

Jack removes the friction from remembering all those different tools, you just type in jack and find the tool you need, on all your systems! No need to install multiple tools, or lookup something online. It’s easy and intuitive to use, with no fancy and complicated options that you may find in more specific tools which, let’s be honest, you’ll only ever need a fraction of the time. It’s composable, simple, and helps with most of your day-to-day tools needs.

The intention is not to replace all the other tools I mentioned, of course they’ll have their use-cases. I don’t expect jack to have feature parity with dedicated tools. No, the aim is to have jack as the easy default tool you go to when you need something so you don’t have to juggle multiple tools.

Jack is made with Kotlin. Why? Because I want to be unique! No, but really - I wanted to try out the language for something else than backend services. It’s cross-platform, and is overall very nice to work with. Additionally, I had recently read about clikt, a CLI library for Kotlin, and I wanted to take it for a spin.

I’d love for you to contribute! If you have a feature in mind you can always submit a PR or open an issue if you want me to put it on the to-do list. You can find the repository at https://github.com/dimeskigj/jack-cli.

Jack has a lot more features, and you can try them out for yourself!

On Linux/MacOS, you can install jack with:

curl -fsSL https://raw.githubusercontent.com/dimeskigj/jack-cli/main/scripts/install.sh | bash

If you’re on Windows, use PowerShell instead:

iwr https://raw.githubusercontent.com/dimeskigj/jack-cli/main/scripts/install.ps1 -useb | iex

Let me know what you think! I would be glad if you find jack useful.

Here’s everything you need to know about the competition, the rules, the prize pool, and how you can participate.

How It Works:

• Advent of Code is a yearly event that challenges coders to solve 25 puzzles over the course of December. Our competition is based around the official leaderboard for the event. Whether you’re a skilled programmer or just starting out, you’re invited to join us for a fun and impactful month of problem-solving.

• Leaderboard: Participants will be ranked on the official Advent of Code leaderboard based on their progress (number of stars earned) each day.

• Charity Focus: For each star you earn, Base42 will donate 5 MKD directly to a charity chosen by the first-place winner of the leaderboard.

• Prize Pool: A portion of the prize pool will go to the top 3 participants based on their leaderboard performance, and another portion will be donated to charity.

Who Can Participate?

• Individual Participants:
  Anyone can join the competition and participate in the official Advent of Code leaderboard. Whether you're a beginner or an experienced developer, this event is open to everyone. You can compete for fun, or if you choose to pay the participation fee, you'll be eligible for the prize pool.

• Company Participation and Sponsorship:
  Companies are encouraged to get involved as sponsors and donors of the event! By sponsoring the competition, your company can contribute to the prize pool, which will be distributed among top participants and donated to charity.

How to participate

• Join the Discord server, you can find the leaderboard join code in the #advent-of-code channel

• Enter the leaderboard code you got from the Discord server into the Advent of Code website

• Fill out the participation form

• Pay the optional participation fee of 200 MKD by buying a participation ticket at this link.

• Code away for the next 25 days, and may the best coder win!

Prize Distribution:

The total prize pool is divided as follows:

• 40% of the prize pool will be donated to charity, with the final recipient chosen by the first-place winner.

• 60% of the prize pool will be split among the top 3 participants.

  • 1st place: 50% of the prize pool

  • 2nd place: 30% of the prize pool

  • 3rd place: 20% of the prize pool
    In addition, for each star you earn during the Advent of Code, Base42 will donate 5 MKD directly to the charity of choice.

Participation Fee:

• Optional Fee: There is a participation fee to enter the prize pool, which will go directly into the prize fund. The fee is 200 MKD. However, you can still join the leaderboard without paying the fee. If you choose not to pay, you'll be excluded from the prize pool but can still participate and compete for fun and donation.

• Deadline for entering the competition: December 15th.

Rules:

• Code of Ethics: While AI tools are prohibited in the competition, we recognize that it’s not always possible to prevent the use of such tools. We trust participants to follow the honor system and compete fairly. Please keep the spirit of the event in mind and avoid using AI to solve the puzzles. Let’s keep it a challenge of skill and creativity!

• Joining the Competition: To enter, join the Base42 Discord server, sign up, and join the official Advent of Code leaderboard.

• Sponsorship: Companies are invited to sponsor the event and contribute to the prize pool. Sponsors can contribute any amount, and their donation will be added to the prize pool, following the same distribution rules as above.

• Charity Selection: The first-place winner will have the privilege of selecting the charity that will receive the 40% donation from the prize pool as well as the donation of the contributions from stars.

• Fair Play: Participants are expected to compete with integrity and in accordance with the rules of Advent of Code. Any attempt to exploit loopholes or cheat will result in disqualification.

• Online: The competition will mostly be online as it's very long running, but you're welcome and encouraged to group up and come by in Base42 IRL and solve challenges together.

Get Involved:

• Compete:
  Solve the daily puzzles, earn stars, and climb the leaderboard. Every star counts towards increasing our charity donation!

• Support a Cause:
  Help us make a real difference in the world by contributing through your coding skills. Every time you solve a puzzle, you’re helping to fund a charity chosen on the final day.

• Sponsor the Event:
  If you're part of a company that wants to get involved, consider sponsoring the competition! For more info, contact us at base42mk@gmail.com.

Why Participate?

• For the Thrill of Coding:
  Challenge yourself with daily puzzles and see how you stack up against other talented developers.

• For a Good Cause:
  Not only will you be competing for great prizes, but you'll also be contributing to a worthy charity chosen by the first-place winner.

• For Being Awesome:
  Do you even need a reason to flex your 1337 coding skillz?

We can’t wait to see who takes the top spot this year and to see how much we can raise for charity!
Let’s make this the best Advent of Code yet.
Good luck and happy hacking!

Questions?

If you have any questions about the competition or need more information on how to join, feel free to reach out to us on the Discord server, social media, or via email at base42mk@gmail.com.
Let’s code for a cause!