PHP, for all its faults, enjoys one advantage over, basically, everything else: SCALE.
People have figured out how to build dead cheap mass hosting in PHP.
You can support next to infinite numbers of small projects on a single apache+mod_php server - as long as they don't get many visitors you're fine.
NodeJS, Java or other hipster languages will require one instance of a runtime for each project that runs.
Also, the problems of how to host and develop PHP project have been solved - for a hoster it's usually enough to tell people "here's your ftp, here's your mysql access data, have fun". No other environment (except static HTML of course) comes anywhere close to that.
Most of the cheap mass hosts support basically everything else in addition to PHP. The world where shared hosting only supported PHP ended quite some time ago.
> Most of the cheap mass hosts support basically everything else in addition to PHP
But PHP requires very little configuration on cheap hosting. At most, tweaking an HTACCESS file. The only competition in this space is Python (Django,Flask and co work with mod_wsgi).
Cheap PHP hosting providers are basically PaaS (Apache,PHP,Mysql...) which is a good thing and a bad thing ( no flexibility, stuck with a PHP version).
Good luck running Rails or Spring on cheap shared servers.
On a $2 PHP/Python shared host I can virtually host as many apps as I want.
Because of memory requirements upfront, I can't do that with Rails, or Spring. Because most mass shared hosting providers do no allow long running processes even NodeJS is out of question.
But surely it isn't the same kind of runtime as for example Node.js, where the script is persistent whereas PHP runs it clean from the start every time?
CGI. Any language can do it. Language runtimes that have long startup times or don't cache the output of any of their compilation steps are less suited though.
A binary or script gets called with environment variables providing info about the request (e.g. query parameters), standard in contains the request headers and body. You can provide headers and response body via standard out.
RAM and CPU usage when your site has no traffic = 0. Running a bunch of this kind of site on a single web server becomes extremely economical. (In the sense that disposable cutlery and 99 cent cheeseburgers are economical.)
This side of 1999, it's worth it to have a few tens of megabytes of application code resident in ram to shortcut start up times. Instead of having each page start its own process, multi-threaded apps running on highly parallel hardware allows you to share effort between requests without bothering with cache coordination (or waiting on round-trips to the cache service). The benefit of faster page loads (higher conversion rates, happier readers, etc.). Since the age of CGI, moore's law and disintermediation has made these things cost less than a child's allowance.
Just making sure this isn't misinterpreted as saying that people run PHP (or really anything) on the old, traditional CGI model that forks a new process for each invocation of a script.
Most php installations are either mod_php, running within the Apache process itself, or via fastcgi.
In either case, the processes are pre-started and pooled.
The distinction isn't as big as proponents like to make it seem.
FastCGI still acts like CGI, the app has to boot itself up every page -- just not the process handling the request (the interpreter, etc.) Thus opcode caches to be able to skip compiler steps.
If Wordpress or Drupal, for instance, could boot up to the point just before they start doing anything dependent on values pulled from the request, then prefork and wait for incoming requests in that warm ready state, that would be more on par with modern application runtimes.
I see what you mean, but there's more to it. The same issues exist for every other script language that's been around a while. They all targeted CGI, because it was what was available to the masses.
The opcode cache, for example, isn't much different than python's pyc files, just shared memory based.
And, yes, some code gets re-interpreted that wouldn't have to. But, there are optimizations, like database connections that persist across requests. There's also a popular pattern of saving costly work that can be cached in shared memory (apcu, for example). So "the app has to boot itself up" isn't as terrible as it seems.
Agreed, it's not the end of the world. The biggest headache I get from CGI-style app runtimes is that most do not allow me to open and use a database transaction across multiple requests. They tend to be designed around the assumption that database connections are stateless that keeping one open is only effecting a sort of cache.
If it's not clear why I'd want this, it can be nice for integration testing (each test happens inside a transaction, aborts the transaction to clean up after itself) and you can extend those transactions as a feature to your user interface, let users start a transaction begin making changes, interact with the domain model inside their transaction but still let them confirm or revert the set of changes, or in the typical usage where an exception of some kind reverts the transaction, but where the exception and the changes that the exception should cause to be aborted might occur in different requests.
CGI is not unique to PHP and is available for most interpreted languages. In Python I can wrap any WSGI app in CGIHandler from Python's stdlib and it just works.
NodeJS and Java as hipster languages? I think there is a lot of enterprise effort put into those VMs to make the code execution fast behind those "languages", more like programming environments. PHP does not have any advantage over Java or even NodeJS as far as language syntax goes, but it offers less in terms of instrumentation and other much needed features of making production ready code.
Scalable but slow. CGI model of execution and everything being synchronous throws away too much effort that could have been shared between requests or spread across CPU cores.
Best case scenario, you have to tie your app in knots and come up with arcane cache keying/invalidation strategies to be able to cache exactly the right things, then you still have to make multiple round-trips to a cache service per page (unless every page is identical or every page is entirely unique), and PHP just twiddles its thumbs waiting on the network for each one, one after the other.
"Scale" doesn't mean being able to run many applications on a server - it means being able to serve a lot of traffic. Dynamic languages are inherently slower and one thread per request server models tend to perform poorly once they hit a certain concurrency threshold because the cost of creating/destroying and context switching between threads becomes pretty high. The reason people talk about node being performant is because it uses a small number of threads with event driven approaches (well, one thread in Javascript itself.)
You'll see a lot of the modern approaches use event driven approaches (Typesafe/Play/Akka/Scala, node, nginx etc) because they handle high levels of concurrency much better than one-thread-per-request models of yester-year. The issue isn't so much one thread per request models as much as it is waiting around for database access etc. Once threads are parked and sleeping, performance will really suffer at scale.
Any use case where you have to read from remote datastores will like topple over pretty quickly or else be very expensive to scale if you're using PHP. The blocking thread-per-request model really doesn't scale very well.
This makes sense, but isn't really about PHP at all. You're comparing node.js, with it's built-in event driven web server to ANY language running in a fastcgi or mod_xxx fashion. Python, perl, etc, running under fastcgi would all have the same downsides you are citing.
You can, for example, use Facebook's HHVM+Proxygen to serve up event driven PHP. That would be a more direct comparison to node.
Back in university, I used to run a porn site on one of these free Apache based 'Unlimited' hosting.
Needlessly to say, I have to agree with you, it did do a quite a bit of traffic: 250gb but began to struggle once the concurrency reached past 40 users.
I remember logged into ssh, monitoring when the site would go down so I could restart the Apache server (wasn't aware of upstart and other techniques back then all I knew was how to jack nulled PHP scripts, upload it on free hosting, and spam forums to get people to jerk off to Japanese porno tube.
Nevertheless, I made small monthly income to pay for cigarettes and food through university thanks to Apache and cheap cheap 'Unlimited' hosting.
I eventually bought a huge $100/month server back in 2009 and that's when things started going south ad revenues started to fall for the adult industry.
Off topic a bit, but it's interesting to hear your perspective on this. Everyone always says "Porn is 90% of the internet" but you never seem to hear from the developers who actually run the sites. Is it shame from being associated with something that people may find "immoral" that keeps these devs quiet?
I would really be curious to hear more about developers who work in this field, especially for the big -tube sites.
haha sure I can throw my 2 cents in here. I don't think they are ashamed but they hang out at places like gfy.com, a cesspool of adult site owners and affiliate marketers, who ironically are hostile towards tube sites as 'stealing content'.
Then one spring afternoon in 2008, I was pondering what I'm going to do for money while sitting around campus then it just hit me that the fastest way to get traffic therefore more money was porn.
I did have some qualms particularly because it felt like I was doing something...that might be looked down upon but then I thought it was pretty fucking stupid since I'm not the one making porn (although I did think about this too) so I felt like this was a good way to learn PHP&MySQL(lol) so I went for it.
And it paid dividends throughout university.
I heard a local guy who founded youjizz.com pulling in $100,000+ CAD /month from webcam ads but this was 2008. I think the advertisement have declined significantly since then and I've moved on to more meaningful problems to solve rather than dealing with the intracicies of delivering smut to the end user on budget web hosting.
I don't know if it's worth it to make porn sites anymore. There's large tube sites that just dominate the traffic.
I consider my own tube porn site to be a failure for not reaching that level of status. But boy did I spend a lot of time getting it all up and running. Equally more innovative was the spamming tools I wrote for forums and watermarking porn videos automatically via ffmpeg and uploading it to multiple websites. Actually ended up spinning off a SaaS business from that script.
If I had to pick the least hipster language I could think of it would be Java. Stable, favored by big slow organizations, old enough to be uncool, but not old enough to be retro. Definitely the anti-hipster language.
People, maybe not you or OA, have learned how to "scale" every commonly used web dev language.
Your error with that, not usiing the common definition of scale, and balls ludicrous assertion that the most, big E Enterprisey language is hipster obliterates your credibility on the subject.
So the whole point is shared hosting ? Use https://www.webfaction.com/?aid=9281 (affiliate link so I don't pay for my own account), it is best-host in the world and also does your django,nodejs,rials,postgis,redis,whatever stuff.
I've been really liking PHP lately. PHP 7 has awesome new features and performance improvements. Of course, PHP isn't right for every application, but I feel like PHP needs to be taken more seriously, compared to Ruby and Python, for large-scale applications, and fast-response web services.
It's hard to break an old stigma.. but.. PHP7 is NOTHING like PHP4, and a LOT better than PHP5.x.
This may very well be true (I haven't written PHP since the era of 4/5-beta), but it's probably going to be a lot like Java in the sense that the older devs scarred from Java 1.0 - 1.5 basically want nothing to do with it anymore and rant and rave about the language despite the language and ecosystem evolving considerably.
Agree. PHP 7 is indeed a pretty decent language. At the same time, it's worth checking out the Hacklang[1], which looks even more interesting than PHP 7. I wonder how many people tried Hack on production.
>PHP 7 has awesome new features and performance improvements
"Awesome new features" does not make up for the rotten core that remains. It never will. So please, don't be fooled by the additions to the language (Which by the way has a history of being poorly built and does not fit well with the rest of the language).
So Php 7 is still Php and all it implies. A language that no one should be unfortunate enough to use in 2016. Case in point [1].
We have some scripts in PHP and yes, PHP 7 is a big step forward. In some ways it's more advanced than C# in terms of language features. It's still ugly but you can do very interesting things with it.
There's still so much nonsense that you don't have to worry about in other languages. PHP still has, for example, php.ini, errors (not to be confused with exceptions), a messy standard library with no coherent naming system or organisation, obvious feature gaps, inconsistent and unintuitive behaviour in many places, outright bugs that have been documented but never fixed, etc.
Nonetheless, things are improving bit by bit. PHP has come a long way.
Is the point of this article is that hosting non-php sites is too expensive or difficult? That really isn't true.
If you just need to get a LAMP stack there's thousands of inexpensive options. If you want to something free and scalable like heroku, openshift would work.
Heroku's free tier seems to be built for hobby or small scale projects.
All it requires is that your application not receive traffic for at least 6 hours per day and have less than 10,000 rows in the database.
Granted it is easy to go past these limits, but it is also very easy not to. Lots of school projects have no need for this. Most hobby sites really don't need to be up 24/7. Generally, if you aren't making money from it, you have to question: does it need to be live 100% of the time? If not, then Heroku is great and you pay $0.
You can do the same for even less money and with any language - $5/mo digitalocean box and a quick hack ansible script to deploy. Maybe if you really don't understand the ops side of things you won't like even writing a little ansible script, but heck, I'd do it just to save $14/mo over this guy's scheme. I think understanding the ops side of things on your own small scale sites is quite useful sometimes though.
Exactly, I think DigitalOcean is a great and unexpensive option here. The thing is, you really don't need a whole box for each of your small projects, most likely you will be able to have a few in one box, specially in the beginning with not much traffic.
So, start small and then move onto bigger things if things look promising. Use something like Dokku for easy deployment if Ansible or others are too much work. Every little bit will help when you do need to scale.
What about firewall config? What about installing SSL certs? What about subdomains? What about queue workers? Cron jobs?
The whole point of the article is that those items are completely beyond many devs. Yes, you could learn to do it yourself, but its just so much easier to get started with a service like Forge.
There are tons of runbooks in DigitalOcean's community, or Webfaction's or whatever else that guide you step by step on how to configure things.
It's a matter of choice, you can spend some extra money and have those things handled for you or you can save it and do it yourself (perhaps just once if you use some config management tool to save your settings).
P.S. It's also worth asking oneself, are these things really required for my small, personal projects? Perhaps they aren't and you can save yourself both time and money.
I don't know, maybe I'm not representative of most developers as I do devops for my side businesses, but I feel like I don't understand a technology well enough until I can handle both the development and the ops side and the ops side often feels like a prerequisite for properly handling the dev side.
Why wouldn't PHP be enough? It solves problems, you can make money with it, what more do you want?
I use Ruby, and I see zero reason to venture outside of my domain. I can happily keep using and learning and diving deep into Ruby for the rest of my career. I used to worry that I'd eventually become obsolete, but languages do not really go away. People still make fine livings coding in Fortran.
If I want to scratch an itch, I'll start a side project. Then again, I use Ruby because I love it, so my side projects tend to also use Ruby.
Also, programming languages are not tools. The tools are the programs written in the language. The language is just the human interface layer. Why people get emotional about this I have no idea. (three downvotes in 1 minute on GP)
With a programming language, you custom-build a tool for every nail-like object you have to drive into wood-like material.
Because you only have a hammer, what do you expect?
> Also, programming languages are not tools
That is obviously not true. If I want to write a decision engine then Prolog is a good tool for that, if I want to write a high volume web-api then Go or Erlang is a good tool for that, if I want to write a kernel module then C is a good tool for that. And so on.
Saying that all objects are nail-like and all materials are wood-like is, at least in my world, quite crazy.
> Because you only have a hammer, what do you expect?
That's right. But it's not that I have a hammer. I am the hammer. Ruby is an extension of my mind, just like how a fencer's sword becomes an extension of his arm.
Why in the world would a champion fencer stop spending 10+ hours a day practicing his art and start picking up axe throwing? Doesn't make any sense. It's not something you would do by choice.
I used to think that devs who bounced around languages and tech stacks were getting more well-rounded. Now I believe they are cheating themselves out of mastery.
> That is obviously not true. If I want to write a decision engine then Prolog is a good tool for that, if I want to write a high volume web-api then Go or Erlang is a good tool for that, if I want to write a kernel module then C is a good tool for that. And so on.
That's ridiculous. I can write a decision engine in Ruby. I can write a high-volume web-API using Rails. You can even write a kernel module with Ruby:
> BTW that link to "a kernel module wrote in Ruby" is pretty much all C with a few lines of Ruby on top.
Did you just look at the language stats? That project implements Ruby using mruby in a kernel module. Of course it's written in C, Ruby is written in C. The few bits of Ruby are just a hello world example.
If you are programmer, you should always learn something new. If you stop learning new things, soon you'll be a bad programmer - you will be just outside of the current scope of technologies.
Never said I stopped learning. I learn new things all the time. I just don't waste time trying to pick up new languages. I read about the features of other languages all the time and I try to glean insights to use in my Ruby code.
But people really underestimate how deep topics like object orientation really are. If you burn all this time figuring out syntax, semantics, standard libraries, toolsets, et al of languages, then you won't have the time or the head space to dive deep into them.
Different languages will allow you to have different points of view for problems solving. It's better to know about different but right tools for each job, than know how to use one tool everywhere (often with hacks and limitations).
> Different languages will allow you to have different points of view for problems solving.
You don't need to actually know different languages in order to get this benefit. For example, I know how to code in a functional style in Ruby and gain the benefits. I know how to use design patterns in Ruby.
A lot of times, I find concepts in other languages that amount to hacks. Haskell's monad concept, for instance, once I understood what was going on, I now feel is mostly used to hack state into a language that was designed to eschew it.
> It's better to know about different but right tools for each job, than know how to use one tool everywhere (often with hacks and limitations).
I disagree. I want to use the tool I know like the back of my hand. I want to keep the number of things I have to learn for each new objective to a minimum. If you call on me to solve a new problem in a new language, I'm liable to ask you to just call a specialist. I am a professional, not someone you can just boss around.
If Heroku is amazing but too expensive, what about Google App Engine? As an under-utilised Google service there is the risk of it being shut down, but aside from that, it delivers on the PaaS promise quite well. The free tier is generous and works on a per-app basis.
> The free tier is generous and works on a per-app basi
The RDBMS isn't part of the free tier AFAIK. The free tier has an horrible datastore and some weird limitations. You can't even do external http requests with your own libs you have to use some stuff provided by Google, and it rewrites incoming request headers.
Nobody is using AppEngine because it is not a good service, even for free. I'm not talking about the latest "google cloud" PaaS which is a very different service.
If you're just looking for a cheap platform for personal projects, why not Google App Engine? You can spin up a dozen free low-traffic projects without trouble, and if you have at least one Real project getting billed you can get more. Hell, you can even use PHP.
However, ultimately, you get what you pay for. Sure, you can get a cheap VPS that you manage yourself, and will die when the hardware it's on craps out. Or you can go with a managed service that handles failover, replication, backups, etc for you. Somebody ultimately has to get paid for all that work. It's amazing that Heroku, GAE, et all are as cheap as they are.
Self-hosting is cheap only if you do not value your time.
Google App Engine is extremely unstable, I have a few 5-year old bugs that are still not fixed. And these bugs are really critical like not functioning backup/restore. And I'm not a fat enterprise customer so there are no chances they will be fixed.
I'm a PHP advocate, although I've found Django easy to get up and running for personal web projects. I mostly enjoyed the out of the box admin panel :)
I'm not against PHP but that statement is flat out wrong. To me it seems a lot of PHP frameworks are building on the frameworks that came before them in other languages like Rails, Django, et al which is a good thing.
> Laravel Forge is a service that for $9 a month they will provision unlimited production ready php servers (install, setup and configure) and you can control it all from a web interface.
So, perhaps I'm missing something here, but how is this economically viable for Lavarel?
You didn't finish reading the article. The $9 gets you unlimited setup/configuration/management of servers and projects. You separately pay for the servers at your host of choice. His example is the $9 at Laravel Forge + $10 server at Linode. The $9 is a convenience package for managing things, not including the cost of hosting itself.
Of course if your load is small, you can host multiple projects on a single server. So you don't need to pay for a $10 Linode per project, unlike what people do with Heroku where you pay the full hosting cost per project.
They don't handle the hosting, just the provisioning. I assume it's almost entirely automated until they're adding new features or one of the supported hosts breaks something.
PHP has batteries included. For almost everything you can imagine doing, from image manipulation to send e-mail, there is some (poorly conceived) API.
And, coupled to Apache MPM or equivalent, it offers a very simple model of development with good scalability. A PHP script can work top-to-bottom, as if it were the only thing in the Web server, and MPM will run that script in any number of parallel instances. Many, many developers can't grasp more complex models e.g. Node.js asynchronous. So there is impedance match between some average programmer with a good idea to implement, and the tool.
Given these factors, people start some prototype in PHP, and one day the prototype becomes a major product, and rewriting it is prohibitively expensive.
> The problem with Heroku is their pricing model and while $7 doesn't look like a lot it rockets when you have several projects. Just having 10 applications make the cost go up to $70 which is already too much to put down each month for something that might as well not pan out to anything.
Couldn't you have one Heroku app instance that runs multiple PHP apps?
You could buy multiple domain names through Godaddy or such and just set them to forward with masking to various URLs of your heroku app. I don't see why this wouldn't work.
If you program for a living and you worry about hosting costs for small projects, you are misjudging your opportunity cost. You are valuing yourself way too low.
You're going to pour $5000 or $10000 worth of your time into a project, but then balk at spending $100 to host it long enough to see if it grows. Makes no sense.
And if you are cash poor, you're much better off spending some of that project time getting paid, and you'll soon be able to afford as much hosting as you want.
This is kind of the point I am trying to make. Laravel Forge is selling me that time I would spend on configuration for a fraction of the price of other services.
But yes, I agree with you, kind of. But my websites are never probably going to have a lot of visitors. I want to build up a network of sites that all give me a small amount of income. Perhaps in the future it will give me more income and then I could spend it more wisely.
The point I understood from your article makes is that the few dollars you are saving over having another language stack (Java/Python/etc) makes using PHP over them worth it.
Which, as people here mentioned, shouldn't really be your main consideration. If you wanna keep programming in PHP that's perfectly fine, but all in all the minor price difference between stack hosting prices is a poor excuse to justify it.
It also depends on the situation. He's said that he's looking for several small sites to provide extra income meaning that he's looking at it from a cash-flow perspective. From a cash flow perspective, hosting cost definitely is a factor.
This is the specific type of situation that PHP is almost ideal for because it scales down better than most other languages since everything is loaded and processed on-request instead of booting up to preload. You can host 1,000 PHP sites on a single small server as long as the concurrent traffic doesn't outstrip the specs. With most other languages that have to boot and preload, you're restricted before traffic becomes a consideration.
PHP's not the right choice for every situation but for his use case it's pretty solid.
Also, if you can use some other technology and then only pour 2000$ worth of your time into it, but have to spend 100$ more to host it, you're still winning. It's easy to shut something down and stop "losing" money, much harder (impossible) to get back the time spent on developing it.
Essentially, your most valuable asset is your time. Optimize for time, not for money. Your time is worth much more.
I don't agree with these kinds of assessments which assume that you can always exchange money for your time. Let's suppose, I am bootstrapping something with X months of personal runway left.
If I can exchange my "so-much-worthy" hours for money, I'll certainly do so and use it on my product but I don't think it is as easy as the calculations assume it to be because finding short-term-high-paying-gigs is not trivial. Instead of investing personal wealth, it feels more comfortable to just try cutting corners without impeding productivity significantly and in many cases, is not that as bad as presumed.
The time investment is one time. Hosting cost is recurring.
I might be able to invest two months in a developing a project. But if it's not making any profit, I might still be hosting it for 5 to 10 years. Then it's a difference of $600 vs $12,000 depending on which solution I choose.
Hijacking a bit of the thread. Does anyone know of a price sensitive ASP.NET setup?
I would love to use ASP.NET for hobby projects, but it really is quite prohibitive price-wise compared to almost every other web setup.
Hopefully prices will go down with ASP.NET 5 being able to run on OS X and Linux, but as of right now I haven't really found any cheap alternatives to Azure to run ASP.NET on.
Less than $10 a month on their lower priced plans; although over the years I have beefed up my machine. I use it for ColdFusion apps/sites primarily, however there is no reason why .NET wouldn't work.
So the OP says hosting is expensive and in the same time pays for provisioning service + the hosting service.
That's sad. I wrote my `git deploy` server-provisioning script with ansible [1] for a weekend. Using DigitalOcean's API you can make a deployable server in your bootstrapping phase ( like running yo [2] ). I'm using this script since an year and so far it saved me 120$, I guess.
What I don't have here is support for scaling, but anyway I hope one day I would need to scale my hobby-project to a point that I can see the difference between 1 and 4 VPS. Also keep in mind that PHP is a bit slower than the alternatives these days - NodeJS, Go ...
Dokku or dokku alt on digital ocean... A $40 VPS can handle quite a bit of load... there's not much in terms of scaling, or redundancy, but as a starting point, with similar cognitive overhead, it's a nice starting point and value... Once you need more, you can worry about it when you need it.
105 comments
[ 1.5 ms ] story [ 150 ms ] threadPeople have figured out how to build dead cheap mass hosting in PHP.
You can support next to infinite numbers of small projects on a single apache+mod_php server - as long as they don't get many visitors you're fine.
NodeJS, Java or other hipster languages will require one instance of a runtime for each project that runs.
Also, the problems of how to host and develop PHP project have been solved - for a hoster it's usually enough to tell people "here's your ftp, here's your mysql access data, have fun". No other environment (except static HTML of course) comes anywhere close to that.
But PHP requires very little configuration on cheap hosting. At most, tweaking an HTACCESS file. The only competition in this space is Python (Django,Flask and co work with mod_wsgi).
Cheap PHP hosting providers are basically PaaS (Apache,PHP,Mysql...) which is a good thing and a bad thing ( no flexibility, stuck with a PHP version).
Good luck running Rails or Spring on cheap shared servers.
On a $2 PHP/Python shared host I can virtually host as many apps as I want.
Because of memory requirements upfront, I can't do that with Rails, or Spring. Because most mass shared hosting providers do no allow long running processes even NodeJS is out of question.
A binary or script gets called with environment variables providing info about the request (e.g. query parameters), standard in contains the request headers and body. You can provide headers and response body via standard out.
RAM and CPU usage when your site has no traffic = 0. Running a bunch of this kind of site on a single web server becomes extremely economical. (In the sense that disposable cutlery and 99 cent cheeseburgers are economical.)
This side of 1999, it's worth it to have a few tens of megabytes of application code resident in ram to shortcut start up times. Instead of having each page start its own process, multi-threaded apps running on highly parallel hardware allows you to share effort between requests without bothering with cache coordination (or waiting on round-trips to the cache service). The benefit of faster page loads (higher conversion rates, happier readers, etc.). Since the age of CGI, moore's law and disintermediation has made these things cost less than a child's allowance.
Most php installations are either mod_php, running within the Apache process itself, or via fastcgi.
In either case, the processes are pre-started and pooled.
FastCGI still acts like CGI, the app has to boot itself up every page -- just not the process handling the request (the interpreter, etc.) Thus opcode caches to be able to skip compiler steps.
If Wordpress or Drupal, for instance, could boot up to the point just before they start doing anything dependent on values pulled from the request, then prefork and wait for incoming requests in that warm ready state, that would be more on par with modern application runtimes.
The opcode cache, for example, isn't much different than python's pyc files, just shared memory based.
And, yes, some code gets re-interpreted that wouldn't have to. But, there are optimizations, like database connections that persist across requests. There's also a popular pattern of saving costly work that can be cached in shared memory (apcu, for example). So "the app has to boot itself up" isn't as terrible as it seems.
If it's not clear why I'd want this, it can be nice for integration testing (each test happens inside a transaction, aborts the transaction to clean up after itself) and you can extend those transactions as a feature to your user interface, let users start a transaction begin making changes, interact with the domain model inside their transaction but still let them confirm or revert the set of changes, or in the typical usage where an exception of some kind reverts the transaction, but where the exception and the changes that the exception should cause to be aborted might occur in different requests.
Best case scenario, you have to tie your app in knots and come up with arcane cache keying/invalidation strategies to be able to cache exactly the right things, then you still have to make multiple round-trips to a cache service per page (unless every page is identical or every page is entirely unique), and PHP just twiddles its thumbs waiting on the network for each one, one after the other.
I mean, I get that there's no money in it for Oracle, so it's certainly not a priority for them, but still, it should work.
You'll see a lot of the modern approaches use event driven approaches (Typesafe/Play/Akka/Scala, node, nginx etc) because they handle high levels of concurrency much better than one-thread-per-request models of yester-year. The issue isn't so much one thread per request models as much as it is waiting around for database access etc. Once threads are parked and sleeping, performance will really suffer at scale.
Any use case where you have to read from remote datastores will like topple over pretty quickly or else be very expensive to scale if you're using PHP. The blocking thread-per-request model really doesn't scale very well.
You can, for example, use Facebook's HHVM+Proxygen to serve up event driven PHP. That would be a more direct comparison to node.
Needlessly to say, I have to agree with you, it did do a quite a bit of traffic: 250gb but began to struggle once the concurrency reached past 40 users.
I remember logged into ssh, monitoring when the site would go down so I could restart the Apache server (wasn't aware of upstart and other techniques back then all I knew was how to jack nulled PHP scripts, upload it on free hosting, and spam forums to get people to jerk off to Japanese porno tube.
Nevertheless, I made small monthly income to pay for cigarettes and food through university thanks to Apache and cheap cheap 'Unlimited' hosting.
I eventually bought a huge $100/month server back in 2009 and that's when things started going south ad revenues started to fall for the adult industry.
I would really be curious to hear more about developers who work in this field, especially for the big -tube sites.
Then one spring afternoon in 2008, I was pondering what I'm going to do for money while sitting around campus then it just hit me that the fastest way to get traffic therefore more money was porn.
I did have some qualms particularly because it felt like I was doing something...that might be looked down upon but then I thought it was pretty fucking stupid since I'm not the one making porn (although I did think about this too) so I felt like this was a good way to learn PHP&MySQL(lol) so I went for it.
And it paid dividends throughout university.
I heard a local guy who founded youjizz.com pulling in $100,000+ CAD /month from webcam ads but this was 2008. I think the advertisement have declined significantly since then and I've moved on to more meaningful problems to solve rather than dealing with the intracicies of delivering smut to the end user on budget web hosting.
I don't know if it's worth it to make porn sites anymore. There's large tube sites that just dominate the traffic.
I consider my own tube porn site to be a failure for not reaching that level of status. But boy did I spend a lot of time getting it all up and running. Equally more innovative was the spamming tools I wrote for forums and watermarking porn videos automatically via ffmpeg and uploading it to multiple websites. Actually ended up spinning off a SaaS business from that script.
If I had to pick the least hipster language I could think of it would be Java. Stable, favored by big slow organizations, old enough to be uncool, but not old enough to be retro. Definitely the anti-hipster language.
Your error with that, not usiing the common definition of scale, and balls ludicrous assertion that the most, big E Enterprisey language is hipster obliterates your credibility on the subject.
It's hard to break an old stigma.. but.. PHP7 is NOTHING like PHP4, and a LOT better than PHP5.x.
The author is totally right about Forge, I have never EVER had a better provisioning experience.
[1] http://hacklang.org/
"Awesome new features" does not make up for the rotten core that remains. It never will. So please, don't be fooled by the additions to the language (Which by the way has a history of being poorly built and does not fit well with the rest of the language).
So Php 7 is still Php and all it implies. A language that no one should be unfortunate enough to use in 2016. Case in point [1].
[1] https://www.reddit.com/r/lolphp/comments/41fqib/it_is_so_sim...
We have DB migrations, model/controller/views scaffolding, simple and powerful routing, etc.
Like..?
Nonetheless, things are improving bit by bit. PHP has come a long way.
If you just need to get a LAMP stack there's thousands of inexpensive options. If you want to something free and scalable like heroku, openshift would work.
All it requires is that your application not receive traffic for at least 6 hours per day and have less than 10,000 rows in the database.
Granted it is easy to go past these limits, but it is also very easy not to. Lots of school projects have no need for this. Most hobby sites really don't need to be up 24/7. Generally, if you aren't making money from it, you have to question: does it need to be live 100% of the time? If not, then Heroku is great and you pay $0.
>'Leaving PHP is too expensive'
seems the opposite in my experience.
So, start small and then move onto bigger things if things look promising. Use something like Dokku for easy deployment if Ansible or others are too much work. Every little bit will help when you do need to scale.
The whole point of the article is that those items are completely beyond many devs. Yes, you could learn to do it yourself, but its just so much easier to get started with a service like Forge.
It's a matter of choice, you can spend some extra money and have those things handled for you or you can save it and do it yourself (perhaps just once if you use some config management tool to save your settings).
P.S. It's also worth asking oneself, are these things really required for my small, personal projects? Perhaps they aren't and you can save yourself both time and money.
I use Ruby, and I see zero reason to venture outside of my domain. I can happily keep using and learning and diving deep into Ruby for the rest of my career. I used to worry that I'd eventually become obsolete, but languages do not really go away. People still make fine livings coding in Fortran.
There is a world outside of code, you know.
If I want to scratch an itch, I'll start a side project. Then again, I use Ruby because I love it, so my side projects tend to also use Ruby.
Also, programming languages are not tools. The tools are the programs written in the language. The language is just the human interface layer. Why people get emotional about this I have no idea. (three downvotes in 1 minute on GP)
With a programming language, you custom-build a tool for every nail-like object you have to drive into wood-like material.
Because you only have a hammer, what do you expect?
> Also, programming languages are not tools
That is obviously not true. If I want to write a decision engine then Prolog is a good tool for that, if I want to write a high volume web-api then Go or Erlang is a good tool for that, if I want to write a kernel module then C is a good tool for that. And so on.
Saying that all objects are nail-like and all materials are wood-like is, at least in my world, quite crazy.
That's right. But it's not that I have a hammer. I am the hammer. Ruby is an extension of my mind, just like how a fencer's sword becomes an extension of his arm.
Why in the world would a champion fencer stop spending 10+ hours a day practicing his art and start picking up axe throwing? Doesn't make any sense. It's not something you would do by choice.
I used to think that devs who bounced around languages and tech stacks were getting more well-rounded. Now I believe they are cheating themselves out of mastery.
> That is obviously not true. If I want to write a decision engine then Prolog is a good tool for that, if I want to write a high volume web-api then Go or Erlang is a good tool for that, if I want to write a kernel module then C is a good tool for that. And so on.
That's ridiculous. I can write a decision engine in Ruby. I can write a high-volume web-API using Rails. You can even write a kernel module with Ruby:
https://github.com/utshina/mruby-lkm
One says such-and-such is good for this, which is right (keyword is good). The other says "I can do this and that with my hammer". Yes, true.
But yeah add the words "not slow as hell" and "maintainable" and one of you is right, the other is delusional.
BTW that link to "a kernel module wrote in Ruby" is pretty much all C with a few lines of Ruby on top.
Did you just look at the language stats? That project implements Ruby using mruby in a kernel module. Of course it's written in C, Ruby is written in C. The few bits of Ruby are just a hello world example.
But people really underestimate how deep topics like object orientation really are. If you burn all this time figuring out syntax, semantics, standard libraries, toolsets, et al of languages, then you won't have the time or the head space to dive deep into them.
You don't need to actually know different languages in order to get this benefit. For example, I know how to code in a functional style in Ruby and gain the benefits. I know how to use design patterns in Ruby.
A lot of times, I find concepts in other languages that amount to hacks. Haskell's monad concept, for instance, once I understood what was going on, I now feel is mostly used to hack state into a language that was designed to eschew it.
> It's better to know about different but right tools for each job, than know how to use one tool everywhere (often with hacks and limitations).
I disagree. I want to use the tool I know like the back of my hand. I want to keep the number of things I have to learn for each new objective to a minimum. If you call on me to solve a new problem in a new language, I'm liable to ask you to just call a specialist. I am a professional, not someone you can just boss around.
The RDBMS isn't part of the free tier AFAIK. The free tier has an horrible datastore and some weird limitations. You can't even do external http requests with your own libs you have to use some stuff provided by Google, and it rewrites incoming request headers.
Nobody is using AppEngine because it is not a good service, even for free. I'm not talking about the latest "google cloud" PaaS which is a very different service.
However, ultimately, you get what you pay for. Sure, you can get a cheap VPS that you manage yourself, and will die when the hardware it's on craps out. Or you can go with a managed service that handles failover, replication, backups, etc for you. Somebody ultimately has to get paid for all that work. It's amazing that Heroku, GAE, et all are as cheap as they are.
Self-hosting is cheap only if you do not value your time.
If I could, I would gladly replace my code base with Python.
Edit: It's pretty telling about the HN community when I simply post an honest opinion about my coding practices, and I am down voted into oblivion.
How are we ever going to actually progress when we can't even talk about things openly and honestly without getting the equivalent of shouted down.
Your feelings may be hurt, but I'm still not going to use Django until it improves.
So, perhaps I'm missing something here, but how is this economically viable for Lavarel?
Of course if your load is small, you can host multiple projects on a single server. So you don't need to pay for a $10 Linode per project, unlike what people do with Heroku where you pay the full hosting cost per project.
And, coupled to Apache MPM or equivalent, it offers a very simple model of development with good scalability. A PHP script can work top-to-bottom, as if it were the only thing in the Web server, and MPM will run that script in any number of parallel instances. Many, many developers can't grasp more complex models e.g. Node.js asynchronous. So there is impedance match between some average programmer with a good idea to implement, and the tool.
Given these factors, people start some prototype in PHP, and one day the prototype becomes a major product, and rewriting it is prohibitively expensive.
My favorite example of this: http://php.net/manual/en/function.gzgetss.php
It tickles me seven shades of pink that this function is built into the language.
Couldn't you have one Heroku app instance that runs multiple PHP apps?
From all I know, you need to pay $7 per app.
You're going to pour $5000 or $10000 worth of your time into a project, but then balk at spending $100 to host it long enough to see if it grows. Makes no sense.
And if you are cash poor, you're much better off spending some of that project time getting paid, and you'll soon be able to afford as much hosting as you want.
But yes, I agree with you, kind of. But my websites are never probably going to have a lot of visitors. I want to build up a network of sites that all give me a small amount of income. Perhaps in the future it will give me more income and then I could spend it more wisely.
Which, as people here mentioned, shouldn't really be your main consideration. If you wanna keep programming in PHP that's perfectly fine, but all in all the minor price difference between stack hosting prices is a poor excuse to justify it.
Yes of course, I agree that it shouldn't be my main consideration. I will think about it, since I really want to switch programming language.
This is the specific type of situation that PHP is almost ideal for because it scales down better than most other languages since everything is loaded and processed on-request instead of booting up to preload. You can host 1,000 PHP sites on a single small server as long as the concurrent traffic doesn't outstrip the specs. With most other languages that have to boot and preload, you're restricted before traffic becomes a consideration.
PHP's not the right choice for every situation but for his use case it's pretty solid.
Essentially, your most valuable asset is your time. Optimize for time, not for money. Your time is worth much more.
If I can exchange my "so-much-worthy" hours for money, I'll certainly do so and use it on my product but I don't think it is as easy as the calculations assume it to be because finding short-term-high-paying-gigs is not trivial. Instead of investing personal wealth, it feels more comfortable to just try cutting corners without impeding productivity significantly and in many cases, is not that as bad as presumed.
I might be able to invest two months in a developing a project. But if it's not making any profit, I might still be hosting it for 5 to 10 years. Then it's a difference of $600 vs $12,000 depending on which solution I choose.
Thats a significant difference.
You can use a $20 per YEAR vps and get really decent performance with nginx + php7
I would love to use ASP.NET for hobby projects, but it really is quite prohibitive price-wise compared to almost every other web setup.
Hopefully prices will go down with ASP.NET 5 being able to run on OS X and Linux, but as of right now I haven't really found any cheap alternatives to Azure to run ASP.NET on.
https://www.accuwebhosting.com/vps-hosting/windows-vps-hosti...
Less than $10 a month on their lower priced plans; although over the years I have beefed up my machine. I use it for ColdFusion apps/sites primarily, however there is no reason why .NET wouldn't work.
That's sad. I wrote my `git deploy` server-provisioning script with ansible [1] for a weekend. Using DigitalOcean's API you can make a deployable server in your bootstrapping phase ( like running yo [2] ). I'm using this script since an year and so far it saved me 120$, I guess.
What I don't have here is support for scaling, but anyway I hope one day I would need to scale my hobby-project to a point that I can see the difference between 1 and 4 VPS. Also keep in mind that PHP is a bit slower than the alternatives these days - NodeJS, Go ...
Hmm...
[1] https://www.ansible.com/ [2] http://yeoman.io/generators/
(posted same comment on-site)