Taking PHP Seriously (2016)(slack.engineering)
slack.engineering
Taking PHP Seriously (2016)
https://slack.engineering/taking-php-seriously/
149 comments
The best language for a startup is one the founders know the best. Every other discussion will at best make a 1% difference.
Really depends on what the business is doing.
Chewing through TBs of data every hour? Probably not a good idea to use Ruby.
Doing a bunch of really heavy math? Probably not a good idea to choose PHP.
Doing a SaaS service? C++ probably isn't a good choice.
There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply them everywhere.
Chewing through TBs of data every hour? Probably not a good idea to use Ruby.
Doing a bunch of really heavy math? Probably not a good idea to choose PHP.
Doing a SaaS service? C++ probably isn't a good choice.
There are some really good general purpose languages that can fit most circumstances (Java, .Net languages, Go). However, I'd be careful to say that you could apply them everywhere.
I would mention that you're not bound to a single language so writing the guts of the business logic in something like PHP, Ruby or server-side node might be fine - you'd just hook up the performance sensitive bits up to a library written in a compiled language.
In fact I think there are certain organizational benefits to partitioning your language use by skills required to maintain that section of code. When you're a startup there's no benefit at all, but as companies grow you can use that to smoothly transition into separate teams with different expectations around testing and feature flexibility.
In fact I think there are certain organizational benefits to partitioning your language use by skills required to maintain that section of code. When you're a startup there's no benefit at all, but as companies grow you can use that to smoothly transition into separate teams with different expectations around testing and feature flexibility.
I hate to be "that guy" but I see no reason not to use PHP for all three of those things.
PHP is faster than Ruby. [1]
PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2]
PHP is an extremely popular language as the backend for SaaS, and arguably one of the oldest and most successful. [3]
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
[3] https://insights.stackoverflow.com/survey/2020#most-popular-...
PHP is faster than Ruby. [1]
PHP from a local script does math just fine. It's the round trip of the request to a PHP server and back that you're associating with poor language performance. In a local scripting environment PHP7 is considerably faster than Python3. [2]
PHP is an extremely popular language as the backend for SaaS, and arguably one of the oldest and most successful. [3]
[1] https://benchmarksgame-team.pages.debian.net/benchmarksgame/...
[2] https://blog.famzah.net/2016/02/09/cpp-vs-python-vs-perl-vs-...
[3] https://insights.stackoverflow.com/survey/2020#most-popular-...
> PHP is faster than Ruby.
It's not helpful to be faster than the language that the parent implied wasn't fast enough.
I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.
More generally, "it depends".
It's not helpful to be faster than the language that the parent implied wasn't fast enough.
I think the parent's point was that if the startup's raison d'etre involves "chew[ing] through TBs of data every hour", then choosing a language that can do that 10x faster than another might have a tremendous impact on cost and so the company's value. It might be the difference between successful or not.
More generally, "it depends".
> PHP from a local script does math just fine
It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.
I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.
It depends on the definition of "just fine" really, not to be argumentative. I've written quite a few algorithms processing big numbers (e.g. numbers with digits in the megabytes) and PHP struggles, where other languages like GO are several times faster and often far more easy to parallelise whereas with PHP if I want to try and use the multiple cores my CPU has, I need to look into pthreads or worse, write worker scripts that I execute with backticks or curl, it's clunky for that use-case. I wouldn't even know where to start thinking about how to run my algorithms in the GPU with PHP.
I say this as primarily a PHP developer in my paid profession, and PHP is my go-to for any kind of web development or if I want to prototype an idea - it's a very expressive and intuitive language but there are always use-cases that any language is decidedly unsuited to, even if it's "technically" capable. I wouldn't build a website in native C, even though I know it's "technically" possible for example.
Well, if you have to chew through TBs of data every hour, don't use PHP i think? Unless you're not in a competitive business and you can pretty much throw money at the data?
I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)
I think to OC is not well formulated: If you're selling a web app or web SAAS, any language the founders know best is the best. Any other stuff, it is not always the case (but it might be!)
"PHP from a local script does math just fine"
I suspect they meant the kind of heavy math that the PHP 8.x JIT is trying to improve performance for.
I suspect they meant the kind of heavy math that the PHP 8.x JIT is trying to improve performance for.
Close I think - the best language to use is the one you will have the easiest time hiring good talent for. If you found a startup and all really love and are fluent in COBOL that's great but... good luck when it comes time to hire another employee.
If you have a good product new engineers will learn whatever language it is in. This very article is a perfect example. I'm sure Slack isn't hiring kids out of college with extensive PHP experience.
Php is pretty easy to pick up. We have way to many languages (Java ,Perl, php and python)
A lot of interns end up using php(symfony). If they know Perl or Java they can pretty much jump right in. Python they take a little bit though not much more.
A lot of interns end up using php(symfony). If they know Perl or Java they can pretty much jump right in. Python they take a little bit though not much more.
This is strange to me because I’ve taken and succeeded at two positions now where I didn’t know the language going in.
I just wanted to clarify that I specifically called out how easy it is to hire for. A lot of developers are pretty quick when it comes to adapting to a new language and there are virtues that lean in favor of a language being easy to pickup: sharing a paradigm with popular language, sharing conventions with popular languages and good documentation.
I have yet to work a day job in Rust, but I've worked in Java, C++ and Go so I'd be quite confident applying to a Rust position as long as it wasn't specifically security focused... I would be less confident in how quickly I could pickup Prolog - I think my brain works well for the nuances of the language but I'm less certain.
I have yet to work a day job in Rust, but I've worked in Java, C++ and Go so I'd be quite confident applying to a Rust position as long as it wasn't specifically security focused... I would be less confident in how quickly I could pickup Prolog - I think my brain works well for the nuances of the language but I'm less certain.
Yeah, this is why I’ve concentrated on learning different kinds of languages in my free time, rather than learning the latest thing: if I know Python, Ruby is relatively easy to learn but Haskell is more difficult. So, it’s worth my time to learn Haskell rather than Ruby.
COBOL.. lol so spoiled. It's machine code or gtfo! /s
That's making a bold assumption you get as far as hiring.
I espoused this sort of rhetoric until I worked at a PHP shop. Every other discussion was about problems posed by the shortcomings of the language, crossed with mistakes made by past staff. It's so easy to make assumptions about "good actors" and "reasonable developers" that just fly out the window with a team that picks PHP and/or doesn't know much else.
I've worked at PHP shops - working on a PHP project for a consultancy right now - and there's 0 issues about 'shortcomings of the language'.
"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).
"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).
I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?
Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.
"past mistakes" are almost inevitable problems - I've been on both sides of this - creating things which likely caused someone else problems (learning to be better at tests and docs) - and inheriting problems created by someone see ( learning to demand better tests and docs from others when possible).
"past mistakes" have little to do with the language. Recently worked with a large Java codebase spanning back more than a decade. There's plenty of mistakes that have been made. And... there's plenty of 'language shortcomings' around Java too (go back to Java from 15 years ago, lots of shortcomings).
I was on a team that picked node for a project; the whole thing failed. Should I blame it on the language, or the people who made bad choices?
Perhaps the issue is mostly around people/teams that either aren't very good or more to the point don't have a structure in place to guide them and help them get better.
As I read this I'm upgrading an old Python 2.4 app to 3.8. It isn't just PHP.
Can you elaborate on the failed node project?
Probably not much of interest. Small team of... 4-6 had mix of experience with php, java and .net (min 8-10 years of each, fwir). Someone wanted to learn node (of course... always the best reason to choose a star), and pushed that on others. I gave up fighting that. Then we needed to "micro service" the node code because... well... you know... we have to be on AWS and lambda because... scale. Funnily enough, 'testing' and 'testability' never seemed to enter in to the decision making equation.
It depends on a lot of factors. I worked at a startup that used PHP and the initial code quality of Product A was godawful because some early hires didn't know how to properly structure their code. Over the next few years, as staff turned over, we were able to clean it up considerably, add a lot of good OO practices, and get to a point where new developers who didn't even have PHP experience could be very productive very quickly.
When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.
PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.
When we started a Product B about nine months into my time there, the new team wrote new, well-designed code from scratch, and was also very productive very quickly.
PHP lets you easily shoot yourself in the foot, but it also gives you all the tools you need to leave your feet in very good condition, and it's not difficult to do that either.
That's true, I've made amazing things with PHP, but as soon as you throw some more people on the project, especially people who pine for their JS or Ruby and don't want to accept the PHP way of doing things, you get a shitshow of epic proportions.
No, really no, as someone who has worked on code bases where people followed the path of least resistance (PHP in this case) things turned into a giant mess of human suffering. Pick a language that has tooling for what you want to achieve otherwise everyone reinvents it or just makes a mess.
I’ve found giant messes of human suffering even where the tooling chosen was relatively excellent for the problem at hand. The part not being considered is that some problems are hard to solve and developers will make a mess even with the right tools. Programming isn’t easy, but especially in uncharted territory. I think that’s why choosing tools you at least know has merits.
I spent a lot of my career consulting as a mess cleaner, more or less, and even very smart people end up making a mess sometimes. Time constraints, shifting goal posts, all of it.
I’d say the worst thing I ever see, regardless of tools, is premature optimization getting in the way of everything else.
I spent a lot of my career consulting as a mess cleaner, more or less, and even very smart people end up making a mess sometimes. Time constraints, shifting goal posts, all of it.
I’d say the worst thing I ever see, regardless of tools, is premature optimization getting in the way of everything else.
If premature optimization getting in the way is the norm for the projects you helped then I'm afraid that the people who crated them before that might not be as smart as you imply.
A "smart" and/or a "senior" programmer knows not to optimize prematurely.
But maybe I latched only on this one sentence and missed your point. Sorry if that's the case.
A "smart" and/or a "senior" programmer knows not to optimize prematurely.
But maybe I latched only on this one sentence and missed your point. Sorry if that's the case.
Honestly I think even junior developers know better, but we all make bad calls sometime and maybe worst of all, requirements can change and sabotage our best efforts.
I think you're going to far. Good luck writing a mobile app in ruby (as one example).
I often hear engineers rave about lisp. Is that really such a superior language?
No, its not, but it is a fun language. I'd take a lisp job over anything if i found one. Not because it is the best language (it is not the best at anything, except maybe prototyping), but because it is fun, and interesting to work with it.
Sounds fun yeah.. Really should start to learn to program. Got a background in pure math but for some illogical reason I feel kind of intimidated by programming.
Superior at what?
Meta-programming? Yes. Object-oriented programming? Meh. CLOS is nice, but not vastly superior to anything else. Something else? Depends on what that something is.
Meta-programming? Yes. Object-oriented programming? Meh. CLOS is nice, but not vastly superior to anything else. Something else? Depends on what that something is.
It's interesting.. all these different languages. Wonder if at some point in the future, you'd just have 1 language. (not an engineer so idk if that's possible/practical)
at best 1% and most of the time -50%
Or the language of any libraries that are useful to build on
[deleted]
PHP was the first language I learnt and although I don't use it as much today I still think it's a great language for startups.
Languages like Java, Node, C#, etc are great but unlike PHP you can't just drag and drop a .php file on a webserver, point your browser at it and go.
Basic things required for web development like connecting to a MySQL database are made trivial in PHP.
Code is executed synchronously in PHP and as mentioned in this article requests are stateless which makes the logic much easier to follow and debug than say Java where you have state or Node where you have callbacks and promises.
PHP also gives you the flexibility to write procedural, OO, or even functional code. This flexibility is off putting to some, but it allows the language to be useful no matter what your skill level or preferences are.
Another thing that's easy with PHP is debugging. You don't have to worry about compiling code or accidentally taking down your entire server (most of the time) if you encounter a critical error. If one of your PHP pages runs into an issue you can enable debugging with a line of code, make your fix then hit the refresh to see if it's working.
I learnt to code writing PHP when I was 16 years old. Me and my friend had an idea for a startup but neither of knew how to program beyond a little bit of ActionScript. We were good with computers, but if we decided to use Java I'm certain the project would have never have gotten off the ground because of the steep learning curve.
PHP allowed us to skill up with the language and enabled us to move fast despite not really knowing what we were doing. Writing PHP in the ICT room at lunch with my friend was some of the best memories I have of school... I doubt I'd be doing this today if it wasn't for how much fun I had learning and building stuff with PHP when I was younger.
Languages like Java, Node, C#, etc are great but unlike PHP you can't just drag and drop a .php file on a webserver, point your browser at it and go.
Basic things required for web development like connecting to a MySQL database are made trivial in PHP.
Code is executed synchronously in PHP and as mentioned in this article requests are stateless which makes the logic much easier to follow and debug than say Java where you have state or Node where you have callbacks and promises.
PHP also gives you the flexibility to write procedural, OO, or even functional code. This flexibility is off putting to some, but it allows the language to be useful no matter what your skill level or preferences are.
Another thing that's easy with PHP is debugging. You don't have to worry about compiling code or accidentally taking down your entire server (most of the time) if you encounter a critical error. If one of your PHP pages runs into an issue you can enable debugging with a line of code, make your fix then hit the refresh to see if it's working.
I learnt to code writing PHP when I was 16 years old. Me and my friend had an idea for a startup but neither of knew how to program beyond a little bit of ActionScript. We were good with computers, but if we decided to use Java I'm certain the project would have never have gotten off the ground because of the steep learning curve.
PHP allowed us to skill up with the language and enabled us to move fast despite not really knowing what we were doing. Writing PHP in the ICT room at lunch with my friend was some of the best memories I have of school... I doubt I'd be doing this today if it wasn't for how much fun I had learning and building stuff with PHP when I was younger.
And this has led to countless SQL injection vulnerabilities some of which WordPress in particular is still fighting with (in community extensions, not in their core) to this day.
"Trivial to connect to a database" isn't a selling point. It is a liability when put in the hands of inexperienced programmers.
"Trivial to connect to a database" isn't a selling point. It is a liability when put in the hands of inexperienced programmers.
People really need to be taught about prepared statements. I once worked on a code base (mainly PHP and Java, with a bit of Perl here and there) where someone had built their own SQL parameter escaping. It still didn't work some percentage of the time.
It's like an ugly C.
It's a perfectly reasonable choice for web development, just like a Chevy Caprice is a perfectly reasonable car for a taxi service (as evidenced by the thousands of them in NYC, still plodding along). You'd still rather ride in a Mercedes E430 taxi (long time European standard)... unless you had never experienced both, in which case you probably think the Caprice is just fine.
And if you knew Ruby, Python, Java, C#, Kotlin, or better yet F#, Clojure, or Elixir, you'd most likely enjoy using one of them rather than PHP.
There are three reasons to use PHP.
1. it works
2. it is well integrated with web servers
3. you can find some of the cheapest contract labor who know how to program in it (compared to other, less common/popular languages)
Bonus 4. you need to extend Wordpress by writing a plugin or theme (and Wordpress is the Caprice of CMSs...)
It's a perfectly reasonable choice for web development, just like a Chevy Caprice is a perfectly reasonable car for a taxi service (as evidenced by the thousands of them in NYC, still plodding along). You'd still rather ride in a Mercedes E430 taxi (long time European standard)... unless you had never experienced both, in which case you probably think the Caprice is just fine.
And if you knew Ruby, Python, Java, C#, Kotlin, or better yet F#, Clojure, or Elixir, you'd most likely enjoy using one of them rather than PHP.
There are three reasons to use PHP.
1. it works
2. it is well integrated with web servers
3. you can find some of the cheapest contract labor who know how to program in it (compared to other, less common/popular languages)
Bonus 4. you need to extend Wordpress by writing a plugin or theme (and Wordpress is the Caprice of CMSs...)
Long live PHP.
15 years of PHP dev work. Games, mobile apps, health care, etc. I have been unemployed for 2 days in 15 years. PHP runs %80 of the internet. Talk to anyone at facebook that wears a suit on friday -- they code PHP (and it seems to scale for them). I think I will be 90 years old hacking on PHP.If you really don't like how the arguments are passed just use an IDE. Or get stuck with real problems like a transition from python2 to 3. (wtf)
15 years of PHP dev work. Games, mobile apps, health care, etc. I have been unemployed for 2 days in 15 years. PHP runs %80 of the internet. Talk to anyone at facebook that wears a suit on friday -- they code PHP (and it seems to scale for them). I think I will be 90 years old hacking on PHP.If you really don't like how the arguments are passed just use an IDE. Or get stuck with real problems like a transition from python2 to 3. (wtf)
"Use an IDE" is never an answer to shitty language design. Shitty language design is shitty language design. That said, I cut my teeth on PHP and still have a fondness for it. It's especially great being able to deploy small little backend-driven pages with rsync or sftp in a pinch. I just discovered other languages and environments I enjoyed working in much better.
If there's room for Javascript, there's room for PHP. Both are sloppy, inferior languages, but both can do anything you need. And unfortunately, both have immense momentum from being first in the web game.
It's worth pointing out back end JavaScript didn't really start to take off until the 0.x versions of NodeJS came out
> If there's room for Javascript, there's room for PHP.
PHP doesn't run in the browser. For browser programming there's literally almost no choice. TypeScript seems to be an improvement but even that compiles down to JS. Same for ReasonML and BuckleScript and Elm.
PHP doesn't run in the browser. For browser programming there's literally almost no choice. TypeScript seems to be an improvement but even that compiles down to JS. Same for ReasonML and BuckleScript and Elm.
My point is that both PHP and Javascript owe their popularity not due to their merits as languages, but rather to being in the right place at the right time - time and positioning.
Yeah, sadly this is true. Inertia is a much bigger motivator than merit for many. I still struggle accepting that as a life philosophy.
Unlike php, I can see Javascript slowly disappearing thanks to Wasm.
Ha, I was going to make a comment along these lines. I didn't mention the languages I enjoy over PHP but I can assure you JavaScript ain't one of them. I don't hate JS but as a server-side language I would pick PHP over it any day.
I'm old enough to remember GoPHP5 and the shit storm that transition was
Kinda funny having php devs shit on python backwards-compat
Kinda funny having php devs shit on python backwards-compat
[deleted]
Argument order problems are somewhat over with named params: https://php.watch/versions/8.0/named-parameters
80%? Of what?
Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures.
I would guess because the greener pastures are still greener or otherwise maybe just as green? I moved from PHP to Ruby and Rails eight years ago. I _really_ enjoy writing Ruby (I love the syntax) and Rails servers all my web dev needs perfectly. I'm now learning about the joys of functional languages though Elixir/Erlang (a common next step for Rubyists).
The question is: so what if PHP even has caught up? What could I possibly gain from going back to it? I would have to rebuild context and learn a whole new web framework in a language whose syntax I personally do not enjoy. So no matter how good it's become, it's totally not worth my time and energy to switch back to it.
The question is: so what if PHP even has caught up? What could I possibly gain from going back to it? I would have to rebuild context and learn a whole new web framework in a language whose syntax I personally do not enjoy. So no matter how good it's become, it's totally not worth my time and energy to switch back to it.
> Somewhat unrelated comment, but the fact that PHP got so good and most people are still not willing to give it a second chance goes to show how hard it is for a language to regain market share after people left for greener pastures.
I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overreliance on C extensions for speed ...), haven't changed. As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content.
I guess some of the reasons why some devs would not chose PHP (horrid syntax, std lib mess, stupid error reporting system, language inconsistencies, the very existance of php.ini, overreliance on C extensions for speed ...), haven't changed. As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content.
> As companies move to single page applications backed by javascript and REST API, PHP CGI style classic execution model provides no advantage, when it comes to generating or serving web content
I lol'd.
SPAs are a fad. Apps that rely heavily on REST API and browser rendering rank terribly on Google.
Create a SPA and help your customers discover your competitor on the first page of Google.
I lol'd.
SPAs are a fad. Apps that rely heavily on REST API and browser rendering rank terribly on Google.
Create a SPA and help your customers discover your competitor on the first page of Google.
This assumes Google can't figure out crawling SPA.
That's correct.
Generally, when I'm building a business, I prefer not to assume that Google will eventually, at some point in the future, solve the crawling a SPA site problem and finally discover my site.
I'd rather get my 70%-80% organic search traffic today, with any boring server-side rendered tech stack.
Generally, when I'm building a business, I prefer not to assume that Google will eventually, at some point in the future, solve the crawling a SPA site problem and finally discover my site.
I'd rather get my 70%-80% organic search traffic today, with any boring server-side rendered tech stack.
I don't think I want any crawler ever hitting my API endpoints for customer lookups, scheduling, inventory management, etc - all that stuff that is the 'Application' part of 'SPA'.
Why people use js/spa/etc stuff as the basis for a content/marketing site... I don't know. I mean... yeah, I know why - mostly to expand their skill set. But there's usually no functional benefit, and usually some drawbacks, as you're pointing out.
Why people use js/spa/etc stuff as the basis for a content/marketing site... I don't know. I mean... yeah, I know why - mostly to expand their skill set. But there's usually no functional benefit, and usually some drawbacks, as you're pointing out.
I lol'd.
SPAs are great if your customers actually want an application. Figma, AirTable, Google Sheets. These don't make sense as server rendered pages.
If you're in the publishing business and need your articles to rank high on Google, then yeah its probably not a good idea.
EDIT: Or Slack for that matter
SPAs are great if your customers actually want an application. Figma, AirTable, Google Sheets. These don't make sense as server rendered pages.
If you're in the publishing business and need your articles to rank high on Google, then yeah its probably not a good idea.
EDIT: Or Slack for that matter
According to who? PHP is still behind ~70% of public websites: https://w3techs.com/technologies/details/pl-php
"Greener pastures" does not sound specific so not sure what your argument is. Clarify, please?
I don't doubt that PHP has some benefits. That said, the reasons cited in the blog post don't seem that unique to PHP.
> By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.
Is there a modern web framework where a failed request can crash the entire server? I'm not sure this is a problem in other languages.
> Second, concurrency. An individual web request runs in a single PHP thread.
Huh, so maybe this could be an interesting concurrency model. But it's not that different than say, Node's promises. The only difference is Node's promises aren't tied to literally making a web request.
The restarting the server problem also is not an issue. Almost every mature web stack I've seen has hot reloading. Yes, even in 2016.
There are certainly reasons to use PHP, but the trap I see a lot of PHP proponents fall into is assuming that the benefits they see are somehow unique to PHP. Laravel fans love to cite packages, migrations, the ORM, etc. as reasons to use PHP. I certainly think all of these are great features but they're not unique to PHP.
> By starting each request from a known state, we get a kind of organic fault isolation; if request t encounters a software defect and fails, this bug does not directly interfere with the execution of subsequent request t+1.
Is there a modern web framework where a failed request can crash the entire server? I'm not sure this is a problem in other languages.
> Second, concurrency. An individual web request runs in a single PHP thread.
Huh, so maybe this could be an interesting concurrency model. But it's not that different than say, Node's promises. The only difference is Node's promises aren't tied to literally making a web request.
The restarting the server problem also is not an issue. Almost every mature web stack I've seen has hot reloading. Yes, even in 2016.
There are certainly reasons to use PHP, but the trap I see a lot of PHP proponents fall into is assuming that the benefits they see are somehow unique to PHP. Laravel fans love to cite packages, migrations, the ORM, etc. as reasons to use PHP. I certainly think all of these are great features but they're not unique to PHP.
> Second, concurrency. An individual web request runs in a single PHP thread.
Erlang/Elixir (or any BEAM language) runs every request in a separate green thread which scales much better than OS threads since most of those green threads can be generously multiplexed on just 4-8 CPU cores due to 90% of the time being spent waiting on a database.
One OS thread per request is such a... strange thing to brag about in 2020.
Erlang/Elixir (or any BEAM language) runs every request in a separate green thread which scales much better than OS threads since most of those green threads can be generously multiplexed on just 4-8 CPU cores due to 90% of the time being spent waiting on a database.
One OS thread per request is such a... strange thing to brag about in 2020.
Most languages have global or module-level state that can leak between requests. Hack deliberately avoids this.
This seems to be an unpopular opinion in the tech world, but I honestly enjoy working with PHP. It's such a simple, robust language, and you can use it in many different ways, depending on what you're building (OOP, scripting, microservices, etc).
20 years for me, for sure. Maybe a touch longer.
I love it. My professional career moved to .NET and Python over the last decade, but if I'm building for myself, I build in PHP.
Whatever foibles people claim are in PHP are really just personal gripes about features they don't like, while ignoring all the other pieces that are ideal for web API development. Frankly, I believe first-class duck-typing and nearly-zero impedance with JSON make PHP a first-class citizen of the web. Duck-typing pairs so well with dynamic typing that I don't know why so many languages abuse themselves with the alternatives.
I remember the Docker switchover being very confusing. Why do all these people need such elaborate instrumentation around their development environments? With PHP, the kitchen sink is always there, and always consistent (we'll ignore money_format() for now). Once I really started using other language environments, the pain points that necessitated Docker cropped up, and of course the deployment benefits are excellent. It was just a very confusing couple years trying to figure out why the Node and Python guys were living like animals.
Anyways, cheers to another 20.
I love it. My professional career moved to .NET and Python over the last decade, but if I'm building for myself, I build in PHP.
Whatever foibles people claim are in PHP are really just personal gripes about features they don't like, while ignoring all the other pieces that are ideal for web API development. Frankly, I believe first-class duck-typing and nearly-zero impedance with JSON make PHP a first-class citizen of the web. Duck-typing pairs so well with dynamic typing that I don't know why so many languages abuse themselves with the alternatives.
I remember the Docker switchover being very confusing. Why do all these people need such elaborate instrumentation around their development environments? With PHP, the kitchen sink is always there, and always consistent (we'll ignore money_format() for now). Once I really started using other language environments, the pain points that necessitated Docker cropped up, and of course the deployment benefits are excellent. It was just a very confusing couple years trying to figure out why the Node and Python guys were living like animals.
Anyways, cheers to another 20.
I'm with you. 10 years ago I was doing moderate 'shell scripting' type stuff in PHP - if I needed to scan a dir, parse some files, etc. PHP seems usually far more useful than trying to shoehorn the problem in to bash. And... writing shell scripts in Java ain't ever going to be a thing.
For general scripting where bash is a poor fit PHP and Ruby remain pretty solid to this day and I like them for that.
For web development though, not really. Elixir is much better there and I am saying this as a guy who had 8 years with Java and 6.5 years with Ruby on Rails (and consulted and helped 10+ PHP and JS projects in the meantime).
For web development though, not really. Elixir is much better there and I am saying this as a guy who had 8 years with Java and 6.5 years with Ruby on Rails (and consulted and helped 10+ PHP and JS projects in the meantime).
It's a technology that mostly gets out of the way and allows you to get stuff done, even fairly quickly.
I think the design of PHP the environment is brilliant: no state, requesting a url just executes a file. So simple and solid.
That being said, at some point in 2010-2015 timeline it became essential to master Javascript to do anything good on the web, and so it became a diversion of precious resources to continue to invest in PHP as well.
Instead the progression has just been to recreate the PHP high level architecture in Javascript/nodejs.
So we took the best parts of PHP and brought them to NodeJs land, and then you can cut your costs because you don't have to learn or invest in the full PHP stack.
That being said, at some point in 2010-2015 timeline it became essential to master Javascript to do anything good on the web, and so it became a diversion of precious resources to continue to invest in PHP as well.
Instead the progression has just been to recreate the PHP high level architecture in Javascript/nodejs.
So we took the best parts of PHP and brought them to NodeJs land, and then you can cut your costs because you don't have to learn or invest in the full PHP stack.
Is NodeJS on the server side faster or lower memory? Because the tooling feels heavier with node modules breaking out thousands of files.
I imagine async of Node may help somewhat.
I imagine async of Node may help somewhat.
So the entire argument is that PHP is single threaded and each request starts with no state? Am I missing anything else?
I’m trying so hard not to rant here, so I just wanted to confirm that those are the only positives he outlines about the language.
I’m trying so hard not to rant here, so I just wanted to confirm that those are the only positives he outlines about the language.
>I’m trying so hard not to rant here
Not that hard, there's a bias showing.
First, those things you've mentioned are nothing to sneer at, are actual very good decisions (even if accidental) for a webserver-centric language.
They enable even naive developers to achive good scalability and isolation, and make fast development/debug cycles trivial.
Second, PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language - all of the above points are already made in TFA.
Most arguments against it are moot today, or only apply superficially to the standard library, not the language (order of arguments, and so on).
Plus, it is speedy too, post 6, and especially post 7 (and there's a whole new JIT in 8). In any case, it has constant work on speed and memory reduction.
And of course it has a huge ecosystem of libs, projects, and frameworks, including not available anywhere else projects like Wordpress.
And the standard library (warts included) between JSON, DB drivers, LDAP support, SMTP, etc., is one of the most complete ones this side of Python, and perhaps even fitter than Python's for typical web development work.
Plus the deployment model is one of the best. Copy your files to a directory. Done. Add a redirect instruction to your server if you want to make it more fancy...
For third party libs, composer is up there with any major package dependency/install solution.
And for the core libs, plugins, etc installation is handled perfectly by the standard package managers in all Linux distros (and probably Windows too), and is even easier with MAMP, WAMP, etc for local development. Trivial to dockerize too if that's your thing.
Not that hard, there's a bias showing.
First, those things you've mentioned are nothing to sneer at, are actual very good decisions (even if accidental) for a webserver-centric language.
They enable even naive developers to achive good scalability and isolation, and make fast development/debug cycles trivial.
Second, PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language - all of the above points are already made in TFA.
Most arguments against it are moot today, or only apply superficially to the standard library, not the language (order of arguments, and so on).
Plus, it is speedy too, post 6, and especially post 7 (and there's a whole new JIT in 8). In any case, it has constant work on speed and memory reduction.
And of course it has a huge ecosystem of libs, projects, and frameworks, including not available anywhere else projects like Wordpress.
And the standard library (warts included) between JSON, DB drivers, LDAP support, SMTP, etc., is one of the most complete ones this side of Python, and perhaps even fitter than Python's for typical web development work.
Plus the deployment model is one of the best. Copy your files to a directory. Done. Add a redirect instruction to your server if you want to make it more fancy...
For third party libs, composer is up there with any major package dependency/install solution.
And for the core libs, plugins, etc installation is handled perfectly by the standard package managers in all Linux distros (and probably Windows too), and is even easier with MAMP, WAMP, etc for local development. Trivial to dockerize too if that's your thing.
> PHP has been improved by leaps and bounds from the days of 4, to the point of being a totally different language.
No, most of bad parts are still here, all the stdlib inconsistancies and co are still here. Just because add more functions to a language doesn't change the bad design decisions at its core. The weird mix between dynamic typing and Java style rigidity (without most of its benefits) didn't go away.
What makes it a different language since PHP 5? more type guards? no, it's still a templating language.
No, most of bad parts are still here, all the stdlib inconsistancies and co are still here. Just because add more functions to a language doesn't change the bad design decisions at its core. The weird mix between dynamic typing and Java style rigidity (without most of its benefits) didn't go away.
What makes it a different language since PHP 5? more type guards? no, it's still a templating language.
Those strange naming choices definitely still have a cost but a lot of effort has been invested in documentation and alternatives to lessen their cost.
The mixed typing is... honestly, it's amazing. You really need to try it out for yourself in PHP7 or 8 - you can lean on really strict type checking in your application, go the old route or generally adhere to strict typing and relax that for entry points and library calls.
Lastly, PHP has come down hard and actually introduced backwards compatibility in a few key places to address some of the biggest WATs, I've been pretty impressed by the balance of the language stewardship.
It does definitely have warts, but there are warts on everything that people actually use in industry.
The mixed typing is... honestly, it's amazing. You really need to try it out for yourself in PHP7 or 8 - you can lean on really strict type checking in your application, go the old route or generally adhere to strict typing and relax that for entry points and library calls.
Lastly, PHP has come down hard and actually introduced backwards compatibility in a few key places to address some of the biggest WATs, I've been pretty impressed by the balance of the language stewardship.
It does definitely have warts, but there are warts on everything that people actually use in industry.
FTA: "I claim that PHP’s simpler “think; edit; reload the page” cycle makes developers more productive.
I agree wholeheartedly with this. I prefer statically-typed languages w/ a bit of local inference (I end up in java usually, but C# got it right) and I consistently see people in my world underestimate the edit/reload workflow. Even a small compilation step is enough to break flow and make development a chore, once you've worked that way.
As a side note: java not allowing signature changes and requiring a whole server restart is absolutely awful. It didn't have to be this way: the DCEVM[1] was presented at the 2009 JVM Language Summit[2], by Thomas Wuerthinger. He patiently demonstrated and explained how his work allowed for hot swap of arbitrary class changes, while the Sun guys sitting in the audience told him that what he was demonstrating was impossible. We ended up using the DCEVM for a long time, but as of right now I'm back to restarting my server when I make breaking changes. It's a funny world.
¯\_(ツ)_/¯
[1] - This is a modern fork of the project: https://dcevm.github.io/
[2] - http://wiki.jvmlangsummit.com/Hotswap
I agree wholeheartedly with this. I prefer statically-typed languages w/ a bit of local inference (I end up in java usually, but C# got it right) and I consistently see people in my world underestimate the edit/reload workflow. Even a small compilation step is enough to break flow and make development a chore, once you've worked that way.
As a side note: java not allowing signature changes and requiring a whole server restart is absolutely awful. It didn't have to be this way: the DCEVM[1] was presented at the 2009 JVM Language Summit[2], by Thomas Wuerthinger. He patiently demonstrated and explained how his work allowed for hot swap of arbitrary class changes, while the Sun guys sitting in the audience told him that what he was demonstrating was impossible. We ended up using the DCEVM for a long time, but as of right now I'm back to restarting my server when I make breaking changes. It's a funny world.
¯\_(ツ)_/¯
[1] - This is a modern fork of the project: https://dcevm.github.io/
[2] - http://wiki.jvmlangsummit.com/Hotswap
It’s hard for me to relate, because I just don’t see “edit; reload” as being that important.
I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
I really like working in PHP but I'd actually agree that edit;reload is a virtue of the language (in the environment everyone normally assumes it's running in) that is losing value.
This virtue was incredibly valuable to me when I was throwing a website together with ducttape and bubble gum and it was the only way (that I knew of) to be able to clearly and quickly see the results of my changes. With tests in the picture I think it loses a lot of that value - it still has some since nobody likes writing front-end tests but most of your code changes should be "proven" by some level of automated test coverage.
This virtue was incredibly valuable to me when I was throwing a website together with ducttape and bubble gum and it was the only way (that I knew of) to be able to clearly and quickly see the results of my changes. With tests in the picture I think it loses a lot of that value - it still has some since nobody likes writing front-end tests but most of your code changes should be "proven" by some level of automated test coverage.
Oh, you were asking about benefits that you can easily relate to.
Well, in that case then you'd be in a much better position to answer than I am.
Well, in that case then you'd be in a much better position to answer than I am.
> I think the difference is I write tests. I usually code everything while writing/running tests. Then it always works the first time I run it, so there’s no need for “edit; reload”.
I write tests, too. I guess I'm not as good of a software developer - because just as my code has bugs and unexpected edge cases, so do my tests, and they don't catch every mistake I made, since I'm the one making them.
I write tests, too. I guess I'm not as good of a software developer - because just as my code has bugs and unexpected edge cases, so do my tests, and they don't catch every mistake I made, since I'm the one making them.
IMO it's such a good thing about PHP that I think other stacks should follow that model (I assume ROR does).
I think it's a superior model to the long-running application. Unless your company has 0 developers in it who make a memory leak, or make a fatal uncaught exception.
I think it's a superior model to the long-running application. Unless your company has 0 developers in it who make a memory leak, or make a fatal uncaught exception.
Hm. This is this and that is that. It is perfectly possible to write a stateless service hosted in a stateful process.
In fact, the popular PHP-FPM way to host PHP does just that.
If you want to take it to the extreme, there's always CGI, of course.
In fact, the popular PHP-FPM way to host PHP does just that.
If you want to take it to the extreme, there's always CGI, of course.
Ruby on Rails lives inside a long-running application server. In development, it has dynamic class loading and will reload on file changes, but in production an app can have a lengthy startup time. It does have the memory problem, but I have never seen the server crash outright as a result of an exception while handling a request.
You might have missed this bit - "Did Facebook, Wikipedia, WordPress, Etsy, Baidu, Box, and more recently Slack all succeed in spite of using PHP?"
They didn't provide any real arguments that the answer is anything other than "yes".
Plenty of languages have support for hot reloading, which means you can just edit, save, refresh exactly the same as in PHP, with the added benefit of not having to use PHP.
Plenty of languages have support for hot reloading, which means you can just edit, save, refresh exactly the same as in PHP, with the added benefit of not having to use PHP.
Besides the common gripes, the thing that ruined PHP for me was learning that empty("0") is true. I learned this the hard way when this edge case caused an incident and I spent half a week rewriting code to be...not that.
PHP has some great properties, and if you're tolerant of its sharp edges, great. But up until recently (and perhaps still?) it's got many of its safeties turned off by default. When I left PHP, (insecure) mysql bindings still came included pretty much universally, but often not PDO. They have every amazing helper function under the sun at your fingertips (urlencode and htmlentities!) but also some tremendously dangerous ones (backticks! variable variables!).
What's most striking to me is that Slack is 100% off of PHP now (onto Hack). There's something telling when neither the syntax nor the runtime nor the standard library are sufficient for the biggest users of a language. With recent versions of the core runtime finally getting fast, I wonder if they'll rip off the bandaid and break backwards compatibility to dull some of the larger sharp edges.
PHP has some great properties, and if you're tolerant of its sharp edges, great. But up until recently (and perhaps still?) it's got many of its safeties turned off by default. When I left PHP, (insecure) mysql bindings still came included pretty much universally, but often not PDO. They have every amazing helper function under the sun at your fingertips (urlencode and htmlentities!) but also some tremendously dangerous ones (backticks! variable variables!).
What's most striking to me is that Slack is 100% off of PHP now (onto Hack). There's something telling when neither the syntax nor the runtime nor the standard library are sufficient for the biggest users of a language. With recent versions of the core runtime finally getting fast, I wonder if they'll rip off the bandaid and break backwards compatibility to dull some of the larger sharp edges.
I've ended up treating PHP like shell scripting, with that mind set it becomes much more bearable for writing new code in... much like bash, you don't dare write anything too complex, yet can appreciate it for being a well positioned language for the specific type of task (and I say that having written lots of quite long but well composed bash scripts).
Unfortunately PHP is more capable as a language than shells while still having all those poorly thought out parts that will make you hate it if you try to exploit it to it's full capability.
Of course this mind set doesn't help much for existing massive code bases where all of the application logic is written in PHP.
Unfortunately PHP is more capable as a language than shells while still having all those poorly thought out parts that will make you hate it if you try to exploit it to it's full capability.
Of course this mind set doesn't help much for existing massive code bases where all of the application logic is written in PHP.
"First, state. Every web request starts from a completely blank slate. Its namespace and globals are uninitialized, except for the standard globals, functions and classes that provide primitive functionality and life support."
It was somewhat amusing to see some of the same people that made fun of this later espouse the virtues of AWS Lambda.
It was somewhat amusing to see some of the same people that made fun of this later espouse the virtues of AWS Lambda.
Given PHP 8 has been released, does Hack provide enough value to consider it as an alternative? My take on it is no, but I'm curious about other people's opinions.
It is good to keep in mind that this article is more than four years old. I would advise against Hack at this point since most of the good bits have been integrated into the main PHP release - typing is a lot more predictable and enforceable for instance.
Oh boi, my apologize, I missed the "Written 4 years ago" part. Good call. Thank you.
only played around with it briefly a few years ago. my view is "probably not unless you've already used it, or have knowledge of some specific PHP issue you know you're going to need that Hack provides". I think 4-5 years ago, there was a point where Hack might have been able to grow out of niche status, but I think that time's passed, with the growing community around 'modern' PHP and the ecosystem provided via composer and frameworks.
This was written 4 years ago. Since then, PHP7 and PHP8 have incorporated many of the benefits of HHVM.
Thanks for pointing this out. I read this article as "PHP is bad, use Hack instead"
PHP after 5 is great. I guess from PHP 7 on things changed pretty significantly.
Combine it with Laravel and nginx, and you've got an enjoyable stack in my opinion.
Combine it with Laravel and nginx, and you've got an enjoyable stack in my opinion.
Nginx is great, but I've used Apache and Caddy as well and they're both great too.
Does anyone start a new php project without a framework these days? There are some great ones (Laravel, Symfony, PimCore, etc.).
Does anyone start a new php project without a framework these days? There are some great ones (Laravel, Symfony, PimCore, etc.).
Article written in 2016, mind you
I get it. Old PHP was a joke, so people (including me) are biased against it.
I would personally love to get beyond that bias. However, every single time I install any piece of software written in PHP, it's simply a nightmare (e.g. Matomo, rss-bridge).
Unhelpful error messages, unexplained or undocumented features, all held together with metaphorical duct tape.
I always have to dive into the source code to figure out things that a README or tutorial should be able to help me with.
I can't recall ever doing that with tools written in any other language.
Is it simply that PHP programmers care so little about their products?
I would personally love to get beyond that bias. However, every single time I install any piece of software written in PHP, it's simply a nightmare (e.g. Matomo, rss-bridge).
Unhelpful error messages, unexplained or undocumented features, all held together with metaphorical duct tape.
I always have to dive into the source code to figure out things that a README or tutorial should be able to help me with.
I can't recall ever doing that with tools written in any other language.
Is it simply that PHP programmers care so little about their products?
It's likely a combination of the sunk cost fallacy and loving the syntax and maybe the enablement for quick iteration (and all 3 aren't specific to PHP at all).
I have the same opinion about Python btw. Just today I had to install a complex toolkit for flashing ROMs and you can guess that thing absolutely didn't work on the first try and I learned much more about "pip" than I ever wanted to.
I have the same opinion about Python btw. Just today I had to install a complex toolkit for flashing ROMs and you can guess that thing absolutely didn't work on the first try and I learned much more about "pip" than I ever wanted to.
As a language i enjoy Python and Javascript a lot more than PHP. Especially the major PHP frameworks and libraries tend to be too complicated and Java-esque for my liking. There are some nice simpler alternatives, but they tend to get abandoned in favour of the larger projects.
But when looking at PHP in terms of deployment and making traditional SQL-based websites/API's it's unmatched. Just reading up on deploying Python code using uWSGI, or connecting to a SQL database gives me headaches, and the confusing package management and versioning system makes things even worse. Running Node feels unpredictable, with the server crashing because you forgot to catch an exception somewhere or having some weird state.
With PHP it's just: write the code, copy the files to a server and stuff (usually) just works. That's why i keep using it. Not that pretty, but it always gets the job done.
But when looking at PHP in terms of deployment and making traditional SQL-based websites/API's it's unmatched. Just reading up on deploying Python code using uWSGI, or connecting to a SQL database gives me headaches, and the confusing package management and versioning system makes things even worse. Running Node feels unpredictable, with the server crashing because you forgot to catch an exception somewhere or having some weird state.
With PHP it's just: write the code, copy the files to a server and stuff (usually) just works. That's why i keep using it. Not that pretty, but it always gets the job done.
"For instance, 123 == “123foo” evaluates to true (see what it’s doing there?), but 0123 == “0123foo” is false (hmm)."
Can anyone explain this to me? I know if a string starts with the number, PHP takes the number part and throws the rest, so "0123foo" should be 0123 for the comparison, so why is that false?
Can anyone explain this to me? I know if a string starts with the number, PHP takes the number part and throws the rest, so "0123foo" should be 0123 for the comparison, so why is that false?
Edit: I was wrong. 0123 is octal, not decimal
[Incorrect original post: 0123 evaluates to the integer value 123]
[Incorrect original post: 0123 evaluates to the integer value 123]
Not quite - 0123 is the octal value 123 which happens to be 83 in decimal. Numbers starting with a 0 in PHP are assumed to be in octal but I this isn't the case for strings[1] - to add to confusion "123foo" == 123 => true but "0123foo" = 0123 => false.
1. https://3v4l.org/hAoL2
1. https://3v4l.org/hAoL2
But the integer part of the string "0123foo" is also 123
[deleted]
[deleted]
I've used a lot of PHP in my life and now feel Go is better suited for my needs. My gut tells me Go libs are written by professionals, while there is a ton of PHP code written by amateurs to contend with. I'll know more once I get further into Go.
That's an unfortunate comparison. Go came around 10 years back and has started to become mainstream fairly recently. PHP has been around for 25 years. So ofcourse the number of libraries you see in PHP are much more and hence much more "amateur" libraries. The professionals writing go code today are the same professionals who wrote PHP code few years back.
How seriously am I supposed to take a language that executes after numerous syntax errors that should be fatal compile/runtime errors in every other language? It keeps on trucking no matter what "code" you give it.
[deleted]
I'm admitting it. I LIKE PHP. It's fun and incredibly easy to work with. I have inherited messy code bases. I have inherited nice code bases. But getting it up and running is _never_ a problem that I have had.
I hated PHP for the longest time (worked extensively with PHP5 and various homebrewed frameworks in the early 2010s), but I gotta admit, it's come a long way with PHP7+ and great frameworks like Laravel.
[deleted]
> Slack uses PHP for most of its server-side application logic, which is an unusual choice these days. Why did we choose to build a new project in this language? Should you?
We already know the painfully obvious answer to this question even if it's not listed in the "reasons": because the technology decision makers were comfortable with PHP and they wanted to use it.
We already know the painfully obvious answer to this question even if it's not listed in the "reasons": because the technology decision makers were comfortable with PHP and they wanted to use it.
is this terribly different from many other choices made by other companies?
"Whew... we're all totally psyched with node, and all have experience with it, know how to solve problems with it... but we're going to commit to Django. We don't want to, but we're going to."
Does that exchange ever happen? I've seen the opposite - almost every tech stack I've seen at small and medium sized companies was primarily the result of the few decision makers who had experiences (good or bad) with specific tech which influenced their decision to use X.
"Whew... we're all totally psyched with node, and all have experience with it, know how to solve problems with it... but we're going to commit to Django. We don't want to, but we're going to."
Does that exchange ever happen? I've seen the opposite - almost every tech stack I've seen at small and medium sized companies was primarily the result of the few decision makers who had experiences (good or bad) with specific tech which influenced their decision to use X.
The argument that you don't have to restart the server after editing a file? I mean I've used a couple of web dev environments and I know for a fact that Rails, Django and Express all come with some sort of automatic reloading in development - provided by the framework itself or by a library. Quite sure there is a solution for most environments.
You still need to contend with build and startup times with those setups though, even if a rebuild is triggered on file save. With PHP, there's no such thing as build or startup, because it's interpreted.
An Elixir Phoenix's page live-reload never took more than one second even on a fairly weak i3 laptop for me. And on my desktop Mac it usually takes 0.2s.
Not that big a deal at all.
Not that big a deal at all.
how's PHP's websocket support?
presumably if it's a thread per websocket then they're using something else to serve that?
presumably if it's a thread per websocket then they're using something else to serve that?
Pretty great with https://github.com/ratchetphp/Ratchet tbh. But yeah, different runtime. Ratchet is built on top of ReactPHP which is an event-loop runtime (think nodejs).
It's helpful to be able to reuse some domain code between the two if necessary, but IO cannot be done the same in ReactPHP because it needs to be async. Good news is ReactPHP has a ton of really great async libs (mysql, redis, etc.) https://reactphp.org/
As others have said, Swoole is also an option, it's more like Go (coroutine style). Personally, I think it's super cool, but not something I want to use, because the majority of the userbase is chinese and the docs and ecosystem suffer from the language barrier.
It's helpful to be able to reuse some domain code between the two if necessary, but IO cannot be done the same in ReactPHP because it needs to be async. Good news is ReactPHP has a ton of really great async libs (mysql, redis, etc.) https://reactphp.org/
As others have said, Swoole is also an option, it's more like Go (coroutine style). Personally, I think it's super cool, but not something I want to use, because the majority of the userbase is chinese and the docs and ecosystem suffer from the language barrier.
fyi on swoole, this book [1] just came out (I cannot comment on the quality, haven't read yet) which hopefully will help bridge the English documentation gap. I've been using swoole for a couple of years and google-translating my way through the Chinese wiki and git issues/comments/etc.
[1] https://www.amazon.com/dp/B0881B227S
[1] https://www.amazon.com/dp/B0881B227S
Swoole (module) is extremely performant in anything networking, including as a websocket server. There are other php-only options (amphp/websocket-server, ratchetphp/Ratchet) but if performance is your need, stick with swoole.
There isn't direct support for WebSocket in PHP like there is for HTTP requests. But there are WebSocket servers written in PHP that work in a similar way to node.js.
A bit sad that despite Slack being (or being built) on top of PHP, there is still no official PHP SDK four years later.
Anyone here want to share their opinion's on Magento? The small time I spent with it left me with a feeling it was the most over engineering piece of software I've ever worked with. It's made to build a market for modules to buy and isn't made to run an e-commerce site.
All written in PHP.
All written in PHP.
Do they still create new backend code mainly in PHP or have they also adopted other languages for new code?
[deleted]
[deleted]
[deleted]
I thought Slack was running on Perl CGI..
* https://news.ycombinator.com/item?id=12703751
* https://news.ycombinator.com/item?id=15262981
PS. Would you mind adding a [2016] in the title? It will show readers they probably need to take a historic context to understand the article correctly.