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.
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?
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.
The problem is this never happens.
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.
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.
Undervalued sentiment.
May I ask if it was for technical reason (JS ecosystem breaking constantly) or for people reason?
The "people" is the reason why the ecosystem keeps breaking and there's no consensus on how to do what; so the answer is both in a combination.
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 :/
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)
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 ..."
You can see all the official packages clicking the "Ecosystem" button in the header of laravel.com
[0] https://symfony.com/blog/new-in-symfony-6-3-targeted-value-r...
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.
wow you weren't kidding -- the docs [0] for each of the "packages" could easily be confused with AI-generated text written as a joke
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)
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 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?
After doing it a dozen times in each direction it gets easier - the advantage of being old is that one has much experience.
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 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.
> I wonder sometimes why more people don’t use Laravel (or similar frameworks in other languages: Rails or Adonis)
these frameworks, and other similar ones, often assume that
1. there is some sort of UI or frontend
2. there is a relational database that the app is connecting to
3. there is some sort of auth, based on usernames and passwords
with the stuff I do at work, these assumptions are almost always incorrect.
(edited grammar)
Web frameworks are excellent for CRUD.
Not everything is CRUD.
I still don't get why Rails doesn't have this out of the box.
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).
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
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. :)
Watched a course on Livewire, and really looking forward to using it in the future
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 just don't _want_ to work with PHP, at all. But it I had to I would prefer to enjoy the tooling.
They do. Most people do. If anyone is serious about putting a project up they use frameworks.
I'd rather use something else in 2024