DEV Community: Solid-Vue

Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

Joni Ilman Pahmi — Thu, 01 Oct 2026 09:20:44 +0000

Solid-Vue is getting another small but important step toward making application structure easier to manage.

This release introduces two additions:

Per-page layouts, powered by Vue Router's definePage().
Octans UI add-on, our first integration with a UI component library.

They solve different problems, but they share the same goal: giving Solid-Vue applications more structure without making developers build and configure everything from scratch.

Per-Page Layouts

Not every page in an application should look the same.

A dashboard might need a persistent sidebar and navigation. An authentication page might need a simple centred card. A public page might use an entirely different shell.

Previously, developers had to decide how to structure those layouts themselves. Solid-Vue can now handle that part with a simple convention.

Create layout components inside src/layouts:

<!-- src/layouts/dashboard.vue -->
<template>
  <div class="dashboard-shell">
    <nav>
      <!-- Dashboard navigation -->
    </nav>

    <main>
      <slot />
    </main>
  </div>
</template>

You can also keep a default layout:

<!-- src/layouts/default.vue -->
<template>
  <main class="default-layout">
    <slot />
  </main>
</template>

Then wrap your application's router once in App.vue:

<script setup lang="ts">
import { SolidVueLayout } from 'solid-vue/client'
</script>

<template>
  <SolidVueLayout>
    <RouterView />
  </SolidVueLayout>
</template>

Individual pages can then request the layout they need:

<script setup lang="ts">
definePage({
  meta: {
    layout: 'dashboard',
  },
})
</script>

<template>
  <h1>Dashboard</h1>
</template>

That's it.

Pages that don't specify a layout automatically use src/layouts/default.vue.

This means layout selection stays close to the page itself instead of requiring another routing configuration file.

Why `definePage()`?

One important detail here is that definePage() isn't a Solid-Vue-specific API.

It comes from the Vue Router ecosystem and is already familiar to developers using file-based routing with Vue Router tooling.

Solid-Vue simply uses the page metadata to connect the route to the corresponding layout.

For example:

definePage({
  meta: {
    layout: 'auth',
  },
})

maps naturally to:

src/layouts/auth.vue

The convention keeps the amount of configuration small while still allowing applications to grow beyond a single application shell.

Layouts Are About More Than Visuals

A layout isn't necessarily just a collection of CSS classes.

It can represent an application's structural boundary.

For example, a typical application might eventually have:

src/
├── layouts/
│   ├── default.vue
│   ├── auth.vue
│   └── dashboard.vue
│
├── pages/
│   ├── index.vue
│   ├── login.vue
│   ├── register.vue
│   └── dashboard/
│       ├── index.vue
│       └── settings.vue

The pages remain focused on their own content, while layouts handle the surrounding application structure.

That separation becomes particularly useful when an application has several sections with different navigation, headers, or visual shells.

Our First UI Kit Add-on: Octans UI

The second addition in this release is a new Solid-Vue add-on for Octans UI.

Install it with:

npx solid-vue add octans-ui

This is the first time one of our add-ons integrates a UI component library rather than simply adding a development utility or configuration.

The goal is the same as with the rest of the Solid-Vue add-on system: reduce the amount of repetitive setup required when starting a project.

What Does the Add-on Do?

Octans UI requires a small amount of application-level setup.

The Solid-Vue add-on takes care of that wiring for you.

In particular, it:

Installs the required Octans UI package.
Adds the UiProvider integration to App.vue.
Registers the Octans UI plugin in main.ts.
Leaves the application ready to import and use Octans UI components.

For example:

<script setup lang="ts">
import { Button, Card } from '@octans/ui'
</script>

<template>
  <Card title="Hello">
    <Button primary>
      Click me
    </Button>
  </Card>
</template>

The important part isn't that installing a UI library is difficult.

It isn't.

The point is that these small integration steps are exactly the kind of setup that tends to get repeated across projects.

Solid-Vue's add-on system gives us a place to automate them.

We Don't Want the CLI to Guess

There is another detail we're particularly careful about.

A CLI that modifies an existing project needs to know when it can safely make an automatic change — and when it can't.

For example, the add-on can normally update App.vue and main.ts when they follow the expected structure.

But developers are free to customise those files.

If Solid-Vue can't confidently determine where an integration should be added, the add-on doesn't try to make a risky modification.

Instead, it reports what needs to be added manually.

That's intentional.

We'd rather give you a clear instruction than silently produce a broken application.

Using Layouts and Octans UI Together

These two features were also tested together.

A typical application can have a layout responsible for the application shell while Octans UI provides the components used inside it.

For example:

Application
│
├── SolidVueLayout
│   │
│   ├── Dashboard Layout
│   │   ├── Navigation
│   │   ├── Header
│   │   └── RouterView
│   │       │
│   │       └── Octans UI components
│   │
│   └── Other Layouts
│
└── Vue Router

The layout controls the surrounding structure.

The router controls which page is displayed.

Octans UI provides reusable interface components.

Each part has a relatively small responsibility, without requiring a large application architecture just to get started.

We tested this combination in both development and production builds, including a layout wrapping the UI provider and router.

The result is the same workflow you'd expect from a normal Solid-Vue application.

Getting Started

If you're starting a new project, create one with:

npm create solid-vue@latest my-app

Then:

cd my-app

And add Octans UI:

npx solid-vue add octans-ui

You can then create your layouts under:

src/layouts

and select them from individual pages with:

<script setup lang="ts">
definePage({
  meta: {
    layout: 'dashboard',
  },
})
</script>

What's Next?

We're keeping Solid-Vue's approach deliberately incremental.

Rather than adding every possible feature to the framework, we're looking for the repetitive pieces that developers commonly need when building small and growing applications.

Layouts are one of those pieces.

UI library integration is another.

The add-on system gives us room to experiment with more integrations without making every Solid-Vue project depend on everything.

And this is only the beginning of that approach.

Try It

Create a new Solid-Vue application:

npm create solid-vue@latest my-app
cd my-app

Then add Octans UI:

npx solid-vue add octans-ui

For more information, see the documentation:

Solid-Vue is still in early access, so we'd love to hear what feels useful, what feels rough, and what you'd like to see next.

Try it, build something small, and let us know what you think.

See: Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

What Is the Simplest Frontend Framework for a Full-Stack Developer in 2026?

Joni Ilman Pahmi — Tue, 29 Sep 2026 09:38:17 +0000

If you already know JavaScript, HTML, CSS, Node.js, and some backend development, choosing a frontend framework in 2026 can feel strangely difficult.

The syntax is rarely the hardest part.

You also have to think about routing, state management, API integration, project structure, deployment, documentation, ecosystem, community, and—if you're looking for work—the size of the job market.

So a very practical question appears:

Which frontend framework is the simplest to learn while still being practical for full-stack applications?

The problem is that "simple" can mean different things.

It can mean fewer lines of code.
It can mean fewer concepts.
It can mean less configuration.
It can mean faster development.
Or it can simply mean that the architecture makes sense to you.

Those are not always the same thing.

This article compares React with Vite, Next.js, Vue, Svelte, and a more opinionated Vue + Vite approach from the perspective of a developer who already understands JavaScript and backend development.

What Does "Simple" Actually Mean?

For a full-stack developer, simplicity is not just about component syntax.

A framework might be considered simple when you can:

get a project running quickly;
understand the project structure without learning dozens of conventions;
add routing without a lot of configuration;
connect the frontend to an API without fighting the framework;
manage application state with a predictable solution;
deploy without understanding a large platform-specific abstraction;
come back to the project six months later and still understand it.

That last point is often overlooked.

A framework can be easy to start with but difficult to maintain.

Another framework can provide a huge number of features out of the box but require more concepts before you feel comfortable.

So instead of asking:

Which framework is the best?

A more useful question is:

Which level of abstraction matches the application I'm building?

That changes the entire discussion.

React + Vite

React remains a familiar choice for frontend development, while Vite provides a straightforward development environment for React applications.

For developers who already know React, this combination can have a very small immediate learning curve.

You already understand components, state, props, events, asynchronous code, and the general React development model.

The trade-off appears when you move from components to the application as a whole.

React itself is a UI library rather than an all-in-one application framework. Depending on your project, you may need to make additional decisions about routing, state management, forms, data fetching, validation, and other application concerns.

That's not necessarily a bad thing.

Experienced developers may actually prefer this flexibility because they can choose exactly what they need.

But if your goal is:

"I want a straightforward application workflow with sensible defaults."

then every additional decision becomes part of the learning curve.

So the interesting distinction is:

React can be simple at the component level while the surrounding application architecture remains your responsibility.

Next.js

Next.js provides a broader application framework around React.

It brings conventions and features for things such as routing, server-side capabilities, rendering strategies, and deployment-oriented workflows.

That can reduce the amount of infrastructure you have to assemble manually.

But convenience has another side.

You're not only learning React.

You're also learning the Next.js way of handling routing, rendering, server functionality, data access, caching, and project organisation.

For developers who want a full-stack React framework, that can be exactly what they're looking for.

But for someone whose main goal is learning frontend development as quickly as possible, those additional concepts are worth considering.

This creates an important distinction:

More built-in capability can reduce manual wiring, but it can also increase the framework mental model.

Vue

Vue takes a slightly different approach to the learning experience.

Its component model is approachable for developers who already understand HTML, CSS, and JavaScript, while the official ecosystem provides established solutions for common application concerns.

That gives Vue an interesting middle ground.

You can start with a relatively small application and gradually introduce routing, state management, and other capabilities as the project grows.

You don't necessarily need to adopt a complete application platform on day one.

For small applications, that incremental approach can be useful.

It allows the developer to learn the framework itself first, then add more pieces when the application actually needs them.

In other words:

Vue can provide structure without forcing the entire application architecture on you immediately.

Svelte

Svelte is another option that often comes up when simplicity is the main objective.

Its component syntax can feel concise, and its compiler-oriented approach moves some work into the build process rather than relying on a large runtime abstraction.

That can make the development experience feel different from React or Vue.

However, fewer lines of code do not automatically mean a smaller learning curve.

A developer coming from React still needs to understand Svelte's component model, conventions, and ecosystem.

So Svelte is worth evaluating on its own terms rather than simply assuming:

fewer lines = simpler framework.

Sometimes the mental model matters more than the amount of code you write.

Full-Stack Developers Have a Different Problem

A full-stack developer already understands concepts such as:

HTTP;
APIs;
authentication;
databases;
server-side validation;
application architecture.

That means the frontend framework does not exist in isolation.

It has to fit into an existing mental model.

There are generally two ways to structure the application.

The first is to keep the frontend and backend separate:

Browser
   |
   v
React / Vue / Svelte
   |
   v
REST / GraphQL API
   |
   v
Node / Laravel / Other backend
   |
   v
Database

The second is to use a framework that combines frontend and server capabilities:

Browser
   |
   v
Full-stack framework
   |
   +---- UI
   |
   +---- Server / API
   |
   +---- Data access
   |
   v
Database

Neither architecture is automatically simpler.

The important question is whether the framework's conventions actually reduce the amount of work required for your particular application.

The Hidden Cost of "Simple"

Every abstraction has a learning cost.

A framework might give you routing, server functions, data fetching, caching, rendering strategies, and deployment conventions.

Those capabilities can save time later.

But every one of those features also creates another concept you need to understand.

This creates a trade-off:

More built-in capability
        |
        v
Less manual wiring
        |
        v
More framework concepts

And the opposite direction looks like this:

Less built-in capability
        |
        v
More manual choices
        |
        v
Smaller framework mental model

Neither side is universally correct.

The sweet spot depends on the project.

A Small Business Application Is Not a Large Platform

Consider a typical small-business application.

It might need:

authentication;
a dashboard;
CRUD operations;
forms;
an API;
database access;
reports;
PDF or spreadsheet exports;
a few charts.

That's already a real application.

But it does not necessarily require the architecture of a large distributed platform.

Sometimes a predictable set of conventions is more useful than a large collection of infrastructure designed for problems the application does not currently have.

This is where lightweight application architecture becomes interesting.

The goal isn't to remove capabilities.

The goal is to avoid making developers configure capabilities that their application doesn't actually need yet.

Where a Lightweight Vue + Vite Approach Fits

This is also the idea behind Solid-Vue.

Solid-Vue is an early-access Vue + Vite application framework focused on small and growing applications.

The basic idea is straightforward:

Keep Vue and Vite as the foundation, then provide sensible defaults and integrated pieces for common application development tasks.

For example, a project can bring together:

Vue;
Vite;
file-based routing;
Pinia;
a server layer.

The point is not to replace Vue.

The point is to reduce the amount of orchestration work around Vue.

Instead of repeatedly deciding how to connect the common pieces together, the framework provides a starting structure for developers who want a more opinionated workflow.

For a full-stack developer building business applications, that can be a useful distinction.

At the same time, Solid-Vue is still early-access.

That means there is less ecosystem maturity than established technologies such as React, Next.js, Vue, or Svelte.

That's an important trade-off, especially if your priority is ecosystem size, tutorials, community support, or hiring opportunities.

What About Jobs and Community?

Learning difficulty is only one variable.

If your goal is employment, you should also consider the technologies actually requested by employers in the market where you want to work.

A smaller framework might be pleasant to learn while having fewer job listings, tutorials, or developers available to help.

A larger ecosystem can provide more resources and potentially more employment opportunities.

At the same time, job availability depends on many other factors, including country, company, seniority, and your overall skill set.

So choosing a framework based only on the word "simple" can be misleading.

A practical way to think about it is to separate your goals.

If your priority is employment, investigate the technologies employers are actually asking for.

If your priority is learning frontend fundamentals, choose a framework whose programming model you can understand and practise consistently.

If your priority is building small full-stack applications, evaluate how much application wiring the framework requires for the kinds of projects you actually expect to build.

Different priorities can lead to different choices.

Should You Stay With React or Switch?

If you already know React and have built several projects, switching is not automatically necessary.

Your existing knowledge still transfers.

Components, state, props, events, asynchronous operations, browser behaviour, JavaScript, and application architecture are not concepts that disappear when you change frameworks.

In fact, you don't have to turn framework selection into a permanent decision.

A better experiment is to build the same small application using two different frameworks.

For example:

Customer Management
       |
       +-- Search
       +-- Add customer
       +-- Edit customer
       +-- Delete customer
       +-- API
       +-- Database

Build it with the framework you already know.

Then build the same application with Vue or Svelte.

Now compare the development experience.

Don't only count lines of code.

Ask:

How long did the first working version take?
How many dependencies did you add?
How many configuration decisions did you make?
How often did you need the documentation?
How easy was routing?
How easy was API integration?
How easy was state management?
Could you explain the architecture to another developer?
Would you still understand the project six months later?

Those answers tell you much more than a generic claim that one framework is "easier".

So, Which One Is the Simplest?

There isn't one framework that is objectively the simplest for every developer.

For someone already comfortable with React, React + Vite may have the smallest immediate learning cost.

Next.js provides a more integrated full-stack React experience, but that also introduces additional framework concepts.

Vue offers an approachable component model and an ecosystem where application capabilities can be introduced progressively.

Svelte provides a distinct and concise development model, but still requires learning its own ecosystem and conventions.

A lightweight Vue + Vite framework such as Solid-Vue takes another approach: add more conventions around Vue while keeping the underlying stack relatively familiar.

So the more useful question isn't:

"Which framework is objectively easiest?"

It's this:

"Which framework gives me the least unnecessary complexity for the applications I actually want to build?"

For a full-stack developer, that's a much more practical question.

And when you're still unsure, there's a simple way to find out:

Build one small application with two candidates.

The development experience will probably tell you more than another twenty framework comparison articles.

DEV Community: Solid-Vue

Solid-Vue Adds Per-Page Layouts and Its First UI Kit Add-on: Octans UI

Per-Page Layouts

Why definePage()?

Layouts Are About More Than Visuals

Our First UI Kit Add-on: Octans UI

What Does the Add-on Do?

We Don't Want the CLI to Guess

Using Layouts and Octans UI Together

Getting Started

What's Next?

Try It

What Is the Simplest Frontend Framework for a Full-Stack Developer in 2026?

What Does "Simple" Actually Mean?

React + Vite

Next.js

Vue

Svelte

Full-Stack Developers Have a Different Problem

The Hidden Cost of "Simple"

A Small Business Application Is Not a Large Platform

Where a Lightweight Vue + Vite Approach Fits

What About Jobs and Community?

Should You Stay With React or Switch?

So, Which One Is the Simplest?

Why `definePage()`?