Re: Why JSP is better than PHP >>

Someone else may be able to address some of these better later, (or maybe we can) but some things I'd respond to right now: Erick Papadakis wrote: > Forgive me for a rehashed topic but the following has > been thrust into my face by a guy who was born with > Java skills and is still using the bloatware - > > ----------------- > Here is a list of reasons why JSP is better than PHP: > > 1. Anything you can do with PHP, you can do with JSP; > the reverse is not true > "ANYTHING" is a bit wideopen. Can it run PHP code? > > 2. JSP is much more powerful, since it has access to > all the Java libraries. PHP only has access to PHP > libraries > A bit circular. The 'power' of those libraries is something we question. Most are closed source, and aren't terribly cross-platform nor efficient. Turn the argument around. JSP *only* has access to Java libraries. PHP has access to PHP libraries. AND any C library that you can compile into it as well. AND anything else you choose to write for it. Pretty lame argument for the 'superiority' of a language. > > 3. JSP is Object-Oriented, so leads to cleaner code > that's easier to debug, maintain, and improve. (PHP > also allows objects, but the object model is more > primitive, and most scripted pages ignore PHP objects > and just use normal variables.) > Just because people are sloppy doesn't mean the language is inherently poor. We've seen plenty of sloppy code. OO doesn't automatically lead to cleaner code. > > 4. The equivalent syntax in JSP is just as simple to > learn, so you can get up and running just as quickly > -- that is, there's no extra startup cost in using > Java, at least not a significant one > First there's NO cost. Then, there's not a 'significant' one. Which one is it? NONE, or some? Can't have it both ways. I'd say there's a startup in any platform, but in PHP it's far less, because you don't HAVE to understand much coding to get started. I don't have to declare libraries and variable types, etc. (again, this may be more the servlet model than JSP). Compare the following: JSP <jsp:getProperty name="clock" property="monthInt"/>.<jsp:getProperty name="clock" property="dayOfMonth"/>.<jsp:getProperty name="clock" property="year"/> This would print out 11.13.2000 PHP <?=date("m.d.Y");?> This would ALSO print out 11.13.2000 JSP syntax seems just SLIGHTLY more complex to my eyes. But I'm not a language bigot either... > > 5. Java programmers (as opposed to 15-year-old hackers > or HTML monkeys) appreciate the importance of a clean > language with complex OO data structures and strong > typing > This is not a technical argument at all, but elitist bigotry. I've known teenagers who appreciate the elegance of a clean solution. And I've known people 35+ who write hack code. Java forces you to be a bit cleaner, but there's still many ways to write Java, and sometimes it ain't pretty (look at the Adobe PDF java bean stuff if you think all Java is, by default, pure OO elegance - it ain't!) > > 6. With JSP, if the code inside a page gets too big, > or if you want to use it elsewhere, you can cut it > out, make it into a Java class, and invoke it from > anywhere in your application (even not from a page). > With PHP, you're stuck inside the HTML box. > What the heck is this guy talking about? You're stuck in the 'HTML box'??? First off, personally we don't mix much 'code' in 'pages' at all - most of our work is templatized, so about 95% of our 'code' is just that - code. In a file, with a beginning, middle and end, with very little 'HTML' anywhere. If your code gets too big in PHP, make some of it into a function call that gets included. True, that file needs to be included and compiled on every page, but that gets you up and running faster than recompiling your Java all the time (forgive me - I may be thinking of servlets, not JSP). Also, why not run PHP from the command line and include classes and functions? You can this 'anywhere' as well - anywhere the PHP interpreter can run. This argument is just pointing out the fact that this guy hasn't used PHP for more than 2 minutes. > > 7. JSP's concept of state management and persistence > is more explicit and powerful than PHP's. With JSP, > you can specify whether a variable persists for the > page, the request, the session, or the application (or > if it's just local to the function). The JSP engine > automatically does the right thing with cookies so you > have access to the variable on later requests. With > PHP, you just have "global" and "not global", you > don't have automatic session management, and have to > do your state thing manually with cookies or hidden > variables. > Any 'state' management Java application servers do for you still has to be done one of two ways: cookies or 'unique id' strings appended to URLs. There's no other way. Sorry. PHP's session handling is pretty automatic - I've done whole apps with sessions where I didn't mess with cookies or hidden fields (to explicitly deal with sessions - I still used hidden fields for other purposes). The PHP engine will (by default) 'do the right thing' with cookies, IMO (depends on what the 'right thing' is!) by making the cookie names into variable names. This leads to easy to understand code, imo. Application variables are indeed neat, but you can easily 'roll your own' if you understand what in fact they are. If you don't, there's no need for them anyway. Furthermore, is variable persistance REALLY a part of JSP itself? It was my understanding that it's reliant upon the underlying Java server engine. Both are languages. PHP is aimed specifically at the web market. Java isn't. Although it has a lot of benefits, I wouldn't say it's the best suited for web work. Also, looks like this list of arguments looks like it was directly lifted from http://www.soft.lv/docs/jsp/jspjgurufaq/jsp_jguru.htm Is your colleague named 'Alex Chaffee' by any chance? > ----------- > > Please help! How can I talk back? I would appreciate > any guidelines and advice. > > Cheers/erick -- ========================== Michael Kimsal http://www.tapinternet.com 734-480-9961