Vue

Vue is a component framework in the same territory as React: state in, rendered DOM out, with a compiler doing the work of turning templates into update instructions. The differences are mostly ergonomic. Templates are HTML with directives rather than JSX, reactivity is tracked for you rather than declared through hooks, and single file components put markup, logic and styles in one file. It has long been the default front end for Laravel work, which is how it enters our stack.

How we use it

Consonas is the build behind this line. The CRM codebase is Laravel 11 with a Vue 3 front end, built with Vite, using Vue Router and Vuex for navigation and state, plus FullCalendar for the appointments and clash view, TinyMCE for rich text and Chartist for the dashboard reporting. It is a modular monolith, so each module ships its own Vue components alongside its PHP, and a new area of the product is a folder rather than a cross-repository coordination exercise.

Two things are worth saying plainly. The codebase began as a fork of an existing self-hosted CRM rather than a blank page, extended with multi-tenancy, per-organisation databases and deployment scaffolding, and the live application at app.consonas.com serves a single hashed bundle that we cannot match to that repository from the outside. The reasoning about who a CRM this size is actually for, and why most of them are bought and then abandoned, is in a CRM for three people.

What it costs you

The ecosystem is smaller than React's, and you feel it in the long tail rather than the core. The framework, router and store are excellent; the third specialist component you need, a particular chart type, a specific rich text integration, is more likely to be a two year old package with one maintainer. Migrating from Vue 2 to Vue 3 broke enough that a lot of the community documentation you find is for the wrong version, and a Stack Overflow answer that does not say which API it uses is worse than none.

The Options and Composition APIs both being valid means a codebase can be written in two styles at once, and inherited projects usually are. Vuex is the older state library and Pinia has replaced it in new work, so a project of any age carries a migration you have not done yet. Hiring is harder in the UK market too: for every Vue developer available there are several React ones, which matters when a client has to maintain the thing after we leave.

We should also be honest about depth. We have one Vue codebase and several React ones, so if you are choosing a stack from scratch and asking us to staff it for years, that asymmetry is a fact you should weigh.

When we would choose something else

For a new front end with no existing PHP application under it, we would reach for React, simply because that is where our shipped work and our recovery instincts are. The technical case between the two is close enough that team familiarity should decide it, and ours points one way.

Vue makes sense when the server is already Laravel and the pages are server-routed with islands of interactivity, which is the pairing described on Laravel and PHP. If the application is entirely client rendered and talks to an API over the network, the framework choice matters less than the build and data layer around it, covered on Vite and client state and data fetching.