In which we wander around the various software stacks and find out what Rob knows and doesn't about building web applications.
I recently moved this site (Late Night PC Service) and my travel journals (On Beaches) to a new server. I went from shared hosting to a virtual private server (VPS). So I now have a lot more horsepower at my disposal and I want to try some cool stuff.
This is the short list and I reserve the right to deviate whenever I feel like it.
Application development on the web can be done by hand on an as-needed ad hoc basis. That's fine for experimenting and for building an application as a one-time event. For ongoing development and building applications that can be the foundation for the next big leap, you have to have a good set of tools. I've divined that this is what people are calling your application stack, your software stack, or maybe your superplatform.
If you were walking into the Web 2.0 Shopping Mall, you'd find the stores selling three major name brands of software stack. They are .Net, Java, and LAMP. I run a Linux server and only have any real experience with Apache servers (unless you count the old personal web server on Windows 98). That excludes me from the .Net product line, so I don't find it very interesting or know very much about it. Here's what I've surmised through my totally informal and accidental trip into the Web 2.0 Shopping Mall.
(this is gonna be a long one)
Like I said, I don't know that much about it, but here goes. Somebody can tell me just how wrong I am in the comments. Active Server Pages (ASP) are written similarly to HTML pages but can contain special ASP tags - surrounded by <% %> instead of < >. The ASP tags are parsed server-side and can call server-side COM executables to perform some work and fill in their contents. The results of the parsing come out as HTML which is then sent to the client and rendered in the browser.
I'm sure there has to be a lot more to it than that, but it involves software, books and classes that I can't afford.
LAMP stands for Linux, Apache, MySQL, P. P is PHP, Perl, Python or some other free server-side scripting language. I've landed in the LAMP stack and I didn't even know it.
Linux is the operating system for the physical box that runs all the server applications. Usually this is Redhat Fedora, CentOS, Debian or the like. Apache is the web server. Actually Apache is also the name of the foundation that hosts the Apache http server project, which can lead to a little confusion since Apache Foundation now has some other great projects picking up steam. MySQL is the database engine that many sites (including several big names like Yahoo! and Google) use. MySQL doesn't suit everyone though, and there are alternatives that I think people would use and still call it a LAMP stack. Alternative possibly free database engines include Postgres and Firebird. All I've used so far is MySQL, I mention the others because I know MySQL is not free for every kind of use or user. Postgres and Firebird have their fans and I'm sure they can tell you about ways those products are the best thing out there.
So we already found alternatives by the time we got to the M in LAMP. The P is worse. In my experience the P is PHP. I've heard people use the term "P scripting languages." That's meant to cover PHP, Perl and Python. I guess those Ruby guys should have called it Pruby to become famous by association. Starting with PHP because I know something here, the way PHP works is similar to the way I described ASP. You write some HTML but have special tags in it that start with <?PHP and end with ?>. When Apache serves a PHP document, it first passes it to the PHP parser. The PHP parser looks at those tags, runs the code inside them, and replaces the tags with the results of that code. The code can be a single print statement or it can be a whole bunch of database lookups. PHP has become mature enough that some big applications are being written in a language originally meant for Personal Home Pages.
Perl, in my minimal experience, is used for writing a script whose output is served as the HTML for the page. This is the way CGI scripts traditionally worked in the early days of the web and I don't know of any advancements to Perl except to build it as a module instead of an external CGI. The difference between normal PHP scripts and normal Perl scripts is that the Perl would have to put out the whole page, whereas PHP can be intermingled with plain HTML. I really can't talk about Python, but it seems to be in the same boat as Perl - more a solid general-purpose scripting language than one that was built to mingle with tags in a page.
I'm not going to say mixing tags is better or writing a single script is better. I think that's up to the developer and the application.
LAMP is the one stack of these three that has happened more as a matter of circumstance than of planning. The conventions seem to have grown up out of the open source community rather than being built as part of a business plan for enterprise web software. I think that's really cool and all, but in order to keep the fantastically low barriers to entry that LAMP allows, there have to be users and developers out there that are using it as a stack for those solid enterprise applications. I heard a while ago about Activegrid and their self-titled debut package. It sounds like a toolset to build applications on the LAMP platform, but I'll have to try it to understand more.
Java is the language, I guess J2EE is the stack. Well J2EE is an edition of Java. Okay, I'm still hazy on this one, but I've save the Java stack for last because it's the platform that I think I stand to gain the most by working on. When I say "gain" I'm talking with regard to the goals I laid out above, not necessarily that the Java stack is the way to go in general.
As I understand it so far (and I hope to start some discussion here with others that are also just starting out on this path), the way it works is this.
You've still got your web server running as before. That web server can be Apache. The web server can still run on your Linux variant of choice (or another OS). The part that happens above the web server is what changes.
The web server has to have a way to handle Java Server Pages (JSP). In JSP, you've got HTML with special tags that have to be processed. Inside those special tags you can call bits of Java applications. When you call those bits of Java, you're running some Java application on the server-side that you've written and deployed to the server. Up to here I'm going on what I know about JSP from talking to some people. Now I'll do a little reading and try to fill in comparable details to what I've got for LAMP above.
Apparently the bits of Java that you run on the server are called servlets. Servlets need a container that can execute them. On Apache, the Servlet container is Tomcat. There are other servlet containers, but I don't know which other ones are free to use or run on Linux.
As far as the tags that call your servlets, it seems that these are part of the JavaServer Pages Standard Tag Library (JSTL). Therein lies some heavy reading. JSP seems to be aiming at tags in XML documents instead of just HTML, adding yet another layer of abstraction. The Java stack seems to be pretty deep. I'm still interested, but I'm going to have to take a break and go put on my hip-waders.
That's all I can handle for today. I wrote this to sort things out for myself, but hopefully this helps someone else building a road map to setting up to develop rich web applications. Speek up in trackbacks or comments if you've got something to add or a direction I should go in. I hope to come back to this in the next few days, but I reserve the right to become distracted for several months at a time.