Slashdot Mirror
PHP, Perl, Java Servlets - What's Right For You?
Sean writes "Take a look at this comparison of Server-side scripting languages. The article explains how PHP scripts, Perl CGIs, and Java servlets work. It can help you decide whether to use PHP scripts, Perl CGIs, or Java servlets for your next Web development project. It also covers the issues that separate the three languages and provides all the source to test their differences." Right tool, right situation. That's all I have to say.
PHP is faster than Perl/CGI, but I'm pretty sure mod_perl beats them both. PHP has to re-interpret each script every time it's run, while mod_perl caches a psuedo-compiled version. Unless, of course, you buy the Zend Optimizer, in which case you'd get the same benefit with PHP. But then you'd be introducing unclean (closed source) software to your web server.
Well, I can use Perl, PHP, or Java for free, or I can drop several thousand dollars on a fractionally powerful template engine. I think I'll pass. CF on Unix is a terrible mismatch of environments, imnsho.
I've seen CF tie into JavaScript a lot, yeah. However, this brings with it the requirement that JavaScript be present. While I realize JavaScript being present is a safe assumption for most users, I don't consider it a safe assumption in web app development. Even if it is there, it's very difficult to do anything meaningful in JS without writing it once for each browser you want to support.
I've also seen whole application suites written in CF (A first mistake) that use _only_ JavaScript for data validation (A second mistake). As a result, if JavaScript is off, or if it isn't written correctly for each browser, the app either simply breaks, or data gets send to the queries (Or in this case, sprocs) unvalidated, creating messy DB error messages.
CF does have one last gasp at a future, though. They're working on converting the language into a set of JSP custom tags, which would free it of the poorly designed CF server, and tie it to a language that does have a solid future (Regardless of if we like it or not, Java is indeed not going anywhere for quite awhile).
It's very fast execution-wise, in my experience. One can write naive, slow code in any language. The most common example I see in the java/servlet universe is establishing fresh database connections for each HTTP hit, rather than pooling them. If one does that, it'll be slow for sure. If one knows what they're doing, on the other hand, java/servlets/jsps can be very fast.
The "cue the foo posts in 3, 2, 1..." posts will commence with no subsequent foo posts in 3, 2, 1...
What the hell is wrong with the PHP interpreter?
It is not as widely-distributed on the systems I work on as PHP. And unless I'm mistaken, #!/usr/bin/php is a fairly recent thing; before the generic interpreter was available you had to use phpcgi or some damn thing.
No offense, but you seem to have a fairly loose understanding of PHP at best.
This may be; I haven't seriously looked at the language in over a year now.
If your programming is good, modular, and loosely-connected, your script will not care whether it's running on the web or on the command line.
Okay; I've got Perl installed on all systems I work on. PHP is (was) installed only where it made real sense: on the webservers. Why would I write Perl modules to do some fairly generic work and then rewrite them in PHP to take advantage of them for the webservers? Or why would I write a PHP class which did something great only to find out later that I can use it on another system without PHP and have to rewrite it in Perl? I simply settled on one scripting language which I feel is more superior.
And I'm not sure where you got the idea that perl doesn't use an interpreter...
Actually I didn't say that. As I wrote to another person who replied, #!/usr/bin/php is a fairly new development IIRC. Before that you had to use phpcgi or some damn thing which I'd written off as a hack to make PHP more useful outside of webspace. If it indeed has gotten a generic interpreter that's great. In my eyes I've crossed that bridge. It's too little, too late. The languages are too similar to me to warrant "perfecting" both.
Don't get me wrong, I like perl as much as the next guy...but this holy war assumed-condescension is silly.
Agreed. PHP makes some things easy that Perl doesn't either. And the general syntax is cleaner IMO as well (I come from a C background). But this entire article seemed to be the breeding grounds for a holy war and it was late, so I thought I'd fan the flames a bit. :-)
The DBI argument gets more specious by the day, too. Check out PEAR. Or PHPLib. Or Metabase.
I can create a connection, run commands and get results generically with DBI. Yes there are vendor-specific extensions, but the base calls are the same. A year ago PHP did not have this. There were pg_* calls for Postgres, mysql_* calls for MySQL, msql_* calls for mSQL, etc. Yes there were generic ODBC drivers but hardly anyone uses them if they're working on a high(er) performance system because vendor ODBC drivers are notoriously slow. DBI fixed that.
There are lots of valid reasons one could give to prefer perl over PHP, or PHP over perl, or emacs over vi, or milkshakes over spaghetti...but what you've written are not among them.
I don't see how my post didn't give any valid reasons. I stated my own reasons and here I've backed them up further.
As I'd said, I started out as a PHP guy. Loved it. Then I started wondering why I was learning two languages that were very similar, did pretty much the same jobs but one was more targetted to web apps. So after some careful consideration and a few posts to various Ask Slashdot's I made my choice. And I really don't miss PHP, which indicates to me that it was a good choice to settle on one scripting language, and (IMO) the more versatile and powerful one. That's not meant as a flame against PHP; it's just a direct observation on my part. I've not been able to prove that PHP is significantly easier, faster or different to warrant learning it.
Perl. Why learn two languages when one does 99.9% of it without breaking a sweat? Seriously. PHP has umpteen number of DB interfaces. Perl has DBI. No matter what you talk to it's all DBI and it's fast. Regexps? OO? Parsing? PHP and Perl both have them but why write your modules once in PHP and then have to redo them again in Perl just because you want to use it outside of the web?
Yeah I know about the PHP interpreter but that's just plain old hokey. And to think I was once a really avid PHP guy. If all you're doing is web, PHP is really sweet. But really when you think of it you have other things to do too... parsing logs, reformatting, search and replace... things that get done on a daily basis and are beyond the scope of "just the web". Write the module once, write it good and use it in all situations!
So its pretty clear. PERL users like leatherman tools, PHP users prefer traditional single purpose tools. Or maybe not.
Definately maybe not. :-)
I hate leatherman tools except as a "where is my... oh fuck it, I'll use my leatherman" type of scenario. Proper pliers, proper screwdrivers and proper nailclippers are essential to me. Hell I can't even stand the dozen-in-one screwdriver sets half the time!
To me, PHP is tailored to the web and is breaking into the generic system interpeter market. Perl owns the generic system interpreter market but has uses in the web world. In my opinion Perl has a better chance at the web market than PHP does in the system interpreter market, but as I said, it's my opinion. I really haven't seen much of a speed difference between mod_php and mod_perl, I happen to love Perl's OO setup (10000000x better than C++) and although it causes me headaches from time to time, Perl's regexp abilities are far more flexible than PHPs.
Considering ASP is crap (and yes I do speak from experience, over a year at that), I think it's ok to skip it in this discussion.
more components? In order to get the least bit productive in ASP you'll need a few THIRD party components (for which support isn't always all that great, not to mention licensing complications). So, NO ASP does NOT have more components than say php or perl.
Not if you don't want to. OK, granted. ASP is OK for people who don't know the first thing about dynamic content. It only takes a couple of days for a newbie to get productive (that's how it was in my case anyway). HOWEVER... as weeks and months went by I came to realize how crippled ASP is, for instance it doesn't come (de facto) with an easy and comprehendable way of saving uploaded files, I did not find a way to use a special mailserver to send emails. Granted this is mostly because of how NT Server is set up, but it's an annoyance. And how do we deal with these annoyances? The easiest and most common way of doing things was to purchase 3rd party components that helped make this easier. And when you do that you have to worry about licenses and it all ends up being a pain in the ass, and of course in the end you blame ASP for being such a piece of crap. --- I know my english is bad, I'm hung over.
> BTW, I'm not against most languages (exceptions include Algol,
Interesting. So you're opposed to powerful non-GOTO control structrues and source code that doesn't depend on counting columns (Fortran IV) or lots of parentheses (LISP)? Because ALGOL happens to be the pioneer of those concepts.
> COBOL
So what's your suggested replacement? There's reasons COBOL has stayed where it is; Binary-Coded Decimal (the only legal way to handle financial matters) is one.
I'm sure you can even find a lot of ASP in use within IBM.
No, you will find very little use of ASP @ IBM.
Poor performance? What are you basing this on? When my company was deciding between mod_perl and Java servlets, we looked at a benchmark by the folks at Caucho, who make the Resin servlet runner. Their test seemd to show Java doing better than mod_perl on Linux. Then we looked at their code. The mod_perl stuff was not coded optimally. We fixed it, and added some more tests that used Oracle for simple interactions. The results showed mod_perl beating Java servlets by a significant margin, even on the fastest (at the time) servlet runner and JVM (from IBM). This was a year ago, and both Perl and Java have new releases since then, but the point is that you should check your assumptions when it comes to server-side performance of languages.
Funny, but most of his comments seemed to be geared towards other issues, such as ease of development/deployment and extensibility.
I'd rather have my page designers working with jsp, giving them a handful of well documented, custom tags to do the dynamic stuff, than try to either a) have java programmers do page design or b) page designers to java programming.
--Dg
My issue was less with Velocity per se, than with what I viewed as gross inaccuracies regarding JSP presented in that article. Not to mention the fact, that article was presented as "JSP still has its flaws" in the post I was responding to. So, I hit the velocity article from the standpoint of debunking it's perceived flaws of JSP - not so much as a debunking of velocity. Granted - I can understand where a lot of them came from, as they're not unlike first impressions I had on JSP, as well as first experiences with JSP code. It's entirely possible that our development group uses JSP in a fashion -very- different from the average JSP developer.
Alas, juggling two jobs doesn't leave me a lot of time to dive deeply into a conversation on this, but I will make this point. My personal perference is to have as -little- logic of any kind in display pages. Whether it's JSP augmented by tags, or Velocity, or any of the half dozen other page description languages out there. (If things ease up work wise for me, I may join the discussion of velocity - if only because I saw a handful of things in my going back and reading the user docs on it that could possibly use some improvement).
It seems to me that where velocity will succeed is in having a very strictly defined, minimal syntax outside of the html code. My personal -preference- here is for syntaxes that line up more naturally with an XML style, however. It would be fairly straightforward for me to provide my web designers with a set of tags that pretty much provide the Velocity functionality (sans the macros, but that's okay for a variety of other reasons).
I wish the velocity crew the best, and may very well put up a velocity environment for play here once I get some of my other dev projects finished. It just tends to put a foul taste in my mouth when my first exposure to a project is laced with as many inaccuracies as the YMTD. (But, as I mentioned above, the YMTD -is- probably correct in terms of how the average JSP developer might end up using JSP pages.)
Cheers,
--Dg
I'm amused to have had the article marked as 'troll'. Granted - I took a rather strong tone in it, but then again, one should see the tone regarding JSP in the velocity article. (It is a shame, actually, that the YMTD article will be many people's first exposure to velocity - as it looks like it could be a very useful tool... Had my first readings on velocity been some of the other documents on their site, I would have probably written off the YMTD article as a marketingish blurb (though, I still would have felt the need to correct some of their assertions about JSP :) ).
:)
Of course, speaking as a developer who uses java (I use too many other languages to be able to just call myself a 'java developer') - i can understand a lot of the java hatred out there. People trying to pound square pegs into round holes and getting pissed that it doesn't work that way, and all that. I know people who still think java is a crappy language because applets, as a general rule, suck ass. Personally, i've found java very useful on the server and on the middleware side. But i'm a crack-head like that.
(Of course, i'd be very surprised if I was still using java in 5 years, i'm sure by that point, there would be other technologies to move on... Real Software Developers can develop with the tools at hand (hopefully choosing the Right Tool[tm]) - and aren't limited to one, maybe two tools
Cheers,
--Dg
I have looked at Enhydra - very interesting model in there. Though, I found with it, when reading through the docs, that you still end up having java code involved with presentation - just separate (having code involved with building presentation separate from presentation bothers me in some environments).
I still want to take a run with building an application with Enhydra, however, as it appears to be an interesting environment.
Cheers,
--Dg
I have no conerns about development on the server/application server side. I do have concerns about making sure that my web designers do -not- have to learn a programming language of any kind. (Setting them up with simple tags to work with is easy, as that fits into their mindset of working with HTML as it is).
Cheers,
--Dg
I have issue with a lot of the 'points' raised in this article, however...
:). They also completely miss the fact that it's fairly easy to limit functionality with Java's security mechanisms... Of course, the gods forbid that someone managing a server that does hosting -understand- what they're providing.
:)
(Let's ignore the fact that they're using a rather idiotic way of using jsp in their article - and in fact, it's rather plain to see that the article is written in a way that displays only a very minimal knowledge of jsp).
So - their first point, is that since Velocity code isn't embedded between tags, it makes it 'easier to see what's going on' when you bring up the page in a browser... Forget the fact that the way Velocity does things would completely destroy the appearance of layout if you just bought the page up in the browser (compared to, most of the jsp pages on the project that I work on, which a browser can actually display most of the layout with very few issues).
Honestly, though, when i have code in a jsp page (or a cgi script, or a, or a) - i almost -never- load it up straight into a browser. There's too much context that would be missing (and this is ALSO true for velocity!)
So - their first point is a weak one.
Let's go on to the second one...
They complain about the way that JSP works, in that it compiles down to java/class files, and that a temp directory could 'grow without bounds'! First off, I've been running production jsp engines for nearly a year and a half now - and I have -never- seen a temp directory grow in the way that they're afraid of, even in a development environment.
In addition, they also seem to be under the mistaken impression that JSP output isn't buffered by default. For a group that's working in the context of Apache's Jakarta project, i'm surprised that they don't seem to understand that JSP output IS in fact buffered.
Last but not least, they use a set of what the java generated from jsp looks like... Here's a clue - end developers never even need to see that stuff...
Now, onto their complaints about error handling...
This section is actually halfway decent, and isn't as full of the erroneous assumptions of other sections, but again, they use bad code examples (e.g. they do an if( true ) throw Exception() and then complain that there's a 'statement not reached' error because of code generated further on in the page - please...) They also completely miss the fact that if you want to - you can handle exceptions right in the page, in fact, I didn't see anything in their comparision about how to handle runtime errors such as this in the velocity engine. tsk. tsk.
I will grant them that at times, a JSP engine can throw out ugly errors, but i've never had it throw anything out that was difficult to deal with (and most of the time, the jakarta engine gives enough proper line number information to be able to find the exact line of the error).
They then go on in the next section to complain about how java beans are accessed in JSP pages... In our 200+ page JSP application, we don't have a single jsp:useBean definition. Nope - instead, we have defied jsp tags (*gasp* - yes, they seem to be so far ignoring the fact that you can define your own set of tags for jsp) that export necessary objects and provide needed functionality. Our application design is separated enough that it's a rare thing to have actual java code/scriptlets in our pages. (Unfortunately, I can't see a way to do a velocity page without their velocity code)
Of course, they do finally hit on tags, but again seem to be doing stupid things with their tags. Honestly, between you and me, if I ever had a (non-junior) developer underneath me write JSP code like this, I would either a) have them rewrite the code or b) fire them on the spot.
They seem to feel that extra typing is a bad thing (even if it makes the layout inconsistent - and yes - throwing #blah tags into the middle of an HTML page is inconsistent compared to a well formed XML document.
They also go on to claim that JSP is pigeonholed to -just- produce HTML. Man, am I glad they cleared that up for me, I must be doing something horrifically wrong, what with outputting XML and WAP, along with HTML, as well as formatted text.
Now - they finally get on to something that Velocity -may- have an advantage in at this point, embedding in other applications. However, this is an implementation issue, not a language/syntax issue. (And in fact, I have been able to embed jasper with relative ease into my applications - yes, you need to gasp *know java* to be able to do it...)
They then move on to some FUD, that because JSP is a 'new' standard it is unstable (and where, pray tell, is velocity's standard? Oh, that's right, its on their TODO list), and feel that the advantage to velocity is that there's only one implementation (as opposed to multiple jsp implementations (which, for the record, I have not had any problem moving code between)).
They then move into a hosting argument, that allowing people you host for to put java into their pages is a bad thing, because they could write something that uses up system memory! (Like, oh, say a CGI...). Of course, because velocity only has foreach, and no for, there's no way to do an 'infinite' looping situation to build up memory (poor, poor, naive developers, give me a day with velocity, and i can probably write something that will throw your server down to the ground performancewise
This document is FULL of FUD, up one side and down the other. And it is a shame, because it looks like velocity may actually have the potential to be useful, but to build their entire argument on a set of horrific misconceptions about jsp development, without trying to -really- understand what's going on... well, that pretty much ensures that it will never be used on any development project I work on. (Sorry, I'd really rather not use a project bourne out of such naivite). This strikes me as a project that was started up because someone spent a day with JSP, got discouraged, and started thinking of other ways to do things - re-inventing all the problems of older CGI/scripting solutions. Yippie. (Gee, what will we see first, an HTML editor that understands JSP or an HTML editor that understands velocity? Hrm....
I'm sure there may be deeper benefits/issues to velocity - this is based soley on this one particular article 'justifying' velocity's existence, and showing all the 'problems' with jsp.
--Dg
--Dg
No, shit, really? I've done implemntation work for jsp, I know what goes on in jsp engines. One of the reasons we use jsp is -because- we can provide well defined tags that our HTML designers can use and be happy with.
I wouldn't expect a designer to code in velocity anymore than I would expect them to write scriptlet code. But I can have them put tags around their page to ensure that we can template the look and feel of the page in a trivial fashion, or use tags that automatically backfill from previously entered data (or pull their data from a supplied object).
--Dg
--Dg
Looks like you forgot to turn on anonymous posting you moron...
--Dg
It's the difference between being a software developer who uses java and a java programmer who can't develop software :)
It's my humble belief that strong software developers should be able to develop in ANY language...
Cheers,
--Dg
Ruby freaking rocks. I wanted to use it as an apache module instead of php but had some compile problems. I think the libGD (for generating Jpeg/PNG programatically) errors were really scary.
Damn I love ruby tho.
If not java (which WAS one of the three compared languages) then faster than what?
-Jer
What about the other embeded languages? HTML::Embperl (perl.apache.org/embperl) can do exactly what PHP does, except you have the power of perl (such as all the modules on CPAN) at your hands...
This is not the first discussion on /. about the best technology for the generation of dynamic web content. So I read only the conclusion of the article, and that looked okay for me.
My personal favourite is Java. Not because jsp or servlets are superior to php or something else from a technology view. (Even if they have a small advantage in my eyes.) But with Java, independent from the kind of task, you get a much better tool from a software engineering point of view. You get a basket full with the best practices and concepts for building complex applications: OOA/OOD, patterns, components, etc. Java is full of these and if you start understanding them, they'll lead to better programms.
Most of this should be possible with php (as an example), too. But a short search at www.php.org about advanced design topics got me only basic hints like "put your code in libraries, not in the page" or an unanswered questions for a mvc framework.
I started development of web applications with perl and cgi four years ago. This is the code centric approach stated in the posting above. Later I started embedding perl code in html. Both times I ended with a big mess. (This is okay, if you can sell your boss a "technology and design update".)
My first article about jsp was about the model-vier-controller (mvc) design pattern, too. If you separate the data modell, the programming logic behind your user interface (the controller) and the user interface itself (the view), you can quite simple replace the html interface with a (for example) wap interface. This is mostly the same idea as from the author above.
As I said before: good design should also be possible with php, embedded perl or something else. But from what I see, people don't do it.
And then you reuse a class defined in PHP in any other application, which includes lots of non-web apps? Is it really that easy to integrate PHP scripts with other language environments?
There are several free (both senses) regular expression packages out there that work quite well. You can find two of them at the Jakarta Project's web site: http://jakarta.apache.org
Far from being "a morbid joke", I've found Java to be one of the best languages for server-side development on Unix. I worked for two years writing server-side Perl apps (with CGI and mod_perl). When I first switched to Java, I was somewhat irritated by it -- but after getting used to its way of dealing with the world, I find it to be more powerful, faster, and far more maintainable than Perl.
Of course, if you haven't done anything with Java since the bad old days of JServ, you can be forgiven for your dismissal. But go download Tomcat and see how well modern Java works.
This may be true now, because most people who have a CS degree (and thus are more likely to understand things at a level greater than the superficial) learned C++ for their degree -- so the people who only know Java, and not C++, are the casual accountants-cum-programmers.
With the move to Java as a primary teaching language, this is going to be far less true in the future. Those people with CS degrees, who've taken classes in assembly language, computer architecture, and symbolic circuit design, will all have learned Java, and not many of them will know C++.
I agree about mixing HTML and code - however, first of all JSP *does* support the ability to separat presentation from logic, though the use of custom tag libs.
But there are other Java based laternatives, such as Enhydra's XMLC solution where you have 100% complete separation (you modify the HTML through DOM).
And as for "neutreal" JVMs, they *are* fast nowadays. The days of interpreted Java is long gone. LInux, Solaris, WinXXX, True64, AIX - almost anything, has a modern JVM with JIT:ing or some kind of mixed-mode solution (Hotspot style).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
First of all, servlets *ARE NOT* a scripting language. A servlet is a class that extends javax.servlet.Servlet. Period. The most common form is the javax.servlet.http.HttpServlet. They are classes that implement a certain interface. It's got nothing to do with scripting.
And as has already been pointed out, comparing servlets with PHP is ludicrous. What they should be comparing is *JSP*. JSP (Java Server Pages) are HTML that gets converted into a servlet (and then compiled and run) by the Web Application Server. So yes, servlets are involved. But JSPs clearly fit the description "Java equivalent of PHP" much better than servlets. Servlets are the building blocks of JSP; but comparing PHP to servlets is like comparing JSP to PHP pages without HTML in them (i.e. everything is done in the form of code).
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
I agree with the conclusion however. At least, if you don't know PHP, perl nor Java, servlets are obviously more difficult than PHP or Perl, simply because it's just yet another application of Java. And in order to use it efficiently, you need to understand OOP, and be familiar with the Java API.
/ Peter Schuller
----------------
E-Mail: peter.schuller@infidyne.com
URL: http://www.scode.org
/ Peter Schuller
--
peter.schuller@infidyne.com
http://www.scode.org
Zope is to PHP, JSP and Perl as The GIMP is to using a HEX editor to make XPMs
www.zope.org
No, not really. What matters is...
1. Is the development time so long that buying faster hardware would be cheaper than building it in something just 'faster' at runtime (PHP isn't fast anyway - its just faster than its peers)
2. Does it work (this means does it support transactional operations, simple distribution and integration with third party application that customers may already be tied to.
The above items alone are the prime reasons why Java solutions are very popular. Enhydra is better than PHP by a long way. Don't get me wrong, I like PHP and have built some very complex sites in it but these days I use Zope (www.zope.org) for all that I'd ever use PHP for and its perfect (can I say that?). If you haven't tried it, give it a go, the curve is steep but that's because you end up a lot higher than PHP would get you. Its offers a lot of stuff starting at a built in transactioal object database (no SQL, no tables, just object that persist automatically - the coolest thing your likely to find in the open source world!)
For example in Zope I could put together a simple website with News postings and suchlike in about 1 hour - and the site would cope with undoing changes to practically everything and version control so changes can be made without them being visible to general visitors (again to everything - even the HTML and images).
I'm pretty much against the idea of Java for web sites (simply becuase I'd not use C++ for presentation layers so why is JSP a good idea? Its ugly and one look at Enhydra's XMLC or Zope's new Page Templates makes it look completely crappy). Also now that there are a hundred and one ways to connect anything to Java backend stuff if necessary (XML-RPC, Soap, Corba, DCOM bridges, etc etc) there just isn't the need for Java on the presentation layer.
Anyway, try Zope - give it a month (yes, its a lot longer than it took you to learn PHP but hey, its worth it). Get there and you won't go back.
ASP is a framework for page based scripting in multiple langauages (VB and JS out the box but Perl and Python from ActiveState).
;)
Page based scripting is bad, ugly and quickly becomes unmaintable and messy.
Check out Zope, its is an object based, cross platform framework which makes PHP, ASP and JSP look decidedly old hat. At the moment it allows you to use Python and Perl (with an add on). If you haven't tried it, give it a go. I know I've said this a few times here but try it, give it some effort and next time the subject comes up, you'll be saying this
A decent color scheme... on slashdot?!??
Have the four horsemen shown up yet?
What do I do, when it seems I relate to Judas more than You?
Still not dead.
When it comes to building webpages with interspersed dynamic content, PHP or Perl no doubt do just great (and are plenty fast); ASP too I'm sure.
However, when it comes to building a web _application_, the pictures changes drastically. The amount of work spent on the presentation layer (the HTML + That "dynamic" content), shrinks drastically. The picture doesn't revolve around what the user see's in their browser anymore, but the complex interations of the objects behind that display. To make these web applications really work effectivly, your web application needs to be able to hold and store complex structions and classes defining these objects and interactions.
PHP and Perl die here. They're not ment for large systems like that. Perl can't hold state unless it's coupled with FCGI, so it wouldn't be able to persist objects or RMI handles between requests. I think the morale of the story is, these different web architectures each have their own benefits, and but they cant' solve all your web needs.
Check out http://projectapollo.sourceforge.net It's a web application framework using java servlets which tries to solve the issues assosciated with a web application, and not "dynamic content" web pages. It uses a template system, stateful operation, and a treebased design of application logic. But regardless, it may be very elegant for a web application, but it would be rediculously overkill (and thusly a poor choice) for the kinds of dynamic webpages the article was discussing.
Thank you for the link in you sig. It roxxx. And I'm stoned.hehehehehehehhe eheh eheheheheheheheh h3h --zmooc
0x or or snor perron?!
Chili!Soft allows ASP to run on virtually any platform you might have sitting in your datacenters. I'm not MS-lover, and there are plenty of things wrong with ASP, but I'd put it on par with PHP (having done significant development in both languages/environments). Right now, I've written my own appserver in Java that I use to serve content, so I guess I'm part of the servlet crowd.
For the record: the article was rubbish. The person writing it seems to not know the first thing about writing servlets or Java. Extending GenericServlet? Who does that?
--Jeff
JSP pages get compiled to servlets. All that's not in 'scriptlet' sections, ie. not in <%
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
JSP is not slow. JSP is not Swing or some other wack Java GUI hype. JSP is probably the closest thing you'll get to a speed similar to that of serving static content. The code is compiled and gets runtime optimized - as I expect you'd only use JSP on websites thus expecting uptime, that is a very very sweet deal.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Even with JServ0.92 running on a 2.0.36 I have yet to see the system go down. The puppy has been running for two years, with average uptime %gt; 150 days - when it's down it's due to human failure or power outages - not Java/Linux. Solaris is rock steady as well.
Unable to read configuration file '/bigassraid/htdig//conf/14229.conf'
Geocrawler error message.
Most widely used dynamic content technology in the world? What world?
According to Netcraft, 62% of web servers are running Apache, and another 6% are running Netscape-Enterprise. Only 21% of web servers are running Microsoft IIS.
ASP is only common on IIS.
Chances are, based on that info, it's unlikely that ASP is the most common dynamic content Generator.
-- The act of censorship is always worse than whatever is being censored. Always.
I work at a company that does domain web hosting. We server thousands of domains from our servers, both Solaris/Netscape-Enterprise and NT/IIS. Many of our Unix customers use some sort of dynamic content generation, mostly Perl CGIs, whereas about 2/3 of our NT customers use NT just to get Front Page support, and don't use any Dynamic content.
*My* "Field Experiance" would tend to indicate that the majority of the domains served by IIS servers do not serve dynamic content. Also, a good chunk of IIS dynamic content, perhaps 10%, is Perl CGIs.
So, assuming that what we're measuring is "Most common method for serving server side dynamic content, based on greatest use by domain." then CGI/Perl wins cleanly.
Other measures, such as most pages avalible publicly, or most bytes served, I'm less sure about.
-- The act of censorship is always worse than whatever is being censored. Always.
Cost 2xOracle ? Ugh. I think I'll keep writing object wrappers around SQL queries for now.
try GNU regexps, or http://www.javaregex.com/; also this review site has about 10 links to Java regexp implementations.
One of the beauties of Java - the ease of finding software and integrating it into your code.
Thats strange, I've found jsp to be faster than some of the other alternatives (especially perl). Yes jsp's compile slowly the first time, but after that it should be quite quick (although that also depends upon the servlet engine; I use tomcat 3.2.1 which is by far not the fastest, but is good enough for my needs (medium sized university)).
At least in the past (I haven't paid attention to this for some time) the JVM for most non-Solaris UNIX platforms had no JIT compiler, a poor one, or an unstable one. Both perl/mod_perl and php significantly outperform strictly interpreted Java.
It would be interesting to test mod_perl vs. Java Servlets on a neutral platform (UNIX with a good JIT) mod_perl has a slightly faster archetecture (runs in the server process), but I suspect at that point it comes down to implementation details.
In any case, if what you are concerned about is speed, use a system lets you cache quasi-static pages so it doesn't even hit your application code most times.
In the end, it usually comes down to taste/features rather than speed though. Personally, I like the perl/cgi/servlet approach of having a program that generates output over the JSP/PHP approach that intermixes code and plain HTML. For me, the deciding factor is that Perl's string manipulation rocks, and that is really what generating HTML is all about.
Like Perl, Java also has a shorthand syntax to define an entire array at once. However, it lacks some of Perl's quirky and powerful array manipulation features, not to mention hashes
I'll admit perl has some pretty damn powerful array maninpulation functions (map, grep, join, etc..). But Java does have 2 standard hash types in the java.util package that are standard with every jdk... (java.util.Hashtable, java.util.HashMap) Although, I do have to admit it's alot easier to use perl's variant..
-------------------
arcane for life
You should check out enhydra, if you haven't. No code in the html, or vice versa.
Just a FYI.... JSP is not scripting. JSPs are Java... period. They have full access to the Java APIs and are actually Servlets. So JSP, as you would say, "is a programming language and library".
oh, I just liked to write what you wrote.
So: EXACTLY.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
no, you don not have to admit that.
In all real world projects where I used jsp it was the fastest alternative.
angel'o'sphere
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
You make a common logical error in your assumptions. Just because netcraft claims there are more DOMAINS running under apache servers does not mean that MANY of them have no dymanic content whatsoever and that the majority of IIS survers do. My field experience shows me that most apache servers run static content for huge virtual hosts with zillions of little bitty domains while IIS typically runs only a few domains or only one but they are much larger and more likely to use dynamic content. Your typical ISP runs Apache because it's the free one that came with the free OS they are running cause they have little money. And, true, it's easier to host zillions of "10 meg limit" static page websites on apache. Businesses typically are running IIS and they have a need for dynamic content and use ASP.
So far we're not using Python in production, but it's probably just a matter of time.
Since the python license explicitly places it under the laws of the State of Virginia, and since Virginia has passed UCITA, and since UCITA lets the sellor make the license terms anything they want at any time they want, even after you've bought the product and started using it and your ONLY recourse to bad terms is to stop using it, you may want to think twice. ("Bought" may be the wrong word in this case, but the principle still applies.)
For these reasons, I'll no longer even consider use of Python (tho I'll admit I'm a perl bigot and the concept of syntactically signifcant whitespace is anathema to me). I used to think about learning Python, before I learned about the licensing.
--
"that's not encryption - it's a new perl script that I'm working on..." - from some Matrix parody
Actually if you follow the links to the *authors* homepage you'll see that the author has no 'expert' level knowledge of ASP etc. I think it's a simpler explanation.
Fsck cluebie moderators. I'll say what I want, offtopic or not. And fsck having to qualify every bloody statement just
I wrote a file upload component that uses pure asp, so don't even try to say it can't be done.t ml
here ya go:
http://www.4guysfromrolla.com/webtech/012401-1.sh
ChiliSoft uses Perl as the language for ASP on Unix and other platforms (including Windows), as well as some proprietary extensions. Additionally, Chilisoft's products are not really ASP, since you can't take advantage of DCOM and ADO anywhere but in Windoze-land. Finally, the ChiliSoftware implementations are subsets and often lag M$ by as much as a year. Finally, ChiliSoft is rather useless as a platform, since the most skilled (and 'productive') ASP 'programmers and developers' cannot use the toolsets and libraries they are used to.
As to your comments about the author's choices for extending Java: these are examples, and this site is used by IBM as an attractant for beginners and to stimulate exchanges such as this. Don't like it? Write one of your own. IBM might even publish it. But lave off the smiping until YOU have the cojones to put your reputation on the line (with your real name and available for peer review) as this writer has. Constructive criticism, yes. But your comments are nothing but snniping and whinging.
Remember guys, this is Amerika. Just because you have the most votes, doesn't mean you get to win.--Fox Mulder
He also got the PHP example wrong. Setting variables, escaping out with "?>", and then using a bunch of "" statements is ludicrous and wasteful.
You can just do this:
$myvar = "Some text";
echo "<html>
<title>$myvar</title>
Here is some text, and here is my string: $myvar
";
The PHP interpreter will also insert newlines in the above echo statement, since it is multiline. This is especially useful since you can pipe the resulting string through nl2br.
I can't agree more. My favorite approach (so far...I'm sure there's something better that I haven't thought of yet) is a template-driven system. Plug in the values you want, and bingo! At any time you can change the templates. Even your web designers could do this. Programmers only need to worry about the application.
I have zero tolerance for zero-tolerance policies.
Constitutionally Correct
If you use PHP as a module, the php engine is embeded in the apache process. If you use PHP as a cgi, that's another story.
If you use JSP's or servlets, you still have to communicate with tomcat over a socket. Tomcat does all the work.
The author shows some examples in perl as a CGI but does not mention mod_perl, I am amazed! For those of you who don't know, the perl interpreter is embedded in the perl binary (/usr/bin/perl). What Doug MacEachern and others did was to embed the perl interpreter in Apache. Not only perl scripts run 100 times faster (really!) but you have access to very nifty things like a pool of Database connection (statefull), you have access to all 14 steps a request goes through in the Apache process, etc.
just my $0.02
Looking for a great online backup: Green Backup
You can't really call PHP an interpreted langauge anymore, and I believe the same is true of Perl. PHP 4 uses the Zend engine, which compiles PHP before executing it, the same way that Java must be compiled before it can be executed. I would assume the same is true with most other scripting languages, such as ColdFusion and ASP. The difference is that the compiling is done at run time, so to update some code it is only necessary to save the file. PHP (with add-ons) and ColdFusion can both cache the intermediate compiled code, so that it doesn't have to be compiled everytime. I wouldn't be surprised if Perl (with mod_perl?) and ASP had this sort of feature.
I agree completely that a real comparison would be useful. Coming from someone who's day job is doing web applications, I'll say that programmer time is much more expensive than hardware, so if it takes less time to develop and maintain an application, having to add an extra server, more ram or a faster cpu is going to end up being cheaper in the long run.
I think it all depends on what you are doing. As for it being faster, the page still has to be parsed just the same, and with Zend, the difference in speed would most likely be negligable. If you have several hundred kilobytes of HTML on a page, then not outputting it through PHP might make a noticable difference in speed, but otherwise it shouldn't make a difference.
If PHP is just used to output a few variables, then it is easier to read to not have the HTML inside the PHP code. But if most of the page is generated dynamically, then it ends up being cleaner to make it all PHP code. Most of my scripts have only one set of in them. However, for any real site or application, it makes sense to use templates for any HTML generation, thus allowing the designers to change the look of the page without ever having to touch the code, along with being able to internationalize the output without any extra work besides the actual translation.
The guy obviously didn't know a lot about PHP. The first example made Perl look better than PHP, but that PHP example can look almost exactly like the Perl one:
<?php
$title = "My first Script";
$greeting = "Welcome to my first script.";
print <<<EOF
<html>
<head>
<title>$title</title>
</head>
<body>
<h1>$title</h1>
<p>$greeting</p>
</body>
</html>
EOF
?>
freakin zealots.
this is my sig.
I've been playing with Webware, which is similar to the Java sevlets + JSP model, but totally in python. You can find it at http://webware.sourceforge.net. So far I really like it. It has more structure that PHP, which is very nice, and it's in a language that is fun and easy to program in, Python. (I like the structure of the java stuff, but java is just hte wrong language for web application stuff, I'm just too used to the faster dev cycle).
Just so you know, James Gosling is the inventor of Java...
I agree that some of the simplest components are commercial, but it doesn't take too much to write one in Delphi or VC++.
No one has mentioned embedded Ruby - probably because no one has heard about it. It's a fully object oriented scripting language somewhat like a cross between Smalltalk and Perl. There's mod_ruby project that's pretty far along. I'm not sure how it compares to ASP/JSP/PHP/Perl for execution, but it's sure a heck of a lot faster for development.
--
47% of all statistics are made up on the spot.
No. Speed differences have nothing to do with platform independance. In fact, they are unavoidable since some platforms may support an operation at a low level and thus it's easy to code in the Java VM and very fast, while on another platform the same operation may require much more and more complex machine code and thus be slower.
The illegal we do immediately. The unconstitutional takes a little longer.
--Henry Kissinger
no,it's my experience from using MTS&COM
.oO0Oo.
I've seen many times IIS being resilient to having it's service stopped & it's process killed
that was on n.t.
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
because making a mistake more often than not leads to downtime when you reboot
.oO0Oo.
that alone is all most people need to know
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
You really have no idea what you are talking about. JSP provides exactly what you are asking for except it goes beyond PHP in that you can define new tags and filters externally to the page in order to increase the maintainability of the site and the readability of the HTML.
"If I can see farther it is because I am surrounded by dwarves." -- Murray Gell-Mann
If you are going to compare technologies clearly this person has left out the best one. Java Server Pages gives you the best of all worlds. It is compiled code, it has extensible tag libraries, dynamic filters, direct Java coding if needed, is completely cross platform, and runs on many server implementations including some free as in speech/beer with an Apache license and not the viral GPL.
"If I can see farther it is because I am surrounded by dwarves." -- Murray Gell-Mann
You dont know the first thing about ASP.
You can use Perl to do ASP so how are you comparing ASP which has no default language to Perl, Php or Python?
Why not at least compare say VBScript the most common default ASP scripting language or Javascript.
ASP happens to have a lot of structures that allow you to write well designed apps that are very modular. Its all about the developers. Even perl is good for huge projects if its actually managed right. This crap about one language being better than another for readability is silly. If you and your development team decide one way to write Perl then its going to be consistent. If you actually do code reviews you can keep that consistency.
Its not one language is better for a quick hack etc.
Your just pro-zope bash everything else.
Jeremy
The one and true answer is separation of content vs. application, and total pluggability between the two.
Velocity.
Anyone who does servlets like described in the article needs a brain wash...
--
Marcelo Vanzin
Marcelo Vanzin
http://www.php.net/manual/en/ref.pcre.php
Great. Now we get even more clueless newbies asking for help on c.l.p.m and refusing to use CGI.pm.
I had an argument...with the person here at the university that teaches OS design. I wonder when I'll learn --Linus
Jython rocks! It got the static but stable java class libraries with the dynamic scripting power of python. Everything JSP can do, jython servlet can do as well.
For larger project, you no longer have to mix presentation with logic like ASP, PHP or JSP, you can use XMLC with it for clear separation.
See this site for more info.
Well, actually, "Also JSP != servlet." is not correct.
If you use for example Weblogic, your JSP is compiled into a servlet,
which in turn is compiled to byte code. With taglibs there is really no need to
write servlets. You write your JSP using the tags that you've defined in your taglibs
and the taglibs points to your regular JavaBeans, where the logic is handled.
Since jsps turns into servlets, there is no need from an efficiency point of view to
write servlets, instead your html-guru takes care of the pages; programmer takes care of JavaBeans.
Works tremendously well!
Non-free: Versant. (probably www.versant.com). Since 40% of the time spent on web development in Java is :)
writing/debugging OR-mapping code (own experience) the object-db:s are really something to look out for in the future.
Problem is that versant costs approx 2xOracle...
There's only so much complexity you can support without a good language architecture. Sure, Java/JSPs are overkill for throwing together a simple site, but the really interesting projects require serious algorithmic chops.
Which is not to say you can't have serious algorithms in other languages, but more to disagree with the idea that web services are always page-based. There is a lot you can't solve well that way...
That's so true, I find that Java is best appreciated coming out of C and C++ (which was my route) and isn't the greatest teaching language because it provides a few too many things. But then, I think teaching languages should be simple - Scheme is great - and not object oriented to start.
I also wouldn't hire anyone who said "I'm a Java developer" for serious work, though I would hire someone who said "I'm a developer, and I really prefer to work in Java". Subtle difference, but important.
Calling PHP "PERL on training wheels" is a bit misleading. Yes we should compare apples to apples, and IMHO PHP vs. mod PERL PHP wins hands down not only in preformance, but also in usability.
.Would I rather use my leatherman or do I want to use a a regular screw driver. Most of you who own leatherman tools know that as pliers they are probably 95% as good as a regular pair of pliers and maybe 50% as good as dedicated screwdriver. (some times they hurt your hands, and the screwdriver would be better if it were magnetic, but I digress. . . ) They also cost considerably more than a single dedicated tool, but can preform a multitutde more functions.
Languages truely are tools, and just like out in the shop you have to make choices. .
PERL doesn't cost any more than PHP in terms of monetary amount, but I dare say it costs more in terms of speed, and in time invested in learning. I would also guess it costs more in terms of maintainablity because it more complex syntax means people need to be more more profiecient at it to maintain it reliably.
PHP was designed for the web, and excels at that. Now that it is maturing it has been drafted into a wider range of tasks, but at its core it is a web language, and its focus is fast web sites. In that respect, it is much like my proverbial screwdriver. The screwdriver can be used for a few auxilary tasks, but it generally isn't nearly as flexible as a leatherman.
So its pretty clear. PERL users like leatherman tools, PHP users prefer traditional single purpose tools. Or maybe not.
MS2k
I disagree with your interpretation of the YMTD article, and certainly with your assessment of Velocity .
However, I think that despite the theatrics, you have some good discussion points, and I (and others in the Velocity community) would be happy to discuss on our user list.
I believe that Velocity and it's kin ( WebMacro , for example) are strong, viable alternatives to JSP, and believe that after more discussion, and you actually trying it, you may see some validity to this assertion.
I invite you to repost your article to the velocity-user list (velocity-user@jakarta.apache.org). The instructions for subscribing start here
geir
http://www.asp101.com/articles/jacob/scriptupload. asp
There is an example of a pure ASP fileupload ! =)
It gives you a nice step by step with the code...
hope that helps
addbo
While "the one and true answer" may be seperation of content vs application, that doesn't mean PHP is not a choice as a language. See the Roadsend PHP SiteManager Project (http://www.roadsend.com/siteManager), an Open Source library that allows just this.
CDO is the biggest piece of hogwash I ever tried to deal with, in php on the other hand to send mail I use a single damn call mail . Not to mention the fact that in able to do anything with asp requires that it stay running for more than 15 sec at a time.
Got Code?
CF should never be mentioned anywhere ever.. CF has to be the slowest crap I have ever seen. Hell ASP can beat cold fusion on a bad day and that is not saying much. Neither one can stay running for more that 15 minutes at a time so they do not count.
Got Code?
Sending mail through the IIS SMTP server is like 4 lines of code using CDONTS. You can access a binary stream, but it's true that you do have to either roll your own file upload code (not especially hard) or cut-n-paste some off of MSDN.
Now if you really want to know why ASP is crap here it is: They dropped Java a supported environment for building COM components, pretty much forcing you to use either VB (which I hate) or C++ (which I don't know).
When I hear the word 'innovation', I reach for my pistol.
Although - IMNSHOAW - I believe that you are a bit too harsh on CF's "crappy simple template expensive engine", you are right about the JSP factor. CF will be running on a J2EE engine (prob by end of year) and will be fluently integrated with JSP (a REAL language!) while allowing you to do the simple things using built in tags. The best of both worlds!
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
I found it especially funny that JSP isn't covered. For the Hello World example, change the file extension from html to jsp, and you're done. :)
--
When all you have is a hammer, everything looks like a skull.
What about ASP?
PHP and JSP are scripting environments.
Perl CGI is a programming language and library.
A proper comparison would have been PHP, JSP and Perl environments such as Perl ASP, Mason or (my favorite) Embperl. For a more detailed (and wider-spread) comparison, see Web Scripting Tools - Compare and Contrast.
When would you need to reboot? Restarting IIS doesn't require it, not does restarting MTS or COM+ objects. Unless, perhaps, you're brand-new to ASP developement and don't use MTS/COM+ stuff.
Java is the blue pill
Choose the red pill
Zope allows faster creation of dynamic sites and the ability to manage thousands of pages via user priveledges built into the Zope platform. ASP is ok for quick hacks (but not as good as Perl, PHP or Python), but for large sites, using raw web scripting can be time consuming. Zope allows scalability using the ZEO clustering, which basically takes a Zope Object from the Zope Object Database (built into the Zope Platform) and balances the requests over a cluster of Zope Servers using replication and synchronization...and maximum flexibility by being fully open source. Zope Methods can be written and the Zope platform can be extended using the amazing ZClasses API, one of the cleanest I've seen.
Cedric Balthazar Rotherwood
Sun Certified Programmer for the Java Platform +
System Admin. for Solaris
Ok this debate is prepetuated by publishing
industry over and over again for purpose of itself
When will we learn that any interpreted languages
are slower than compiled ones, like C++ and C,
and we just should use best language that fits the
task at hand, rather than reasoning what is faster
or better is some lofty unappliable way?
Consider this,
Team of developers is more expensive than rack of
fire breathing SCSI raid enabled with all power
extension rack of intel boxes. So hire two perl
geeks to do the job, if you want some big
dynamic website and give'em plenty of hardware,
instead of hiring a dozen of C/C++ or Java
developers to implement your site.
If you build a game, don't even think about any
of interpreted languages, or ones that even
started as interpreted, such as visual basic, java
or python. Stick with C++/C, you will benefit in
long run.
You want a cross platform gui that will interface
legacy severs around the world with little
resources on your side, get few Java hackers.
For gods sake, everyone should do their job to the
best and should not drag people into unproductive
holy wars like our assembler is better than your
assebler because it has more instructions...nyah
nyah...
just give it up people.
Hello, where the mention of ASP? the definitive scripting language of the Microsoft platform. Why would you use php or perl on win2k when ASP is already installed and has more components.
Sure, it's not "free", but is was made for developing web applications and is extremely easy for HTML guys and designers to pick up.
When evaluating a scripting language, ease of use matters. Time is money!
Oops, you missed the fact that it runs on Windows, Linux, HP/UX, and Solaris. Hardly "locked into a Windows world".
ColdFusion System Requirements
The coverage of Java is very poor, and the omission of JSPs is a big deal. Most sites combine servlets and JSPs, which is a very powerfull combination.
I also found it odd that the example extended GenericServlet, not HTTPServlet.
I dont have a
The author of that article obviously does not know about Apache mod_perl (http://perl.apache.org/), HTML::Mason (http://www.masonhq.com/), or Embperl (http://perl.apache.org/embperl/).
Those provide a PHP or ASP like templating system with full access to the Apache API and all of full fledged Perl (and thus the CPAN modules). It's way better than PHP!
Anything that can be done in PHP could be done with either of these systems. I think it would be worth doing to port a lot of that fancy PHP HTML magic over to either HTML::Mason or Embperl. (May the better engineered solution win!)
There is, additionally, an emacs extension called "mmm-mode" (found via the HTML::Mason site) that makes psgml-html mode and cperl-mode co-exist! The perl parts are in cperl-mode, and the HTML parts are in HTML mode. It's really cool!
a high school student could have written that crap.
he didn't even get into the way that perl or java are normally run (mod_perl, tiger, dynamo, jsp), the types of libraries that each language provides, the open source level support, etc. etc. etc.
but what do you expect from a guy who would have his saturn painted like vincent van gough's starry night. (not to mention that he got a saturn in the first place, gack!) and then wrote a poem about it. and put cheesy midi on the page with the pictures of his car.
i bet erik zoltan is made of pure cheese.
--
in this age of communication i'm just not getting through
guess Im confused... what can Perl do in string-manipulation that java cant?
I just love java as a langauge, which is the main reason I use it (java servlets and jsp). For bigger sites I'll use servlets, for something simple I can use jsp, and sometimes I'll mix them.
At least that is the jsp code I get to read usually.
All of these 3 files eventually wind up in different directories, adding so much overhead to development that I am not convinced that servlets+jsp is an effective way to build web sites.
It [java] is much neater, so you have a higher chance that the code is re-usuable, but as I see it, code usually gets rewritten rather than studied anyway.
I'm still trying to figure out what people mean by 'social skills' here.
There are at least 3 styles you can use servlets: by themselves, with html in strings inside java, with the html in the jsp or with the html inside a class model, like org.apache.jakarata.ECS .
How the database is accessed, and how you can implement a database (caching) layer is another important performance issue.
Each style would merit its own performance review, and its owb assessment of coding speed and style.
I'm still trying to figure out what people mean by 'social skills' here.
Not sure what you mean by flexibility.
Scalability/Performance: If we're going to talk typical Slashdot-geek "I made a web site that generates random yo-mama jokes in PHP," then it's anybody's game. For actual high-volume sites, however, this all depends on the "container" (i.e., application server) the scripts are being run in. Big e-commerce sites will invest in a multiple machine cluster, running a bad boy like BEA WebLogic, and will out-scale/perform anything comparable on the market. Java is bar-none the most robust technology for highly scalable sites.
At this level, though, it's no longer about the fastest script compile time - it's about scalability of servers running your business logic. Again, this moves way beyond scripting languages and becomes a matter of robust application server technology.
www.Jackassery.com
...then take a look at Eric Meijer's CGI library in Haskell. Using Haskell gives you all the power of a modern, pure, powerful, strongly-typed functional language [oh well, that's lost 99.9% of the audience.] Read the paper here and you can find the source here. With the forthcoming .NET integration this should become easy to integrate with all the other stuff a web site has to deal with.
While the article itself isn't too bad, they seem to neglect Cold Fusion (and ASP, but I hate ASP, so you wont see me running to it's denfse). I love PHP, and use it often. its a great language. But the development time is nowhere near as fast as cold fusion. I'd take this article alot more seriosuly if they bothered to compare a few other languages.
----
One of us needs to stick ones' head in a bucket of ice water.
- Hobbes
I'm sick of people assuming that their favorite pet technology is better, faster, smaller, etc. than the competition. Whether this occurs out of malice or ignorance, it's worse than any intentional FUD in the marketplace. Hard data is the only thing that matters in software engineering.
So, I'm happy to say that both you and the original poster are wrong. At least on the Win32 platform, where Java has an excellent VM, PHP is 1/3 to 1/2 times slower than the equivalent in Java. I know because I just finished a series of load tests earlier this week comparing the two.
On a 1x1 GHz Win2K machine, I set up Apache 1.3.19 running PHP 4.0.4pl1 and the Resin 1.3.b1 servlet container.
The simplest case, a hello world page in PHP ran at 300 h/s. The exact equivalent in Java, a hello world JSP, ran at 380 h/s. A more advanced case with a large amount of dynamic page output ran at 170 h/s in PHP. The equivalent JSP ran at 350 h/s. In addition, Java scaled far better for multiple concurrent users. It scaled better than linearly, while PHP scaled worse than linearly. Finally, if you get rid of slow-ass Apache, the Resin servlet container + web server ran at double the speed--over 760 h/s.
If PHP is faster on some *nix variant--and I have no idea whether it is or not--my bet is that it's because the Java VM sucks on that platform. Try running PHP vs. Java on Solaris and see who comes out on top.
The only certainty is entropy.
That's the most pointless article I've seen in a long while. They neglect to mention anything except language syntax and implementation. If that's all that mattered, any developer would choose the one which was most familiar or which came most naturally to him/her. I do see a small mention of "power" in the conclusion, which they seem to think PHP has sacrificed in favor of ease of use. They might even be right, who knows.
I wonder if Hemos even took a look at the article before he posted it. (Hmm, slow day.. Hey lookie here, an article comparing PHP and Perl and Java servlets, that should get the flame wars going!)
-- If no truths are spoken then no lies can hide --
No support from the community, huh?
15 Seconds
Active Server Pages
4 Guys from Rolla
ASP 101
There are a lot more, but I'm getting tired. Oh yeah, and there are all of the companies making components for ASP. Right. No support. Good troll. Try harder next time. Oh, and ASP has nothing to do with CGI. But, good try.
I think you're a twat
--
MadCow.
I used to have a sig, but I set it free and it never came back.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Even if we could get somebody to be objective, their objectivity is bounded by their knowledge. Facts can be as easily distorted by ignorance as malevolence.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
If you were IBM, wouldn't you like to take Linux and show Microsoft that, among other things, it's a great suppository? Neglecting ASPs in a scripting roundup is just another brick in that wall.
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Compare the languages on the same hardware with a controlled loading environment.
Do some problems in a timed environment, tapping that whole 'ease of programming' thing.
Give some to FNGs like me, to test the learning curve.
Give a stuffed penguin to the winners.
Publish some results.
Call it 'Script Race '01'. (no TM)
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Whilst the Article was OK as a 'taster' it lacks the depth to be considered a practical comparison. All the examples coupled the content with the code, a big no-no in an industrial strength system.
Take the Java Servlet example, you only ever implement one Servlets in that way; Your first hello world Servlet. The problem is that it couples the content with presentation, something even the most light weight Servlets will avoid by implementing some form of Page Wrapper class to abstract the layout from the content. It also ignored JSP and/or using the Model-View Controller pattern.
Whilst I know Perl and PHP do suffer from this coupling problem, since the article does not do Java Servlets Justice, I am inclinded to believe the same is true for those too.
- PHP generally handles errors better - with PHP I see informative error messages instead of "Internal Server Error" in my edit-debug-run cycles. Of course, you can use CGI::Carp 'fatalsToBrowser' in Perl to get better error handling, but even with that turned on, I still see "Internal Server Error" more often with Perl than with PHP (maybe I'm not using CGI::Carp 'fatalsToBrowser' correctly? The Perl programs I work with call subroutines spread out over many files - does CGI::Carp 'fatalsToBrowser' need to be in each file?)
- PHP has a standard mechanism for HTML embedding - with Perl, you need to choose between Mason, Embperl, and Active Perl with ASP. (Also, do any books cover Mason or Embperl?)
- There are some very quality open-source PHP programs available. Some leading examples: Drupal, a Slashdot-like news system, phpShop, an e-commerce system, and Chora, the nicest web interface to CVS I've seen (BTW I've prepared a zip file of Chora so that people can have an easier way to download it than by using cvs checkout. Use Ctrl+F to search for Chora here)
- cleaner syntax for classes and functions
PHP vs JSPPHP:
$adjective1 = 'quick';
$animal1 = 'fox';
$adjective2 = 'lazy';
$animal2 = 'dog';
print "The $adjective1 brown $animal1 jumps over the $adjective2 $animal2";
JSP:
String adjective1 = "quick";
String animal1 = "fox";
String adjective2 = "lazy";
String animal2 = "dog";
String output = "The " + adjective1 + " brown " + animal1 + " jumps over the " + adjective2 + " " + animal2;
angle-bracket percent equals output percent angle-bracket
sig: BeanShell: lightweight scripting for Ja
Several people pointed out that Java is slow. Well, it is slow to load into memory, but once loaded it is tolerably fast. Servlets stay loaded in memory once they are run once, so the second user that hits a given web page gets MUCH improved performance. How does this compare with Perl, which has to be started each time the page is accessed? Also, Java servlets can generally pool database connections, which is another big performance boost. Can you do these things in Perl or PHP?
Perl and PHP users please forgive my ignorance. I am only trying to point out questions this article should have addressed. I don't mean to knock your choice of language.
I'm a little surprised to see this article on an IBM website, since IBM sells some really good tools for creating Java servlets and doesn't make a dime off Perl or PHP. You would think they'd recommend servlets more than this article does.
I thought assembler was the fastest.
On NT, PHP can be used as CGI, or ISAPI, which is the more common case.
--
Two witches watched two watches.
Which witch watched which watch?
You can download any of the free compotents to do it for you, get online and do a little search on how to do it yourself.a d. asp
Here is one of many:
http://www.asp101.com/articles/jacob/scriptuplo
And what about CDONTS? Or any of the many other components to send emails via ASP?
And *please*, remember, ASP is a *frame work* it's not a language.
You can write ASP code in any language that you desire.
--
Two witches watched two watches.
Which witch watched which watch?
Well, since you asked for it... here are couple of links.
, 12 249,2646052,00.html
s ht ml
1 a. html?tw=programming
http://www.zdnet.com/enterprise/stories/linux/0
http://www.4guysfromrolla.com/webtech/030200-1.
This I *highly* recommend:
http://hotwired.lycos.com/webmonkey/99/46/index
--
Two witches watched two watches.
Which witch watched which watch?
Actually, that is the best way to program in PHP. Escaping in/out, as it turns out, performs much faster on the server.
Also, in a multi-disciplined development environment, it's much easier for the graphic artist to read HTML in between the PHP than it is to read the HTML embedded in the PHP.
But what do I know, beyond my own first-hand experience?
-----------
Try Velocity. It separates code from presentation much better than JSP in my opinion. We're currently using it where I work, and it works out quite well!
You can accomplish anything you set your mind to. The impossible just takes a little longer.
The great advantage to CF is the extent to which it enables very easy and quick database access. It is also an easy language to learn if you know HTML and SQL. Used in conjunction with Javascript, ColdFusion apps can be very powerful.
I agree that it is somewhat simplistic and you can't use it on its own unless you have very simple needs, but your comment that it only works if you're "locked into a Windows world and you don't want to do anything complex" is patently false.
I agree with your general aguement 100%, right tool for the right job, but you are entirely wrong on java.
Forget Java servlets, try JSP. JSP source is compiled by the JSP server ( eg. apache tomcat ) right before the page is viewed the first time. This makes JSP potentially very fast. I don't have benchmarks, but I'd bet a mature JSP server would kick most other scripting languages' butts in speed.
JSP also has some very cool features useful for larger projects. Taglibs allow you to make your own markup tags. This allows you as a programmer to hide the implementation details from the designers (as not to confuse them, separation of content/presentation, etc.). Check out info on taglibs at the apache tomcat web site. PS I'd love to see taglibs in PHP.
JSP allows you to store objects at different scope levels. So you can, for example, have a method execute at startup, and the result is saved in application scope for every session of your app to use.
Many of the open source web applications I see out, IMHO, there are better suited for JSP then PHP. I NOT a big fan of java and I understand the pressure to use PHP because of more talent out there (I had to make that decision recently), But I think more people should download tomcat give JSP a try. It might be the better technology for your next web project.
PS. those colors really are an improvement
Based on upvotes, Ageism is the only "-ism" Slashdotters care about and think isn't SJW
PHP is the fastest and isn't that what really matters... I've tried many languages for my web game (www.woofcat.com) with a few thousand players and CPU usage is always 0.0... You can't do better than that...
Es ist nicht leicht ein Gott zu sein. www.woofcat.com
It's stupid to try to compare the ease of use of languages... You have to admit that jsp is s-l-o-w.
Es ist nicht leicht ein Gott zu sein. www.woofcat.com
Has this already been done? If it has been done, why is this article being posted in the first place?
Sorry but have I wandered into some alternate universe where java programmers are slave labour or something.....
In agreement with the guy who did the first reply....most commercial apps are just methods to process and present information. Sorry if this sounds obvious to most people but you seemed not to have noticed.
How can you be as naive as to rate languages in such a way? Languages are tools that are good for some jobs and crap for others... rating them on one feature is stupid ..yes java is slow but you cannot build distributed apps in vb with the same ease as java..
You have anything to back that up, or are you just trolling? I've found java quite useful for large projects.
Reboot macht Frei.
I hate to be rude, but that's a load of mindless drivel.
When contemplating large, commercially successful entities, objectivity is always the "least hypothesis": They couldn't have gotten where they are if they weren't objective in the first place. The principle of Enlightened Self-Interest proves this quite factitiously.
--
Dear Slashdot: Why, yes, I would like fries with that.
Right: Conflict of interest. We'd be fools to trust anything IBM says on the subject. It's a very good point, and it raises serious questions about the independence of journalism in what could be called a "capitalist command economy" such as that of the USA: When vested interests control information, who can you trust?
This leaves aside the fact that IBM was Demon-of-the-Week in the hacker community fifteen years ago, but they've now been "rehabilitated", like Kruschev. Scary stuff, when you think about it.
--
Dear Slashdot: Why, yes, I would like fries with that.
Thank you for mentioning Scheme, a sorely neglected gem of a language. In fact, until C and C++ support arbitrarily recursive macro substitution like Lisp does, I can't see any sense in taking them seriously as programming languages -- particularly for demanding real-world applications like CGI: C is unbeatable for writing trivial UNIX command-line utilities like ls, but it's just not scalable . . . and the fact that Perl was implemented in C should give us pause about that language as well.
--
Dear Slashdot: Why, yes, I would like fries with that.
Hello?
Yeah, sure, it's "politically incorrect" to speak in public about technologies that are out of favor with the Open Source Taliban, but is it so wrong just to mention the most widely used dynamic content technology in the world?
Can we have just a little open-mindedness around here? Just a small dash of fairness and honesty in our reporting, for once?
--
Dear Slashdot: Why, yes, I would like fries with that.
Amen!
intellectual property law is philosophically incoherent. it is your moral duty to ignore it or sabotage it
LOL, you may be good as a microsoft whore and a troll, but thats it.
Your brain cell isnt up to much more, you best not tax it too much so go back and play with your toys.
People like you really lower the average IQ of slashdot members.
viral sig pls copy and spread Corruption in TFC
You were the one avoiding the issue, now shut the fuck up and dont post to a story again until you you know what you're talking about.
Moderators, moderate this off topic fool and me down.
viral sig pls copy and spread Corruption in TFC
What difference does it make. Something comes by default as SHIT and BROKEN and you dont think it makes a difference? The internet is littered with morons like you who write broken barely functional ASP with the one brain cell they have.
Hey everyone - windows is great, sure by *default* it needs patching and reinstalling every few months - but hey you can do that!
viral sig pls copy and spread Corruption in TFC
The issue of PHP vs Perl is more an issue of personal taste.
PHP is mostly a subset of perl(in fact, early versions of the PHP interepter were written in perl), with many of the funtionality used to be part of the syntax moved into standard library.
It also has somewhat cleaner OO approach.
The fact that it was designed for the web shouldn't prevent from PHP from spreading other areas, just like the fact Perl was written as admin utility didn't prevent from Perl taking over the web.
Concerning speed, one will have to make lots of benchmarking to find which is faster, althought Zend likes to build lots of hype around's PHP's speed, i have yet to see a real, well done benchmarks of mod_perl vs mod_php, in similiar applications.
Anyhow, I wonder why the article didn't cover Python. It's clean syntax, excellent OO, namespaces, as well as the famous white space many hate, make it very suitable for big projects.
Shack doesn't use any homebrew server-side code. It uses PHP4 (.x pages) and a little bit of comment system was done in C. (.y pages)
+++ATH0
Sure, CF has its uses, if you're locked into a Windows world and you don't want to do anything complex. However, ColdFusion is quite firmly locked into a small box of features, and the moment you want to do something outside that box, it's time to switch languages. Extending CF is a joke. Sure, you can write a custom tag. Not terribly versatile. You can even write new functions, if you know C++. No thanks.
ColdFusion is a joke for anything beyond the stereotypical database plug-in-dynamic-text-here site. Which is fine, that's exactly the market Allaire (Now Macromedia) targets CF to. The guy with the little static website describing his car repair shop and what sort of services he offers. CF to the rescue! Or something.
But let's say you want to pass around relatively complex data with CF. Well, CF arrays are limited to three dimensions, and you have to declare how many dimensions you want ahead of time. ColdFusion's idea of a list is a delimited string. As a PHP coder, I literally laughed when I read through a book of CF's support for "complex" data types. It was utterly pathetic. But, CF gets away with it because people that CF appeals to don't need that sort of power.
Me, I do. So CF can go collect dust next to the NT server I don't need either.
Besides, I think it helped get me my new job :-).
Eric
--
Be who you are...and be it in style!
I'm also wondering why this article compared PHP and Perl to Java Servlets, rather than JSPs (which are a little closer in concept). In practice, Venice uses a combination of both--servlets for front-end processing, and JSPs for easy output formatting.
And, of course, the Java architecture leaves me open to employ new techniques at a later time, such as object relational mapping (using projects like Osage or ObjectBridge, both of which are similar in concept to the commercial product TopLink), embedded scripting (using an engine like Rhino or Jacl, or, yes, Jython), XML/XSLT rendering (using Xalan or something similar), and other techniques, both those that are part of J2EE and those that aren't.
But, in the end, I agree with you; use what you know, and use what you think works best. Other people may prefer something other than Java for a Web site project. Fine by me; I'm not running their projects, and they're not running mine.
Eric
--
Be who you are...and be it in style!
I've been using Webware lately, which is a Python servlet engine. Very similar to the Java servlets, except without a lot of the verboseness that Java demands. For Python there's Zope as well, but I found it unwieldy, and not very Pythonic.
I'm more sysadmin than web developer, but the 30 or so developers at work have pretty much unanimously shunned ASP. As one woman explained, once you get past a couple of variables on a page, ASP gets very cluttered, and she (for one) felt it was harder than Perl when trying to understand someone else's code. But to be fair to ASP, it was out quite early in the game, so picking on ASP is like picking on Windows 95. At the time, it was quite good. As far as what the developers *do* rave about...the top 2 guys at work are stoked about Python. Not so much from a performance standpoint as a technical elegance standpoint. So far we're not using Python in production, but it's probably just a matter of time.
As a writer for IBM's developerWorks, I have a good reason why Microsoft's ASP and Allaire's Cold Fusion products weren't mentioned in that article. The editors reject references to non-open source applications.
Also, ASP is, at best, a weird framework for CGI development. It supports a number of languages like ActiveState's PerlScript, but the default language is the demon-haunted VBScript. If there's one language that demonstrates ad hoc design, it's this one. Two incompatible assignment operators? Thanks!
Lest you think I'm casting aspersions wontanly, I do help maintain the ASP XML-RPC library. My ASP pain is real.
--
Care about electronic freedom? Consider donating to the EFF!
And that's exactly the point - purists. I have come up against a number of these fascinating creatures in my time. Their ideology is so fixed you just give up and ignore them. One project I was lucky not to be on, one such purist wanted to send radar feeds over RMI "because that is the way it must be done in an OO world". Let's try tracking 1000 different objects at 20hz and shuffle that over the ideologically pure way. This project ended up being 2 years late (from an original 18month timespan) and went on to use C++ and raw sockets as the communication mechanism.
You wonder why languages like C++ and Java are winning the mindshare of the developers over "pure" languages like Eiffel and Smalltalk? Stupid comments like this, and the people that make them are the bane of a commercial software developer's life. I have yet to see one actually produce a real, working system (and I've run across probably a couple of dozen or more in my code-development life). The reason - complete inflexibility. There is only one "true" way and all others are punishable (and yes, I've seen them try that trick with management).
So, use the right tool for the job. That tool is the one that gets things up and running and maintainable in the fastest amount of time.
Life is complete only for brief intervals in between toys or projects -- John Dalton
Of course that's irrelevant if you are enrolled in a decent CS program. At least where I go, they're teaching me about large-scale application design, specifcation, data abstraction and modelling, OOP, functional programming, etc. To quote one of my professors, "A language is something you learn over the weekend. If that's not the case, then you're in the wrong field." That about sums it up. The only real skill you need to make the leap from Java to C++ is a firm grasp on memory managment, which can be gleaned by hewing to the following maxim: for every 'new', there must be a 'delete'. Simple as that :) Everything else is just details, or is not worth learning. Like operator overloading. Avoid that like the plague.
--
I think there is a world market for maybe five personal web logs.
There are many more alternatives for server-side programming. If you look at all the possibilities in such a shallow way as the article does, you can always safely choose PHP - it's simple and gets the job done - or whatever language you're most proficient in. In other words, the article is 100% redundant. IMHO.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
Java leaves your idea of PHP dead in the water for one big reason - with Java you write your application classes seperately from your HTML generation classes/JSPs/whatever. Then you use the application classes in both the web site and any number of different apps, without having to write them as 'web services' or whatever. If you wrote your application classes as data abstractions of your app data, using the Observer/Observable pattern, you now have shared data objects as well as shared code.
I guess people just quit using it. Maybe it exited.
now we need to go OSS in diesel cars
Oh really? You say "peddles" so I assume it's not for free. So how much would it cost me to buy the BSD/IRIX/Linux/Solaris versions?
now we need to go OSS in diesel cars
vanza wrote:
Great. Now how do I plug modules of other languages in there? Or more to the point, why was this designed to be specific to just one language? My prior post did say "and total pluggability".
now we need to go OSS in diesel cars
I've found that C programmers who come from a heavy assembler background tend to know how to handle pointers a lot better than those for whom C was their first language. So I certainly agree with you about the "first programming language" syndrome. There being no one language that uses all technologies (intentionally), a programmer who knows only one is essentially inexperienced in computers, no matter how many years they've been doing it (for the most part ... surely there are a few exceptions, though most would have picked up another language within a few years).
now we need to go OSS in diesel cars
CGI is not a scripting language. It is an environmental programming interface which many languages can use. If you want to make comparisons validly, you would compare languages to languages (e.g. ASP vs PHP vs others) and environments to environments (mod_whatever vs CGI in Apache, or Apache vs Roxen vs iPlanet vs IIS).
now we need to go OSS in diesel cars
Businesses typically are running IIS and they have a need for dynamic content and use ASP.
SERIOUS web businesses run Java.
It would have been more apropos to use a JSP, not a servlet in this comparison. It it typically considered bad practive to embed HTML code in a Java Servlet. Servlet are used for business logic and communicating with backend systems. When it's time to render the presentation, use a JSP:
<%
String title = "My First Script";
String greeting = "Welcome to my first script.";
%>
<html>
<head>
<title><%= title %></title>
</head>
<body>
<h1><%= title %></h1>
<p><%= greeting %></p>
</body>
</html>
coulnd't have said it better my self.
War is necrophilia.
I'd be interested in your views of enhydra VS velocity. Did you try enhydra and reject it?
War is necrophilia.
The components are all out of process activeX calls. Every control called adds lots of overhead to the ASP page and ASP is nothing more then a framework for calling activeX components.
.NET pretty soon why bother reviewing it?
You can call activeX objects from PHP or perl too and you can use perl in ASP.
In the context of this article I'd say ASP has no place. It's not a language, it's not platfrom independent, and it's on it's way out. ASP will be replaced by
War is necrophilia.
Does anyone knows a free PHP-compatible object database ? I'm fed up to death with SQL transactions which are bulky and inefficient when interfacing with Web pages. A persistent-transactionnal object database is my wet dream...
I would have to concur that this article really did not hit its mark. The four sentence conclusion was a waste of digital storage space.
All this article did was cloud the decision making process for neophites even more.
Where the article should (or could) have gone is into detail on when to choose the various technologies. Why and when would I choose PHP over PERL over JAVA? What are the performance trade offs for using each? What language features does is support?
Paying a little more attention to meat rather than trying to get something published would have benefited us all a lot more.
RD
Bravo... At my company we've encountered this exact issue.. There are various elements in our organization that have differing skills. Some artistic, some executive, and others coding guru's.
Since Perl was a local favorite, we did something that I assume is similar to "Velocity" referenced elsewhere. Basically separate engines produce HTML (either through flat pages, or through cached perl-scripts (similar to FastCGI or Apache::Registry)), and then a template merger will take important parts of the various pages and produce the final HTML. The approach is generic enough to allow side-content to be applied (kind of like a static layered HTML).
In this, a template is specified for a directory (via putting a file and possibly munging a config), then throwing cgi's or htm's all over the place.. Exec's can use Front Page, or artists can use Photoshop, and us guru's blow in complex perl code. The best part is that it's transparent... Nobody need learn anything new.
Well, unfortunately that only seems to work efficiently with perl.. So basically you'd have to reinvent the wheel for each language, since there would be a different problem set.. Java wouldn't be too bad (a la Velocity, I'm sure), PHP would probably be a b*tch, and so on.
One slight addition was going to be the general piping of HTML to the merging engine. Thus non-Perl CGI's could just be exec'd and passed through. I'm sure through post-filtering in Apache you could accomplish this just fine with any other language.
The problem mostly arises in how you generate the HTML around the actual data you're trying to display (i.e. the table or pretty printed dynamic forms). Creative uses of templates could work. But mostly we resort to language and package specific methods: CGI.pm, embperl macro's, PHP thingies, etc. Don't really have an answer for that..
Another idea could be the micro-translation of data-types into HTML widgets... The recreation of the document (a la XML descriptions) with an associated style sheet could be ideal. Especially if this is all passed to the browser for final construction.
Other issues come from sidebars and dynamic menus.. The graphics designer will make all the reall cool button graphics, but how do they implement the switching logic without doing any code. I'm a big fan of static (non context sensative) menus, but on bigger sites that's just not practical. The only solutions I've come across require definate communication between developer and artist.
I'd be more than happy to learn what other's have found.
-Michael
-Michael
Cocoon is much better at this. JSP's only invert content and presentation. JSP tags do separate them in someways but cocoon is much more powerfull.
And who says you can't teach old dogs (or mainframe jockeys) new tricks?
thelocust[dot]org
Come on folks, you can pick up PHP in a day. You can read the entire online documentation guide in four hours.
If you're going to hold this party line of avoiding new tools, just keep it in mind next time you crack on a forty-something who insists on doing the job in COBOL.
Where do you get this from? Java is shoddy implementation of its own chosen paradigm. I'm sure OO purists would more often recommend Eiffel to Java if you are speaking purely from a elegance perspective.
As elegant as it may seem to create a modular architecture for creating content, the web is page-driven and this is the best way to produce dynamic content. Html-in-code is dead. Long-winded OO syntax for producing html is dead. None of the Java solutions for producing content are going to last beyond the hype phase. The popularity of PHP is simple - it works, and it is only as complex as the problem it is trying to solve.
I agree completely. The article does not explain the basic difference between these three approaches, it gives no guidelines when to use them. Just publishing examples is simply not enough.
And the problem is not only the Java examples. Just like the missing JSP pointer, I would have expected pointers to embedded Perl scripting, too. And to template-based systems, for those who want to do real work.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
The way to create the best application possible is to take a langauge you know well, and use it. Period. Suddenly going and studying "Language X" because you think it might be best for a client while doing work for said client likely will create a lot of headaches and long hours for everyone involved. If you find out in the end that it wasn't the langauge you should have used for the project, you're screwed.
Optimize the code you know how to optimize, and use (properly coded) external tools to handle requests you can't handle well on your own. Breaking up large programs into a series of smaller ones is acceptable; look at KDE. One tool that I am surprised does not get more publicity is FastCGI. It is the only langauge and web server independant (more or less) way I have found to speed up CGI scripts. Perl scripts coded for mod_perl more or less port easily to FastCGI, with most of the performance boost. And here's the real kicker; unlike mod_perl or PHP, which take up huge chunks of memory, mod_fastcgi for Apache does not. A small handler simply hands off control to one or more copies of your program running on the side, possibly even on another server!
I've used FastCGI extensively on systems that otherwise could not serve the load they had to handle. While it is not used as much as mod_perl or PHP (it no longer is in the core Apache distribution because it evolved too rapidly), I strongly encourage people to consider it a choice.
There is no mention of JSP, the current standard for generating HTML with Java Servlets. Just this makes the article loose all its credability. People use Java Servlets without JSP mainly to generate non HTML content, such as images or sound.
Sindri Traustason
"It takes two to lie, one to lie and one to listen"
Sindri Traustason.
What about ASP and ColdFusion? Gee, why didn't I see them here? And what about the homebrew server-side code that the Shack uses? That site's uptime and responsiveness is greater than that of Slashdot, which is primarily due to the server running BSD rather than Linux. And that web server doesn't even have a RAID cage (the proof is in the "0 comments" lines beside some of the mid-March articles, due to a missed backup).
"Ancillary does not mean you get to rule the world." --U.S. Circuit Judge Harry Edwards, speaking to the FCC's lawyer
Dude, I was responding to the post about there not being any community support for ASP. My point is that there's HUGE community support for ASP. Who was talking about whether or not it's a language? And, on top of that ASP IS platform independent. Ever heard of Chilisoft ASP. And why is platform independence such a big idea, anyway? Most people don't suddenly decide to change server platforms in the middle of a project. That's generally decided a long time before the project is started, so platform independence is usually a moot point.
As someone else commented, ASP is far from the most widely used dynamic content technology. I refuse to call it a technology since it consists of one dll which exposes objects written in C++ to perform as a layer to CGI. That's all it is, an object layer to CGI. ASP is not a language, while PHP, Perl, and Java are.
.NOT will make it a compile-on-first-run library. It'll first be a pseudo-compiled thing which its creator then plans to drop for something completely different. Unlike the other 3 languages discussed in the article, ASP has no support from its inventors or the community, one of which is always needed to keep it desirable for use.
ASP in 2 years will have no relation to what it is now.
---
Developers: We can use your help.
IMHO that article nor can any other give a definitive insight as to what someone should use to manage their site.
Example, I was using PHP before for my site, and chopped up a random image script for chick pictures, and my server load would go sky high, from loading nothing more than pictures... Now php for content was fine but the pics killed me.
Over to embedded perl. Works well I even use it for certain tasks here and there, but nothing major. Python, well its fine but not suitable for me, since my site is small. I wonder why eperl wasn't mentioned, nor was the latest entry Curl.
Java is a morbid joke under most *nixes, at least in my experiences. SSI is ok but again for heavy content, sites with massive interaction from the server to client, it can become cumbersome too.
Anyways enough ramblings... I do however think I have thee ultimate old school solutions for fixing my site without using any of the above!@!@... Combos of sed/for scripts which till this date have done me more justice maintaining my site
P.S. nice colors going on here maybe that shit looking brown over yellow should be changed to this too
© GBonics 101
360 degrees of Karma
While I know the answers to a couple of these questions, I would have liked to see a really thorough side-by-side comparison (at least of performance.) Anyone know of anything like this?
The article also incorrectly states that there are no hashes in Java. This is also quite incorrect. The java.util.Hashtable class is one example of how to do this:
import java.util.Hashtable;
Hashtable numbers = new Hashtable();
numbers.put("one", new Integer(1));
numbers.put("two", new Integer(2));
numbers.put("three", new Integer(3));
System.out.println( numbers.get("two") );
The above code will, of course, output "2". The Hashtable supports having ANY object used as a key, not just a String. As well, Java has a Properties class which pretty much has the same functionality, but can be loaded and saved from a file.
Also, those who are interested in developing web applications should have a look at Velocity. It's much cleaner than JSP in that it more closely enforces the separation between code and design. I'm currently using Velocity in a web application project I'm working on and it's working out wonderfully!
You can accomplish anything you set your mind to. The impossible just takes a little longer.
http://www.webobjects.com i saw a demo of this NeXT product in 1996. this was as amazing and advanced as every NeXT product were for their time. because NeXT was bought by Apple this is now an Apple product. it could make a comeback with Macos X. it seems to have been forgotten but i'm curious to know how it evolved. apparently hey're going from Objective-C to Java.. does anyone still use this software ? did anyone evaluate this technology in the context of today ? i know it's not opensource so no "it's closed software !!" flames please
Actually, BOTH HTML-in-code and code-in-HTML are dead. The one and true answer is separation of content vs. application, and total pluggability between the two. The ultimate solution will work with any content/information form (HTML, XML, etc) and application form (C, C++, Perl, Java, Scheme, etc). This is organization and the web still majorly lacks it.
Don't get me wrong here. I love PHP. I did LinuxHomePage.Com in PHP in one day as my very first PHP project. It was great and PHP was very easy to work with.
In the long run, mixing content and application is bad as systems get far more complex. One critical need will be the ability to change one or the other. By having them be fused together, it becomes more cumbersome to make those changes.Some people are inherintly more program/application development oriented. Other people are more information/content development oriented. And still others are graphical/artistic oriented. Few people have the capability to be all that and good at all of it at the same time. So it will be necessary to divide the development (and change) functions and thus also necessary to divide up the entities these different people work with to implement and deploy the components they do.
An author of an article can't write the page layout, but she does need to write the article. She can't concern herself with what tag needs to be inerted at the top to get the properly rotated ad banner inserted. She can't concern herself with how to lay out the menus on the left side or the right side.
The very model of dividing things up at the page boundary is what is wrong. We got fooled into thinking of that with HTML itself because the tags were (at least early on) easy enough for even a non-techie document writer to work with. But today's web applications bear little resemblence to a hierarchy of documents for which HTML was designed. Our thinking needs to be along the lines of keeping separate, and dynamically merging in the appropriate way, the various components that make up what it is we are accessing. That is where we are headed and we best be prepared to deal with it, regardless of what our preferences are for things like content language or programming language.
now we need to go OSS in diesel cars
Apache's cocoon is a basically jsp done right using XML/XSLT.
No one uses scripting languages to display static text. The comparisons were meaningless.
A really good article comparing any server- side technology would compare:
Never play leapfrog with a unicorn. Or a juggernaut.
Calm down.
It depends on the background of the java developer...
I've found that java developers who come from a heavy c/c++/unix background tend to know what's going on underneath the language -fairly- well, and understand how to do things like work in a debugger, work with a profiller (and interpret the results from said profiler!) - as well as handle a lot of things outside of direct development, i.e. system maintenance, development environment tuning, etc... etc... etc...
I find that developers for whom java is their first programming language, tend to be very weak all the way around. (Then again, i've found that to be true for most developers who are on their 'first programming language').
(I do want to get back into doing regular C++ programming, it's been about 2 years for me, hrm, perhaps its time to re-install that BeOS cd...)
--Dg
This is a really crappy article, at least the part that applies to Java. First of all, the correct analogue to PHP would be a JSP, not a straight servlet. With JSP, the first Java example would not be any longer than the Perl and PHP ones.
Also, that business about having to be careful not to confuse the class names is hogwash: that's what packages are for.
I've done sites with perl, JSP and servlets. Experience has taught me that you're usually better served using what you're most comfortable with -- it's easier to learn new tricks with an old language. Admittedly, it is less fun, but when the boss is yellin', you need to get it out fast.
The difference, I think, is mostly that these options are reflections of certain approaches to programming. Whichever approach you feel most comfortable in, that winds up being what you use the most. Hardcore *nix will like Perl because it reminds them of long summer nights with sh and awk. Computer scientists will like Java since it's "clean" and "pretty" and "portable" <snicker>.
Use what's best for the job and leave the flamewars for Happy Hour.
"Honey, it's not working out; I think we should make our relationship open-source."
I love it, it means our java developers can concentrate on logic, and our HTML designers only need to learn a small handful of JSP tags, but can concentrate on their display.
--Dg