I've been working with Laravel since '13 and PHP since '99.
Both just keeps becoming better and better to me. Recent years of needed improvement and feature development of PHP, keeps me happily invested in continuing with PHP as well.
I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.
> I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.
That's an interesting statement, as it heavily contrasts with my personal experience.
From the start, TypeScript felt as a breath of fresh air and the whole experience was very enjoyable.
The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure.
Can you point out the single most egregious thing you experienced with TypeScript?
> That's an interesting statement, as it heavily contrasts with my personal experience.
The key take here is that it's a personal experience - for the both of us. I'm confident that it works for some, the same way as PHP doesn't work for everybody.
> The only (and major) drawback was having to deal with JavaScript frameworks which required tsconfig.json/webpack voodoo to work at all, let alone with TypeScript, but once the project was sorted out everything was a pleasure.
I guess this is a great transition to your question...
> Can you point out the single most egregious thing you experienced with TypeScript?
The _most_ egregious thing? I would definitely say the community behind it. While I've worked with other languages as well (Kotlin, Dart, Python), the community behind NodeJS/TypeScript is the single most fragmented and toxic environment I've ever experienced.
It seems to have no common direction whether it comes to dependency managers, coding styles, transpilers, bundlers or much about any other “best practice” paradigms. And this also something that is pestering packages and the maintainers. Often, it looks more like a contest on who can make the most complex solution to simple problems as well. I don’t experience this vast amount of fragmentation in PHP, Python, Kotlin or Dart. Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers and toes; sure - not all agree on everything, but there’s more often than not, a sense of consensus on what a common approach to any given problem could be.
> Whenever you reach out to the community, you’re rarely met with more opinions than you have fingers
One looks like a large and fast-progressing area, the other like a smaller and more cohesive area. JS/TS ecosystems made a lot of breathtaking progress in the last 15 years. It has a price: trying all the new approaches to find a better path means a huge breadth and fragmentation of the mindshare.
Not that Python hasn't made a lot of progress in the same 15 years, but, frankly, it's not as varied and novel, even with the advent of gradual typing and async support in the language.
Stability may sound and even feel good, but being stuck with targeting IE6 or C89 is also stability. Both stability and progress have upsides and downsides, there's no absolute winner, and you have (and, importantly, can) choose the balance you're more comfortable with.
It's constant churn in that ecosystem to keep the build system working in any medium/large project, way more so than in any other backend runtime/package managers I've used.
It's hard to quantify, maybe, but it just feels like constant stress. I've worked in bad Java shops where you wonder if the build will compile today. The average Node places are much worse in terms of the tooling and build system not working for whatever fancy reason on <insert day>.
Recent example: Did someone at Google decide to merge a PR to a library two dependencies down? Because now shit won't compile, the compiler OOMs. Just what I wanted to figure out today, a crashing compiler on a minor library version change that nobody asked for.
It’s a challenge, but it’s not that bad. All the package managers have lock files, so no dependencies change daily until you update them. You could even have auto-update via dependabot or renovate and the smallest amount of CI would stop the breaking update from getting through. I’ve worked in a lot of node projects and never worried about whether they’ll compile today. Lock files have been standard/default practice for a long time.
The hard part is actually doing the updates. So many breaking changes, so many new (often better) approaches, so many different tools that interact with each other in weird ways…
It happens regularly to the point that it becomes the happy path.
The trick is that you should pin all dependencies and not just let auto-updates happen, and instead treat even patch updates as if they could be major-version bumps.
> It's hard to quantify, maybe, but it just feels like constant stress.
I agree, but the key factor is auto-updates cause pain. Once you disable those you no longer experience any pain. For instance, no one needs to constantly upgrade dev dependencies, and even patch upgrades to TypeScript are hard to justify without full regression tests.
If you put off all updating doesn't that lead to a lot of technical debt down the road? I guess most of the stuff I work with has to work for a long time and putting off updates just makes for a worse pile to sort out later once you find something newish to integrate and now it won't work with the older existing stuff. For us, keeping up to date incrementally helps prevent that maintenance work from building up. I guess it depends on how long you'll be maintaining the code. If it's something that won't need to work for a long time and you have enough devs then you can probably skip keeping things up to date and just rewrite it when it needs updating.
> If you put off all updating doesn't that lead to a lot of technical debt down the road?
It depends on what you interpret as being technical debt.
For example, are you piling up technical debt if you skip a patch update to the typescript compiler? What about Jester? What if you skip a point release of React? Are you piling up technical debt if you are not on the bleeding edge?
In case this counts as technical debt, what's the productivity hit of staying on that treadmill? Are you actually gaining anything by systematically be on the latest and greatest?
> For us, keeping up to date incrementally helps prevent that maintenance work from building up.
In my experience with modern frontend frameworks, the vast majority of these incremental changes do not add any significant value and in fact amount to wasteful noise. Some patch releases introduce regressions that are ironed out in following releases, and automatically applying these updates only buys you problems.
Also, it's very hard to justify having to refresh your whole dependency tree at each commit, or risk experiencing problems because switching local development branches causes dependency issues. Installing dependendencies should be a rare occurrence.
I can't overstate the importance thay pinning all dependencies and lowering the frequency of how these dependencies are updated has on a team's development workflow. No one will get hurt if you upgrade Jest or TypeScript on a monthly basis instead of at each commit.
I think pinning dependencies helps, but I have literally never seen an organization do this with Node. At one job, the "architecture review board" decided that all services would always use "latest" for all dependencies...
I don't disagree, but there are other issues too. Namely the Node runtime is much harder to diagnose performance issues than with even async Java, and every time this comes up it's a huge resource sink for most teams I've seen.
I think Node is a great tool. Lots of FastComments is built with Node. I just don't advocate for building large systems or monoliths with it.
I think for my next project I'll be trying out using Laravel's prebuilt user auth/login system, then building the business APIs in Node+TS (interfacing with the same relational DB). Developing not-so-dynamic webpages is just quicker in Laravel/Rails/Adonis, and reusing a prebuilt auth system across small projects just seems logical.
There's a bit more coordination involved in this approach, but there's sufficient separation of auth logic from other logic to allow it to work efficiently. Might run into issues with performing auth-related tasks (like invalidate session) on the Node API side, but I think they won't be too difficult to work out.
I have about 7 years of professional Laravel experience. I think it's quite slick! There is one aspect I haven't seen mentioned here that frustrates me: the community is quite eager to make new shiny things and forget about existing things. I feel the core framework doesn't get a lot of love anymore, and the same for some other packages. Something like Homestead got introduced as a huge thing, but got relatively quickly replaced with Sail and Valet it kind of seems. (Yes, they have a bit different corners, but I would say it doesn't justify a complete package) For authentication you have multiple packages that were introduced as the holy grail but now sit in an awkward spot with each other, and similar for frontend things packages.
Another small frustration for me is all the huge adjectives being used:
- "Laravel Horizon provides a beautiful dashboard ... "
- "Laravel Jetstream is a beautifully designed application... "
- "Laravel Octane supercharges your application's performance..."
- "Laravel Prompts is a PHP package for adding beautiful and user-friendly forms ... "
- "Laravel Reverb brings blazing-fast and scalable real-time WebSocket ..."
- "Laravel Sanctum provides a featherweight authentication system ... "
- "Laravel Telescope makes a wonderful companion ..."
- "In other words, Valet is a blazing fast Laravel development environment ..."
I think it would we wise to do a bit of a cleanup and merging of official packages, and to not forget about the core framework. I think Symfony shows you can still do great additions even after many years like Targeted Value Resolvers [0]
You can see all the official packages clicking the "Ecosystem" button in the header of laravel.com
> the community is quite eager to make new shiny things and forget about existing things.
When I got into the Laravel ecosystem I had high hopes for all packages made by Spatie (Belgian Laravel agency). Later I noticed that the packages aren't all that great (or: very opinionated, less idiomatic) and that I fell for their great marketing. The packages sometimes are more of a self-promotion device. Also some of them are open core only (for instance media library has a corresponding media library pro).
Relating to your other point they aren't only "created" but "crafted" as so many other "artisan" in the web programming space, maybe especially in the Laravel world :)
So, if working with Laravel be sure to take everything with a huge grain of salt.
Next time I'll start a PHP project I'll probably go with Symfony.
> I think it would we wise to do a bit of a cleanup and merging of official packages, and to not forget about the core framework.
Isn't this an issue that most enterprise frameworks end up with?
For example, if you look at the Spring ecosystem, there's also quite a few packages: https://spring.io/projects and https://start.spring.io/ (if you click on the "add dependencies", it integrates with a lot of stuff)
Laravel has been amazing for a long time. I heard its 'convention over configuration' approach was inspired by Rails, and the ecosystem is competitive with anything.
For small to medium web projects, the benefits of having JS across the stack has kept me from using Laravel again. That doesn't apply to all projects, though, and I still love it.
Waiting for the next thing. Toying with Deno Deploy (no association).
I'm really wondering: how can people switch frameworks / languages for each project so easily? Isn't there a lot of benefit to not having to learn everything new and doesn't that outweigh any technical advantages of the "next thing". And Laravel for example has such a broad, high quality ecosystem, that is mostly lacking in new projects..
It took me quite a while to get traction back then with ZendFramework V1.0
I fiddled around with Flow, from Typo3 and a bit of Laravel.
If you only add a controller here and there and do some simple database query you can work in 20 frameworks in one language in parallel.
I side with you, frameworks per project on a rapidly changing basis won’t work. Experience is a must, 3-6 month extensive exposure to doing some heavy lifting as well as debugging is a necessity. Staying up to date and dealing with migration issues as well as older version maintenance is a must, code reviews, build pipelines, even bug fixes or change requests.
Also frameworks evolve quite a bit over time and there also seems to be trends and biases towards certain tools or add-ins in certain cases, setups, configurations.
So in my experience I never met a jack of all trades, only real masters of one framework with all the ins and outs.
> I'm really wondering: how can people switch frameworks / languages for each project so easily?
My trick is to use Anki to remember the important details occasionally, and before starting a project in any particular language or framework to heavily review that language or framework in Anki beforehand.
After doing it a dozen times in each direction it gets easier - the advantage of being old is that one has much experience.
I agree that there's a lot of benefit to sticking with a thing. I've only seriously used Perl, PHP, Erlang, and Node, over 20+ years, deliberately. For productivity.
One reason for switching and trying is a fascination with finding the next amazing thing, always hunting for something new and better. Usually it's only slightly better, or not better. But sometimes you find Elixir, Laravel, or Deno. And it's more fun and productive, plus you're ahead on the resume.
I've been working with React, Vue, Nuxt/Next, even some ASP.net... Somehow, I keep coming back to Laravel when creating a new dynamic project. Whenever I setup a new project in other frameworks, I get exhausted afterwards, I had this great idea I wanted to try out, but after the setup, I lost all motivation.
It's different with Laravel, because the setup is so much quicker and it has everything I need preconfigured out of the box. I don't mind writing PHP, my heart loves C# but I've worked with PHP for almost a decade now. The best thing is, that I can STILL use Vue if I want (and I very often do) through Laravel Breeze.
I used to use silex a microframework from symfony.
I really liked the limited scope. It’s gone, and they said just use symfony. It’s a jump there are too many knobs, and even though I kinda know what’s going on it can be overwhelming.
My summer project is to try larael.
I’ve dealt with python,perl and java sites but always come back to php… I know it gets a lot of flack but I kinda like it.
Just do what I do, use something like Phroute or any other routing library. Add a couple of supporting classes (Request, Response, DB connection, etc.) and you're good to go.
If you don't need all the stuff that comes with a large scale framework, there is no point using one. It all depends on your requirements though.
Honestly most of what you consider to be good or bad is a personal preference. But what I can say for certain is that framework-less modern PHP is 10x less ugly/complex and an order of magnitude more performant. There are a ton of new language constructs and features which puts it on par with, if not ahead of, most other languages.
Here are some of the most recent feature additions:
PHP kind of stagnated in terms of development with PHP 5.5 in 2013. It kind of went quiet. Along with an overshared article[0] on how bad and why PHP 5.4 was bad (which the community in all fairness overall agreed with, with some exceptions) PHP got a real bad reputation.
PHP 7.0 landed after key persons picked up the development of PHP again, and while progress was slow it really took off from here.
It seems like the biggest pain for the entire community is the lack of generics. There's a lengthy explanation as to why it's so difficult to achieve in PHP, but overall the features since 7.0 added has really added some modern value compared to peer languages.
A lengthy list of additions is easiest generated by some GPT provider. But the community painpoint is generics.
PHP tends to be a red flag for security specialists. When talking to other technologists I tend to get eyebrows if I mention building a product in PHP. Most of the damage is done by Wordpress, unfortunately. I think Laravel is a boon for no-nonsense rapid application development.
Yep. It's scary to enterprises, because of lazy (or incompetent) security folks. It's just like any other language. They just look at crap like WP and the amount and ease of code dumped out to the net. Disregarding the actual stuff that would actually be used.
It's actually PHP's success and simplicity that creates the volume of code (and thus volume of bad code) that gives them that impression.
I wind up using PHP for tons of scripting or internal tools still. :)
I think loving your tools is good. While there's no framework that's _better_ than the language, there are ones that are worse than the language they are written in (Grails comes to mind).
I just don't _want_ to work with PHP, at all. But it I had to I would prefer to enjoy the tooling.
Was there some particular event (new release, announcement, etc.) that has prompted the ton of Laravel references I'm seeing on X and elsewhere very recently?
Nope. It’s all Twitter beef that spiraled into drama over the weekend. Prepare for the discourse to continue this week as there will be a few crossover podcasts from JS and PHP land with various talking heads.
Many people praise the PHP-native model of mixing HTML with server-side code (Dynamic HTML if I remember correctly), and rightfully so for many use cases.
But I wonder why no other languages has implemented this model, not even Python which is used for almost everything.
Templating is not the same thing as the language in the template is normally not the complete host language, and JSP is quite old and did not even support Java 8 the last time I tried :/
Nah, Razor is a template engine. Laravel's equivalent is Blade. They're templates in the same that the templates is compiled into a string with parameters then the string is output to the response.
What top post is referring to is the ability to control what is output to the buffer (raw characters) and what is scripted (<?php ... ?>). The closest equivalent would be classic ASP (not asp.net)
As a side note, I once tried to do a hello world in Razor because of its Wasm capability and found the documentations unbelievably horrible. Admittedly I am not a .Net developer.
My back end/app just gets a few headers that say who an authenticated user is, if they are logged in. When I need to log in or create a user, I can just direct them to the Keycloak SSO portal, where they can also use social login.
It's using OpenID Connect without the insanity of dealing with the low level logic. And the Relying Party implementations work across any technology, be it PHP or Ruby, Node, Python or anything else (a simple auth filter that checks the headers is trivial across all of them).
Seems like almost no Node framework has this out of the box. Maybe AdonisJs, but I think you still have to create login and signup page templates yourself (and password reset forms, etc.). It's probably because Node is used to back self-designed SPAs, but it's still a bit of a bummer for getting a new idea off the ground quickly.
I write firmware for high-power EV chargers. Before that I took part in working a zkVM (cryptography) and before that I ported a PHP web app to Kubernetes; it was written in Laravel.
Are you French?
Seems like the only place where PHP is still popular is France because of Symfony.
But for the rest I agree, coming from Rails and now working in Typescript: Rails is way faster for building stuff, but building scalable apps in a team that scale without a typed language is way more complicated
Both just keeps becoming better and better to me. Recent years of needed improvement and feature development of PHP, keeps me happily invested in continuing with PHP as well.
I tried NodeJS/Typescript for a couple of years, between '21 and '23 - I never learned to like it and leaving the community was the best decision for my mental health in a software development context.