To everyone recently discovering and/or considering Laravel as a web framework, welcome. There’s plenty of room!
My name is Dave Calnan. I first learned programming via Laravel (and Laracasts) 7 years ago. My last job was at a startup, helping to scale a Laravel + React application to over a million users. My current job is running my own startup built on the same stack. It’s great. I really like it. I’m not here to convince you it’s better, just tell you what I personally benefit from using it.
I spend half my time in the JS world and half my time in the Laravel world and I think there’s a lot the JS ecosystem could benefit from Laravel.
Caveat: I primarily work with React and in this post will refer mostly to frontend JS frameworks as that’s what I have experience with rather than backend frameworks. If your JS framework has none of the warts I describe, please do tell me about it as it sounds great!
Frontend-first vs Backend-first
Imagine you want to show a list of posts on a blog. Depending on whether I’m wearing my JS hat or my Laravel hat I might approach this one of two ways:
My theory is that JS developers are more likely to follow the frontend-first approach and Laravel developers are more likely to follow the backend-first approach I mentioned. Is this true for you? Please let me know I’m so curious.
I think I’m slightly more of a frontend developer than backend developer so I typically start with some mocked up UI and then make it “real” by going from the frontend towards the backend.
That’s the R in CRUD
I think these are both dandy approaches to solve the problem of “take a list of posts and render them in a list”. Laravel and JS frameworks can both solve this really well. That’s the Read part in Create, Read, Update & Delete (CRUD) sorted.
If we were to extend this out the remaining letters (CUD), that would involve:
- Adding a Create Post form
- Adding a Update Post form
- Adding a button to delete a post
Forms & Actions, a developer’s bread and butter. Forms are a core part of the web and Laravel has had them baked in since day one. I think a lot of us in the JS world (myself included) forgot about forms and instead wired up a bunch of controller
<input />s and intercepted the browser’s normal behaviour to make an API request.I personally feel parts of the JS world are kind of figuring this out. Remix introduced
actions early on to handle standard web form submissions and NextJS has only recently introduced Server Actions in alpha. Reading data was a solved problem but writing data is still kinda being figured out.Still, with either a Laravel app or a JS app you can write data as well as read it. Great.
What about things not tied directly to the UI?
This is where I started to miss having a backend framework like Laravel.
Authentication
What if you want your users to have to log in to create posts? For me this was a mess of searching for NPM packages, reading blog posts, and making a choice. Typically you can either use a managed service like Auth0 or Clerk or roll your own. It seems rare for a JS framework to have auth built-in like Laravel does.
Laravel also has built-in API token management, auth via cookies or bearer token, 2FA, email confirmation, password resets, out of the box screens for user & team management, rate limiting, etc. The batteries are definitely included.
Emails
What if you want to send your users an email when the request a password reset? Again, research and look for an NPM package, managed service, or roll your own. There are plenty of great options but you still have to choose and wire it up yourself.
Emails are built in to Laravel.
Operations outside of a web request
What if you want to send a daily digest of top posts? It’s easy to take a web request, handle it, and return a response. What about something that happens outside of web requests like a daily task like this? Again, I researched different NodeJS solutions and managed services to handle this.
In it’s one line of code to schedule a job:
php$schedule->job(SendDailyDigest::class)->daily();
It’s just so good.
Async operations/queues
What if you want users to be able to download a report of all their posts and their views? It will likely take longer to generate the report than a) you want the user to have to wait or b) longer than your requests are allowed to stay alive before they timeout. You’ll want to offload this task to an asynchronous queue. I tried to figure this out in JS world and again was presented with NPM packages and managed services.
Queues are a first class citizen in Laravel. They’re simple to start using and so powerful when you need them to be that Mohamed wrote a whole book on it.
More complicated database queries
What if you want to be able to have draft posts? Usually people write a draft of a blog post before publishing. How do you stop draft posts from showing up everywhere you show posts? I had this problem with archived users and Prisma did not have a solution for it. I had to add the condition to everywhere I queried posts. If I ever forgot to add it I could end up with unintended data leakage.
Laravel’s Eloquent query builder allows you to add global scopes to solve this. Adding the
SoftDeletes traits solved my archived users problem with one line of code.That’s only scratching the surface
Every time I’ve taken a JS app from relatively straightforward to a bit more feature-full, this pattern has re-emerged. How do I solve this? In my JS app: research, pick an npm package, managed service, or roll my own. In my Laravel app: it’s likely built-in and if not, has a framework specific community package to pull in and work out of the box.
Community
The Laravel community is wonderful. It’s full of really genuine, helpful people who enjoy using the software. There is a great culture of sharing what you know, in the form of blog posts, videos, conf talks, or packages. People are generally very helpful and I find more focused on getting the job done in an enjoyable way than dogmatic about their architecture. There certainly is some of that but less so than other places online in my experience.
Conclusion
I would highly encourage JS developers to take Laravel out for a spin and see if you like it. Even if you don’t I think it’s good to get out of your normal sphere and see other ways of doing things. It’s a bit like travelling to see other cultures but also not at all like that in that we’re very much inside in front of a screen.
This post and this site was quickly thrown together in response to seeing some of the JS developers I follow starting to discover and interact with Laravel. This site isn’t meant to diss JS at all, just to say “come on over and take a look, it’s nice here too”.
I don’t even have comments set up on this so feel free to tweet @davecalnan or email lambo@jsforlaravel.dev (a real email) with any thoughts or feedback.
