I've actually been really impressed with Laravel after switching back to PHP for a few projects. Not only is the developer tooling experience some of the best I've experienced, it's just really the only framework I've ever experienced with a high quality ecosystem of tools—from Forge[1], which makes it dead-simple to deploy a Laravel app into production to things like Horizon, for managing Redis queues.
A great example of this in action is Laravel Spark[3], a first party base for building paid SaaS apps. I built and launched a writing tool, Write Together[2], to the world in under three weeks, payment systems and all, and got 150 paying customers in a matter of a few weeks. One hell of a great way to MVP an idea and build something useful, in a low amount of time.
I'm basically developing two Laravel apps full-time at the moment, and it's the most fun I've had in years...compared to the hellscape of NPM dependencies and other complexities I'm usually bogged down with. Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.
Agreed, Laravel provides the best dev experience in the PHP world.
The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.
IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.
I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.
Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.
It's funny, I remember when I started working on my first PHP framework, I knew about Drupal, CodeIgniter, Kohana, Symfony and Ruby on Rails. Back then, Symfony was the Ruby on Rails applied to PHP. And I wanted to have a more "php-like" approach to everything. That's when I made phponpie.com (the early attempt).
Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.
In particular, the Db module may be better than Doctrine, for example.
I used both Laravel and Symfony but I ended up with the second. I didn’t like the way Laravel’s ORM has its models structured plus the Symfony PHPStorm plugin is a miracle. Your mileage may vary and this is just me but I never quite understood why people ended up loving Laravel so much vs. Symfony.
It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.
The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).
Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?
Nice! It looks very nice and complete.
I've found this other one in Go lang https://buildsaasappingo.com (I'm not affiliated nor tested it)
I think it is a good idea to turn something that you need for yourself into a side income, I've though about doing this same thing myself in a different language.
What can you tell about your experience building this course, is it worth it ? rewarding ?
Did you find difficult to promote it ? what are the main channels to adquiere customers ?
And if you don't mind sharing some numbers, how many people purchased it so far?
I'd like to get an idea on how profitable (or not) and
personally rewarding are type of courses, to motivate myself and write one of these one day.
thank you!
edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))
Seem's like it'd have to be the "honor system". They could certainly add somethings to detect the software being used on multiple domain, but you could ultimately remove that if you were motivated to.
Tokens are issued from within the Spark customer dashboard and the token is required in order to pull the repo during install. It’s basically the honor system.
I cut my teeth as a developer on PHP, back in the 4.3 days before they'd really placed their bets on OOP, and we were dealing with mysql_real_escape_string, needles and haystacks, and haystacks and needles. No PDO, XSS and SQL injections up the wazoo.
I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).
It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.
I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.
Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".
Last time I used composer (about 3 years ago) it had a nasty memory leak that eventually meant I had to run the build on a higher specced instance than the actual application. This was mainly due to the ridiculous dependancies of the application, but it was almost a show stopper. Has this improved?
In my opinion the framework matters more than programming language. One typically doesn't need the "odd" or "fancy" features of a programming language if the framework is well designed and/or a good fit for the shop's conventions or needs.
Honestly I don't see what's all the fuss about Laravel, especially when you compare it to Django. I mean, you have an admin ready out-of-the-box, and database migrations are automatically generated. Correct me if I'm wrong but, Laravel you need to do those things manually...!
Laravel was fantastic. The first month I followed the tutorial, I was bitter about the complexity, but when it came time to building my back end, it took only a few weeks.
Laravel is interesting for greenfield stuff. I'm working on a legacy project and we've had a bunch of good times with zend as it allows you to transition to it more naturally piece-by-piece.
On one hand, I do see that HN (and probably Reddit) live in a bubble. Where most of the darling languages and tools have very low use in the real-world. And where most of the languages and tooling that actually run the real-world go un-discussed, or simply dismissed, because they're boring and don't appeal to students and entry-level devs working on side projects. I realize that the perspective most rookies get from these forums is completely distorted.
On the other hand, I ALSO think that PHP is only still relevant because of WordPress. The business world runs on Java, and .NET to a lesser extent. I see job postings for Python all the time, as it and the JVM run the worlds of data science and big data. One can even still make a thriving living with Ruby. But I just don't see any recruiter activity around PHP at all. And whereas my Java shop will hire Python or Node junior devs, on the theory that they can learn, we would more likely to skip over a PHP-based resume (if we ever actually saw any).
Often when there is a post about PHP I read over these treads sort of subtly trying to figure out how a language with such a large user base has remained basically invisible to me. And I don't think I live in the HN bubble, though I do use a lot of Python, in my consulting work I've also done plenty of work with .NET, JVM to a lesser extent and other "boring" tech.
But PHP has literally never come up, even as a suggestion or as a tool that is a small part of the company stack or whatever. It feels like I'm looking into a strange parallel universe of software development reading through these threads. PHP devs, where are you?
PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it.
All popular projects have swarms of consultants offering advice, prebuilt additions, and custom development. (E.g. WordPress plugins and themes are everywhere.) This is also a significant factor for the penny-pinching customer — from their point of view, they avoid vendor lock-in and expensive development this way. (Spoiler: it rarely works out, in the end. "Tower of Babylon" and "shallow learning curve" mix in very exciting ways.) So there are masses of people who know the basics of PHP and call themselves "PHP developers". In my opinion, just a fraction of them actually deserves that title.
Right here! Drupal has been moving into the enterprise sector with their latest release (v8, built on Symfony). I get a lot of interest from recruiters based on my Drupal background, especially lately.
In the world I’m in and the journey I’ve taken in my career of being in digital/dev for 10+ years, PHP is what I have based my dev foundations on. (albeit web rather than software)
I am recruiting PHP developers for my team now, and they are out there, but maybe not here?!
We make websites, and not a tremendous amount beyond that bar a few Laravel apps.
I think the bubble has to do with purists vs pragmatists.
I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.
Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.
I was just talking about with a student who got on to a PHP project with an older developer lead. We decided that PHP is a code smell for a poorly managed project. You know, the kind that were common in the early aughts that featured poor version control practices, no tests, no automation, live changes, live database schema, etc., etc. That's certainly not the way things have to be, but it's never surprising if it is. The root cause is the developer in charge and their reports, but PHP usage is an easy marker to check. We found most examples using other languages (you mention) to be generally better managed in our area/sampling.
> PHP is a code smell for a poorly managed project
Woo, that's a harsh but honest assessment.. Having lived through countless PHP projects, I'd have to say I agree.
> That's certainly not the way things have to be
As the article pointed out, there are new developments in the language, frameworks, tooling, etc., that support better practices and well-managed projects. It's just that the average codebase still tends to be haphazardly organized, idiosyncratic, bloated, complicated, tough to maintain and extend.
The popularity and evolution of PHP have been impressive, and having used it for years I do have some fondness for it. But at some point, I think it becomes necessary to move on to other languages and systems that encourage best practices from the beginning, with a higher baseline/average code quality.
Well I've been gainfully employed for pretty much my entire career using PHP and I've never had a problem with recruiters. It really depends on the city, the companies in that city, and the overall market in your region.
Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.
The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.
Indeed, and also Joomla. But the thing with all of these CMS systems is that they're already written. So the related "PHP work" is writing or tweaking plugins for them.
It's kind of like acknowledging the footprint of Microsoft Excel and VBA. Yes, it's quietly a huge deal, and thousands of people hold a job largely because they maintain it for an organization. But it's also the sort of thing one "stumbles into". They don't get hired specifically for that, and it doesn't really transfer to more general developer jobs.
There's still lots of small-fish web development agencies who specifically hire PHP developers.
That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.
I don't know if there's anything inherently wrong with them.
I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.
Laravel and Symphony, in particular, have the terrible code smell of elongated toolchains, that are specific to the frameworks.
> php artisan serve # laravel
> symphony server:start # symphony
Same poor thinking that NodeJS introduced, albeit less offensively integrated.
If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
You make a sweeping statement about a bubble and then demonstrate the edge of yours:
> The business world runs on Java, and .NET to a lesser extent.
Flip those.
> I just don't see any recruiter activity around PHP at all.
This is probably true. My own anecdote: I'm at a primarily-PHP SaaS provider in a major tech hub, and for the couple hires we've made in the last year all of our applicants with extensive PHP experience said we were the only PHP shop they'd talked to, many of them over a year into their job search.
Nope. That's just incorrect.
From Experian to JPMorgan Chase to Cambia Health to Amazon, Java is the typical case for every project. Look at stream processing tools at netflix via any given youtube presentation about stream processing. There are entire tooling segments where .NET is absent, despite their quality tools that run on Windows. Nobody trusts Windows by default and this has mortally wounded .NET
I think the easiest thing to forget is what made PHP popular was how easy it was to get started writing software that worked good enough. The barrier to entry was incredibly low. It caused a lot of bad code & gave PHP a bad reputation but a lot of good was also made from it.
PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.
In the world of machining people will often build a tool for a job. Its a one off, or something that will rarely if ever be used again.
These features of PHP are still eminently useful if you have to do the dirty one off. You can eliminate a massive amount of time pressure (an emergency or time invested vs time saved) if you dont have a ton of overhead that comes with modern frameworks.
And many of us took the jump and refused to do things that way. You're wrong, PHP scales and you CAN do separation of concerns and have pretty, maintanable code, using a framework or not: just a matter of knowing what you are doing
> PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.
I think it's a bit harsh and elitist to label this with "unfortunately"; for developers like the ones you mention, often their goal or aspiration is not to work in a FAANG or silicon valley startup; they want to make a decent living as a developer in their city and this provides that career for them. Many of those companies aren't trying to be the next unicorn, they're just small dev teams trying to maintain a web site for their business.
Why on earth is that unfortunate? Seems like a positive thing to me, even if some people don't make it to the pinnacle of their craft so what? If someone has gainful employment and meaning in their life I see that as a net positive.
Writing with PHP is better than ever... and getting better and better.
And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.
Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.
I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...
My issue with modern PHP is that it's essentially becoming Java. And with the JVM and the Java ecosystem, what is the compelling reason to not just pick Java at this point? With Java you are basically writing exactly what you would be writing with PHP, except with more language features and the ability to opt into other languages on the JVM like Kotlin and Scala.
The modern additions are fantastic for projects and teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.
Interesting analogy, performance wise PHP has made impressive progress. On par with node and the JVM. But Java code specifically is just so bloated. And then there is the worker-per-request model in PHP - All resources isolated to a worker and cleanup on exit. This avoids global garbage collection freezes by design. Something you would get otherwise only from Elixir/Erlang natively. Compared to the JVM that allows PHP applications to scale vertically to any amount of RAM/CPU, and horizontally to any amount of machines. If you let me free choices I'll do Elixir all day long. But pressed on Java vs. PHP for a web app it's PHP for sure.
Java is killing itself at a rate of 6 months. They removed javapackager, which means the official tool to build releases is missing from the LTS version.
The EE ecosystem is collapsing thanks to Oracle opposing the Eclipse Foundation, making the quest to build enterprise applications challenging due to namespace collisions and overrides, because of modularisation.
PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.
The only missing part is a good private composer repository for companies who don't release source code.
Even the nature of server-side PHP is bad. Running the script like an executable and using opcache on better case is no good. Also it is not uncommon to upload a php shell using some crappy upload.php forgotten script... Come on, it's Personal HomePage language - you shouldn't do anything bigger than your home page in it.
One of the main takeaways I got from the original Fractal of Bad Design post was the myriad of inconsistencies in both representation and execution of code. This was barely touched upon, mostly this post focused on how PHP has added features and ecosystem. But then so has Javascript.
Unfortunately this is true and it can't be changed, the functions are named and parameters are soemtimes inconsistent like strpos and str_replace, I would have to use the docs all the time if my IDE wouldn't show me the param names.
But after you get productive with PHP there is no feature that I think I am missing from other similar languages.
- expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings".
- specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associative array at the same time is awful.
- a templating solution similar to JSX. I am spoiled by TypeScript's ability to typecheck my HTML views along with other code.
The thing that matters is language consistency... A language with a pure clean vision of itself in which the programmer can guess at syntax because they understand the general syntax principles to which the language adheres. Nothing here says PHP has been fixed in this regard.
Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.
I've been coding in PHP for almost 20 years now. I think I can count on one hand the number of times where I have had an issue regarding inconsistent function signatures. It becomes second nature, and if I forget, the documentation is available online or in worst case built into my IDE.
I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.
23 years here (php/fi in jan '96) and I probably hit the 'parameter order' issue more than you. I still need to look param order stuff multiple times per year. Normally I can get it in the IDE, but doing remote vim stuff, for example, I need to look it up.
Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.
For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.
Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)
Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.
The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.
See, I code php very rarely, I review php code a bit more often, and I stumble upon these inconsistencies all the time. So because you got used to something bad doesn't mean it's not bad.
That would break too much things and the benefits will not be enough. They could add some new things, deprecated the old things and keep them all but then you get a manual twice as big. All the changes in PHP feel pragmatic, like better SQL support, better cryptography support, better defaults, better performance and less on cool looking syntax or latest cool features.
IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).
> Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.
Rust did it with its "edition" system, where you can freely mix and match modules from the 2015 edition with modules from the 2018 edition. Unfortunately, in the Python 2 to Python 3 transition a fundamental data type (strings) changed, which would make freely mixing Python 2 and Python 3 code much harder.
In retrospect, for me many of the problems would have been fixed it they'd wrapped everything in one release, like gcc with the -std flag.
Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.
That's irrelevant. When talking about language consistency, we should also be including the language's standard library.
The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.
The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.
Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.
> The thing that matters is language consistency... [...] Python made the big leap and fixed some huge problems when it went to python 3
And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?
At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.
Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.
What are you talking about is just a syntax. Which is not an issue for a PHP dev nowadays. I am typing much more custom method names than vanilla PHP functions. And when I have, my IDE shows me the right syntax after a few keystrokes.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
I often run into this argument - "inconsistent syntax", followed by zero proof. Then I wonder - is the person making the comment even using PHP or is the person behind the comment.. even capable programmer?
Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.
There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.
Here's the thing that always grates a little bit for me about these posts:
I don't have a choice.
I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.
In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.
I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.
I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".
I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.
More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.
I've been using PHP semi-regularly since the late 90s. It's been empowering and infuriating.
The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards.
For whatever reason, I often feel clumsier after working on a PHP project. After working in other languages like JS or Python, I tend to feel like I've leveled-up my skills.
One thing I wish PHP would address is the inconsistency in its map-filter-reduce functions -- their argument-order doesn't match (array, callback) vs. (callback, array):
I hear this complaint a lot but I find those argument orders completely intuitive.
You filter (1) an array with (2) a function.
You map (1) a function over (2) an array.
You reduce (1) an array with (2) a function.
It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"
Laravel has Collection class that wraps arrays - as such you can do `(new Collection([your array]))->filter(function(){})` or `(new Collection([your array]))->map(function(){})`. It also adds other helper methods. I guess Symfony has something similar
From a performance perspective, you likely want to do those with `foreach` anyway in PHP. Especially when the array function is fed a closure. I know it is not as interesting as using those functions, but because of PHP internals, `foreach` is almost always preferred.
Infuriating? I'm not here to defend php but even when I do agree that inconsistencies are not nice, nothing stop you of creating your own wrapper for these functions.
Yes, it is really infuriating that PHP literally cannot commit to any coding standards whatsoever for its standard library. Even if you choose to write your own wrappers, it doesn't change other people's code which you have to read. It's idiotic that the developers of PHP didn't take 5 seconds to consult their other functions before adding new ones with the arguments reversed, and it is totally appropriate to feel angry at them for their unconscionable shortsightedness.
Readit News
A great example of this in action is Laravel Spark[3], a first party base for building paid SaaS apps. I built and launched a writing tool, Write Together[2], to the world in under three weeks, payment systems and all, and got 150 paying customers in a matter of a few weeks. One hell of a great way to MVP an idea and build something useful, in a low amount of time.
I'm basically developing two Laravel apps full-time at the moment, and it's the most fun I've had in years...compared to the hellscape of NPM dependencies and other complexities I'm usually bogged down with. Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy.
[1] https://forge.laravel.com
[2] http://writetogether.space
[3] https://spark.laravel.com
The funny thing is that Laravel basically took the Ruby on Rails philosophy and applied it to PHP. Just looking at their site it's clear they have a very similar vision: simple, fast and fun. One can always find differences but the basic principles are the same.
IMO this is great kudos to the Laravel guys, whatever language I use I always look for the tooling that follows the KISS principle. In PHP you have Laravel, in Java/SCala you have PLay, etc.
I need to add that, because of the job, I did a lot of PHP, Ruby, Java, Javascript with many different frameworks and I can say that Rails is still the best for me when it comes to dev experience if you need to move fast. Laravel has come a long way but it's still not at the same level of maturity in terms of tooling and ecosystem. As a bonus with Rails you use Ruby which is designed for programmer productivity and fun.
Anyway, whatever language/framework you use just keep it simple, that's the most important decision you can make for the health of your project.
Fast forward to now. After 10 years there is https://qbix.com/platform . If you're reading this and know PHP / LAMP, I would encourage people here to try it and give me feedback. I've never really spent time growing the community or popularizing it like Laravel. But at every turn, it's made decisions that are as close to PHP and standards as possible.
In particular, the Db module may be better than Doctrine, for example.
For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/
It covers everything about user registration, profiles, subscription billing, 1 time billing, invoicing, and about 50 other things you would likely want to do in a SAAS app or any application really.
The course comes with the source code along with 15+ hours of video explaining every line of code in stages, life time free updates and life time support for close to half the price of what Spark charges just for the source code for 1 site license (with the Flask course you can use the code in however many projects you want).
Spark's business model seems interesting though. I don't use it personally but do you just get the source code and nothing else? How do they limit you to 1 site if you end up with a local copy of the scaffolding / code base?
What can you tell about your experience building this course, is it worth it ? rewarding ? Did you find difficult to promote it ? what are the main channels to adquiere customers ?
And if you don't mind sharing some numbers, how many people purchased it so far?
I'd like to get an idea on how profitable (or not) and personally rewarding are type of courses, to motivate myself and write one of these one day.
thank you!
edit: I'm thinking maybe that was too many questions, sorry if so, you could create a "meta-course" on explaining all these things and I'd buy it! :)))
I can't say I enjoyed working on any of those projects compared to the kind of stuff I do now (and how much I've learned since), but I've been remarkably surprised by some more recent codebases, despite the architecture sometimes feeling a little over-engineered (Symfony 2, for an outdated example).
It's not the style of code I enjoy writing at all but I've seen some incredibly clean stuff that would put a lot of Rails apps to shame. And I'd take that PHP over a badly maintained Rails app any day.
I wouldn't use PHP by choice still, but I no longer care to be snobbish about it. People are doing some good stuff in it, just the same as has happened with JS.
It's also use abysmal amounts for RAM for some reason. I managed to use Chrome headless for my app with only 512MB, but not Composer.
[1] https://github.com/hirak/prestissimo
a package distribution system.
Composer suffers some of the same issues NPM does, IMO: it encourages stuff like 'install dependencies at deployment' and "why write it when you can blindly trust someone else's code".
Not everyone who uses PHP uses Composer.
https://packagist.org/packages/hirak/prestissimo
Give this package a try, it really worked for me to speed up package management with composer.
I would recommend.
Dead Comment
On the other hand, I ALSO think that PHP is only still relevant because of WordPress. The business world runs on Java, and .NET to a lesser extent. I see job postings for Python all the time, as it and the JVM run the worlds of data science and big data. One can even still make a thriving living with Ruby. But I just don't see any recruiter activity around PHP at all. And whereas my Java shop will hire Python or Node junior devs, on the theory that they can learn, we would more likely to skip over a PHP-based resume (if we ever actually saw any).
But PHP has literally never come up, even as a suggestion or as a tool that is a small part of the company stack or whatever. It feels like I'm looking into a strange parallel universe of software development reading through these threads. PHP devs, where are you?
PHP has its tentacles all over the web: WordPress and Drupal are immensely popular for simplistic sites and short-lived promotionals, Magento and WooCommerce attract many e-commerce users, and Symfony/Laravel handle the custom stuff. I've worked with all of these and have the scars to show for it.
All popular projects have swarms of consultants offering advice, prebuilt additions, and custom development. (E.g. WordPress plugins and themes are everywhere.) This is also a significant factor for the penny-pinching customer — from their point of view, they avoid vendor lock-in and expensive development this way. (Spoiler: it rarely works out, in the end. "Tower of Babylon" and "shallow learning curve" mix in very exciting ways.) So there are masses of people who know the basics of PHP and call themselves "PHP developers". In my opinion, just a fraction of them actually deserves that title.
In the world I’m in and the journey I’ve taken in my career of being in digital/dev for 10+ years, PHP is what I have based my dev foundations on. (albeit web rather than software)
I am recruiting PHP developers for my team now, and they are out there, but maybe not here?!
We make websites, and not a tremendous amount beyond that bar a few Laravel apps.
I suspect we travel in totally different worlds?!
I once joined a Java team as a front-end dev (I'm full-stack). They would do the back-end. They had done everything by the book perfectly. Following all the best practices. But the back-end wasn't doing what it needed to do by a long shot. They were stuck. Meaning I couldn't make progress. So I cooked up a simple (temporary) PHP back-end so I could easily build the needed queries. All nicely secured with LDAP. I was literally running circles around their solution. But it was blasphemy.
Eventually they ported my code into Java. Some portions literally one-to-one. Nobody will ever know the critical role PHP played in this Java success story.
I shipped apps in 2 weeks myself that the company got paid ~70k for. And we kept my clients.
Woo, that's a harsh but honest assessment.. Having lived through countless PHP projects, I'd have to say I agree.
> That's certainly not the way things have to be
As the article pointed out, there are new developments in the language, frameworks, tooling, etc., that support better practices and well-managed projects. It's just that the average codebase still tends to be haphazardly organized, idiosyncratic, bloated, complicated, tough to maintain and extend.
The popularity and evolution of PHP have been impressive, and having used it for years I do have some fondness for it. But at some point, I think it becomes necessary to move on to other languages and systems that encourage best practices from the beginning, with a higher baseline/average code quality.
Big business runs on Java/.NET, but small-midsized businesses run on a variety of different platforms partially based on the history of their IT department and their development needs.
The bottom line is that you can write a good greenfield web application for a midsized business faster, with less overhead, and with fewer headaches using PHP and a good framework than you can with Java or any of those other tools you mentioned. The tradeoff is that they don't integrate as easily with the huge backend software packages and may not scale as well as Java and .NET. Which is why huge businesses don't run with them as much.
There's also Drupal, which is very common in higher ed.
It's kind of like acknowledging the footprint of Microsoft Excel and VBA. Yes, it's quietly a huge deal, and thousands of people hold a job largely because they maintain it for an organization. But it's also the sort of thing one "stumbles into". They don't get hired specifically for that, and it doesn't really transfer to more general developer jobs.
That's about it though, I think the web development industry is specifically tied to PHP because of their excessive dependence on WordPress, Drupal etc, this also produces developers who are overly specialised in niches using these platforms at the expense of general capability. Think back to the mid-2000's where there was a big difference between a JavaScript developer and a jQuery developer - while they both wrote JS the latter was generally incapable of using vanilla JS proficiently because their use of jQuery's abstractions as a crutch impaired their learning of the underlying fundamentals. A lot of "WordPress developers" are so heavily specialised in using WordPress they probably can't even remember how to write a vanilla PHP site.
I'm just saying that I don't see any job listings for them as an interviewee, or see any resumes with them as an interviewer. In contrast to other technologies that HN or Reddit declare to be "dead" or "dying", yet actually seem to run the world with no serious disruption on the horizon yet.
> php artisan serve # laravel
> symphony server:start # symphony
Same poor thinking that NodeJS introduced, albeit less offensively integrated.
If you need additional toolchains, you're not using PHP per se, but another meta-language. There's literally no good reason to do this other than to remove the concept of tradeoffs for a "we know better" or "don't worry about it". These frameworks have never added anything that I couldn't do simpler and faster, nor have they provided me with constructive guidance in the design or maintenance of a project.
> The business world runs on Java, and .NET to a lesser extent.
Flip those.
> I just don't see any recruiter activity around PHP at all.
This is probably true. My own anecdote: I'm at a primarily-PHP SaaS provider in a major tech hub, and for the couple hires we've made in the last year all of our applicants with extensive PHP experience said we were the only PHP shop they'd talked to, many of them over a year into their job search.
Nope. That's just incorrect. From Experian to JPMorgan Chase to Cambia Health to Amazon, Java is the typical case for every project. Look at stream processing tools at netflix via any given youtube presentation about stream processing. There are entire tooling segments where .NET is absent, despite their quality tools that run on Windows. Nobody trusts Windows by default and this has mortally wounded .NET
PHP made a lot of careers for developers as they were able to fake it until they made it while learning how to code & providing significant value to a businesses.
While PHP is nothing like its former self, most people who developed web apps in the first decade of the century will probably always remember PHP for what it was.
This is incredibly useful when learning basic web development, even though it doesn't scale for more complicated applications.
It's also incredibly useful when trying to bang out a simple experiment.
These features of PHP are still eminently useful if you have to do the dirty one off. You can eliminate a massive amount of time pressure (an emergency or time invested vs time saved) if you dont have a ton of overhead that comes with modern frameworks.
Unfortunately it also provided a lot of careers to developers who never got to the "make it" stage.
And... you don't need too worry too much about the server, or the request lifecycle, or networking... you just write your app, in a language which is, in my opinion, going in the right direction with a stronger slant towards OOP and types.
Of course it's still entirely possible to write garbage PHP code... but it's possible to write garbage in anything.
I'm increasingly proud to say I'm a PHP developer; it still gets a lot of bad commentary but it all tends to be based on historical stigmas which are increasingly untrue. Yet all the original benefits are still here, and the language itself is going from strength to strength...
The modern additions are fantastic for projects and teams that have a specific need to stay on PHP. I still work on projects with PHP and am thankful it has so many improvements. But in its current form and direction, I'm not sure how it has not become simply a little bit worse version of Java.
PHP is on this aspect still strong and you can still choose your weapon of choice to build whatever you want and not being hostage of a company.
The only missing part is a good private composer repository for companies who don't release source code.
What is PHP's multithreading model again? Hotspot VM? NIO?
I'm sure someone will chime in and cite something similar in PHP, but the comparison will be laughable in reality.
Oracle.
I really do need to get over all of that and give it another shot.
But after you get productive with PHP there is no feature that I think I am missing from other similar languages.
- expressive type system with generics, union types, literal types, basically TypeScript. I can say "this function returns a string" or "this function returns an array", but not "this function returns an array of strings".
- specialized collection/hashmap data structures with good support across third-party libraries. Having one array() structure acting as both a sequence and an associative array at the same time is awful.
- a templating solution similar to JSX. I am spoiled by TypeScript's ability to typecheck my HTML views along with other code.
You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script.
In a major release, you then get rid of a load of cruft.
Python made the big leap and fixed some huge problems when it went to python 3 - yes it's migration approach was a total fail, but it further cleaned up what was and already clean and consistent language.
The only thing that would have really interested me in this post would have been to hear that PHP had been cleaned up into a consistent syntax, but that's not what this article says.
I can understand why people make this into such a pain point, but quite frankly it isn't for anyone who works day in day out with PHP.
Yes, it's technically a non-zero problem. I get it. Having spent several years in the Java/Spring world, the classic ASP world, and the Perl world... they all have problems, both with the languages and the ecosystems. There will always be people who will throw out Rust or Go or Erlang as 'better' by some metric.
For the types of projects I work on, the modern PHP stacks of the last 5-6 years are all probably the best ROI. Colleagues/friends are running medium-sized SaaS on Rails, and it works, but we compare headaches sometimes, and it's not carefree in the Rails world. There's issues there. Regardless of whether your language is 'clean' or 'discoverable', the rest of the ecosystem can still present problems.
Anyone that works with PHP on a daily basis very quickly gets used to some of the naming differences or inconsistent signatures. Anyone that works with PHP rarely is almost assuredly going to have to look it up regardless of how inconsistent it is. (do people really guess at function names, signatures, and return values in other languages!? I've guessed that they exist, but I don't ever think i've tried something without first checking the docs just to see about any surprises or differences)
Consistency is nice to have, but it's pretty far down the list of requirements in my opinion. If it's different for some, I can see how they wouldn't like PHP, but calling for it to "clean up" it's syntax in a giant "python-3-esque" move seem really misguided. People who program in PHP regularly don't really mind the warts, and the language has improved significantly in areas that it's users found most important. Types slowly working their way into the language, easy closures, traits, nice new operators, and the massive speed and memory usage improvements have all been very welcome improvements that have made me more productive in the language.
The time spent on "cleaning up" the standard library would be a welcome change by most, but it wouldn't really have any material impact for me or any of the other PHP devs I know.
IMO pragmatic is good, especially when you have to use an existing code base and you have to upgrade it to the latest supported version you don't want a Python 3 migration story(I migrated a medium project to latest version and the only problem was a cryptographic function that was used to generate some random looking strings that was deprecated, I replaced with the new safer function and done , my project is now compatible with the older and the new version).
People keep saying it was a huge failure, but honestly, I don't see how it was supposed to be done better otherwise. Either you make breaking changes that will impact your entire ecosystem or you don't and live with the same cruft from 20 years ago.
Then once someone had (say) python 2. 6 I'd know they also have python 3.2, and I wouldn't have to figure out that name of the executable to call, it would just be python, with (perhaps) either a command line option or a comment at the top of the file.
To be fair, we are talking about standard library consistency and not language consistency. PHP is a consistent language but it's standard library is very low-level. In Python, you don't call the mysql C library functions directly, you use an object-oriented abstraction. In PHP, you can call those mysql C library functions directly or you can use an object-oriented abstraction.
The problem is that PHP wasn't designed as language-first but as a tool to make web development more accessible. Hence the acronym for "Personal HomePage". PHP was merely a native interface to modules written in C (e.g. MySQL), with the interface hosted in a simplified version of Perl.
The draw of PHP was that you didn't need the CGI bin, and it was easy to deploy with Apache.
Nowadays, the deployment issue has long been solved. No one should choose PHP if they have a choice as there numerous languages better designed, more performant, and more generalized than to just web dev.
If you are still writing PHP in 2019, you are either very unfortunate or just very lazy.
And yet, here we are over a decade along and the Python project is still maintaining Python 2 and I still need to maintain a copy of Python 2 on my computer because of the number of actively maintained projects still using it. How many developer-hours that could have gone into doing something else have instead gone into this "language consistency" project?
At any point in the past 25 years someone could have forked PHP to clean the syntax up and accomplished the exact same thing -- and yet apparently nobody has seen the inconsistency as a big enough issue or time sink to do so. I would take that as prima facie evidence that this isn't nearly as important as you seem to think it is.
Meanwhile, one of the strengths of PHP in my opinion has been how carefully they have maintained and managed backward compatibility. While "move fast and break things" might be the new norm, there is still a huge contingent of developers and businesses that see value in slower, more considered change.
So, it's apparently a good reason to hate, but by no means a reason not to use PHP.
Yes, PHP has been "cleaned up" and you have always had the option to use clean, concise way of coding without language interfering or hindering you in any way.
There's no programming language out there that makes up for the sloppiness and inability of the person behind the screen.
str_replace(old, new) vs. stri_replace(new, old) kind of thing.
I don't have a choice.
I've worked at a couple of organisation where there are hundreds of thousands of lines of code written in PHP. It's been there for years. It does its job and - from a business perspective - it does its job pretty damn well. And I get paid to keep it ticking, and to improve it. Not to rewrite it to fit my personal tastes.
In my spare time I've played with Haskell, Rust, C, Lisp, assembly languages, and I enjoy them. I dearly miss some of the more functional aspects from these languages every time I write PHP.
I work with a large PHP codebase right now (amongst others) and while there are a great many technical benefits I could wring from it in another language, runtime, or environment, a lot of the changes needed to get there would be prolonged, painful, and would provide no noticeable business value.
I'm somewhat reminded of Python, where there is the concept of a "pythonic way" of doing things. There is very much a "PHP way" of doing things, a "${LANGUAGE} way" of doing things, and of course an "${ORG-SPECIFIC} way".
I'm also somewhat amused at Rails as a frequent comparison. I've also worked with Rails, and I hated it. It was quite some time ago, I'd probably enjoy it if I tried again. But I will try to remember in future that opinions formed from bad experiences need to be reviewed in light of the time elapsed since then, and my own personal/professional growth as well.
More generally, when I hear a developer (in my own office ;P) espousing the view that "${LANGUAGE} is garbage", I assign more meaning to the fact that they choose to make that statement than I do to any particular view of the language in question.
Deleted Comment
The ecosystem is radically better than it used to be. Composer and the Packagist registry are as mature and dependable as npm, PyPI or RubyGems. (despite hours lost to my own namespace screwups). I'm also happy to see the Prettier-PHP project automating and enforcing code-style standards.
For whatever reason, I often feel clumsier after working on a PHP project. After working in other languages like JS or Python, I tend to feel like I've leveled-up my skills.
One thing I wish PHP would address is the inconsistency in its map-filter-reduce functions -- their argument-order doesn't match (array, callback) vs. (callback, array):
The amount of cognitive overhead I've wasted on those is ridiculous.- https://packagist.org/
- https://github.com/prettier/plugin-php
You filter (1) an array with (2) a function. You map (1) a function over (2) an array. You reduce (1) an array with (2) a function.
It follows exactly what I'm thinking when I type it. To reverse the orders would be, what? "Mapping an array with a function?" "Filter a function on an array?"
Reference: https://laravel.com/docs/5.8/collections
https://stackoverflow.com/questions/18144782/performance-of-...
Infuriating? really?