PHP has been in a pretty good place since 7, IMO. These are some great developments.
I would say that Laravel is an extremely high quality framework (on par with and even in some ways better than Rails) that nobody should be ashamed to use.
It's unfortunate that the stink of old PHP is so powerful and that salaries are still lagging so far behind.
That's because the "stink of old PHP" never really went away.
For example, Wordpress install guide [0] still talks about making your code directory writtable by web user -- practically guaranteed that any minute exploit will lead to permanent web shell.
So does Nextcloud install guide [1].
I am sure there are nice, modernPHP somewhere, but a lot of time you I see old-style programs with horrible security practices.
Not just writeable by web user. The page here[1] suggests making files and folders world writeable all over the place (to be fair, followed by disclaimers.. but still).
>If you use Permalinks you should also change permissions of .htaccess to make sure that WordPress can update it when you change settings such as adding a new page, redirect, category, etc.. which requires updating the .htaccess file when mod_rewrite Permalinks are being used.
Go to the main directory of WordPress
Enter chmod -v 666 .htaccess
Making a server configuration file (.htaccess) world-writeable. What could go wrong? I am amazed that shared hostings still somehow manage to keep their tenants safe from each other.
1. WordPress was released in 2003, Netscape Navigator was basically dead by then.
2. It’s fair to judge a language by its dominant platform / use case. Rails (2004) and Django (2005) are barely younger than WordPress. Is it fair to judge Ruby and (one facet of) Python by examining Rails and Django respectively? Yes.
According to some statistics [0], Wordpress is used on 41% websites in the world. That’s a lot of websites! Even if those numbers are inflated, It is still likely the most popular PHP app in the world. It is not disingenuous to judge a language by its most popular application.
I wonder what fraction of PHP programmers today mostly work with Wordpress.. and how many PHP jobs involve maintaining Wordpress apps.
The list goes on, I have a pet peeve with matomo (aka piwik) for example. Impossible to do immutable containers --- it's just bad software design, not a fault of the language itself. But because these softwares are old and have an user base, design errors remain throughout decades.
They're not lagging behind. Based on my experience, companies in the bay area using PHP often pay just as competitively as others. There are likely a large number of "PHP" jobs available overall though which could bring average pay down, the low-end is low because there's such a low barrier to entry for something like WordPress development.
> There are likely a large number of "PHP" jobs available overall though which could bring average pay down, the low-end is low because there's such a low barrier to entry for something like WordPress development.
I was about to write exactly that. There is a long tail of relatively unskilled developers who technically count as PHP devs. I also do not perceive PHP salaries to be lower relative to other web dev stacks.
I liked Symfony but becoming a “PHP guy” looks like a terrible career move still. Also not a huge fan of the one data structure being both a dictionary and an array.
Amen. And it does neither very well. Not to mention that you can get surprising results like if you insert into an "array" out of order then iterate over it, you get the results in insertion order and not index order.
> if you've used one MVC framework you've kind of used them all
Same goes for C-like languages like PHP or C#. Most of the features and syntax are the same across all in the family, so who really cares if it's Ruby, PHP or C#, they are more alike than they are different.
Those are fine. PHP has just been tainted by its past and low barrier to entry. I hate to say it but my company now just filters out candidates who have PHP as the majority of their experience because the signal to noise ratio is so bad.
> I would say that Laravel is an extremely high quality framework
I strongly disagree. My experience with Laravel made me see it as a medium quality framework with many flaws. I'll point out to a few of them.
The source code quality of the framework is not very high, and locally very poor. For instance, you can't autocomplete normally with an IDE unless you load extra declarations of the magic. Sometimes functions return values of varying types. And, last but not least, there are many cases where a call to a method on on object is intercepted by the magic `__call()` and redirected to another object created on the fly.
As pointed above, the abuse of magic means browsing the Laravel API is a nightmare. You won't see methods that you may call. Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation.
Laravel is extremely slow. Speed or concurrency is not a problem for many web sites, but when your framework is 10-100 times slower than others, you hit performance problems sooner. I suspect the magic and a few design choices (e.g. not using PHP native sessions) mean that a Laravel application can't get fast.
Firstly if there are "many flaws" list them because it seems you only don't like the developer experience with the autocomplete. I noticed no problem with browsing the Laravel API [0] with my short adventure with it.
> framework is 10-100 times slower than others
citation needed.
Also you didn't mention what you tried to use it for but remember software engineers are paid to pick the right tool for the job, Laravel is not the top pick for highly-concurrent idempotent microservice on Kubernetes, it's for monolithic app replacing that old WordPress installation without changing the tech stack
Presumably, you pick/choose which would use swoole or be delivered on php-fpm maybe run both with nginx proxying swoole, then your old code would just run sync and newer could run async if required --maybe for things like chat/websockets and not for just static pages.
> Overall, the official documentation is tutorial-oriented, with an abuse of videos. I have not worked with Laravel for more than 2 years, but at that time I could not find a public reference documentation
The docs are geared more towards beginner/intermediate users most advanced users go to the API/class docs, and look at the underlying code to get an idea of how things work internally, if you haven't done that then you're definitely not going to know how everything ties together.
Also there's plenty of plugins and an ide_helper package to generate metadata/etc to make it so you get damn good autocompletion in just about any ide and especially phpstorm, but I use vscode and used to use sublime both have great completions...
The magic is a problem in other ways as well, it confounds static analysis (Psalm has to have a separate plugin just to be able to profile it).
I'm not saying it's a fault of Laravel (yet) because the framework predates a lot of 7/8 stuff but they show absolutely no incentive towards making it better in that area.
Frankly, just pick symfony it's a better tool for longer lived projects, better documented (insanely better), better backwards compatibility.
Rails also got traction in SF & other high paying areas at the right time. PHP had it’s chance to make establish itself in SF in the mid to late 2000s, but Ruby on Rails worked its way in as a fast prototyping tool that made efficient use of VC capital at a time that PHP was seen as a tool used by less serious developers. A lot of startups contact me about Rails to this day.
I have wondered how much of this is also due to markets. A lot of governments and security-centric nonprofits (eg hosptials) use PHP instead of Rails, which seems much more popular in startup land. It could even be that PHP is used fairly evenly across the whole US, while Rails is used more on the coasts.
Disclaimer: I don’t have hard facts or even anecdotes, I am a functional-first developer who marvels at any language which actually has jobs on the market :)
Laravel docs are virtually non existent. The code comments are meh.
Their upgrades are frequent but are not backwards compatible. Many times after an upgrade we spent hours finding something that broke and was not documented in the upgrade guide.
Their code quality leaves much to be desired, and it very significantly will slow down every part of the site.
It is hard to call this a "extremely high quality framework" or even a "acceptable low quality framework". It may be possible to say this is unfortunately the best we've got in PHP.
Upgrading literally takes 1-2 hours MAX for any codebase and I've upgrading from MANY versions... I once updated a 4.2 app to 6.* ...that did take more than a few hours and there were some hitches but those would've been smoother if there was decent unit testing.
There's also some services that will basically use static analysis to tell you how to "safely" upgrade your project, what files need edited etc...
Also, can you kindly tell me how to upgrade from Rails 2.8 to 6.*?
I once scrapped a project trying to upgrade from 2.8 to 3.2..I see MANY open source rails apps that never upgrade because it's too damn hard they just keep building for an older version.
> I would say that Laravel is an extremely high quality framework (on par with and even in some ways better than Rails) that nobody should be ashamed to use.
Never heard of Laravel. Decided to take a look. First thing the intro documentation says to do is install something called 'Docker Desktop'. I'm good, thanks.
Why do I need Docker to play around with a web framework?
“ Never heard of Laravel. Decided to take a look. First thing the intro documentation says to do is install something called 'Docker Desktop'. I'm good, thanks.
Why do I need Docker to play around with a web framework?”
Because modern web development is complex, and Docker helps make that burden less so.
You make it sound like you took one look at the docs, and that was just too much for you to go any further.
Don’t get into front end development, because you’ll lose your mind.
OP has a valid point. What's so painful about Laravel deployment that it requires Docker? And that's just for Laravel, then you need another for your database. Then if you're working from home most broadband connections will not be suitable for containers. The whole Docker/Kubernetes cult is a farce as far as solo freelancers are concerned. Making it an idiomatic default just smacks of elitism.
This feels so un-PHP. One of the reasons PHP won is because it was relatively environmentally neutral.
There was a galaxy of free and cheap PHP software whose deployment process was basically "FTP everything up and plug in database credentials." At most, you might have to confirm you had PHP5+, but basically any random cheap hosting or default-config VPS would work with default or near-default settings.
In contrast, a lot of Rails and Node stuff was much more fragile by comparison-- I can recall trying to deploy other people's RoR applications and it turns into a huge rabbit hole of version matching and dependencies that aren't there out of the box and "OMG you never should have started with $distro."
The Docker mindset feels like a snarky response to "it works on my machine"; rather than actually making things reasonably environment-neutral, just ship your machine with every install!
Unfortunately the documentation does make it look like you need docker to get started. You don’t though. A litter further down in the docs there is a section for using just Composer, if you’re still interested in checking it out: https://laravel.com/docs/8.x#installation-via-composer
I haven't used PHP since ~2002/2003 so I wasn't aware of Composer, but this seems more along the lines of the original Rails tutorials which used gem to install rails.
I think learning things with as few components as possible is an important part of actually learning what you're working with, rather than just turning knobs.
Alive and well. And if you haven’t seen the surrounding laravel ecosystem in 4-5 years I think you will be quite impressed. The amount of 1st party integrations and side projects is amazing.
I was testing out Apache Superset the other day and it recommends using Docker to do so. I am not strong in Docker - I prefer to run things from scratch so I know exactly what is going on under the hood - but thought I'd give it a go.
I had so many problems getting it going. Part of it was the Superset instructions were slightly obsolete, but mostly it was this same problem in this issue[1] from 2016, which was closed in 2017, which is still obviously an active issue for new Docker users.
It seems to be just a relatively simple Linux filesystem permissions issue (or at least, that is how I resolved it quickly, just to get it working), but it strikes me as bizarre that this kind of thing could not be resolved with a better installer or docs or something.
I then ran into problems with the application running under Docker not being able to access the database in the host OS. Again there are a zillion resources for resolving this, going back years, with many dead ends as it has changed so much since then.
There's this hugely upvoted solution[2] on Stack Overflow - which works for Docker, but Superset is launched through docker-compose, so straight away a new user has to figure out the differences.
In PHP on a fresh Linux box, you can be up and running and developing on Debian/Ubuntu with two or three apt-get commands, depending on whether you need a database server. Adding Docker into this mix just seems like it would unnecessarily complicate things.
All that said, I appreciate once you're over the learning curve of Docker, it's super useful. I am finding myself increasingly reaching for it as an option to container-ise some setups away from my current setup, which is basically bash-scripted install processes on fresh VMs.
I happen to do web development and run a Docker course and I will confidently say it's a lot easier based on support questions and overall feedback that I've gotten over the years.
Because the alternative involves a ton of manual steps that every individual needs to take, for example with Python (and this applies to most languages / ecosystems with tiny changes):
- Which version of Python do I install? How do I install it on Windows 10? What about macOS? What's the instructions look like on my distro of Linux?
- How do I handle multiple versions of my programming language or install the language without the root user?
- I need to run Postgres, how do I install that on my OS?
- I need to run Redis, how do I install that on my OS?
- I need to run a specific version of Postgres / Redis for this project but a different version for another project, how to set this up?
- I need to use Webpack, how do I get Node installed and set all of that up
- How can I easily run all of my app's dependent services at once (web + worker + webpack + database + cache) without having to open multiple terminals or discover language specific tools with their own config files
- How can I use environment variables in my app that are loaded from a file?
- My app needs a library that requires a C dependency to be compiled to use it, how do I get that working on my OS?
Now imagine you're just getting into programming and want to build a web app with Flask, Django, Laravel, Rails, Phoenix or any other language / framework. You're going to need to do this for pretty much every tech stack and the learning curve for this stuff is really high when you're a beginner. There's so many unknown unknowns that lead to dead ends causing folks to get really frustrated and just say fuck it and never start.
But with Docker, you install Docker Desktop and technically you can treat it as a black box where everything is on a need to know basis. As long as you can find a reasonable base project to work off of getting started is as easy as installing Docker and running docker-compose up --build, and waiting 5-10 minutes. Now you can focus on learning the important thing (web development using the framework you've picked).
In most cases that works very well. Sure there's some installation related issues along the way but with tens of thousands of folks who have taken one of my courses using Docker, this a huge minority and it's usually something that's easily fixable (I offer support and deal with questions like this once in a while).
All points taken! I just get frustrated because I figure if the developer is taking care of building a Dockerfile or whatever it is with all of that stuff sorted out for me, providing at least those build instructions as part of the README is enough for weird users like me.
Then I can spin up my own VPS/VM with the dependencies myself, which removes the entire black box nature of it.
I get that most people don't want to do that and indeed embrace the black box, but I've never worked anywhere where I could spin up a random application in Docker in any sort of Production or even near-Production capacity and say with a straight face I'd done due diligence in what was going on under the hood. (Maybe people don't use it for this ever though.)
I would probably be more on board if I'd ever had a single Docker experience that was just "install docker and run something" and it worked, but every single time I have run into problems.
Realised I forgot to include my references in my previous post. Again, appreciate these problems are probably old hat for regular users, but for people coming in cold they're just pains in the ass.
Docker on non-Linux OS's is just a VM. You could do the same by starting a linux VM w/ the system environment you're deploying on, and save the Docker overhead.
> Docker on non-Linux OS's is just a VM. You could do the same by starting a linux VM w/ the system environment you're deploying on, and save the Docker overhead.
It's not close to the same user experience.
- If you roll a custom VM you need to first pick a hypervisor. Are you going to use vmware workstation, virtualbox or the native type-1 hypervisor on your OS such as hyper-v on Windows or hyperkit on Linux?
- Are you going to set up that VM using your hypervisor's UI or look into using something like Vagrant?
- What private network subnet are you going to choose when you set up your static IP to your VM?
- How will you get file sharing to work really well (complete with inotify support on Windows)?
- What about starting and stopping the VM for each project? What if you wanted to run a few projects at once with different exposed ports, how will you manage all of these VMs and the resources they've created?
- What if you're running native Linux and still want to isolate everything? Now go back to the first bullet point and add KVM, etc. into the mix
- Which Linux distro are you going to choose to run in the VM? If you're using Vagrant does your Vagrant box's OS support all of the guest features of your hypervisor?
- Now that you have your base Linux environment in a VM, how are you going to set up all of those bullet points I provided in my previous reply. It's back to the drawing board on having to do everything yourself but now on Linux.
A beginner developer is not going to have the same experience doing all of that instead of installing Docker Desktop and running docker-compose up --build. Docker is adding massive value from a convenience point of view and it gets much better once you go beyond your local dev environment too. Now you have a way to easily share your exact project set up process with another developer on any major OS and you can run your containers in the same way on a VPS if you deploy your app there too.
Redis and postgres are an apt install away. I can't imagine redis would throw you. Postgres use to require using a separate user to login through the shell.
You don't, that's just the quickest/easiest way to get started. If you read slightly further, you'll get to the section for people who already have the dependencies installed directly: https://laravel.com/docs/8.x#installation-via-composer
I would say that Laravel is an extremely high quality framework (on par with and even in some ways better than Rails) that nobody should be ashamed to use.
It's unfortunate that the stink of old PHP is so powerful and that salaries are still lagging so far behind.