Reflecting on a year with Node.js and why I should have stuck with Laravel
Tags: laravel, php, node, javascript
Published: 2020-12-23 01:15:50

---
title: Reflecting on a year with Node.js and why I should have stuck with Laravel
published: true
description: A year ago I made a bet on full-stack JS and switched my focus from Laravel to Node.js. A year later, I found that Node just slowed me down.
tags: Laravel, PHP, Node, JavaScript
//cover_image: https://direct_url_to_image.jpg
---

Earlier this year, I was two months into building a full-stack JavaScript app. I used an Express server, set up Next.js for server-side rendering, added Chokidar for instant server reloading, used Next.js's Webpack config to compile my server's TypeScript code, hooked up cookie authentication with Argon2 encryption, found the perfect Node ORM, and had the app running in separate containers for Node, PostgreSQL and Redis.

After two months of hard work, all I had built was a mediocre server-rendered CRUD app hacked together with two-dozen NPM libraries. If I had used Laravel and jQuery, I could have built this all in a weekend.

**After a year of building Node.js apps, I discovered I was spending more time piecing together tools than writing application code.** Laravel gives me 80% of my tooling out-of-the-box for 20% of the work. If moving fast is important to you, you should consider batteries-included frameworks like Laravel and Rails first.

## The failed promises of full-stack JS

Full-stack JavaScript evangelists preach that developers can work faster by staying in one language and sharing code between the front-end and back-end of an app. I spent a year chasing that dream without ever reaping its promised benefits.

While Node.js and ES6 are both JavaScript, they are very different implementations. Node historically hasn't worked well with ES6 modules, which means you must compile ES6 code to CommonJS to run it on the server. Configuring Webpack and other bundlers is a completely separate skillset from application development, and it can take days to set everything up correctly. Opinionated tools like Next.js have eased this pain slightly, but its serverless-first approach can make it feel constraining when implementing features that would be standard in a server environment (like using the filesystem).

I had hoped that by staying in a single language I could at least gain speed by not switching contexts, but instead I spent my time switching between endless tabs of third-party package documentation in my browser. Node.js doesn't have a killer back-end app like Laravel that the community has rallied around. Instead, it has a multitude of frameworks gunning for the spot but with no significant adoption or traction. To mitigate the risk of picking a framework that could disappear, many developers use Express.js and piece together an application around that. Unfortunately, using this approach leaves you with countless decisions to make. What ORM or DB driver do you use? Cookie auth or JWT? What encryption algorithm is best? What library should you use for data validation? 

Every one of these decisions can take a week to fully understand the implications of, all while you could have been building your app. It's death by 1,000 paper cuts.

## Laravel: Rapid Application Development done right

Laravel is an incredibly productive application platform. It comes with all of the things you'd expect from a batteries-included framework: routing, an ORM, middleware, authentication, validation, migrations, and testing (just to name a few). But Laravel has two killer features that other full-stack frameworks don't have: a vibrant **first-party package ecosystem** and **incredible documentation**.

Laravel has a first-party Stripe integration for billing. The framework includes a first-party integration for users to use social OAuth to log in. Laravel has first-party app scaffolding, a pre-configured docker environment, a powerful queue system, and if you're willing to pay a few extra dollars, you can get managed Laravel deployment and a gorgeous application dashboard.

Laravel's first-party paid modules are a differentiator: its paid offerings have made it a self-sustaining business with full-time employees who can maintain first-party packages and sweat the details on things like documentation. 

Laravel's documentation might be its most powerful feature. While many documentation sites feel bleak and inhospitable, the design on Laravel's docs is bright and inviting. The docs are well-organized and maintain a consistent voice throughout the pages. The docs also have an instantaneous full-text typo-tolerant search, which will not only take you to the correct page, but also put you on the relevant part of the page.

Laravel's powerful first-party integrations and superior documentation let you get to the business of building your application right away. Rather than comparing the six most popular ORMs for Node, you use the one that comes with Laravel. Rather than researching all the ways to authenticate your users with their social profiles, you use Laravel's first-party package. All of your framework's documentation lives in one place instead of across a dozen sites, and you can leverage the entire Laravel community when you have challenges instead of the few people using the same libraries as you.

## What I've learned

What I've learned is if you want to develop applications quickly, it isn't about staying in one language: it's about reaching for the tools that let you move quickly, whatever those are. 

I use Laravel because it lets me build my server-side apps fast. I use React for most of my front-end web applications, and Laravel gives me the tools I need to spin up the backend quickly. On sites where SEO is important, I can pair a server-rendered Laravel site with Vue widgets for the more interactive parts of the site. Laravel Mix's zero-configuration bundling makes compiling a project's assets a breeze.

Rather than sharing code between the front-end and back-end, I've learned to move almost all of my business and validation logic to the back-end, and I consume it on the front-end via API. Just because you're using two different languages doesn't mean you need to write the same code twice.

**I prefer Laravel over Node.js because it lets me move fast.**

## Parting Thoughts

I could end with a note about "using the right tool for the job," but I don't feel like that's the right take away. Instead, use the fastest, most productive tool you have available to kick apps out the door quickly and get feedback from your users. For some developers and for some projects, Node.js will be that tool. However, for those who are already proficient with Laravel, Rails, or Django and want to use full-stack JavaScript to move faster, I would caution you that you might just lose a year piecing together your own framework with little to show for your investment.