There may be another point: the author asserts PHP is just glue "between the front and the back" of a web application, I guess with the implication being that it's not really important. However, I don't believe the glue analogy is valid. Typically, the server-side scripting language implements the business logic, the real data structures (as opposed to what's being saved to DB) and a large part of the layout. That's not just the glue, that's pretty much the whole neocortex.
"To me, the only significant aspects of Web development are data model, SQL queries and transactions, and page flow design. The rest is just glue code that marries HTML templates to information pulled from the database."
> I guess with the implication being that it's not really important.
You'd guess wrong then. The implication isn't that it's not important. Rather, that it's not important to the resulting web page. That the web page is written in Ruby or Python or Perl. This isn't to say that what inside doesn't matter to those working with it.
To provide a comparison: I don't care if a game uses C, C++, Objective-C, Java, etc. I care about the end result.
At least, that was my understanding of what was written.
> Rather, that it's not important to the resulting web page. That the web page is written in Ruby or Python or Perl.
Without going into a pointless flamewar about the definition of important, and what the author possibly meant as opposed to what was actually written, I believe the choice of technology stack does indeed influence the outcome of the project in many ways. But that's not really the point here at all. The author's assertion that PHP is "just" a glue component simply doesn't reflect the amount of heavy lifting done by it.
> I believe the choice of technology stack does indeed influence the outcome of the project in many ways.
Project.
> Rather, that it's not important to the resulting web page.
Web page.
I was merely referring to the HTML that gets sent to the browser. I wasn't suggesting that the technology being used doesn't affect the project.
> The author's assertion that PHP is "just" a glue component simply doesn't reflect the amount of heavy lifting done by it.
I just said I think you are reading too much here, and inferring things the author never intended, especially considering the context of the article, especially around the part being referenced.
I agree, it's useless to speculate. So, maybe you should focus on what's being said rather than putting your own spin on it? =)
> So, maybe you should focus on what's being said rather than putting your own spin on it? =)
This is the second time you used language designed to escalate this into some kind of personal attack. Why? Simply say you disagree and move on. (I even modded you up the first time.) It's not like one of us has a huge thesis to defend here. It's a minor point about a minor article.
> This is the second time you used language designed to escalate this into some kind of personal attack.
I've done no such thing. I've stated clearly my opinions. If you feel offended by my opinions, I apologise. That being said, I don't preface everything I say with weasel words.
I personally believe doing this (though you might disagree and if you do that's fine) that weasel words are mostly useless (though they do help at times for people who infer more than intended) and I really try to avoid using them as much as I can, though I have been known to fail at this. =)
> Why?
I haven't intended to do this. I didn't "design" anything. At most I felt that the previous statement could have been taken the wrong way, hence the smiley (Which is basically my way of saying I don't intend to start a flame war). You were, in fact, putting your own personal spin on things rather than discussing what was actually said.
I'm not offended, I just felt the discussion was taking an unnecessary turn towards the unproductive side, about a point that is simply not worth the effort we both have so far unwisely invested into this exchange ;-)
I do believe "weasel words" are important, not only because stating personal opinion as fact is impolite, but mainly because it can be vital for the structure of an argument to distinguish possibilities, speculation, belief, theory, and factual data.
Of course the result is what matters. But hypothetically, if you can throw together the basic CRUD of an app in 5 minutes with one toolset, and it takes 2 days in another, which one is more likely to let you hone in on the fine details? If one toolset lets you automate testing really easily, and the other doesn't, which one is going to make you feel freer to experiment and improve?
Yes, tools don't matter. Output matters. But tools affect output. So tools matter.
I'm not saying one should rewrite one's codebase in The New Hotness every 6 months - that would be crazy. Which maybe is the author's point.
Sorry, I probably confused you. I'm strictly referring to the actual HTML/JS output of a Ruby or PHP web application. Sure, production output matters, but my point is actual output doesn't necessitate using a particular language in this case. I believe that's is what the original author was referring to in his original post, especially considering the context.
As for your hypothetical situation, I imagine for those reasons and more, they continue to use PHP. PHP isn't devoid of these tools (and I'm not suggesting you are suggesting that), and they are widely used and fairly popular. And because they are proficient in PHP, they can use these tools easily.
As has been mentioned by the original author (in both the original post and in comments), they don't use PHP as a hammer, and they do explore other languages. Learning is good. Take what you learn, and apply in a language you are extremely proficient at.
When I read that. I instantly thought well of course they use it as just glue cause they are using a cruddy language.
There's lots of reasons to use BASH as a glue language (people should do it more) and there are lots of reasons not to use it to write whole software. PHP, same.
I'll go out on a limb here and say that most apps handle some kind of data structure on the server, and in many cases they facilitate some kind of interaction between the user and this data. While you can theoretically do the entire functionality in client-side JavaScript, I assert the idea is so abysmally bad it's not really worth considering as a valid counter example. Please note that I wouldn't include pure single user applications like http://www.diagram.ly/ in this category because they don't manipulate objects on the server that are in need of protection and validation.
I will argue that for mid to large applications, scripting languages are just the entry point to your entire application, as the author says, the glue. I would run a "real" application server underneath for the middle tier (i.e. to handle the business logic), and have the scripts handle the presentation layer only.
> I would run a "real" application server underneath for the middle tier (i.e. to handle the business logic), and have the scripts handle the presentation layer only.
Yeah, I believe you would. But not Facebook, Wordpress, or even large parts of the Google Apps landscape. I'm not judging either side, mind you. Do you by chance primarily develop business applications? Because business app people often favor this special type of multi-tiered design that typically has a Java app server behind everything.
Facebook could probably go in either camp. I'm sure they write some of their business logic in php, but they made Thrift for a reason. In particular, isn't their chat written in Erlang and feed stuff written in c++? I've read that they even use Java for some things.
