Choosing a web framework: why I use Next.js and Ruby on Rails, and when the others are the better call

The short answer: the framework follows the job

I work mostly with two frameworks. Next.js for the pages people read and click through, and Ruby on Rails for the application behind them, where the business rules live. For shops, that Rails application is built on Solidus, an open source eCommerce engine for Rails.

I don't use them because they are fashionable. I use them because they let me move fast, stay safe, and give me both a flexible front end and a sturdy back end. That is my choice for my work. It is not a law of nature, and good teams build good products on Laravel, Django, Express, NestJS and WordPress every day.

So I explain what each framework is, compare them on what costs a business money (fit, people, support windows, licence), and walk an invented Galway business through a choice. Technical facts come from the official documentation, fetched on 8 November 2026. The businesses and figures in the examples are invented.

What a web framework actually does

A web framework is a ready made skeleton for a web application. When a browser asks for a page, something must find the code that answers that address (routing), fetch the data, apply the rules and turn the result into HTML. A framework does the repetitive parts the same way every time, so the developer writes only what is particular to your business.

Frameworks differ in how much they decide for you. Rails describes itself as opinionated: it "has opinions about the best way to do many things in a web application" and prefers conventions to configuration files.¹ Express sits at the other end and calls itself "fast, unopinionated, minimalist".² Neither is better in the abstract. An opinionated framework gives you a well trodden path. A minimal one gives you freedom, and with it every decision.

Worked example: one order page, step by step

An example: a customer of a Kilkenny florist opens https://bloomsandbranches.example/orders/481. Five things happen.

1. The router reads the address and finds the code that shows an order, with 481 as the order number.
2. That code asks the database for order 481.
3. A rule checks that the person asking is the customer who placed it.
4. A template turns the order into HTML: the bouquet, the delivery date, the price.
5. The server sends the page back.

In an opinionated framework, steps one, two and four follow conventions, so the developer writes mainly step three. In a minimal one, they first choose a router, a database library and a template engine.

Next.js: React on the server, for the pages people read

Next.js is a framework built on React, the JavaScript library for building user interfaces. Its App Router is the default for new projects.³

The idea that matters most is the Server Component. In the App Router, layouts and pages are Server Components by default, which means they fetch data and render on the server and send finished HTML to the browser.⁴ React defines Server Components as components that render ahead of time, and they can run once at build time or on each request.⁵ Only the parts that need interaction in the browser, such as a button with state, become Client Components, marked with "use client" at the top of the file.⁴ Less JavaScript travels to the visitor's phone.

When is a page rendered? Next.js gives three answers, and one page can mix them.

• Prerendered at build time. The page is made once and served as a file, the fastest possible case.
• Regenerated in the background. Incremental Static Regeneration (ISR) serves a prerendered page and rebuilds it after a set time or on demand, so content updates without rebuilding the whole site.⁶
• Rendered on each request, for anything that depends on the visitor, such as a cookie.

With Cache Components switched on, which new apps created with the recommended defaults already have, Next.js builds a static shell for each route and streams the parts that must be fresh into it at request time. The documentation calls this Partial Prerendering.⁷ The use cache directive marks data or components to cache, with a lifetime set by cacheLife.⁷

You don't need Vercel, the company behind Next.js, to run it. It deploys as a Node.js server, in Docker or as a static export, and Cache Components and ISR work self hosted, though ISR not on a static export.⁶⁸

Why I use it: for anything customer facing where speed, responsiveness and polish matter. Paired with a sturdy back end, such as Rails or a headless eCommerce engine, it covers the part of the product the customer actually sees.

Worked example: a studio website with three kinds of page

An example: Tramore Pilates is an invented studio in Tramore, Co. Waterford. Its website at tramorepilates.example has three kinds of page.

The home and about pages change twice a year. They are prerendered at build time, so every visitor gets the same file.

The class timetable changes during the day. Say 2,000 visitors a day open it. Rendered fresh for each, that is 2,000 renders. Cached with a lifetime of one hour, it is rendered at most 24 times a day:

$v = \frac{V}{R} = \frac{2{,}000}{24} \approx 83$

Here $v$ is the number of visitors who share one render, $V$ is the number of visitors a day and $R$ is the most renders a day that a one hour lifetime allows. Foundations: ratios and rates

// app/timetable/page.tsx
import { cacheLife } from 'next/cache'

export default async function Timetable() {
  'use cache'
  cacheLife('hours')
  const classes = await fetch('https://api.tramorepilates.example/classes').then((r) => r.json())
  return <ClassList classes={classes} />
}

The member greeting ("Welcome back, Jo") reads a cookie, so it cannot be shared. It sits inside a Suspense boundary and streams in at request time, while the rest of the page arrives from the static shell.⁷

Ruby on Rails: one application that holds the business rules

Rails is a full stack framework for Ruby, built around two ideas it states itself: Don't Repeat Yourself, and Convention Over Configuration.¹ One application holds the models, the rules, the background work, the emails and the admin screens, laid out the same way in every Rails project.

Rails 8, released in November 2024, made that one application need fewer outside services.⁹ Its announcement lists the new defaults:

• Solid Queue runs background jobs on the database you already have, so neither Redis nor a separate job framework is needed.⁹
• Solid Cache stores cached page fragments on disk instead of in Redis or Memcached.⁹
• Solid Cable relays WebSocket messages through the database.⁹
• Kamal 2 comes preconfigured for deploying to a cloud server or your own hardware, with Thruster in front of the application server so no Nginx is needed.⁹ Kamal deploys any app that runs in a container, not only Rails.¹⁰
• An authentication generator creates the basic models for users and sessions.⁹

The current release line is 8.1.¹¹

Solidus sits on top. Its guides describe it as a free, open source eCommerce platform based on Ruby on Rails, built as a Rails engine.¹² An engine plugs into your own application, so the catalogue, basket, checkout and orders share a codebase with your own rules. More on that in headless Solidus.

Why I use it: it lets me deliver robust systems fast. In growth projects, speed to value matters more than trendiness. Rails is where I put SaaS back ends, admin panels and workflows where the business logic matters more than pixel perfect screens.

Worked example: renewals for a subscription tea club

An example: Ballyvolane Tea Club is an invented Cork business with 1,200 subscribers who renew on the first of each month. Each renewal means charging a card and sending a confirmation email. Assume each one takes two seconds, mostly waiting on the payment provider and the mail service.

Done one after another, that is $1{,}200 \times 2 = 2{,}400$ seconds, or 40 minutes. So each renewal becomes one background job in Solid Queue. With four jobs running at a time, the batch takes $2{,}400 \div 4 = 600$ seconds, ten minutes, and nobody waits on a page. In Rails 8 that needs no extra server: the jobs are rows in the same database as the subscriptions.⁹

Why I pair the two

Next.js renders the pages the customer sees. Rails holds the data and the rules. I pair them with a REST or GraphQL API between them, and I test that boundary carefully, as I explain in TDD and BDD for APIs.

Read the diagram from the top: each box is one step of a single visit, in order. The upper half is Next.js getting the page on screen. The lower half is Rails deciding the price for this customer today. The API in the middle is the contract between them.

The pairing has a cost: two applications to deploy and update instead of one. For a small product with little public site, one Rails application with its own views often does grand. The pairing earns its keep when the public pages carry real weight in search and campaigns.

Worked example: where a price change lands

An example: a Galway bakery supplier changes the trade price of sourdough loaves from €2.40 to €2.55. The change is made once, in the Rails admin. The Next.js product page shows it on the next request, because price is a live part asked from the API, while photos and description keep coming from the static shell. One source of truth, and no website rebuild for a 15 cent change.

The fair alternatives

Each of these is a sound choice in the right hands. Here is what each is, from its own documentation, and when I would recommend it.

Laravel

Laravel is a full stack PHP framework with its own queues, caching, authentication starter kits and more. A major version comes out every year, around the first quarter. Laravel 13 was released on 17 March 2026 and needs at least PHP 8.3.¹³ I think of it as the Rails of PHP, and I mean that as a compliment. For teams already in PHP, or businesses with in house PHP support, Laravel is a great choice. I just prefer Rails for its consistency and culture.

Django

Django is a full stack framework for Python. Its admin interface is generated from your data models and is meant as an internal management tool for trusted staff, not as the public front end.¹⁴ Its documentation sets out protections that come with it: templates escape risky characters to stop most cross site scripting, querysets are protected from SQL injection, and there is built in protection against cross site request forgery and clickjacking.¹⁵ I use Django for data science applications with heavy Python logic, where the analytics pipeline matters more than the presentation. For APIs I still prefer Rails, and for UI heavy projects Next.js.

Express, and NestJS on top of it

Express is the small, flexible web framework for Node.js, "fast, unopinionated, minimalist".² NestJS adds the structure Express leaves out: it is a framework for server side Node.js applications, uses Express underneath by default, can use Fastify instead, and takes its architecture heavily from Angular.¹⁶ I use Express when building microservices or small API endpoints at the edge. For bigger apps, it becomes a tangle of choices without guardrails. NestJS brings conventions of its own to that problem.

WordPress

WordPress is not a framework but a content management system, and for a site that is mostly articles and pages edited by non developers it is often the honest answer. It is released under the GPLv2 or later.¹⁷ Where it gets harder is when a site grows custom business rules, which then live in plugins and themes. I have written about that in a separate article on WordPress and PHP.

Worked example: three teams, three right answers

An example: three invented businesses, three answers.

A Limerick recruitment firm has two PHP developers who know its systems inside out. It needs a client portal. Laravel, because the people who will maintain it already speak the language.

A Galway analytics start up builds forecasts in Python and shows them in a customer dashboard. Django, because the models and the website share one language and one codebase.

A Kilkenny events company runs a small booking API that its partners call, and a separate website. Express or NestJS for the API, because the job is a handful of endpoints, not a whole application.

None of these is my stack, and each is right for that team.

How long each version is looked after

Every framework stops fixing old versions. After security support ends, a newly found hole stays open unless you upgrade. That makes upgrades a running cost of any choice.

• Rails: each minor series gets bug fixes for one year and security fixes for two years from its first release. Rails 8.1 has security support until 10 October 2027. Rails 8.0's security support ended on 7 November 2026.¹¹
• Next.js: a major version is in Active LTS until the next major comes out, then in Maintenance LTS, with only critical bug fixes and security updates, for two years from its first release. Next.js 16 came out on 21 October 2025. Next.js 15 gets security releases until 31 January 2027, an extension of its original date. Maintenance releases can land as minor versions even when they contain breaking changes.¹⁸
• Laravel: bug fixes for 18 months and security fixes for two years. Laravel 12 has security fixes until 24 February 2027, Laravel 13 until 17 March 2028.¹³
• Django: 5.2 is the current long term support release, supported until April 2028. Django 6.1 is supported until December 2027, and the next long term release, 6.2, is planned for April 2027.¹⁹
• Express: only the latest version of each major line is supported. Versions 4 and 5 are both listed as supported with no end date.²⁰

The horizontal axis lists the newest release line of each framework, plus Django's long term release. The vertical axis is the months from November 2026 to the published end of security support. The takeaway: none of them lets you build and forget. Every option here needs an upgrade within about one and a half years.

Worked example: an upgrade calendar

An example: a Waterford garden supplies shop runs its shop on Rails 8.0 and its marketing site on Next.js 15. Today is 8 November 2026.

Rails 8.0 lost security support yesterday, on 7 November 2026.¹¹ That upgrade is now overdue.

Next.js 15 has security releases until 31 January 2027.¹⁸ From 8 November that is 22 days left in November, 31 in December and 31 in January: $22 + 31 + 31 = 84$ days, or 12 weeks.

So: Rails 8.0 to 8.1 this month, then Next.js 15 to 16 within 12 weeks, both budgeted as known costs.

What the licence lets you do

Rails, Next.js, Laravel, Express and NestJS are under the MIT licence.^2122232425 Django and Solidus are under the BSD 3 clause licence.²⁶²⁷ Both are permissive: you may use, change and sell software built with them, including closed source, as long as you keep the copyright notice and licence text. The BSD 3 clause version adds that you may not use the project's or its contributors' names to promote your product without permission.²⁶

WordPress is under the GPLv2 or later, a copyleft licence. Its own position is that derivatives inherit the GPL and that plugins and themes are derivatives, while it admits some legal grey area.¹⁷

For a website you build for your own use, this rarely changes anything. It matters when you plan to sell or distribute what you built, and then a solicitor is the right person to ask.

Worked example: selling the booking module

An example: a Cork climbing wall wants to sell its own booking module to other walls under a closed licence.

If the module is a WordPress plugin, WordPress's position is that it inherits the GPL,¹⁷ so a closed licence needs legal advice before launch. If it is a Rails engine, the MIT licence asks only that the Rails notice travels with Rails itself,²¹ and the wall can license its own code as it likes.

Popularity, measured once and dated

Popularity matters for one practical reason: how many people can work on your system. The Stack Overflow Developer Survey 2025 asked which web frameworks and technologies people had done extensive development work in over the past year, and 23,678 respondents answered that question.²⁸

The horizontal axis lists the frameworks in this article. The vertical axis is the share of all respondents to that question who did extensive work in each one over the past year. Respondents could pick several, so the shares do not add up to 100%. The takeaway: the JavaScript options have the largest pools of people, Rails the smallest of the seven. It counts developers worldwide who chose to answer, not the Irish market, and says how big the pool is, not which framework is better.

Worked example: the pool per thousand

An example: picture 1,000 of those respondents.

$N = q \times 1{,}000$

Here $N$ is the expected number of the 1,000 respondents who work in a framework and $q$ is that framework's survey share written as a decimal. Foundations: ratios and rates

Next.js: $0.208 \times 1{,}000 = 208$. Laravel: $0.089 \times 1{,}000 = 89$. Rails: $0.059 \times 1{,}000 = 59$. So for every Rails developer in the sample there are about $208 \div 59 = 3.5$ Next.js developers and $89 \div 59 = 1.5$ Laravel developers. For a business that needs to hire, that goes into the score below.

Worked example: a Galway coffee roaster chooses a stack

Woodquay Roasters is an invented coffee roaster in Galway. Sam, the owner, needs three things: a marketing website with a blog, an online shop with coffee subscriptions, and a wholesale ordering portal where cafés see their own prices and order on account. There is no developer in house. Every figure below is an assumption made for this example, not a quote.

Three options are on the table.

• A: WordPress with WooCommerce, with the wholesale rules in plugins.
• B: a Laravel application, with the shop built from packages and custom code.
• C: Rails with Solidus for the shop and the portal, and a Next.js marketing site.

Step one: the total cost over five years

The total cost of ownership adds the build, the running costs, the cost of changes, and the expected cost of things going wrong:

$TC = C_0 + T\,(12m + k\,c) + \sum_i p_i\,x_i$

Here $TC$ is the total cost over the horizon, $C_0$ is the one off build cost, $T$ is the horizon in years, $m$ is the monthly cost of hosting, licences and care, $k$ is the number of changes a year, $c$ is the cost of one change, and $\sum_i p_i\,x_i$ is the expected cost of the risks, each risk's probability $p_i$ times its cost $x_i$. Foundations: expected value

The assumptions, with their reasons. $T = 5$ years and $k = 8$ changes a year for every option. A costs €14,000 to build, because most of the shop exists as plugins, and €350 a month including plugin licences. Its changes cost €900 each, because the wholesale rules must fit around third party plugins Sam does not control, and for the same reason it carries a one in four chance of a €10,000 rework. B and C write the wholesale rules as plain application code: €600 a change, and a one in ten chance of a €6,000 upgrade overrun. B costs €32,000 to build, because the shop is assembled from parts, and €250 a month for one application. C costs €30,000, because Solidus brings the shop, and €300 a month for two applications.

Option A:

$TC_A = 14{,}000 + 5\,(12 \times 350 + 8 \times 900) + 0.25 \times 10{,}000$

$12 \times 350 = 4{,}200$ and $8 \times 900 = 7{,}200$, which makes $11{,}400$ a year. Five years is $57{,}000$. The risk is $2{,}500$. So $TC_A = 14{,}000 + 57{,}000 + 2{,}500 = €73{,}500$. Foundations: expected value

Option B:

$TC_B = 32{,}000 + 5\,(12 \times 250 + 8 \times 600) + 0.10 \times 6{,}000$

$12 \times 250 = 3{,}000$ and $8 \times 600 = 4{,}800$, which makes $7{,}800$ a year and $39{,}000$ over five. The risk is $600$. So $TC_B = 32{,}000 + 39{,}000 + 600 = €71{,}600$. Foundations: expected value

Option C:

$TC_C = 30{,}000 + 5\,(12 \times 300 + 8 \times 600) + 0.10 \times 6{,}000$

$12 \times 300 = 3{,}600$ and $4{,}800$ for changes, which makes $8{,}400$ a year and $42{,}000$ over five. The risk is $600$. So $TC_C = 30{,}000 + 42{,}000 + 600 = €72{,}600$. Foundations: expected value

The horizontal axis shows the three options, the vertical axis the five year total cost in euro. The takeaway is how close they are: €1,900 between the most and the least expensive, about 2.7% of the lowest total. On these assumptions, cost alone does not decide.

Step two: a weighted score

When costs are this close, the choice turns on things that are not money. A weighted score puts them side by side:

$S_j = \sum_{i=1}^{n} w_i\, s_{ij}$

Here $S_j$ is the total score of option $j$, $n$ is the number of criteria, $w_i$ is the weight of criterion $i$, with all the weights adding up to one, and $s_{ij}$ is the score from one to five that option $j$ gets on criterion $i$. It has the same shape as an expected value, with weights in place of probabilities. Foundations: expected value

Sam sets four criteria and their weights:

• Fit for the wholesale rules, weight 0.35. A scores 2, B 4, C 5, because in C the shop already exists inside the same Rails codebase where the rules are written.
• Five year cost, weight 0.25. The lowest total scores 5, and half a point comes off for every €1,000 above it. B scores 5. C is €1,000 above, so 4.5. A is €1,900 above, so $5 - 0.95 = 4.05$.
• People who can maintain it, weight 0.25. From the survey pools above, A scores 4, B 4, C 3.
• Speed and editing of the marketing pages, weight 0.15. A scores 4, because editors know WordPress, B 3, C 5, because of the prerendered static shell.

Option A: $0.35 \times 2 + 0.25 \times 4.05 + 0.25 \times 4 + 0.15 \times 4 = 0.70 + 1.01 + 1.00 + 0.60 = 3.31$.

Option B: $0.35 \times 4 + 0.25 \times 5 + 0.25 \times 4 + 0.15 \times 3 = 1.40 + 1.25 + 1.00 + 0.45 = 4.10$.

Option C: $0.35 \times 5 + 0.25 \times 4.5 + 0.25 \times 3 + 0.15 \times 5 = 1.75 + 1.13 + 0.75 + 0.75 = 4.38$.

C wins by 0.28 points. A, with the lowest build cost, comes last, because the wholesale portal is the hard part of this job.

Step three: change one fact and the answer flips

Now say Sam has a long serving PHP developer. B's people score goes to 5, and C's drops to 2, because the developer would have to learn Ruby. Nothing else moves.

Option B: $1.40 + 1.25 + 0.25 \times 5 + 0.45 = 1.40 + 1.25 + 1.25 + 0.45 = 4.35$.

Option C: $1.75 + 1.13 + 0.25 \times 2 + 0.75 = 1.75 + 1.13 + 0.50 + 0.75 = 4.13$.

Laravel now wins by 0.22 points. That is the lesson in one sum: the framework is rarely the deciding fact. The team, the hard part of the job and the cost of change are.

A decision flow you can use

Answer each question from the top. A yes leads to its suggestion, a no to the next question. Every path ends the same way: the total cost sum and the upgrade calendar, because a stack you cannot afford to keep up to date is the wrong stack.

What this means for you

I don't believe in hype based frameworks. Every business has its own constraints: team experience, time to market, maintainability, flexibility and cost. I build with Rails and Next.js because they let me handle those constraints better than any other combination I have found.

Still, great outcomes don't come from frameworks. They come from how they are used. Choose the stack that fits your team and your hardest problem, price it over five years, and put the upgrade dates in the calendar on day one.

Footnotes

1. Ruby on Rails, Getting Started with Rails, Rails Guides v8.1.4.1, guides.rubyonrails.org, accessed 8 November 2026, https://guides.rubyonrails.org/getting_started.html

2. Express, Express: fast, unopinionated, minimalist web framework for Node.js, expressjs.com, accessed 8 November 2026, https://expressjs.com/

3. Vercel, Installation, Next.js documentation, nextjs.org, updated 2 October 2026, https://nextjs.org/docs/app/getting-started/installation

4. Vercel, Server and Client Components, Next.js documentation, nextjs.org, updated 5 October 2026, https://nextjs.org/docs/app/getting-started/server-and-client-components

5. React, Server Components, react.dev, accessed 8 November 2026, https://react.dev/reference/rsc/server-components

6. Vercel, How to implement Incremental Static Regeneration (ISR), Next.js documentation, nextjs.org, updated 15 October 2026, https://nextjs.org/docs/app/guides/incremental-static-regeneration

7. Vercel, Caching (Cache Components and Partial Prerendering), Next.js documentation, nextjs.org, updated 6 October 2026, https://nextjs.org/docs/app/getting-started/caching

8. Vercel, How to self host your Next.js application, Next.js documentation, nextjs.org, updated 15 October 2026, https://nextjs.org/docs/app/guides/self-hosting

9. David Heinemeier Hansson, Rails 8.0: No PaaS Required, rubyonrails.org, 7 November 2024, https://rubyonrails.org/2024/11/7/rails-8-no-paas-required

10. Kamal, Deploy web apps anywhere, kamal-deploy.org, accessed 8 November 2026, https://kamal-deploy.org/

11. Ruby on Rails, Maintenance policy for Ruby on Rails, rubyonrails.org, accessed 8 November 2026, https://rubyonrails.org/maintenance

12. Solidus, Introduction, Solidus Guides, guides.solidus.io, accessed 8 November 2026, https://guides.solidus.io/

13. Laravel, Release notes, Laravel 13.x documentation, laravel.com, accessed 8 November 2026, https://laravel.com/docs/13.x/releases

14. Django Software Foundation, The Django admin site, Django documentation, docs.djangoproject.com, accessed 8 November 2026, https://docs.djangoproject.com/en/stable/ref/contrib/admin/

15. Django Software Foundation, Security in Django, Django documentation, docs.djangoproject.com, accessed 8 November 2026, https://docs.djangoproject.com/en/stable/topics/security/

16. NestJS, Introduction, NestJS documentation, docs.nestjs.com, accessed 8 November 2026, https://docs.nestjs.com/

17. WordPress, License, wordpress.org, accessed 8 November 2026, https://wordpress.org/about/license/

18. Vercel, Next.js support policy, nextjs.org, accessed 8 November 2026, https://nextjs.org/support-policy

19. Django Software Foundation, Download: supported versions and roadmap, djangoproject.com, accessed 8 November 2026, https://www.djangoproject.com/download/

20. Express, Version support, expressjs.com, accessed 8 November 2026, https://expressjs.com/en/support/

21. Ruby on Rails, MIT licence file, GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/rails/rails/main/MIT-LICENSE

22. Vercel, Next.js licence file (MIT), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/vercel/next.js/canary/license.md

23. Laravel, Laravel framework licence file (MIT), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/laravel/framework/12.x/LICENSE.md

24. Express, Express licence file (MIT), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/expressjs/express/master/LICENSE

25. NestJS, Nest licence file (MIT), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/nestjs/nest/master/LICENSE

26. Django Software Foundation, Django licence file (BSD 3 clause), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/django/django/main/LICENSE

27. Solidus contributors, Solidus licence file (BSD 3 clause), GitHub, accessed 8 November 2026, https://raw.githubusercontent.com/solidusio/solidus/main/LICENSE

28. Stack Overflow, 2025 Developer Survey: Technology, web frameworks and technologies, survey.stackoverflow.co, 2025, https://survey.stackoverflow.co/2025/technology