Quote:
|
Originally Posted by rollercoaster375
That's the way HTTP was designed—It wasn't meant to be an interactive application, it was meant to be a get/send transaction-based protocol.
|
Well then shoot tell all the folks that implement shopping carts, sessions, and other state based functions that the web wasn't designed to do those things. And, if they do implement them they should be hard to work with.
Quote:
|
Originally Posted by rollercoaster375
There is a difference, however, in your comparison. You're comparing a language with a framework. That isn't fair. PHP itself doesn't have near the ease-of-use that a framework (There are numerous of PHP frameworks: Zend, Cake, Symphony, Trax...) will have. To further this point, would you attempt to write a Web Application in raw Java? [Although, I'm not sure if that's a valid comparison, as I don't know Java]
|
Well yes and no. Like I said the PHP interpreter runs a script and quits. That is how the language is designed. It was not designed to make an app that you compile and and keep running for the life of the web app. The alternatives that I talked about do take this approach, and there are big advantages to it.
1. Better performance - A compiled language will generally outperform an intrepreted one
2. Better error checking - Compiling helps you discover errors before you run
3. Better state handling - I've already talked about this one.
The downside to those is a steeper learning curve.
None of the above has anything to do with frameworks, only server implementation. Unless someone drastically alters the implementation of PHP, you can consider it a feature of the language as PHP only works one way on a server.
Additionally you are wrong in saying that PHP does not come with a framework. Out of the box you get support for sessions, database access, collections, etc. It might not be as full featured as some of the other web app frameworks, but that is a lot more than just a language.