30 ms·

PHP in 2019

• owenwil 7y ago
  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. [1] https://forge.laravel.com https://forge.laravel.com [2] http://writetogether.space http://writetogether.space [3] https://spark.laravel.com https://spark.laravel.com
  • Intermernet 7y ago
    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?
    • bashy 7y ago
      Yeah I remember the problems with composer. It's good now.
    • jbrooksuk 7y ago
      Yeah, that's not a thing anymore.
    • bayesian_horse 7y ago
      Composer is very useful in penetration testing. Lot's of good information in the composer.json files people keep forgetting to block..
      • ceejayoz 7y ago
        A Laravel or Symfony app operates out of the public/ directory, so composer.json shouldn’t need any blocking typically - it’d be outside the web root.
    • codedokode 7y ago
      It is not a leak, it just loads too much data into memory so you need about 1 Gb of RAM to run composer update.
  • SXX 7y ago
    > Composer, the package distribution system, really needs work and is incredibly slow, but other than that—I'm really happy. 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.
    • gog 7y ago
      How long ago was that? There were some issues if you had xdebug enabled, but AFAIK that has been fixed.
      • SXX 7y ago
        Just few months and I did not use xdebug on that server. To clarify it's was just CRUD app on Laravel with few small dependencies on top of it. Composer used like 700MB RAM to install it for whatever reason.
      • stdclass 7y ago
        Just today, I had to resize the swap on a raspberry pi so composer could update the dependencies.
      • DCoder 7y ago
        I've had fun issues recently where Composer crashed after hoovering up 1.5 GB of memory. (Composer sets that limit by itself on startup, I didn't arbitrarily choose that number.) XDebug was off. I fixed it by telling Composer to use unlimited memory.
      • beezischillin 7y ago
        I had to raise Composer’s RAM limit last week for a fairly simple Symfony project with less than 10 extra dependencies. I had to up it from 2 to 4 gigs. PHP 7.2.8. without xdebug.
  • nickjj 7y ago
    There are comparable things with other frameworks too. For example I wrote a course on building a SAAS app with Flask. It's available at: https://buildasaasappwithflask.com/ 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?
    • bayesian_horse 7y ago
      Every time I try out Flask, Aiohttp or even Express.js I appreciate more the stuff Django normally does for me.
      • zius 7y ago
        Django abstracts away a bit too much, if you ask me. For a simple REST API it's complete overkill. I prefer Flask or Falcon[0], in which you don't just get better performance[1] but also a lower level of control. [0] https://falconframework.org/ https://falconframework.org/ [1] https://klen.github.io/py-frameworks-bench/ https://klen.github.io/py-frameworks-bench/ or https://github.com/the-benchmarker/web-frameworks https://github.com/the-benchmarker/web-frameworks
        • zeptomu 7y ago
          I agree with your parent. When I started with (Python) webdev some years ago I picked Flask, but nowadays I use Django, as it has superb documentation and useful things built-in. In particular I miss the user-management, authentication and authorization in Flask. Personally I consider Django without any additional apps less complex than Flask with apps (or "plugins" in Flask jargon) to handle basic stuff like auth. If performance is a concern, both of them are insufficient and I would rather pick another language like Rust, Go or even Java.
  • cntainer 7y ago
    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.
    • brightball 7y ago
      Yep. Laravel is basically PHP on Rails. They do a great job with it too.
      • toastal 7y ago
        I dunno... Their home page looks like something out of the Panera Bread playbook looking at the homepage. 'Web artisans'? Why is it 'clean' because it has an absurd amount of whitespace and comments of platitudes for the code example?
        • cntainer 7y ago
          Lol, I agree their packaging looks a bit different but the contents of the package are basically the same. Working with both Laravel and Rails will make it clearer that they try to follow the same principles of convention over configuration and programmer happiness :).
        • mmccaff 7y ago
          "Clever" "marketing" language like this is not unique to Laravel, most frameworks use language like it for tag-lines on their homepage. Pyramid, a framework for Python, even goes with the same "artisan" language. They're just trying to be fun, inspiring, etc From the home page of a few other frameworks: Django: "The web framework for perfectionists with deadlines." Flask: "Web development, one drop at a time" Express: "Fast, unopinionated, minimalist web framework for Node.js" Pyramid: "You need a Python web framework that supports your decisions, by artisans for artisans." Why is it clean? Build an application with Laravel and you'll find out. :) The documentation and community are excellent. I've used many frameworks across many different languages, and (imo) it really is very nice to work in. It's funny how the most negativity comes from people with very little experience, or at least recent experience, in the thing that they don't like.
  • userSumo 7y ago
    No doubt its great, but does anyone know how does it compare to django for saas apps?
  • tacone 7y ago
    To speed up Composer you can install Prestissimo [1] globally, it speeds things up considerably. [1] https://github.com/hirak/prestissimo https://github.com/hirak/prestissimo
  • stephenr 7y ago
    > Composer, the package distribution system 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.
    • ryeguy 7y ago
      The vast majority of people using a package manager in the PHP ecosystem are using composer. It makes sense to call it "the" package manager.
      • stephenr 7y ago
        I’d argue that the only “the” is one that’s distributed with it, which is PEAR. I’m not saying PEAR is used more or that it’s better, just that it’s the only one close to “default” with the language distributions.
        • akie 7y ago
          I literally know no one who uses PEAR.
          • stephenr 7y ago
            Which is literally irrelevant to my point.
          • icedchai 7y ago
            I do. I was using it back in 2003... pear/DB. I still have some code from that era that uses it.
            • munk-a 7y ago
              Would you use a pear dependency in a new project if you weren't pulling bits in from an older one? Personally, I wouldn't... I worked with pear and pecl and composer is just far more pleasant to interact with.
  • throwayEngineer 7y ago
    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. I would recommend.
  • joeldg 7y ago
    In PHP shops I have worked in we would just hand new interns the 'Object-Oriented Programming with Java' book and have them go through that as everything in that book would transfer directly to PHP (and they all new Java). Then, Laravel, that is the best framework I have ever seen in any language. Comparing it to rails is a huge disservice as it is far superior by almost any measure.
  • ljm 7y ago
    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.
    • bufferoverflow 7y ago
      Modern PHP is light years ahead of 4.3. Not just the ecosystem, but the language itself, the performance. It's really not bad.
  • no_wizard 7y ago
    I hear you on composer being slow. One thing I found that works extremely well to speed up composer installs: https://packagist.org/packages/hirak/prestissimo https://packagist.org/packages/hirak/prestissimo Give this package a try, it really worked for me to speed up package management with composer.
  • munk-a 7y ago
    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.
  • tabtab 7y ago
    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.
  • agumonkey 7y ago
    kudos to laravel team (and symfony, since IIRC, laravel is built on top of sf bundles)
  • lazerlapin 7y ago
    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...!
• ch_123 7y ago
  > Do you remember the popular "PHP: a fractal of bad design" blog post? The first time I read it, I was working in a crappy place with lots of legacy PHP projects. This article got me wondering whether I should just quit and go do something entirely different than programming. Seems like a pretty extreme reaction - how about trying a job with something other than PHP?
  • brendt_gd 7y ago
    You're absolutely right. I think it's fair to say that I was closing in on a burnout, which made me think irrational. Like I said: I was lucky being able to switch jobs, and re-discover my passion for programming
• d33 7y ago
  Is the debugging experience finally any more bearable?
  • jbrooksuk 7y ago
    Xdebug remote debugging is great, especially when paired with Laravel Valet (which supports more than just Laravel apps).
  • Lazare 7y ago
    The debugging experience is very good, actually. Certainly comparable to other languages.
• johnday 7y ago
  Thanks for sharing. The thing that I am most concerned about with PHP is not, strictly speaking, the language itself. The syntax is slightly odd but otherwise fine. And the semantics are much the same as any similar language. The real problem that I find with PHP is that the designers seem (from an outside perspective) to take a similar approach towards language backward-compatibility that, for example, C/C++ have. There is some rejection of the idea of getting rid of the old, bad stuff. Plenty of new, cool features is all well and good - but there are still holes in the floor that new learners will fall through. [To clarify, I understand the case made by the C/C++ committees on supporting old code. But nobody's programming pacemakers in PHP, one would hope.]
  • jbrooksuk 7y ago
    I heavily agree with this. The standard library, whilst great, has so many inconsistencies which I wish they'd fix and standardise.
  • gog 7y ago
    The amount of legacy applications being run on the internet is huge. Breaking stuff would put a great financial burden on the companies running those. It is a sensible approach IMHO. What kind of bad stuff are you talking about? If you talk about function names and parameter ordering not being consistent that is not an issue for developers using the language daily, most of them are using an IDE so it doesn't matter as much as people who don't use it say.
    • pdimitar 7y ago
      Those legacy applications won't ever be upgraded to that theoretical and slimmed down PHP anyway, so I don't see a problem.
      • simion314 7y ago
        Old PHP projects can be upgraded in the present because backwards compatibility exists, as i metnioend in other comment I done such a small upgrade and I hat to change only 1 deprecated function with a different one. If this would not have been possible the project would have still be running on an old version without security fixes and slower(eating more electricity so bad for environment)
• Arbalest 7y ago
  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.
  • simion314 7y ago
    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.
    • richardwhiuk 7y ago
      It can be changed. 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.
      • pilif 7y ago
        > You have some syntax to opt into a later release (e.g. doing `<?php(version=8)` at the start of a script. imagine the exponential complexity as old behaviours need to be kept around for various levels of opting in.
        • mgkimsal 7y ago
          There's already been a degree of that with php.ini flags, and some of the behaviours available via those flags have been deprecated then removed over a period of years. It's not impossible. Yes, it's complex, but the process for dealing with that complexity has already existed and worked out ... relatively smoothly. The bigger issue is getting people to upgrade - I'm still dealing with a couple of projects - one started in 2017 - that are on PHP 5.6.
• kijin 7y ago
  Not only did PHP clean itself up a lot in the last few years, it also managed to do so while maintaining a great deal of backward compatibility. It's not uncommon to pick up a really old library that used to work in PHP 4.4, stick it in a PHP 7.3 project -- maybe you need it to import legacy data -- and experience no issues whatsoever. You can probably also use the library in question in parallel with a modern dependency management system like composer, or any framework built on top of it, without any conflicts. This is Windows-level backward compatibility, and I mean it in a good way. Why would anyone want that in this day and age? Because there are tons of legacy PHP code that still power a very large fraction of the web. Not everyone is writing new projects from scratch. Not everyone can afford a total rewrite. PHP's backward compability allows people to transition gradually at their own pace. It might not be sexy, but it gets the work done, and it just keeps working. That's all that matters for many, many businesses out there.
• aacanakin 7y ago
  "While async and await are not available yet, lots of improvements to the language itself have been made over the past years" It's 2019 guys. Please.
  • yzssi 7y ago
    It's good if they take some time to think about the implementation instead of doing a crappy job like Python did.
    • scrollaway 7y ago
      Wait what? Python's async is actually well implemented and very consistent.
    • makapuf 7y ago
      Cani you please elaborate a bit how python Async await is crappy ? Not defending anything but I'm curious. Is it in the language or its implementation ? I've found the loop choices and relationship with dbus loop or other internal libraries cumbersome on Linux but that is implementation.
  • zanny 7y ago
    If you are looking for speed tacking an event loop on an interpreted scripting language is trying to dig a hole with a rake. Its why the demand for such functionality was almost wholly absent from Python, PHP, etc for so long. Asyncio is a throughput boon even in a single core environment, which dates its practicality back to the 90s - and it was found there, in pretty much every graphics stack and COM. C apis have used what is fundamentally a promise since the 80s, But if you are in a situation where you want those kinds of performance characteristics where you have work to do during blocking operations you probably don't want to be writing that code in an interpreted language to begin with. Last week I was optimizing some performance critical Python but when considering my options I just ported the whole thing to Boost / C++ and got an ~80x speedup over the whole loop. Theres only a narrow range of problems actually best solved with interpreted asyncio, pretty much only in the space where introducing a build system and doing language binding isn't worth it but the gains from being non-blocking are. They exist, and its definitely not a bad thing to have async support in your interpreted language, but it definitely isn't mission critical in the slightest.
• scandinavian 7y ago
  php > echo count(get_defined_functions(TRUE)['internal']); 1196 They should clean up the global name space, but that will never happen, so I'll continue not using PHP.
  • jbrooksuk 7y ago
    Why does the number of methods in the global namespace bother you? * Genuinely interested in the rationale behind this. Sure, it's a lot, but why does that matter?
    • jbrooksuk 7y ago
      Why the downvote? This is a genuine question!
    • itwy 7y ago
      Complaints like this one make PHP seem perfect.
  • imtringued 7y ago
    Yeah and they should add basic features like lambdas and rewrite the entire standard library to support that while they are at it and when they are done with all of that could they potentially provide a separate syntax similar to facebook's reason? It's no longer the same language anymore if you change everything and therefore there is no reason to waste time improving PHP.
    • Lazare 7y ago
      PHP has had lambdas for years, and the next major version has a concise syntax similar to JS arrow functions.
    • liability 7y ago
      I'm sensing some sarcasm but that unironicly sounds like a good idea to me.
  • noname120 7y ago
• thibran 7y ago
  I would argue that Kotlin is the better modern PHP. Beside of a lot of magic Laravel makes PHP okayish, but it is still the worse mainstream programming language.
  • jbrooksuk 7y ago
    > but it is still the worse mainstream programming language. Please back this up.
    • thibran 7y ago
      This is my opinion. Some hints why I think PHP is not great: * property type declaration in doc-strings * bad documentation * verry verbose for a dynamic language * a lot of inconsistencies * automatically loading of classes is a hack (psr4) which doesn't support importing functions without specifying it in a global project file
      • highesttide 7y ago
        As a note, typed properties are coming with 7.4.
        • thibran 7y ago
          And I welcome it. Also the shorter anonymous function syntax will improve the current situation by a good deal.
    • pdimitar 7y ago
      https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ Well, this is still true.
      • Lazare 7y ago
        I mean, apart from the huge number of items that have been fixed over the years, yeah.
• coblers 7y ago
  It might not be, but how does it fare against similar languages? I have no idea why you'd choose it over Go/Node.js/Ruby or similar for your standard webdev stuff.
  • EugeneOZ 7y ago
    All apps I saw, written in Ruby, were awfully slow. I don't know Ruby, maybe it's just me, but would be interesting to know examples of not slow Ruby apps.
    • cntainer 7y ago
      Well, github, just to name one:). Also shopify, digital ocean, stripe. I also worked on a large ruby app that was faster than another large Java app. Keep is mind that all these platforms handle a great deal of requests at any given time, so we're not talking simple web apps. In my experience bad software design, bad DB design and bad developers are the major cause for performance issues, you rarely get to that level of polish with your app that the difference between different languages really matters. At micro-bench level PHP always beats ruby pr python, but most apps have performance issues without ever getting to that level. My funnies experience was with a java team that where baffled why their app is slow. I told them it looks like they have a huge bottleneck on the DB, their answer: "Yeah but it's java, it should be fast"
      • return1 7y ago
        github is terribly slow... or maybe it's just me?
        • cntainer 7y ago
          It's usually fast for me with the occasional slow down. From experience (did some code contributions to gitlab) when you work a lot with the filesystem, as is the case for platforms hosting git repos, you will have performance issues related to that, regardless of the programming language. we host gitlab at my company for internal use, just switching from SSDs to HDDs made a big difference in terms of response time for big actions like opening a merge request, etc I'm sure there are apps in the wild that get to that level of optimization where you need to decide on a different language. But what I've usually seen is you just slice that part out into a service and only rewrite that part. I think stripe and others are basically doing this if they do hit the limits of ruby in very performance intensive workloads.
• coblers 7y ago
  Maybe it isn't, but other languages/frameworks have improved the past ten years as well. I don't see the selling point in building something in PHP in 2019 when you have similar if not better/more mature languages/frameworks at your disposal. Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? I really fail to see where PHP has its place in 2019. For your "build a minimally viable product fast", the above win. For enterprise stuff, the good old Java/C# win.
  • jbrooksuk 7y ago
    > Won't your prototyping be faster in Go/Python/Node/Ruby anyway, with a more stable surface to build upon it? One of the most understated pros of PHP (IMHO) is that it's so easy to get setup with. You can start hacking on something so quickly. In my experience, Go has not been like that. Node.js also was never as quick.
    • chimen 7y ago
      Not really the case with Docker. I can spin up a container targeting any language in less than 10 seconds, mount a volume and start hacking away. Best of all, it doesn't pollute my system in any way. We shouldn't pick a language just by how easy it is to get started, a decision which often leads to a lot of regrets. Pick whatever is good for the project not your disposition.
      • simion314 7y ago
        But I am productive with PHP, I don't know docker or related tool chains, I am more productive in PHP then Python(because of my own experience and dilikes for Python like syntax), the ecosystems are equivalent for my task so I would use PHP. Buf if PHP was not good enough then sure I would always use the best task for the job(I used Java for a different project or even use a bash script and pipe UNIX tools)
    • jeltz 7y ago
      But other languages like Python and Ruby are even easier to get started with than PHP.
• tannhaeuser 7y ago
  Rather than chasing MVw or OO trends of the JavaScript ecosystem and become more like JavaScript or Java, so to say, why don't the PHP developers identify and build on the unique strengths of PHP? Which are IMO: the large installed base in classic web hosting, and the original purpose of PHP as a high-level scripting language embedded in otherwise static HTML as in "<?php ...>". There is a huge room for improvement there since PHP's quick-and-dirty hackjob of a page-embedded language isn't HTML-aware and thus prone to injection attacks, which has caused uncountable attacks, botnets, and other problems for PHP and non-PHP sites alike, in particular when coupled with PHP's target demographic. This is especially painful because PHP embeds via SGML mechanisms (processing instructions), when SGML has all the features needed for context-aware, injection-free templating. If PHP can improve that story, and stop becoming the language of unintended consequences and usage-outside-its-comfort-zone, then it might earn a lot more respect and consideration.
  • simion314 7y ago
    Your claims are vague, do you have a specific example of a new feature and a new mainstream framework that has the security issues you mention?
    • ptx 7y ago
      I think the point is that if you use a "new mainstream framework", you lose the traditional unique strengths of PHP by using it essentially the same way as you would any other language, so you might as well use a different language. So instead of trying to be like other languages but with worse syntax and weird quirks, PHP could try to improve on the things that make it different and lead to its initial popularity.
      • tannhaeuser 7y ago
        Exactly my point. Thanks for explaining it much better than I could.
        • simion314 7y ago
• bayesian_horse 7y ago
  It's true. I'd like to say it's a new crappy language, because that'd be funny, but it wouldn't be true either!
• hguhghuff 7y ago
  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.
  • simion314 7y ago
    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).
    • pdimitar 7y ago
      I don't disagree with your points -- but then it turns out that PHP is still the same old crappy language it was ten years ago.
      • simion314 7y ago
        Is that and more, I mean everyone uses classes and namespaces now and structures code better so there is this improvement. Projects use autoloaders now and things again are better. Have a look for example http://image.intervention.io/getting_started/installation http://image.intervention.io/getting_started/installation how you would resize an image if you used a framework, it is much different then you would see in a code that was written 20 years ago.
• baybal2 7y ago
  > PHP isn't the same old crappy language it was ten years ago But it is too late. JS on the backend has nearly completely ate its mindshare in its target demographic. I think, JS itself risks ending up like this if core developers in Node and TC39 will not begin to think of the need for JS 2.0 and fixing fundamental design issues, and bug-o-features.
  • swah 7y ago
    I usually code a backend in Go or Python, but recently been thinking if I should just abandon my "prejudice" (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries, etc) and move to JS on the backend as well, since that's what I already use on the frontend - be it web or React Native. (I actually find JS very expressive and oriented towards a style of "table-oriented programming" which is useful for software that changes a lot like UI, IMO).
    • baybal2 7y ago
      > (JS sucks, Node sucks, Node is single threaded, there are no SQL libraries, etc) and move to JS on the backend as well, since that's what I already use on the frontend - be it web or React Native. My prejudice is the same. A lot of JS and its ecosystem feels to me to be broken by designs, but you have an option to use a boutique option of Scala/Dart/Go that nobody uses (relatively speaking,) or JS which is broken as a language, but is OK as a work tool. JS will fall just like PHP, when it will be bested by the next better tool for "quick and dirty" programming, because Node and TC39 delayed the "2.0" change for too long. What I feel already is increasing awareness of real world JS performance limitations, and people beginning to speak about JS sponoffs with native types, and further direction of work on things that sprung up from ASMjs
      • coblers 7y ago
        Putting Go in the same box as Dart seems a tad insulting - it's not that much of a niche language anymore.
• simias 7y ago
  As far as I'm concerned the bridges have burned a long time ago and I definitely can't see myself giving PHP a second chance. That being said, if I'm wrong and PHP has really managed to become a decent language (or at least something that's not completely insane) its defenders should focus on actually showing what modern PHP code looks like. Is performance that much of a big deal for most people? In a world where Ruby on Rail exists I find that hard to believe. Server are cheaper and vastly more powerful now than in PHP's infancy, I'm sure that for the vast majority of use cases PHP's performance (whatever it is) is good enough. The infamous "Fractal of Bad Design" wasn't about that, it was about the ridiculously inconsistent and error-prone API, the insane defaults, the counter-intuitive behaviour of '==', the headless chicken development roadmap where maintainers would add features because they were popular in other programing languages without trying to figure out if they had their place in PHP,... Surely a lot of this has turned into technical debt? Even assuming that "modern" PHP managed to come up with better ways to deal with all of this, I assume that these obsolete functions and operators still linger for backward compatibility? If so how do you avoid them? Again, I personally don't really care, but if you want to win new converts who haven't been as scarred by PHP as I have been I think that's where you should focus your efforts. Maybe somebody should write a point-by-point rebuttal to the "fractal of bad design" article?
  • jbrooksuk 7y ago
    > [...] its defenders should focus on actually showing what modern PHP code looks like. Laravel does this very well, not just by being a great framework but also in its ecosystem (Envoyer, Forge, Spark, Nova, Horizon, Socialite) and its documentation (https://laravel.com/docs/master https://laravel.com/docs/master).
    • lugg 7y ago
      If laravel is the best we have were fucked. Laravel is fine for prototyping but it breaks backwards compat constantly, probably due to the massive amounts of over abstraction, not to mention layer upon layer of IOC hell.
      • 7y ago
• richardwhiuk 7y ago
  And yet ~everything in https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ https://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ is still true. All that's happened is that the language is even more complex, has even more baggage.
  • alexandernst 7y ago
    I'm not really sure why this comment is getting downvoted, but literally every single thing in that post still holds true.
    • pornel 7y ago
      No, it's not. PHP has disabled or removed the major anti-features like magic quotes, globals, URL includes and the bad mysql extension. It has a proper AST-compatible parser which removed tons of quirks, and added syntax sugar to look more normal to outsiders. The remaining things are: • the endless whine about inconsistent underscores in function names and haystack/needle. These are a bad look, but aren't really an obstacle to using the language (PHP devs memorize the common functions, rely on IDE or docs for the rest, and move on). • being offended about use of backslash as the namespace separator. It really doesn't matter at all. • old constructs and edge cases that exist, but are not used in new code. • general upset about dynamically-typed languages, and all the consequences and compromises that dynamic typing brings. That post is just a rant. It presents insignificant/arbitrary choices as flaws (e.g. "clone is an operator?!" — so what?). Some complaints are totally ridiculous, e.g. exceptions thrown in destructors were fatal errors, and that was bad. When the restriction has been removed, the post has been updated to complain that this is bad too, because now you can throw literally everywhere! Apparently, no matter what PHP does, it's bad.
      • out_of_protocol 7y ago
        > (PHP devs memorize the common functions.. Nope (c) Me, after 5 years on trying to but still falling back to googling every 20 minutes despite years and years of using the language. ... And just writing code without looking into docs much after a week with ruby
• golfer 7y ago
  So much of the web is powered by PHP. Wikipedia (MediaWiki software) and Facebook are two of the largest footprints of usage. And of course, WordPress. PHP has a lot of firepower behind it.
  • Shish2k 7y ago
    The Facebook www code is written in Hack, which started off as a PHP-compatible language / stdlib, and then dropped PHP compatibility when it was holding them back. Having worked with both, any one of the major additions (XHP, good type annotations, sane collection types, etc) makes my development experience 10x better; going back to vanilla PHP now just makes me sad...
    • noir_lord 7y ago
      Collection types is a big one for me, I miss those like crazy when working in PHP.
• paulcarroty 7y ago
  Thanks, modern JavaScript is much more better & profitable than not_a_crappy_language_anymore today. If you're 60, you can still use PHP for legacy projects, but no sense to learn it now and kill your career. Market matters.
  • megous 7y ago
    As a seasoned PHP dev, I can actually see where nodejs sucks. Things that are native functions or part of default extensions in PHP, I have to hunt for on npm or be responsible for re-implmeneting from scratch. And PHP has a lot integrated. It sucks if you know you can whip out a single call in PHP, but have to search for an hour in npm and not really find anything satisfying - all the while knowing that in PHP you'd already have been doing something more useful.
• alexandernst 7y ago
  Does it have an actual debugger already? Or are we still stuck with xdebug?
  • LeonM 7y ago
    What's wrong with xdebug? Sure, xdebug requires a graphical frontend to be practical (I use phpstorm), but so does GDB. Debugging with xdebug has been a really good experience for me. Much better than python or even GDB for C code.
• maitredusoi 7y ago
  Benchmarking should be made with a more real world point of view: https://www.techempower.com/benchmarks/#section=data-r17&hw=ph&test=json https://www.techempower.com/benchmarks/#section=data-r17&hw=... tries to do it ... For me https://github.com/the-benchmarker/web-frameworks https://github.com/the-benchmarker/web-frameworks is just testing the routing system (e.g. in the rails case def user render plain: params['id'] end ) ;)
• larzang 7y ago
  As a primary PHP developer, PHP has improved by leaps and bounds in the ten years I've been working with it, however there's still a major fundamental issue that has seen improvement but remains unresolved: function overhead. Contrived example: - https://3v4l.org/eEtFl https://3v4l.org/eEtFl - https://3v4l.org/8QMFh https://3v4l.org/8QMFh Two identical ways to do the same thing, one with nicer FP-like syntax, but because of function overhead even on 7.3.x it's significantly slower. If you're building large-scale PHP applications you have to stay away from a bunch of shiny new features in anything remotely performance-sensitive, and it causes you to write worse code in general (e.g. this monolith would be a lot cleaner as multiple sub-functions, but it's going to be called in a loop 5 million times so I have to keep it ugly). With compiled languages you can write clean code and then have the compiler optimize it. With PHP, you have to make development-time sacrifices in legibility and maintainability in order to not make runtime sacrifices in performance, which is both worse as an any-stage dev and a huge footgun as a junior dev.
  • efficax 7y ago
    Do you really find function overhead to be that great of an impact on performance? I work on a php app that sees around 15k/rps and I use a lot of functional patterns (feels best to me, my brain was formed in a lispy way). By far database time remains our biggest bottleneck, especially since we finally made it onto PHP7
• tluyben2 7y ago
  I have kept up with PHP since I replace my own 'PHP' which was a Perl cgi script. It is not as crappy as it was and Laravel is quite nice, but there is still so much crap in there, compared to modern languages, libraries and frameworks, that I only do maintenance on projects (upgrade Laravel, port to Laravel etc) but would never start a new project on it.
• bovermyer 7y ago
  My major side project does most of the heavy lifting in an API written in Go, but the front end is a Laravel app. It works nicely, is easy to make changes to, and gets out of my way. /shrug
• majewsky 7y ago
  If the author happens to read this thread: Please please please use a different font. Serif fonts with very dynamic stroke strengths look awesome in print, but they break down on screens where the narrow strokes round down to 0px and vanish. Although I'm reading this on a HiDPI notebook display (1440p over 13"), I have to crank up the text zoom to at least 150% to be able to read the article comfortably.
• hadriendavid 7y ago
  Do you still need a dollar sign for variables? :troll:
  • megous 7y ago
    You pay for every useless variable. It keeps the variable count low.
    • premun 7y ago
      Luckily it's a dynamic language, so you can keep reusing one or two for everything!
      • megous 7y ago
        Wow, you're right. :) I'll do that from now on.
• StevePerkins 7y ago
  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).
  • phlyingpenguin 7y ago
    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.
    • lioeters 7y ago
      > 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.
• guggle 7y ago
  Do we have still to use mb_* functions to deal with utf-8 ? That was a major PITA when I used to write PHP.
  • malinens 7y ago
    No
    • guggle 7y ago
      How ? ~ php --version PHP 7.2.17-0ubuntu0.19.04.1 (cli) (built: Apr 18 2019 18:01:25) ( NTS ) Copyright (c) 1997-2018 The PHP Group Zend Engine v3.2.0, Copyright (c) 1998-2018 Zend Technologies with Zend OPcache v7.2.17-0ubuntu0.19.04.1, Copyright (c) 1999-2018, by Zend Technologies ~ cat test.php <?php echo strlen("ùé"); echo "\n"; echo mb_strlen("ùé"); echo "\n"; ~ php test.php 4 2
      • CiPHPerCoder 7y ago
        The answer is: Composer + Packagist. There's almost certainly a library that handles it in a sane and transparent manner for you so you don't have to deal with the pain.
• katet 7y ago
  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.
  • deleted 7y ago
    [deleted]
• DJBunnies 7y ago
  I'm hiring PHP developers in Boston! Doctrine, symfony, AWS, all backend API work.
  • esistgut 7y ago
    If you are doing API with Symfony you may want to check API Platform: https://api-platform.com/ https://api-platform.com/
• hc91 7y ago
  Ah yes, PHP, the garbage fire of the Software Engineering world which like the cancer that it is, just refuses to die.
• pictur 7y ago
  a vicious circle
• jbverschoor 7y ago
  It's funny how shitty decisions in tech always seems to win the masses, only because it's easier to get started with. And only 10 or 20 years later, a great amount of effort is put into patching all of this. "Good tech" is created by people with a lot of knowledge of a specific domain. For them, it all makes sense, but the mental modal does not map to newcomers. "Bad tech" is usually forgiving (messy syntax, accepting bad data etc), so people don't get stuck. The solution is to have good tech with proper tooling and hints / error/configuration reporting. apache, php, mongo, mysql, javascript.. They all have the exact same strengths, weaknesses, quirks, bad decisions, and mass adoption.
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• icedchai 7y ago
  Developing a database driven web site with a modern PHP framework, like Laravel, is very productive and quite pleasant. PHP is fast enough. It's simple to deploy. It's easy for "non-engineers" to get involved with: designers can edit templates, see the result instantly, no build issues, etc. For my day job, I do Python and Java... For side projects that are database-driven web apps, PHP is perfect.
• dvfjsdhgfv 7y ago
  From https://thinkmobiles.com/blog/php-vs-nodejs/ https://thinkmobiles.com/blog/php-vs-nodejs/: > Node.js is faster than PHP only in adding numbers.
• jokoon 7y ago
  I wonder, wouldn't it be possible to generalize the work that was done for JS with V8 to a variety of languages, to target something like LLVM? Can't most interpreted language be targeted to a common ground? Anyhow, I've generally avoided a lot of languages. For now my choices have boiled down to C++ and python, and I've even used brython instead of client side JS. I either don't touch other languages, or just thread very carefully. My cynicism is usually yelling out to nuke all existing things, including HTML and JS, to favor something new, clean, less bloated, so that it can possibly run well on smartphones. I just wish public research and engineering entities like DARPA could come up with something better. I think C and by extent C++ are already that, but crowds of nerds will keep moaning about out of bound arrays. HTML freed the web from the grasp of greedy capitalists, but now it has done its job and a lot of things should be put away. Aren't there tools to optimize HTML rendering for speed?
• deleted 7y ago
  [deleted]
• deleted 7y ago
  [deleted]
• ashton314 7y ago
  I worked at a small PHP shop for about two years. There was a ton of legacy code that was utterly terrifying: a 13-deep nested `if` and the like, global variables, etc. I convinced my boss to let me start using Laravel. It made development worlds more sane. It made development orders of magnitude easier. Laravel does a lot for you, and they’ve thought about how to solve some tricky problems in clever ways. That being said, I would never recommend PHP as the language to solve any given problem. It is now less of a terrible language and more of simply a mediocre language. I can’t think of anything it does particularly better than another language. For any given problem, there is most certainly a better language to solve it, be it Ruby, Elixir, Clojure, Rust, etc. I’ve been working with Elixir and Phoenix for web development for a few months now, and it is sooooo much better. It’s hard for me to enumerate all the things, small and large, that reduce developer friction in contrast to even PHP’s best framework.
  • IloveHN84 7y ago
    You forgot one thing: PHP has a far larger community and packages compared to exotic languages like Elixir. Everything is documented and there are tons of resources out there to solve a problem. It's like C++ for the web. Why does C++ still live? Community, extensively tested and adopted by large organizations. Well PHP is the same. Until big companies are out there using PHP (consider Vimeo or Flixbus or Groupon as example), because it is perfomant, it will fail to die.
    • ashton314 7y ago
      I agree with you: strong community support is essential in the survival of any language/technology. PHP has a large community and a dizzying number of packages. That helps a lot. But I can think of a number of languages (Python, Perl, Ruby) that also have large communities and vast numbers of libraries at their disposal. Therefore, I don't think you could pick PHP over any of those just because "it has more libraries". Furthermore, Elixir, while it has fewer libraries and a smaller community, is growing fast. The core language is also exceptionally well documented and discoverable. It has libraries that cover essentially all your common use cases. I guess what I want to say is, I'm happy PHP is getting better for all the programmers stuck using it. There's no reason to use it for anything new, because there's always a better tool out their for your job.
• lasermike026 7y ago
  PHP isn't going anywhere. PHP is fine. Perl, Ruby, Python, all fine. That being said, for general programming TypeScript/JavaScript is the way forward. Other than PHP, I have loved all these interpreters. It's over. Accept the middle and move on. Everything else is nitch.
• beager 7y ago
  I'm impressed with the evolution of the language and the tooling around it, driven by the necessity to scale and maintain apps for big businesses. Nevertheless, I would think that PHP is a hard sell for new projects and new enterprises. Unless you're a dyed-in-the-wool PHP junkie and you're bringing a team that is the same, there are a multitude of reasons why you'd want to choose a different language for web dev work.
• pragmaticlurker 7y ago
  definitively much better than other programming languages out there, especially when it comes to MVP. Fast, easy and flexible. CakePHP is a wonderful framework and the community support is simply huge (orders of magnitude bigger than Java and C# for instance). Don't forget that PHP runs 70% of internet (where also Wordpress and Magento are big helps)
• LoSboccacc 7y ago
  eh my problem with php never really was performance (up to a point) or the language itself, it was the default library making figuring out every operation an exercise in googling like, why the weird _ difference between strtok and str_split, why str_replace has the search first and string as third parameter but in strpos the source string is the first parameter and then the search term the second it's all confusing and weird and while someone that's a specialist is maybe at ease with this, for a generalist going in and out the language as needed it's frustrating.
  • maxxxxx 7y ago
    When I did more PHP I quickly ended up writing my own sort of standard library with consistent functions and unit testing. It doesn’t really take much time and makes things much more predictable.
    • noir_lord 7y ago
      I think we all do this to a degree. If you look most major projects have equivalents e.g. Laravel has Str. Same with collection types, SPL is an abortion so everyone maps over array which isn't really an array to pretend we have proper collections/lists etc. It's mostly fine but there are times when it's annoying.
      • maxxxxx 7y ago
        With JS it’s pretty much the same. It’s standard library is so weak that you pretty much have to write your own.
• deleted 7y ago
  [deleted]
• spacemanmatt 7y ago
  The thing that burns me so much about PHP is all the crap in php.ini that should be configured by applications at runtime. The container vs programming language mindset is basically my biggest architectural/cultural peeve.
• myspy 7y ago
  Working with Laravel for more than a year now and it enables writing quality code. Testing is nice, as is building models, routing, validation, and authorization. PHP itself is not that important. The language is solid and does its stuff. I'm moving mainly in the framework to create functionality.
• mattferderer 7y ago
  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.
  • gwbas1c 7y ago
    The thing that I like about PHP is that I can mix HTML, code, and database queries into a single file. 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.
    • juangacovas 7y ago
      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
      • barbecue_sauce 7y ago
        It's pretty clear that he meant mixing HTML, code, and database queries into a single file was what didn't scale, not PHP itself.
      • munk-a 7y ago
        I think you're missing the point of the comment - when it comes to prototyping PHP is incredibly easy to whip out a buggy test thingy in minutes that breaks all best practices but still lets you prove a concept or prep a demo.
    • strictfp 7y ago
• pancakespls 7y ago
  I can't imagining switching back to PHP, even if it is much better than it was before. It has to _surpass_ other languages.
• derefr 7y ago
  I always wondered, in a world where 1. people seem to hate writing (old?) PHP, and 2. there are a good dozen languages that were created solely because people hate this other language Javascript, which both compile to Javascript and have the semantics of Javascript, just not the syntax or stdlib of Javascript; ...why we didn’t end up with languages compiling to PHP, targeting the Zend VM, or whatever you’d have to do to get the PHP module in Apache to interpret non-PHP code.
  • dajonker 7y ago
    Because Javascript is the only thing that runs on the client side.
    • derefr 7y ago
      And for many “LAMP” hosting environments—such as the tiny ones many ISPs and/or universities hand out like conference swag—(secured, sandboxed) PHP is the only thing that runs on the server side. Same with many “WordPress hosts”—they don’t let you run code per se, but they let you install arbitrary WordPress plugins, so you could deploy your own code into the site... if you’re willing to write PHP. (Secured) PHP is used by these environments in about the same way that Server Side Includes and .htaccess files were used by Apache in the late 90s: as a way to give users the ability to add some dynamism to a website, without actually giving them a Turing-complete environment that they could use to run bots on. And yes, I’m not being facetious, it’s really not Turing-complete: most of these environments have fixed request timeouts, fixed memory quotas, and no ability for the runtime to write to disk or make network requests. So there’s no infinite tape! This is “PHP as pushdown automata.” ;) As such, the language I’m talking about would actually have to be built to understand that it it’s operating in this super-limited environment (more limited than PHP normally is.) I would expect that this would be presented less as a “programming language” per se, and more as something you can use in a Static Site Generator to inject a bit of server-side dynamism to your generated “static” site.
• caseyamcl 7y ago
  I’m going to chime in here and say that I stayed with PHP through the roughest years. I’ve only seen positive changes in the time since then. I’ve made a good living from writing code and I don’t see any reason that has to change.
• xrd 7y ago
  I think the way to analyze a language and framework should be: "what does this framework permit the worst developer on the team to do?" I think the story for Php in this regard has not been a good one historically. You can put processes like PR review, and add coding standards, but getting things done will always trump those things, especially when you are bootstrapping. If you can tell me modern PHP is better than the alternatives at preventing bad behavior (or encouraging good behavior) then I'm interested. But, this post didn't move me to change my mind there.
  • xrd 7y ago
    For example, coding standards: `There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.` https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md https://github.com/php-fig/fig-standards/blob/master/accepte... A language that has to permit this kind of thing (or thinks it has to) is just going to lead to developer infighting. This is an important issue because GitHub PRs are going to be unreadable if one developer can insist that "this line needs to be 145 characters..." and then no-one can diff changes to that code. You can break the PR process with this kind of thing.
    • zerocrates 7y ago
      I'm not sure what this has to do with PHP as a language... barring the few languages with a very strong default formatting convention like Go, code style differences are both a fact of life and not terribly problematic (set rules for the project and enforce them automatically).
• cwaffler 7y ago
  Yeam im really digging php these days. Composer and Laravel have made it fuggin awesome! I think more so the frameworks built when php was first picking up steam are a little convoluted and oldschool (im looking at you drupal!... 6 & 7, mostly). The language has come along way since then though, so thanks to the team for all their hard work.
• cletus 7y ago
  The sad thing is that nothing else has come along to fill the niche that PHP fills. Here are the key advantages of a PHP like language: 1. Low barrier to entry. An HTML document is pretty much a valid PHP program. You can add as much or as little code execution as you want to it. While at a certain point you should probably use templating (to handle things like escaping automatically, etc) but a low barrier to entry really helps get people on. 2. PHP has a stateless functional core. All the system functions are part of the web server binary. There's no loading some giant object tree just to print something to the screen. This is huge because of... 3. Resource management for serving HTTP requests is, to me, basically ideal in that you create a bunch of stuff, spit out a result and then tear everything down. It's hard to leak resources this way. No garbage collection oddities to deal with. The Java equivalent to this was the servlets API (years ago) but it doesn't share the same issues; 4. No multithreading on a per-request basis so you don't have to deal with race conditions at all in user code; 5. An opcode cache sufficiently closes the gap on code performance in the vast majority of cases at little to no cost to the end developer; and 6. Typically you can just hit reload on your browser and immediately find out if something works. That's really nice. Big things missing from PHP: 1. A good type system. I use Hack at work (Facebook) and this solves a lot of problems; and 2. Cooperative multitasking via async/await semantics (again, Hack has this). I'm a big fan of PHP not making breaking changes (badly) like Python did. You can't fix the inconsistent argument ordering in standard functions ("is it needle, haystack or haystack, needle?") but it basically doesn't matter at this point. I use an IDE that tells me the correct order anyway so who really cares? The way to handle that is to create new versions that are consistent. Hack has these collections: vec, keyset and dict. These essentially replace array (side note: PHP maintaining insertion order on array is such a hugely useful feature). They have a consistent set of library functions (in C\, Vec\, Keyset\ and Dict\). One other thing that I found hugely useful when I first did PHP was preg_replace_callback. I found this so useful that when I did Java after that I basically write a version of this function. So anyway, there are a ton of legacy problems with PHP but nothing else has that same set of desirable characteristics IMHO and I really wonder why not.
• joemaller1 7y ago
  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): array_filter($arr, $fn) array_map($fn, $arr) array_reduce($arr, $fn) The amount of cognitive overhead I've wasted on those is ridiculous. - https://packagist.org/ https://packagist.org/ - https://github.com/prettier/plugin-php https://github.com/prettier/plugin-php
  • taytus 7y ago
    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. Infuriating? really?
    • jonatron 7y ago
      Back when I wrote PHP, the solution was to use an editor which shows you functions arguments after you type the open bracket.
    • earthboundkid 7y ago
      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.
  • eithed 7y ago
    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 Reference: https://laravel.com/docs/5.8/collections https://laravel.com/docs/5.8/collections
• startup23 7y ago
  Disclousure: Amezmo creator The PHP community and eco system is only getting better every year, and the language continues to advance. PHP is one of the easiest platforms to get started with. I built Amezmo to automate the modern PHP server infrastructure and deployment. Check it out at https://www.amezmo.com https://www.amezmo.com - Use coupon code FRIEND
• mudiadamz 7y ago
  nope, never touch it again
• fruktoed 7y ago
  Unkillable PHP, will last ages.
• fbn79 7y ago
  I develop on PHP from 2 decades. I loved PHP. I took 2 Zend cerfications as PHP engineer. After working in Javascript projects for some time on client and node.js, and after learning basics of functional programming I think PHP is really horrible as language. The only thing that I think make it still unique, is the REST nature of the web server integration. Every request is world apart. The script starts and end with the HTTP request(exceptions here). This make it really easy to understand and scale.
• fruktoed 7y ago
  Php here to stay, I personally hate it, but respect for such a long successful journey since 90th last century.
• nathan_long 7y ago
  What's the concurrency story in PHP - does it use 1 thread per incoming HTTP request?
• ilmiont 7y ago
  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...
  • momokoko 7y ago
    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.
    • ppeetteerr 7y ago
      Have you ever tried building, deploying and maintaining Java? There is more to a language than the syntax
      • momokoko 7y ago
        I have. And honestly, with modern, professional PHP development, most of us are not just FTP'ing PHP code to our shared host to deploy. So realistically, we are dealing with some of that deployment complexity regardless. The modern Java ecosystem has tooling like Maven and Gradle. IDE support and static analysis in Java is more advanced as well. As I said above, the additions are fantastic and I think they have absolutely improved the PHP experience for projects where PHP is required. But for new projects, I just do not see deploying PHP vs deploying Java with modern tooling as holding up like it may have 7-10 years ago.
• CodeSheikh 7y ago
  Does one still debug using var_dump()? Disclaimer: I have not used PHP since 2010.
• hiccuphippo 7y ago
  The thing I like about php the most is how all the different frameworks have come together to create standard interfaces for building frameworks. I was able to easily create my own microframework using packages from zend, symfony and the php league.
• chairleader 7y ago
  I'm working in a vanilla PHP codebase right now, and I see all sides - the fractal design fails and the surprising improvements to the language. I've just read up on the architecture of Laravel, and given the public opinion of it, must be a very nice framework. What strikes me most about PHP is the fundamental request/response execution model. Your execution context begins when a request is received and ends when we send the last byte or terminate the request. There's no startup healthchecks, no cache warming or any other bootstrapping of your service unless you jump through convoluted hoops on your own. Your service is either accepting requests or it isn't. You either lazy load your data into APCu or you don't. I've leveraged AWS healthchecks to achieve these in the past, but that path is not very maintainable. Inevitably in the course of maintaining a service, I find use cases for a phase of execution that should occur before the server is live or shared static memory that should be available at all times, but (unless I don't know something) those are things that PHP doesn't do. This is the reason that I find PHP to be a bizarro language - for its fundamental design assumption!
  • DCoder 7y ago
    This execution model is just good old CGI scripts [0]. [0]: https://en.wikipedia.org/wiki/Common_Gateway_Interface https://en.wikipedia.org/wiki/Common_Gateway_Interface
  • IloveHN84 7y ago
    Actually you can compile PHP code and optimize it.
• nippler 7y ago
  Falling for the php meme lmao
• bartimus 7y ago
  > Back in the 5.* days, PHP's performance was… average at best. Even with 5.* it very much depended how you used it. The real world scenario's. PHP functions are written in C. You could make great gains by leveraging on them. Using PHP as just the "glue" for a blazingly fast library (and templating engine) written in C.
• sputr 7y ago
  I'm more and more surprised that Laravel is so often mentioned over Symfony in this types of debate. I've worked with both and done professional projects in both. While both are great, I would have to sing some praise for Symfony's developer experience and tooling. But realistically the're neck and neck. PS: It's really funny seeing people seriously discuss PHP when they themselves have not tried it since the 5.* days.
• Roofduck 7y ago
  The question for me is what can PHP do better than any other language out there? I've worked with Laravel for a few years and while it has sooo many great features out of the box, it doesn't quite detract from how unpleasant working with PHP is, when comparing with any other common/modern language. Of course this is only my opinion and experience with it. I don't think I would ever recommend PHP to anyone unless they live in an area where you can only find PHP job opportunities. Otherwise, any other language can do what PHP can do and will provide a better programming experience IMO.
• joeleisner 7y ago
  In all honesty, Laravel has been a blast to create projects with. Prior to that framework, I had very little experience with PHP or any back-end development. It's simple to setup, has sane/safe defaults, and it scales well with the complexity of projects. Can't recommend it enough!
• no_wizard 7y ago
  As someone who deeply misses Python (warts and all) and due to a job change forced to take on PHP (thankfully, we are on an aggressive language versioning schedule, so we're already on latest 7.3) as the full time language of of choice, I miss a few things that just make me want to pull my hair out: For what its worth: I used (and personally still use) Python 3.6+ so the comparison is with that. 1. Async programming. While in Python its not perfect, having it baked into the core of the language makes so many things trivial like processing jobs between requests and sending the results back later, or having a simple queue for persisting data to a database after validation has been done on the data (Marshmallow is my hero for this). 2. Not having to worry about all the strange things you have to worry about when everything has to be re-built per request. While I understand WSGI requests are definitely this (kind of, usually you have a daemonized runner that keeps your app alive even then), your entire app did not spin down between requests like it does with php. Simply having to rebuild everything every single time a request comes in (even when using php-fpm, more or less) drives me insane, because I can't just send some data off to another channel in memory easily, or sleep a generator in a position and resume it when I need to. Everything has to be handled in said request. This kind of goes along the same lines as number 1, but its sort of a different problem (in particular, I think generators in Python are very elegant in comparison to lots of other languages, not just PHP (looking at you javascript), but PHP generators feel worthless unless I'm reading something line by line from a file or some other external resource, or I'm iterating against say, a doctrine array result) 3. Your app is full stop dead without a cache if you are planning on doing anything interesting. I don't just mean like opcache, but even small applications have to leverage this (APCU at a minimum), because of the aforementioned problem of nothing being alive after a request has been spun down. Yes, I have leveraged caching before, and yes I leveraged it all the time with python, but for just getting a quick prototype feature out the door, and adding those kind of layers later, I really miss that. Try iterating through database results non-sequentially, where you have tons of variable conditions on how that data needs to be shown, its a pain in the ass without caching aggressively (this is unfortunately a very real scenario I have to deal with all the time. We have non linear questionnaires in my current job I have to deal with, and the questions have to pass a certain validation and then we either have to get the next immediate result, or skip `x` ahead, without really knowing whats what or having any real idea of what anything may be keyed to. I'm open to suggestions if anyone has a good link or something to read on this kind of problem. I have not found it easy to work through personally with php) With all that, Its been an OK experience though. Not my favorite language (may never be). However, if I was to postulate further, if PHP doesn't start gaining traction on these issues (and no, the weird async extensions are not a replacement for any of this. It needs to be core to PHP and maintained as such, for it to work in the language, in my not so humble opinion), it will eventually be supplanted in full even where it may have some strengths. Unfortunately, nobody working on the core of the language seems to care about this at all.
• 75dvtwin 7y ago
  I would say, that PHP faired through time much better than Perl. May be is Facebook's investment in the platform, may be it is wordpress , the PHP's 'killer app'. I invested into building a system in PHP in 2010 (and using ignite as framework), when opportunity came to redo it, recently , I picked Java (besides type safety, I also had to build a client as an Android app, so sharing classes across both was another reason for Java). I would also say that 'health' of a particular language+ecosystem should be measured by 6 variables. 1) new project uptake (OSS) -- eg how many new projects are created using particular language. 2) existing project updates frequency (OSS) 3) leavers (how many projects leave this ecosystem) and same for non-OSS projects (where this can be measured)
• wyqydsyq 7y ago
  I respect the leaps PHP has come as a language and runtime in recent years, however I still can't understand why anyone would elect to use it for greenfields projects. The developer experience might be better than it's ever been, but even as pointed out in this article, it still has all the old issues like inconsistent core API, vague global context, and way too much implicit magic and guesswork. Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python etc stacks where the HTTP server itself is a native construct of the language/runtime. I can't see any single use case where there isn't a more appropriate alternative to using PHP. The only feasible reason I can see someone would use PHP for a greenfields project in this day and age is that they simply don't know any better. "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."
  • jtreminio 7y ago
    > it still has all the old issues like inconsistent core API Seriously, people keep bringing this up. Why? Are you a machine? Did you memorize the API to every single language you write in? I type `strst` and my IDE autohints `strstr()` and the argument order. > vague global context What's vague about it? What does global context even mean in this sentence? Do you mean like super variables? Static properties? Can you provide some detail? > Not to mention it still relies on running a separate, third party HTTP server, in contrast to Node.js, Java, Python You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that? Or are you going to put Nginx or Apache in front to do what they're made to do: be webservers? Hell, there's Unicorn, Passenger, Puma, all aimed at doing exactly this. And surprise, surprise, PHP also has a built-in webserver you _can_ use, but shouldn't. There's even ReactPHP, Swoole, Amp, all with webserver capabilities. Sounds more like a person who knows PHP in passing, or may have used it lightly, or long ago.
    • wyqydsyq 7y ago
      > Did you memorize the API to every single language you write in? No, that is my point. Languages with consistent core APIs are more easily discoverable, less error-prone and result in developers being less reliant on editor hinting. Writing PHP requires to you memoize random shit like the fact that json_encode() accepts options via bitmasks, inconsistent with the rest of the language for no apparent reason. > What's vague about it? - Imports/namespaces are not explicit (no intuitive way to know what methods are being provided by a given import without diving into it's file) - All HTTP input (remember, PHP basically exists to script HTTP responses) is magically provided through vague superglobals that are set to wildly different values depending on what HTTP server you use and how it is configured - Variables are all declared in global scope by default > You _can_ run your website using only the built-in webserver for those languages, but are you really going to do that? Yes. Unlike with PHP, running a single-process HTTP server does not result in thread locking for most other languages as their HTTP implementations are asynchronous by nature. There are currently some PHP community projects to implement async i/o, but there isn't even really any point trying to use them given PHP is meant to be having native libuv support eventually which will more or less make them redundant. And even then, why would you go to all this extra effort reinventing the wheel if not just to be stubborn and avoid having to learn a new language which is better suited to the task at hand? > Or are you going to put Nginx or Apache in front I hope you realise that other than for traditionally CGI-executed runtimes like PHP, Ruby and Perl, external HTTP servers like Nginx and Apache are almost exclusively used as a reverse proxy for things like load-balancing and SSL termination and have little to no involvement in processing and responding to the actual HTTP requests, which is typically left up to a HTTP server implemented in the application code. Sounds more like you have little to no experience with web services outside the PHP world.
• nikdaheratik 7y ago
  I've spent basically two years working to convert a legacy project built on PHP 5.x into Laravel on PHP 7.x and I can agree that it's come a long way as a language, and that frameworks like this help. The biggest issues, however, are not technical but are based on changes in the development philosophy overall. The legacy project was written by people who envied Java and its object system and wanted to make everything an object. Laravel (and similar projects) have moved towards something that is a mix of object-based approaches and Functional/Lispy approaches. This puts it more in line with the direction alot of languages (JS, Rust, etc) have been taking. TL;DR: PHP is in a better place than it's been in awhile, largely because it's willing to borrow good ideas and execute them while still being able to make use of its legacy libraries when needed.
• stunt 7y ago
  Most of the people defending PHP are talking about PHP7+, and most of the people hating PHP are talking about PHP5-. Both groups didn't experience what the other group did and they are not talking about the same thing. So it is kind of pointless discussion. The language itself has improved a lot. It is easy to find decent PHP7+ code now. It is also easy to find bad code. And that is the same for all major programming languages in terms of usage. As Java got more popular, it was easier to find crappy code everywhere from people that only learned inheritance from OOP. More projects mean more technical debt for the future. So you always find more critics against most popular ones.
• cutler 7y ago
  I just took a random sample from Spatie's PHP libraries - https://github.com/spatie/crawler/blob/master/src/Crawler.php https://github.com/spatie/crawler/blob/master/src/Crawler.ph.... Most of the code consists of: public function getSomething(int $someParameter): SomeType { return $this->someParameter; } If this, along with the fanfold block comments you see in modern PHP, is considered "clean code" I'll take procedural PHP4 any day of the week. Why PHP5 had to be reborn as the scripting version of Java I'll never understand.
  • kbenson 7y ago
    It's been close to a decade since I did anything in PHP (PHP5), but since I know PHP5 had public (and private,and protected) accessors back then, but didn't have any real typing of parameters if I remember, I assume this is a design pattern to enforce typing on the object parameters. Also, a good amount of them have some other guard that throws an exception on specific problems. I think it's a valid design choice to decide that since some object variables may need special handling that is accomplished through accessor methods, just create them specifically for each item that needs public access, and while you're at it throw in a few sanity checks. That provides a consistent interface, where accessors are both named and act in the same manner (i.e. you don't have mixed method call and direct assignment).
• lukaszkups 7y ago
  I'm a front-end guy (with bit of Node.js experience) and I would like to learn PHP and Laravel properly - do you have any suggestions where to start (I would like to learn strong PHP fundamentals as well, not start from Laravel immediately)
• anecdotalShit 7y ago
  Never seen a php dev in my life. I know some big names use it, but never heard of anyone recommend it over something like node/java/go
• bradezone 7y ago
  Personally I'm a fan of the Phalcon framework. It's also structured similarly to Laravel/Cake/Rails but is compiled into a PHP module and thus runs super fast by comparison. PHP has certainly improved with the 7.x line so I'm happy to continue using it.