Full-Stack TypeScript Stack vs Laravel-Rails
I’m in the process of organizing the next cohort of the Full-Stack Web Development Bootcamp, starting February 2025 (join the waitlist), and when I sent the email announcing it a couple weeks ago, I had some questions.
One question was why TypeScript/React over a Rails or Laravel stack.
If you’ve been wondering and still debating over this choice, read on.
In the bootcamp we use a TypeScript stack. TypeScript on the frontend, TypeScript on the backend. Full-Stack TypeScript.
One question people asked me is how this compares to Laravel or Rails, two very popular frameworks people use in Web Development. There are many more frameworks and programming languages one can use for Web Development, but let’s focus on those 2.
By the way, if you prefer video, I also made a video version of this email on YouTube.
Asking this question, trying to see how they compare with each other, is absolutely legit, because - especially as a beginner - you don’t want to waste time learning the “wrong thing”.
I can immediately tell you they’re all great choices, for various reasons. But since my end choice is full-stack TypeScript, I’ll tell you why.
When I say “TypeScript” I mean “TypeScript paired with any TS frontend library”, like React or Svelte or Vue. Depending on that, you pick a framework, be it Next, Remix, Tanstack Start, T3, or SvelteKit, or Nuxt.
There’s a lot of choice depending on your preferences, but I bring them under the same roof.
I’ve used PHP a lot in the past, and Laravel in some projects, but I’ve been a 100% JavaScript / TypeScript guy for 5-6 years now.
Rails, not so much experience with it except tinkiering with it over the years, since when it was released, but i never worked with it professionally, but I think it’s very similar to Laravel, if you ignore the programming language, PHP vs Ruby, so I’ll group them in the same bucket.
So we have the TypeScript world, and Laravel/Rails.
Both are great choices, you can’t go wrong with any. This makes choosing even more difficult, because if one was far better than the others, there would be no question.
The ideal answer would be learning all, and then making your own informed decision. But let me tell you what I think, in this video.
I think we can say it depends. One clear distinction we can make is if you are going to create Web Apps as a solo developer, indie hacker, building your own indie product, or if you want to learn programming to then find a job as a software developer.
You’re still a developer, but you’ll end up doing a whole different career, and a whole different life.
As a solo developer you have much more choice, you are the only person choosing the tech stack.
As an employed software developer, you are less likely to make the technical decisions, unless you’re tech lead or CTO, so the choice is mostly related to getting the job, learning a tech that can make your job search easier.
If you’re looking for a job in your area and most companies use Ruby and Ruby on Rails, learn that. Why make your life harder? If companies mostly use React, learn React. That will simplify your job research.
Something that is quite common knowledge, with exceptions, is that PHP jobs are paid less. Not sure if it’s true, but worth checking.
TS/React has a ton of job offers.
I just looked up Remote OK, the remote jobs board. Jobs tagged “javascript” now are 423, react 409, php 70, ruby 107, laravel 15,
The Stack Overflow Survey in 2023 listed JavaScript (I consider that as “TypeScript”) as #1 language with 63%, PHP 18%, Ruby 6%.
React is 40%, Laravel 7%, Rails 5%.
https://survey.stackoverflow.co/2023/#technology-most-popular-technologies
So Laravel and Rails are quite niche, we can say. This doesn’t make them bad per se, but this has some consequences.
As a solo indie dev, when the choice is just on you, you could base your choice on pre-existing knowledge, for example you used PHP in the past, maybe you’ll feel familiar with Laravel. Same with Rails.
You could base your choice on how fast you can build your app. I don’t know if there’s a clear winner, it depends a lot. Laravel and Rails provide you a lot of tooling built-in. They give you a ton of stuff out of the box, and DHH also labeled Rails “the one person framework” to signal how he views Rails as a tool that a single person can master completely. https://world.hey.com/dhh/the-one-person-framework-711e6318
In JS/TS land notoriosuly there’s no “all in one” solution, there are a million different libraries and tools, that you mostly combine yourself.
Things similar to Laravel or Rails do exist, in fact, but they are not that popular, I think because philosophically JS/TS developers value bringing their own choices when it comes to picking libraries, and this flexibility can have its benefits. There’s no “single source of truth” in JS, no “benevolent dictator” taking all the decisions. It’s a “bazaar” compared to the “cathedral” approach of rails/laravel. Many decisions in Rails I think come from what 37signals is working on at that moment, be it “no build” or “pwa” or whatever battle they engage on, or trying to promote what they are selling. Same for Laravel, of course there’s one person at the top deciding all about the framework.
When I say “TS” I mean a whole ecosystem of competing tools, all trying to bring something better to the market. Tools like Next, Remix, Tanstack, Hono, Astro, Svelte, Vue, and many many more. You pick what you prefer, based on the kind of app you need to build you’ll need different features so you’ll shop for the right solution. Be it based on Deno, Node, Bun, whatever.
Ruby on Rails is basically the only popular “application” for Ruby. Without it, not many people would have heard of the Ruby language. And it’s fair to admit Rails is well past its “golden age” of 2006 -2014. Which is not bad per se. This means it’s stable, no groundbreaking changes all of the time. But a lot of talent as moved on, back in the day every single startup used Rails, nowadays there’s simply too much competition.
PHP is a bit different due to WordPress and the old “PHP CMS” and “PHP frameworks” wave, but nowadays probably the only framework with some hype and popularity is Laravel. People don’t choose PHP, they choose Laravel.
In TS land, once you know the language, you have a gazillion options about libraries and frameworks. 5-6 different popular UI libraries, 5-6 ORMs, 5-6 metaframeworks. There’s a lot more innovation, while on PHP or Ruby, either nothing is happening, or hardly nothing is happening. From the outside, feels like what had to happen happened (PHP -> Laravel, Ruby -> Rails) and nothing new will show up there. In TS land on the other hand, seems like everything could show up tomorrow and dominate the ecosystem. Maybe a new runtime, maybe a new UI library, maybe a new framework (TanStack Start?)
This reflects on the number of blog posts and tutorials and questions/answers and in turn AI’s expertise on the topic.
One big deciding factor is that when using a TypeScript stack, you only write TypeScript.
This is huge in my opinion because you never have to switch context, you don’t have to learn 2 different languages (which, done well, requires a lifetime). Learning different languages is fantastic for personal growth but I just really want to become an expert in one.
Rails or Laravel use a different language becuase they are server-side only.
And while you can do a lot without writing JS in Laravel, using Hotwire, you can’t just ignore the fact that your code is not running on the server, but on the client, and in the client only JavaScript can run.
In Laravel/Rails it’s all very server-centric, and in order to create the kind of experiences that we expect from modern web applications, we use “bits” of JS (think Livewire/Hotwire), which is fine, but for some thing you really want a full application running in the browser, especially when you need a lot of interactivity in the UI, or when you have client-side state that needs to be persisted in the browser.
Inertia in Laravel allows you to do that, but then you basically manage 2 different applications.
In many TS stacks you can write server and client code very near each other (colocating functionality), sometimes even in the same file, for better or for worse.
One thing I can mention is that in the TypeScript ecosystem I have the impression you get a lot for free. Lots of free tier options. I can create 10 projects on Vercel or Netlify or Netlify or Cloudflare Pages or StackBlitz for example, for free but if I want to create and host a Laravel or Rails app on the Internet, I think I need to first setup my own VPS first (but then you need to learn basic sysadmin/devops skills too), although that might just be an impression as many of those tools I mentioned can also deploy Rails or Laravel apps although the’re more “ready to go” for JS apps.
The impression you have, also the marketing, is that you “just set up a $5 VPS” and use Rails/Laravel. You can do that with a TS app, but cloud hosting solutions are so good we sometimes ignore that option.
This is not an issue in real projects, but it’s a bit of a barrier for my courses where people might not be ready to buy hosting for their demo apps.
Talking about specific features of the language, types makes the whole development experience much better in the editor.
PHP / Ruby are not typed (mostly, Laravel has started adopting types in PHP), this alone is a huge advantage I think. You get whole classes of errors removed by the editor itself when coding.
Also, types enable a better auto completion in the editor. It’s probably something you only notice when going “back” from a typed language to an untyped one. And you get things like auto completing imports, auto renaming imports when moving a file in a different folder, and so on.
The amount of libraries available for TS/JS is huge, there’s always a 1st party library or API example integration for everything, while sometimes this is not true for other languages.
Technically about php/rails, I don’t like the OOP stuff much. I much more like the more dynamic functional nature of JS/TS, while those frameworks in particular tend to be a lot more object oriented, with the MVC pattern, naming classes, putting some file in a specific place, splitting a single feature over 3-4 different files, and all that.
JS/TS feels more dynamic and free.
JSX/TSX, adopted by React and many other tools (Solid, Hono…) is far better (for me) way to build components / UIs over Blade or Erb. You basically write HTML components in TSX files, import them, pass around data and state, handle events nicely, it’s super powerful and well done. I think that’s the best part of React, at least the part it “got” better.
Ultimately, it’s just a choice. You can be happily programming with any of the mentioned tools.
Biggest thing probably for me, specifically for teaching this stack, is not teaching multiple languages, only TS, and being able to have people deploy their apps for free on many different platforms without paying up front.
Then, I see TS as a technology that is moving faster, has more velocity, more jobs available, and I think it’s a great thing to teach people.
→ I wrote 17 books to help you become a better developer:
- C Handbook
- Command Line Handbook
- CSS Handbook
- Express Handbook
- Git Cheat Sheet
- Go Handbook
- HTML Handbook
- JS Handbook
- Laravel Handbook
- Next.js Handbook
- Node.js Handbook
- PHP Handbook
- Python Handbook
- React Handbook
- SQL Handbook
- Svelte Handbook
- Swift Handbook
Also, JOIN MY CODING BOOTCAMP, an amazing cohort course that will be a huge step up in your coding career - covering React, Next.js - next edition February 2025