If you are just starting out as a web developer and aren't planning on changing careers anytime soon, the #1 language you should learn is JavaScript. It, or languages that compile to it, will still be in fashion in 5 or even 10 years. That's because the web is shifting to thick clients, and JavaScript is the only choice in browsers. JavaScript is also finding its way into server-side code (Node.js).
"I think PHP is the perfect language for beginning web development for two reasons: Direct HTML embedding."
Server-side view rendering is on its way out. So this is not a real advantage.
"I find it more than a little strange that PHP is simultaneously (a) out of fashion, and yet (b) absolutely everywhere."
This is simply how technologies rise and fall. By the time a technology is ubiquitous, the original problems it solved have changed and new solutions are being created. Just because you have a bunch of legacy code running lots of web apps doesn't mean it's the future--it means it's the past.
Also, why pick a language that pays poorly? Ruby is by no means inferior to PHP, and you will get paid more per hour to program in Ruby.
The seductive advantage of server side rendering is centralized control of what all clients see. Whenever you push too much business logic down to the clients you have to contend with how to ensure all of those clients are using the same logic at all times.
This is just a result of loose architecture. If your models are cleanly abstracted using REST principles on the server-side, then server templating becomes much more appealing.
I say this because I am doing it -- building apps with REST interfaces on the server side. It's not a common pattern yet but I think this is where things will actually go (as opposed to the client), because it's actually easier to use, understand and iterate on.
If you can write Javascript templates that interface with your back-end using REST calls like "GET /accounts", you can do the exact same thing in a server side template with better performance and dramatically simpler security.
Exactly. Correspondingly, my hope (along with one of the folks below) is that advances in hardware will obliterate any speed difference and enable the back end to be king.
I'm not convinced that it will fade, especially given the rise of mobile devices (as the gentlemen has already pointed out) and what I expect will be a marked improvement in browsers in the coming years (Google Chrome/V8 is a good example). The rise of JS libraries that enable you to use models and persistence in the front end make a lot of people really question why going to the server side and asking for a view is always necessary. Still necessary sometimes, absolutely. But better to go to the server side only when necessary.
there is a place for both. There are certain things that make sense for server side rendering. If I have a blog, why render it on client side, its evergreen content... makes sense for the server to deliver the static content. For web apps, there is a lot of value to client side rendering.
Well said. RESTfulness will ALWAYS have its place, and blogs are the example par excellence. Even in Node, which prides itself on its async/non-blocking capabilities, there are all kinds of ways to incorporate REST.
Twitter is a web site, not a web app. First-page load performance is critical for them. I wouldn't have chosen a client-side rendering architecture.
My perspective is that of web apps. By using client-side rendering I can prefetch more data than the user needs at almost no extra cost, and render it when they click without hitting the server. Not having to contact the server at all beats any server-side rendering architecture. Even web apps that supposedly do server-side rendering will end up with some prefetching for performance (e.g. tooltips and detail panes are already embedded in the page but hidden).
The reality is that the big bottleneck in any web app is not the fetching of data but the fetching of the front-end. The more front-end code (images, js, css) that you can fetch from browser cache or CDN the faster your app. The "ideal" case is not having to fetch anything except the data from the server. You can do that today with client-side rendering combined with far-future expiration or HTML5 appcache. The caveat here is that the performance benefits only start compounding for client-side rendering if you can prefetch data. Twitter couldn't do that, so there was no benefit.
Like any complex technical issue, there is no right answer in general, only a right answer in context. People should just be careful about what they're measuring. The important benchmark is time to load the page, not time to process the page on the server (a huge difference), and measurements should be globally distributed (you should be measuring transcontinental page visits).
History has shown that with time these numbers shrink, there will come a time when the difference is between two very small numbers and that won't be a factor. It almost is. A couple of years. 4G LTE for example.
The issue in this case isn't (primarily) bandwidth, it's latency. Cell connections have terrible latency, universally, and there are a lot of problems to solve before that stops being true.
You could be right about these numbers becoming meaningless. But in the meantime, there is a noticeable difference, and that can mean life or death in the jam-packed web dev market that we see today. If cramming as much application logic as possible into the front side continues to shave off milliseconds or even seconds in some cases, then I think that trend will continue.
That said, I hope you're right. A world in which front vs. back end didn't matter with respect to time would be one in which developers were free to reveal far less on the client side, and that would be a victory indeed!
The Internet is becoming more ubiquitous. Being "on the Internet" will mean less and less being in front of your computer. The proliferation of devices you can access a web app from is increasing (smartphones, tablets, more coming in the future) so it is becoming more useful for web apps to be like a "smart database in the cloud" and for the view logic and code to be on the client.
I'm really not sure why this is being downvoted. It's not trollish. I believe what I'm saying to be true: mobile is increasing, and this is leading to thicker clients and more JavaScript and therefore less server-side view logic. Please correct me if I'm wrong, but downvoting me is confusing.
Thanks for the courtesy of a constructive discussion. :)
Yes, that's a valid point, if you mean that smartphones have less resources (memory, CPU) to handle JavaScript execution. But keep in mind that a native smartphone app is a thick client; it has all of the view logic.
Perhaps I need to back up and explain my point better. Maybe people are misunderstanding me because they think I'm talking about what's going to happen in the next few months. Server-side view rendering is not going anywhere anytime soon. But it's on its way out in that it's an anachronistic way of thinking about the web; it's a relic of the past--of the time of web "pages"--and not of the future, of web "apps" and "resources". As long as you are serving content that's primarily to be "read", like articles, books, blogs, etc., server-side rendering has its place.
But look what's happening to the web. Native iPhone apps have to store their data somewhere, so they communicate to the backend via an API. Cars are reading Twitter. Thinking about the past of the web, only browsers consumed web content. Now non-browsers consume web data via APIs, and I see this trend as increasing.
I see a trend where more web apps will be like a "smart database in the cloud", meaning they hold data and business logic and communicate via JSON APIs. There may be a variety of client devices accessing this data in the cloud: native iPhone apps, desktop browsers, other Internet-enabled devices.
The main point is that clients are no longer only browsers. The clients could be a variety of devices running on a variety of operating systems. So it doesn't make sense for the server to render the view and send it down the pipe for the client to display. It makes more sense for the server to send data to the client and the client to decide how to render it.
I'm not claiming that server-side view rendering will go away completely; it has its place with articles and blogs. But with apps, I see a movement toward thick clients and I don't see this trend slowing down. It's hard for me to envision a world in 10 years with less smart phones, less devices hooked to the Internet, and people only accessing web apps and web app data with browsers.
Let me also put this in context of the article's original point, that PHP has a nice feature of being able to be embedded directly in HTML. Yes, this is nice. But my point is that if you are starting your web career and therefore are looking toward the future, the types of web sites that will use inline PHP will be more like content sites and less like web apps. And I expect a bigger demand, higher pay, and arguably more interesting work for web app creators than web content site creators.
You seem to confuse server side rendering for page based apps, these are unrelated. I can build fully dynamic Ajax pageless applications that are effectively just as snappy as anything you can with client side rendering while keeping all rendering on the server. Rather than sending down json, I'd just send down rendered fragments of HTML and update the contents of some tag.
It's a vastly simpler approach that makes client side code nothing more than update this or that, and works just as well while allowing the traditional server side templates. It's not a relic of the past and it's not on it's way out, nor is it inferior to client side rendering, in fact I think it's better.
> Server-side view rendering is on its way out. So this is not a real advantage.
server side is "on its way out" the way relational databases were "on their way out" when everyone was hysterical about NoSQL 18 months ago. That is, while client side rendering will become much more prominent, server side will remain quite popular as well. Hybrid approaches will likely become the norm.
We've written an app here with 100% client side templates, and while there are some nice patterns that fall out of it, unless you're writing your whole server in javascript as well, you have to give up a lot of conveniences offered by server side templating.
Agreed, it will be hybrid for a long time, but I expect the trend toward view logic being more on the client and less on the server to continue, simply because the web is less and less about "pages" and more and more about "apps" and "resources".
I don't understand this argument. The way I use server side templates is much simpler and more powerful than any demo of client side templating I've seen. I think you're reading a little too much into the hype, otherwise maybe you can share an example of superior Javascript templating patterns because I can't find them.
It depends what you are trying to do. If you are only targeting browsers, and especially if you don't need a lot of responsiveness, it's much simpler to just render views on the server side and optimize your server for speed. It takes a lot of effort to write a thick client.
But if you are targeting a browser and a native iPhone app, the view logic lives on the iPhone app. It used to be that you could just serve up a web page and assume that your client was a browser. Not anymore, and that's my point. And my point is that the trend will continue: I think we will have more variety of non-browser clients in the future, not less. Your car, refrigerator, geranium, etc. will all be hooked up to the web.
Keep in mind that I'm not talking about whether you should create your web app in Backbone.js today, but I'm looking years into the future, anticipating trends.
I think I see what you're talking about: more non-browser clients exist so the web servers need to be able to expose an API. I agree with that.
Besides that, the ability to "template" output on the server is still my ideal way to transform the business API to something the client can read. In the case of a browser, I'm templating for HTML. For a mobile app, we may just pass through in JSON and let the native mobile app handle the views, even output HTML5 for mobile in addition.
In all of these cases, server side templating of output plays a role I think. For browser targeted output, server side templates are still simpler in the implementations I've seen.
I don't think the necessity of writing your app so that it exposes APIs has any correlation to whether or not the traditional web server interface to your app can still serve HTML from the server. It's just as easy to wrap API methods on the server and feed that data into a server side template as it is to call the API from a client side method (well, it's actually much easier, no need to manually futz with the browser URL/history and all that).
It's hard to predict 10 years out, but not too hard to see 5 years ahead. Generally speaking, what's popular now existed in some form 5 years ago.
JavaScript has a monopoly as the only language that runs in browsers. If this were to change, it will take years, not months, for browsers to start supporting another language (or go to a bytecode model). Then it will take more time for developers to start using these new languages and then an ecosystem of tools and libraries to form around this. Then it will take even more time for the "old" language JavaScript to seem obsolete.
JavaScript is currently gaining traction and is the lingua franca of the client-side Internet, which is growing. This is why I predict it will still be strong in 5 years, because it's got a lot of momentum and I only see the trends as increasing (mobile devices are increasing, browsers are becoming even more like operating systems with memory management etc., JavaScript as a language is continually being improved).
We really need a quantum leap in language technology. Currently the Internet technologies have grown organically and because of this, most of what we use to program has been repurposed.
HTML was meant to describe text, now it describes regions of the screen to be repainted as well as the "content" to be repainted.
CSS was meant to add simple effects like bold, italic and simple newspaper-like positioning (float this image left). It's been repurposed to describe visual rendering and even animations.
JavaScript was meant to add some scriptability to the DOM, and now it's morphed into a full-fledged programming language.
So the state of the web is a depressing mishmash of old, repurposed technologies.
It would be nice if there were a programming language that "knew" about the web. It would realize that the programming effort would be shared between two computers, client and server, and would have appropriate security and other conveniences baked in. For example, you should only have to describe your business logic once (as opposed to once on the server and once on the client). Also, this programming language should no longer be tied to the anachronistic concept of rendering a "document" with "styles".
But alas, it's very hard to simply go into an academic tower and design a language and release it into the wild and expect it to catch on. These things tend to grow organically and incrementally. So whatever next step there is has to embrace where we currently are. This is why you see not merely new client-side languages, but new languages that compile to JavaScript. If they didn't compile to JavaScript, how could they ever be used?
Absolutely agreed. I really love JavaScript for a lot of reasons, but it still astonishes me that that our lingua franca was designed in 10 days. In 1995. For NETSCAPE.
I'm not so sure I would describe the mishmash as unambiguously depressing. It's also pretty inspiring seeing people using the mishmash in a sort of bricolage kind of way. One thinks of libraries like Underscore and Backbone that seek to account for some of the "deficiencies" in JS.
And don't even get me started on CoffeeScript.
But I think we would both agree that it's strange that no one has come along attempting to really REALLY break the mold by designing a new browser from the ground up that wasn't tied to JavaScript and the DOM (and maybe not even HTML!).
This is true now, but Dart is also less than a year old. I don't have strong feelings toward Dart either way, but these things have a gestation period. Internet Explorer didn't support JavaScript at first either, and Safari and Chrome didn't exist in 1995. So it really remains to be seen.
I think you're right about a lot of things. Things like Backbone (which I wrote about at http://blog.appfog.com/putting-some-mvc-meat-into-your-app-b...) will make recourse to the back end more and more selective as time goes by. JavaScript is indeed quite a force, and as far as I can tell that will stop only when browsers start reading other languages directly (which is not completely unthinkable, but also not really on the horizon).
My point was not directed so much against JavaScript as against the notion that PHP is simply an anachronism.
There's also nothing stopping you from using lots and lots of front-end JavaScript in a PHP-driven context...
"Ruby is by no means inferior to PHP, and you will get paid more per hour to program in Ruby."
Any decision you make to learn anything based on payback has to factor in what will happen if more people choose to learn something. If more people learn Ruby because it pays better (let's assume that is correct) then supply and demand could equalize and the pay will go down. Right now if pay is high for Ruby it means most likely there is a supply and demand in balance. When that changes so will the pay. The only time I haven't seen this happen is with the rates lawyers charge. And the reason for that has to do more with personal relationships and quality of work.
Right right right. I would add this: Ruby could well be considered "passé" someday (history tells us it necessarily will be), and the Rubyists of the future would really bristle at the suggestion that what they're doing is worth less simply because the market says it is.
The Rails MVC architecture is already past its prime, since it solves the problems of 2004. It's possible that startups may move more toward backend-as-a-service + JavaScript front-end instead of using Rails as their MVP.
In any event, the transition should be slow and I fully expect Ruby to be around for a long time, but people may notice a slow decline in demand for Rails programmers in the next few years compared to other hotter technologies. Sinatra (or some other Ruby framework) may replace Rails as a backend.
I'm a Rails programmer and I don't bristle at the suggestion that market demand changes. I welcome the change and adapt. I don't mind learning new languages.
I think that Sinatra will become increasingly popular within the Ruby community (and financial help from Heroku/Salesforce can't hurt!), but I also think it's interesting that the micro-frameworks inspired by Sinatra (Flask for Python, Express for Node, plus many others), will become the fall-back for more advanced developers because they do a lot less specification and leave a lot more space to the developer.
So I say don't give up on Ruby. And if you insist on Rails-style MVC, there's always Padrino for Sinatra, Tower for Node, etc.
I don't think MediaWiki or Wordpress are good examples of how PHP scales. Those are the two examples of extremely bloated pieces of software that require a lot of hackage to get to scale. I've done deployments of those on mid sized VPS'es and it's always a pain getting it responsive while still able to hold a good number of concurrent connections.
The only way anyone gets Wordpress to scale is to put caching in front of it. But now the heavy lifting is being done by memcache or varnish, not by anything engineered into Wordpress or PHP.
Any sort of scaling is a hack (not always bad). Good luck if you expect to scale to Wikipedia or Wordpress(.com) levels without using external tools such as Memcache and Varnish.
Here's an idea.. If PHP is so bad.. Don't use it. Simple as that. Let the people who want to use it... There's absolutely very minimal things wrong with the language. Everyone's quick to compare it with Python or Rails or something else saying "PHP does this wrong that Python does right" well, if PHP did everything the same way as Python, Rails, or something else, when what makes it different? Who wants to use a language that doesn't have some severe difference?
It's annoying seeing people waste their breath on arguing why PHP is so bad... Especially when many people/companies have proven PHP is good and can be scaled and used on high trafficked sites, yet 90% of the arguments are how it doesn't scale.
Just because you have used Wordpress or built a quit todo app in PHP that took you 5 minutes and that's the extent of your usage with the language, doesn't make OR break the language.
Quit complaining and let PHP users use PHP, and you continue using whatever the language you use is.
PHP has all the beauty of Perl with none of the power.
I think part of the reason folks pillory PHP is their annoyance that people are using it as their first language and may never move beyond it to the better alternatives available.
"Rails" isn't a language, and PHP has fundamental design flaws that those other languages don't have. It's not that it has flaws, it's that it has unavoidable flaws.
It's something I find interesting. PHP "haters" keep pointing at flaws, yet in almost 10years of doing PHP, the only thing that really ever annoyed me is the string and array parameters order...
And I've done a wide range of thing in PHP, including scaling websites to millions of pageviews per day.
PHP might have design flaw, but in the end, they don't matter because they actually don't affect the day to day developer.
And I've tried my hands at Ruby, Python (still use it but more for scripting than web dev), C# (was actually my first language for webdev), and weirdly enough I find that they get in the way more that PHP does when it comes to building websites.
This is how I feel too. PHP to me has been ideal for getting things done, but I suppose those who harshly criticize it are concerned with some obscure purity that has less to do with getting things done than style preference.
Every language has flaws, may not be the same, but they still do... I am sure I can go dig up enough flaws in Python to write an article totalling 960 words on why it's so crappy too... But I am not, because it's dumb to nit pick at one language just because YOU don't like to use it.
Some of the problems with PHP are things that are problematic or irritating to development (e.g. its inconsistent standard library) but other things are actively dangerous to security and correctness. For example, in PHP, '9223372036854775807' == '9223372036854775808' returns true.[1] Now imagine those two strings are hashed passwords.
The overall problem is not with specific flaws of PHP; the problem is that flaws in a language lead to errors in programs written with that language, and when that languages is used to write some kind of web infrastructure, then use of that language by people less than experts (i.e. almost everyone) is harmful to the whole internet. PHP can be used to write useful, scalable, secure web apps in the hands of someone who knows what they're doing, but in the hands of someone who doesn't quite know what they're doing, or who does but is tired enough to miss individual details of their code, it is much more dangerous than other comparable languages.
That is why I discourage the use of PHP if possible.
[1]: https://bugs.php.net/bug.php?id=54547 (Both strings appear numeric, so they are casted to numbers before the comparison, but because they are larger than maxint, they are rounded down. The solution, if you really must use PHP, is to use === instead. The fact that a solution exists does not mitigate my concern.)
Agreed on what you said about writing scalable, secure web apps. No question about it.
But I should say as an aside (and you wouldn't necessarily disagree, I don't think) that these kinds of problems are not exclusive to PHP. JavaScript gets you exactly the same result. And try doing something as simple as 0.2 + 0.1 in JavaScript. Oy vey...
Because in a real application people are checking to see if those lazily match every 3 to 4 lines... Half of this stuff that makes the haters "cry" is unrealistically used things.
I enjoyed PHP. I enjoyed Ruby. If I was to do a complex project that would require a lot of integration with external services, I would want a good OOP language like python or ruby.
There are something PHP does nicely than Ruby does. Visa versa. However in all the PHP apps I have made / used, their structures started out with good intentions and then descended into pure chaos. There isn't a unified package manager for Python and PHP that is widely accepted. Ruby has rubygems and bundler.
Maybe next time when I start building another PHP app with namespacing, I'll behave better and make my designs more decoupled so that components can be removed and added, provided their interfaces match.
If you come from a namespaced language, using PHP namespacing will only make you want to hunt down the PHP devs, point to PHP's namespacing implementation and say "Are you proud of what you've done?!?!?" over and over.
9600+ generally concise words on many, but not all, of the issues with PHP. As a summary, PHP isn't "out of fashion" as much as people are tired of continuously being misled and abused by their language of choice.
That is unfortunately a terrible article. It's probably 33% accurate, 33% the author being confused, and 33% just plain wrong. Continuously trotting it out on every discussion on PHP does everyone a disservice.
"Dozens of new language-specific communities have now entered the fray and brought along their legions of devotees with them, and many of those devotees see PHP as being passé. I even had the following happen to me, and this is absolutely a true story and can be verified by our VP of Operations, Richard Kotulski: I was in an elevator with O’Reilly’s very good “PHP Cookbook” in hand and an older gentleman scoffed at me and said, “PHP? What is this, 1920?” This really, actually happened. I doubt it would’ve have happened if I had had a Python or Ruby book in my hand."
Which... is even odder because some evangelists like to point out that python and ruby are older than PHP, as if that means much.
While I generally agree with the points, many PHP strengths are also weaknesses. For example - "Direct HTML embedding." It's nice and easy, but because it's so easy, it leads to unescaped output, and xss exploits and such.
PHP does let you as productive as you want to be on the web, either with raw PHP or with one of the myriad frameworks. The author's point that no other language gives you that is, I think, another one of PHP's strengths (but yes, is essentially a weakness in the wrong hands as well).
EDIT - have been using PHP since early 1996 - almost since its inception, and have watched the criticism (and occasional hate) ebb and flow over the years. That seems to be the only constant to PHP. :)
PHP is a Web scripting language (which I consider to be very different from a general-purpose programming language or even a scripting language), designed and developed to generate markup.
I have seen a lot of "templating" libraries (Smarty among them) and all they do is mimic the basic syntax of PHP using something else that is not PHP.
I know the theory ("designers don't know how or want to program"), but learning PHP conditional statements or loops is as difficult or simple as any "templating" library that asks you to learn its exotic syntax.
Now, MVC is good and one should avoid blending presentation code with models and controllers, but most MVC frameworks fail when they require you to instantiate a gazillion extra objects, just to render a Web page.
1. The gentleman's comment was indeed quite curious, and I wish that I could have used this info as a comeback. Thanks!
2. Direct HTML embedding could be seen as a weakness, yes, but that all depends on the kind of project. That's why I describe it as a good language for beginners and don't make any claims for or against it beyond that (beyond its demonstrated scalability, which I can only imagine being quite difficult in light of the security and other concerns that you voice).
There's no denying PHP's popular, but that doesn't mean it's the best tool for the job.
Most of the arguments I see against it though are really problems with the programmers using it. "Look at this horrible code I have to put up with! The comments are inane and useless, there's no structure at all, and I'm stuck in a chain of nested if statements 10 layers deep and I have no idea what's going on. PHP sucks!"
As Jeff Atwood said, "sufficiently incompetent coders can write FORTRAN in any language."
"But the converse is also true: sufficiently talented coders can write great applications in terrible languages, too."
PHP wasn't exactly designed… it was formed, like a ball of mud picking up various debris as it grew. It shows, too, especially if you've had the pleasure of working with PHP 4. (I can only imagine what earlier versions were like.) I can't for the life of me think of a language with more brain-dead "reference" semantics. It's just bizarre. Their date functions miraculously manage to be worse than their C counterparts. I could go on and on.
But in the end, using PHP doesn't doom your project to failure any more than using the current flavor of the week guarantees your success. Jeff Atwood, again: "The only conclusion I can draw is that building a compelling application is far more important than choice of language."
So why are we still comparing programming languages instead of writing code?
I think people are comparing apples to oranges. Ruby on Rails is as some have stated, a framework, much like Zend or cake or CodeIgniter.
I think the author is spot on in this post. PHP is not without its warts, but as a programming language for web development, it is scalabe, reliable and robust.
Can you perhaps do things faster or more elegantly in other languages? Sure, but writing good clean code is really in the hands of the developer. I can do everything in python because its written in python doesn't mean that that code is going to be designed well or scale well.
"Scalable" and "reliable", perhaps. "Robust" actually means something, though, and PHP is not it. Its wretched approach to error handling prevents that.
PHP's problem is it's soul. I will make an analogy about this. My analogy will be local, but i will explain it so you can understand.
PHP is my university, Gazi University. It first established in 1926 as a Teacher Training Institute. Nobody knew that there will be a medical school or faculty of fine arts or even a faculty of dentistry. 1926 was the third of our newly established Republic and we needed teachers. So, Teacher Training Institute was born.
Our main campus is very small. Law School or dentistry school is not in the campus. Because, as i said, nobody knew we need them in 1926.
Ruby, C# and many other languages are METU: Middle East Technical University. METU was designed as a university. So, they got a gigantic land in Ankara (capital city of Turkey). They build all their building in there.
Back to the PHP: PHP was born to solve one problem. Just one problem. When they got another problem, they solved it and added the function or implementation in the language. PHP is not designed at desk, it was not "feature-complete" at version 1.0. It's still getting more mature as version numbers increase. For example we get "traits" in 5.4.
PHP is also Windows too (both Microsoft and PHP in a HN comment :) The most un-loved things in this community). Remember the video which a guy installs Windows 1.0 and successfully upgrade it to every version of windows with all his data and programs up to Windows 7? even doom from 1993 works! (http://www.youtube.com/watch?v=vPnehDhGa14) PHP is like Windows. I know the "parameter order inconsistency" problem too. But you can't solve it after this point of time. You just can't. Like windows, every program should work after the upgrade. There are millions of millions PHP sites. after a "apt-get update;apt-get upgrade" they should work.
Back when all you had for choices were Perl, Java, and C++ it was easy to see why PHP got big. However there are issues with starting out on PHP now:
1) It's really only meant for web development.
2) There are other languages now that are simple to learn, flexible (more than just for web apps), and powerful (Python, Ruby, and now even Javascript)
Unless PHP has another major evolution, like its move to OO; (or unless I just missed something else big) I just don't see the point of using it unless you or your company been using it for years already. This article doesn't have any real compelling arguments.
Maybe all of this will change once Facebook releases Hiphop VM AND people actually start using it. To this day, I'm not sure why no one started using Hiphop enmass and why people love using the inefficient eval method. O yeah there's also an issue with PHP and logic dealing with concurrency, in that there isn't a good way to distribute work within an app. Then again I could be completely wrong.
I've been working with PHP since 1996 and rarely see eval being used. I've worked with hundreds of companies training PHP developers, seen inside (and written) some very large codebases handling millions of dollars of transactions, and don't recall seeing eval in any of them.
"it was easy to see why PHP got big"
It's easy to see why it's staying big:
1. cheap shared hosting to get started
2. most hosts offer one-click installation of any sort of application people need on the web (blogs, shopping carts, calendars, social networking, file hosting, etc)
3. 15+ years of knowledge about what works and what doesn't when attempting to scale PHP to large needs.
4. ubiquity which keeps a large pool of reasonably priced talent available, which perpetuates the cycle.
When there's a competitive language that can be placed in a directory as FOO.abc, I can hit it as /FOO.abc and have it execute, with html content type sent by default, it'll have a running jump at dethroning PHP.
The barrier to entry is the lowest out there, but the heights it can scale to are facebook-level and beyond.
> I've been working with PHP since 1996 and rarely see eval being used.
For some reason most of the major frameworks use it, hence their incompatibility with hiphop; then again I could be wrong.
> 1. cheap shared hosting to get started
One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.
> 2. most hosts offer one-click installation of any sort of application people need on the web (blogs, shopping carts, calendars, social networking, file hosting, etc)
With the rise of the cloud hosts and automated config, as well as more automated tools available (e.g. Chef, Puppet), this is a temporary advantage. Deploying on Linode and Heroku and (insert cloud host company) are getting easier and easier.
> 3. 15+ years of knowledge about what works and what doesn't when attempting to scale PHP to large needs.
No argument here. My points only apply for people starting now, and not for PHP vets.
> 4. ubiquity which keeps a large pool of reasonably priced talent available, which perpetuates the cycle.
No argument here either. My points were being made for individual programmers who are just starting out, and not for companies.
Even from the point of a company though, PHP's current lack of flexibility lowers the chance of innovation imo. The other dynamic languages are just as easy to learn and they just offer more than PHP does.
>No argument here. My points only apply for people starting now, and not for PHP vets.
I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that.
>> 1. cheap shared hosting to get started
>One can argue that all of the major languages have access to this. PHP doesn't have an edge in this area.
Really? I think there's far more options for people with 'PHP' in the hosting arena. It's not that you can't use other languages/platforms, but ... competition for hosting basic PHP stuff is massive - not so much for Ruby/Rails, Python, etc. along with all the extra stuff you'd need (community libraries and such) - much more is baked in to PHP hosting than you get with the majority of other platforms. Java in particular is expensive to host anything useful because it's RAM hungry.
re: eval - do you have pointers to examples? I just grepped Zend Framework 1.10, and there was 1 eval, in Serializer/Adapter/PhpCode.php, with a warning that it shouldn't be used.
> I wasn't meaning for people - I meant 'the industry' as a whole (or a large segment) - standing on the shoulders of giants and all that.
Ruby and Python aren't very new. There are giants there as well. If you're going to make that argument, then Java has a bigger advantage.
> I think there's far more options for people with 'PHP' in the hosting arena.
As I've already said, I don't disagree. I just said that this advantage is going away. Personally I'd also rather go for host that's mid-ranged as opposed to hosts that are in the race to the bottom. I don't think paying $10 more a month is exorbitant especially if it buys you a lot of language power and it takes over more sysadmin duties from you.
> re: eval - do you have pointers to examples?
Every major PHP framework uses it. How do I know? To my knowledge you can't use any of them with Facebook's hiphop out of the box. I suspect this is one of the main reason's no one uses hiphop even though it gives you a good deal of performance gains for PHP.
"Every major PHP framework uses it. How do I know? To my knowledge you can't use any of them with Facebook's hiphop out of the box. I suspect this is one of the main reason's no one uses hiphop even though it gives you a good deal of performance gains for PHP."
Zend Framework 1.10 - a fairly high-profile framework - has 1 instance of eval in a component I've never known anyone to use. I suspect hiphop has a few other issues with it, but... even more to the point, I don't think most people think they need hiphop. It's an unknown - it's a compilation step, and adds a couple extra steps of complexity. People can get a lot of performance gains by using Zend Server caching or APC with far less unknowns vs digging in to hiphop.
Additionally, hiphop has had some issues with postgres/pdo, closures, imap and more PHP stuff over the last year or so. It's a nice thing from facebook, but it was written for their own problems, not as a general use tool for everyone. If it can evolve in that direction, the adoption may go up. Until then there's far more well-tested ways to improve your performance of PHP.
>> Maybe all of this will change once Facebook releases Hiphop VM AND people actually start using it.
The argument that PHP doesn't scale is a strawman. To scale anything to the likes of Facebook or Google you have to have serious architecture in place regardless of the language you choose.
I stand corrected. I hadn't thought of it really. But the thought of PHP for non-web kind of makes me cringe even if it's translated into another language by an intermediary. For sanity sake I'm going to assume NO :).
The issue with PHP isn't that you can't make it do a whole bunch of things that are wonderful...
It's why PHP would be the best tool for the job once you have a specific objective in mind.
When you have a specific problem to solve other than 'supported by millions of cheap webhosts' PHP is rarely the best choice.
It's like a swiss army knife, it's highly useful in many situations and a good tool to have in your pocket, but if you know you're going to need to unscrew something you should probably bring a screw driver.
[off-topic] If PHP and Javascript are the only programming languages you know, you really should experiment with at least one or two others. It comes easier than expected. For example, check out http://www.diveintopython.net/toc/index.html. You can't know what you're missing out on until you try something new.
But if you already know PHP and Javascript, why not try branching out a bit instead of learning Python, which is very similar overall? How about a lispy language like Racket, or a statically typed functional language like OCaml, or a 'big' mainstream applications language like Java?
That's the point. Python is similar to php/js (which is why it's easy to pick up), but in contrast to them it is extremely well designed (imho). You suddenly understand how many of the quirks you have to go through every day coding in php/js are in fact artifacts of these two inconsistent poorly designed (imho) languages rather than programming as a whole.
This does not justify chosing PHP for a new project.
There are hundreds of examples that show how bad PHP really is. Why make the choice of using a broken language when there are so many better alternatives?
I strongly believe that using a complex, non consistent and hard to debug language actually slows down development and is even dangerous.
Being "absolutly everywhere" is not an argument. COBOL, PASCAL and FORTRAN used to be everywhere too.
I agree that PHP is good for starting learning web development and for small sample apps, but from experience I really think that large-scale PHP applications are not easy to manage. The codebase becomes disorganized very quickly, and tracking down a piece of code's "hierarchy" (what it inherits from, what methods it has available, etc.) can be a whole new kind of hell. IMO, of course.
You're quite right that the analogy isn't perfect. The point I was trying to make, though, is precisely that PHP development can proceed without any recourse whatsoever to a framework. Jumping straight into web dev without an accompanying framework like Rails or Sinatra is a complete non-starter if you're a Rubyist.
So you're quite right, but I hope you would agree that the Rails/PHP comparison, in spite of its imperfections, is compatible with the point I was trying to make.
Yes, I agree. You make the point a lot better here than in your linked post - i.e. with PHP, you can 'just start'. With Ruby you need to choose a framework, understand enough about how it works, and where things go before you can even start to do "hello world"
I got my start with Ruby web development using ERB in a CGI script. Same with Perl before and Python after. The option to do that has not been taken away.
I'm just mad about the title. The post was about how PHP is quick and dirty for simple stuff. The reason all of the other web frameworks exist is because once you get past the learning curve, you can accomplish a lot in a very short span of time. If anything, they are the powerhouses, not PHP.
PHP has some of the most robust and modern frameworks available today. Symfony draws on the best of almost every modern framework, and leaves a lot of the crap behind.
It depends on how you define powerhouse. Is PHP my favorite language or framework? No. But the use cases I provide show that it's worthy of consideration.
Maybe. I actually like Perl a lot, and there are lots of things you can do with it that you'd never want to use PHP for. The difference is that in the world of web development (and this is the crucial distinction here), Perl has neither the use cases nor the easy uptake nor the development frameworks (Drupal, Joomla, Zend, CodeIgniter, etc.) that PHP has. And so my comment wasn't against Perl tout court.
It's interesting seeing so many people defending PHP by suggesting that because Facebook use it, it's good enough for anyone. From what I understand, Facebook continue to use PHP because it's heavily embedded in all of their systems, and they continue to develop with it despite other languages being more attractive? ( see http://www.quora.com/Why-hasn-t-Facebook-migrated-away-from-... )
> I think PHP is the perfect language for beginning web development for two reasons: "Direct HTML embedding" and "Straightforward file organization"
After thinking about it a bit, it seems that your reasons for suggesting PHP for beginners are about the same as the reasons people gave three decades ago when suggesting BASIC as a language for beginners, namely the norm of having GOTO and global variables everywhere.
Just as GOTO and global variables make it easy for a beginner to easily pick up programming, embedding raw code in your pages and having only one file organization makes it a lot easier to pick up web programming. And yet at the same time, all four are eventually shown to be "considered harmful" - the only ones who advance are those who are willing to abandon the first things they learn while the rest are doomed to mediocrity.
Now don't get me wrong, I don't think PHP or even BASIC is inherently bad (well, they are, but at least they're not MUMPS or Brainfuck). I just don't think teaching bad practices to newbie developers is a good way to promote a language.
"It’s been very interesting beginning my trajectory in web development in 2012... [PHP] might be the best language to use in gaining an understanding of the fundamentals of web development... No web development language outside of PHP grants you the kind of flexibility to both (a) produce genuine functionality from scratch, outside of an MVC framework, and also to (b) work within the bounds of MVC in deeply sophisticated ways if you wish."
I believe you have overstated your case, perhaps due to inexperience with other languages. In particular, claiming that any modern scripting language is inflexible sounds a bit crazy.
I have attempted explaining how to get a WAMP stack running, with EasyPHP, to an absolutely new-to-web-dev indiviual who was curious about creating a chat room. Let me just say that the situation is ten times better now than when I was the same age and was poring, lost, over Bruce Eckel's Thinking In Java trying to do the same thing, which must have been sometime around 1999/2000.
These efforts to teach a newcomer reminded me that there's a lot I take for granted. There is a step where you are saying "okay, we've got to see where Apache is; what port is it listening on, how can we get you to phpMyAdmin; here's how you set up rows and columns in your tables and think about a database; no the reason it's not working is because you saved as '.html' and not '.php'; I know you've seen URLs that don't end in '.php' but that requires invoking the Rewrite Engine and teaching you about .htaccess files; oh the header modifications can't be the first thing you emit; here's the docs, you basically have to search them because there is no organizing principle and no way to find out what you can do..."
I agree, Python+Django will make you learn a bunch of weird "modeling" stuff first. To me, setting up the data model at the beginning of an app is like inputting a character name at the beginning of an RPG: as some sources testify [1], you can easily waste several hours on purely aesthetic concerns before you even really start to play.
Nonetheless, Python+Django comes with a lightweight dev server and an interactive console and a routing table, as well as a template language. The knowledge of the database is internalized to the language, so that I don't have to teach someone how to use phpMyAdmin but rather when to use a ForeignKey. If we talk purely about learning to develop on the Web then PHP has much, much more useless overhead.
Sure, eventually we will have to get a production-ready web server communicating with the application, but that can be abstracted until later with Django: it occurs as an up-front teaching cost with PHP.
I say this not even as a Python aficionado per se. If anything I like Node, and Node is nowhere near either of them in offering pleasant functionality.
I certainly didn't mean to say that languages like Python and Ruby are inflexible!
What I meant to say is that you can't use either of them in direct conjunction with HTML the way that you can use PHP. This was what I meant when I said "genuine functionality from scratch." Would I prefer Python+Django/Flask for lots of use cases. Absolutely.
As for the "useless overhead," there are things like the command line (which Python and Ruby web dev absolutely demand) standing in the way of some of the other languages. Personally, I strongly prefer the command line for almost everything, but for beginners this is another barrier.
My argument was not for the superiority of PHP over other languages, but rather against its casual dismissal from consideration.
1. I wouldn't want to do anything at a meaningful level of complexity without templates. No question about it. And I think that having so many templating frameworks is wonderful (ERB, Jade, haml, etc.). I was only arguing that PHP lets you dive in without NECESSARILY needing to jump through a templating hoop.
2. Is it unthinkable that a person could start learning web dev and pick up the command line along the way? I started out learning PHP/MySQL on my old Windows machine, terrified of the CLI, and now I do almost everything on it (and have converted my old PC to Linux). If the command line were a barrier at all points in the learning trajectory, then you might have a point. But I also don't think that command line mastery should be held up as a sine qua non of learning web dev.
1.
Ok so when is it appropriate/useful to use the power of embedded php (in html) instead of templates? Just for learning the first couple of hello worlds?
In my experience it becomes a mess to manage when you start having more than one commiter and more than a couple of lines of code.
2.
You don't have to be a command line expert to start using it. All the books at http://learncodethehardway.org/ show that command line can be integrated in the language learning process seamlessly. No reason to be terrified of it, on the contrary, new coders should embrace it as soon as possible.
Look, there are two things you are saying. One is "you can't do this with Ruby/Python" -- which is a superiority-of-PHP argument -- and the other is a plea of "PHP has done a lot, so let's not be too hasty dismissing it." You made both of these arguments. In fact, you made the first one in this very comment where you say you're not arguing for PHP's superiority over other languages.
In some ways this is true but I would be hesitant. What you're really advertising is that PHP has an implicit `echo("` statement which looks like `?>` and also implicitly occurs at the beginning of the file. A lot of new folks write really hard-to-follow code. Here is the seed of badness from which such code eventually germinates and blossoms:
If you do not see why this is bad, imagine that you have a loop within a loop and they get separated by more than 20-30 lines of PHP. Notice how some of the HTML occurs within the PHP statement but pairs with tags outside of the PHP statement, and imagine functions which are producing such code. Et cetera.
Python+Flask will force you to either do it in a Jinja template, which avoids the problem because you cannot 'return back to Python' midway through:
<ul>{% for user in users %}
<li><a href="/users/{{ user.id }}">{{ user.name }}</a></li>
{% endfor %}</ul>
Or else you could define the file within Python using strings, in which case your syntax highlighter will be able to tell you exactly where these strings begin and end:
output += """
<!-- ... more code ... -->
<ul>""" + "".join(["""
<li><a href="/users/%i">%s</a></li>""" % (u['id'], u['name'])
for u in users]) + """
</ul>
'<li><a href="/users/%i">%s</a></li> % (u['id'], u['name'])
for u in users]) + """
Of course, Jinja is more readable in this case, and that's kind of the point. For most web apps, you want a sort of preamble which calculates and formats a bunch of information, selects a template, and renders the template to the user. For PHP, this preamble is Apache, and if you want more, you probably need to generate an include() file to force yourself to stay sane. (PHP doesn't force this however, and many people write bad code which simply does the calculations in the HTML wherever they are needed -- and then you get massive code duplication and the joys of trying to match curly braces through large blocks of HTML.)
I've lived Ruby land and Python world for quite some time and I must say it's good to be back in home in PHP where getting things done doesn't involve clever semantics and tying yourself up in layers of abstraction. Oh yeah, and it's nice to read code that has comments explaining what the hell is going on too (seems Rubyists and Pythonistas don't believe in comments, you know, because that'd make the code too obvious)
As somebody who maintains and develops a commercial WordPress site as well as doing Rails work, my impression is the opposite: Rails projects tend to be moderately easy to follow while PHP projects tend to be composed of 10kloc balls of intertwined logic, state and IO with no comments aside from a healthy helping of:
// $var = foo(bar);
$var = baz(bar);
Perhaps we're both encountering a bit of luck rather than accurately assessing the two languages' ecosystems.
Have you used PHP? Spend 5 minutes with it and you'll understand; a very expressive language, simple to learn, massive library of functions, massive number of examples to copy, no framework to learn, no syntactical overhead like in Java, practically everything works with, or has bindings for PHP.
I prefer to work in python, but I don't much care anymore, each language has it's strengths and weakness' but PHP most definitely is good for getting things done "very very quickly"
Yes you can get up and running quickly with php, but my comment was mostly about the fact that it is not much slower in other languages (most of the time not slower at all).
And yes I did a lot of PHP but that was 5-6 years ago. I know things have changed a lot since then but the language still has a lot of the same flaws.
> But I also think that it might be the best language to use in gaining an understanding of the fundamentals of web development
OP admittedly has less than one year of web development experience. Perhaps it would be wise for OP to gain a more thorough understanding of web programming before coming to conclusions like this.
I use words like "might" very intentionally! And yes, right you are that my conclusions about things might change radically. I'm already appalled at some of the things that I thought even weeks ago...
I will simply point out that one can do a good deal with a little code using WSGI. As for templating, Python has for some time had very handing formatting.
PHP could be a wonderful thing if not for its original sins.
It is easy and fast, but it is also bad. It is "good enough", and for many years it prevented just "good" from arising and gaining adoption.
I would pick "good" over "good enough" even if it costs me a bit because I think this is fundamentally right.
No. Sometimes I spend a lot of time and effort seeking out niche genres and digging through blogs and news sites to find "good" music. But sometimes I don't want to put in all that effort, and then putting on "Kind of Blue" or the first Weezer album is "good enough." There is room for both approaches to music listening.
"I think PHP is the perfect language for beginning web development for two reasons: Direct HTML embedding."
Server-side view rendering is on its way out. So this is not a real advantage.
"I find it more than a little strange that PHP is simultaneously (a) out of fashion, and yet (b) absolutely everywhere."
This is simply how technologies rise and fall. By the time a technology is ubiquitous, the original problems it solved have changed and new solutions are being created. Just because you have a bunch of legacy code running lots of web apps doesn't mean it's the future--it means it's the past.
Also, why pick a language that pays poorly? Ruby is by no means inferior to PHP, and you will get paid more per hour to program in Ruby.