For those like me that didn't know what ngrok is, "ngrok exposes local servers behind NATs and firewalls to the public internet over secure tunnels"[1]. So it allows you to easily expose internal services publicly, letting you (for example) show someone outside your network a website in your local development environment, without having to deploy it externally into some sort of live environment.
Also, not sure why so many people seem to take "... written in PHP" as a gauntlet slap to their own face, instead of some additional technical information.
If you have nothing to add to the conversation other than witty snark about PHP, maybe your time would be better spent writing a competing open source product in a language of your choice, giving it away for free, and then letting users compare their pros and cons?
OP has been putting out a series of useful tools lately [1] and been very transparent about his process on Twitter [2].
Seeing this thread derail into a discussion about PHP is pretty annoying. It seems to happen to anything PHP-related here. Do that all day long please, if someone comes here saying PHP is the best language... but he created something useful and open sourced it - that deserves more than toxic bike shedding about your favorite toys.
It can be handled using a single go binary using pgrok which comes less the source code size and not to mention without any dependencies on almost all platforms!
This requires unnecessary things to bundle and too complex for some simple stuff. Mileage may vary though.
My personal take on this was that it's for a lot of people a lot simpler to extend Expose, as it's written in PHP.
It also uses ReactPHP as a foundation - which is battle-tested for many years.
After reading the architecture post [1] referenced in the comment by mpociot [2], I’d say PHP is more “suitable” for the server-side if you choose to self-host the Open Source code rather than use the service.
These tunneling services use a client-server architecture with the server-side running on a public IP address. A static binary written in Go, like pgrok, is ideal for the client-side. On the server-side, you want an app server that is both common and can dynamically load a module. A dedicated Go server makes sense if you are building a service but not if you want to add functionality to an existing app server with a public domain name.
Except the PHP version only works with HTTP, Ngrok works with any TCP protocol which is much more powerful, hence why you don't want the weird PHP model with it modules and HTTP server.
That description does not apply to me, and while I know Python, I don't use it. I do however have respect for Python.
PHP would benefit from the Zen of Python:
>>> import this
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
80% of web servers is not the same as 80% of web traffic.
I guess at least 80% of web traffic would go to the Alexa top 100 sites. How many of those run on PHP? There was a time where many if not most of them ran on PHP, but today many have migrated away from it for performance reasons.
Facebook? (I know, it's technically HHVM but the language is basically PHP)
Wikipedia?
Wordpress?
Tumblr?
Large chunks of Slack?
That's a lot of traffic.
Fun fact: Companies typically leave PHP not for performance reasons (it's faster than Python and Ruby, for example) but because it's hard to hire people who know PHP since there's a strong bias against it.
(To be fair, I was one of those anti-PHP people, but after seeing PHP7, Laravel, etc, I acknowledge it's vastly improved from the early 2000s).
We got around that by hiring language-agnostic. Laravel is such a well designed framework we had no issue getting people contributing week 1, while continuing to expand their knowledge of the framework over time.
Wikipedia and Wordpress have massive reverse proxy caches in front of their PHP servers. Those servers are the ones that handle most of the load.
99% of users only read articles and blog posts, which is content that can be aggresively cached. If the workflow was not as cache friendly, they would not be using PHP, for sure.
Again, is it as performant as compiled/byte code languages like C, Java, GoLang? No. I'm not making that statement. This is why most real reverse proxy caches are not written in Ruby or Python.
Does it compare favorably or equally to most interpreted languages? Yes, it is not an outlier in performance (and tends to be one of the fastest cause of all the tuning it's had from use at high load companies). And yes, large chunks of the code in these companies still, today, run PHP. I guarentee you Wikipedia's global editor activity is higher than you think it is. Same with Tumblr and Slack's entire channel communication pipeline (which was an offshoot from Glitch).
It generally scales better than Ruby and Python. You can write shitty code in all of these languages and you can write clean code in all of these languages. And every language has it's warts (Python, which I LOVE and had a startup built around it, is FULL of these warts too).
PHP has almost the verbosity of Java. For the same amount of effort you get less performance and access to inferior tooling for debugging, profiling, testing, static analysis, etc.
The average person working on PHP applications cannot write a multithreaded socket server and do not understand TCP. They don't know how things work and what to do when they don't.
Their mental model is based on self-evident truths such as "Laravel is good because Laravel is good" and "PHP is good because PHP is good", but as soon as you ask why, they cannot really ellaborate in terms other than "because it's good". It's a cargo cult.
You realize you are stereotyping a large group of people. You also know absolutely zero about modern day PHP, it seems. Let's argue about Perl 4.19 while we're at it.
I assure you the actual writers of Laravel know why Laravel (or Lumen) is good and why they made decisions they made. I promise you the Facebook PHP engineers who worked on HHVM and Hack know best practices and PHP really well (and know how to write a multithreaded socket server and understand TCP).
I also promise you that there are engineers that work all over the place (like non pure tech companies like banks and insurance companies) that don't look at Java as craft. They use Spring cause it's "good" and have written the DAO pattern 100s of times cause it "works". I bet the vast vast vast vast majority of Java Spring developers have not read Rod Johnson's Expert One-on-One J2EE Design and Development and actually understand WHY Spring was invented.
Knowing Java doesn't create some magical space where you suddenly know the TCP protocol state diagram. That's just a silly statement. I promise ANY average developer of ANY language can NOT spit out a bare metal implementation of TCP. Hell, I bet the average Java developer doesn't know the difference between UDP and TCP (or the average php developer, average python developer, average ruby developer, you get what I'm saying)
PHP is a language. One that is as performant as it's peers, has a large presence on the internet, and is battle-tested. If you instinctively shit on PHP developers, that's something you need to work on.
And, just to be clear, I don't CODE IN PHP and never have. I just know people who are brilliant who do and also deal with some PHP buried in my company to this day (like pretty much every tech company).
> I promise you the Facebook PHP engineers who worked on HHVM and Hack know best practices and PHP really well.
I said "the average person working on PHP applications", that clearly does not fit the description of HHVM engineers at Facebook, people that certainly know what they're doing.
If PHP users are so great, let's take a quick look at what kind of discussions are they having in 2020:
Again, you listed a ton of compiled languages compared to an interpreted language. Want to throw X86 Assembler in there too? Should we write all software in Intel syntax x86 Assembler? It's faster than Rust - just manage the registers yourself!
Fact is, interpreted languages have THEIR advantages in lots of areas.
Nice random zend link. I literally took 100ms and found questions on Stack Overflow about writing async PHP code from 2013.
Python LITERALLY just added the async/await keywords and co-routines in 3.5 in 2015 (AFTER PHP did). I can also link to "Why you should use Async in Python articles" from 2020 and 2019. Hell, google that phrase and see what comes up. Look at the talk tracks at PyCon last year.
I can also link to an article on how to do asynchronous programming in C# on MICROSOFT.COM from May 20, 2020 (you know, a pretty authoritative community place for .net) But it's a stupid point. There are tutorials to learn how to do things in every language written every day.
I get it, you're a language snob. This conversation feels like "Man, fuck people who speak German. They don't know how to build cars the way people who speak Japanese do."
Languages are languages. You can write shitty things in any language and good things in any language.
The facts are, nearly all of the big sites on the Internet have PHP somewhere, some PHP is bad and some is good, and there is a wide variance of skill level among PHP developers.
Replace that previous paragraph with any language and the answer is the same.
ReactPHP and similar solutions have existed for a while, but after many years of existence, how many people are using it? Not many.
Was async I/O promoted to a core language feature? It hasn't. You can do it, but you have to install a 3rd party dependency, and you will have to still interoperate with code that does not use async I/O. Contrast that to the reality in other languages.
Then, the rest of your arguments are not new, and are the usual last-resort losing arguments:
- "write everything in assembler if you care about performance": zero/low cost abstraction are different than no abstractions at all. Different in terms of productivity, maintainability, portability, etc. And you know this, I wonder why you mention it.
- "everything is relative and the choice of language doesn't really matter because they're all the same": they are not the same and the choice does matter. Languages are the product of different design and implementation processes, as well as different levels of investment, and results can differ a lot.
- Ad-hominem: I don't care. To me, your ad-hominem is the same as admitting your argument is inferior.
Anyways, PHP jumped the shark long ago and today it's just another legacy code language.
PHP is quite fast actually. Its not Go fast but for an interpreted language its doing really well, runs circles round Ruby for example which was very popular for web apps.
Also, not sure why so many people seem to take "... written in PHP" as a gauntlet slap to their own face, instead of some additional technical information.
If you have nothing to add to the conversation other than witty snark about PHP, maybe your time would be better spent writing a competing open source product in a language of your choice, giving it away for free, and then letting users compare their pros and cons?
1. https://ngrok.com/product