|
 |
|
|
Comparison of H2O to PhP
By Christian Manalansan
PREFACE
When I first encountered H2O I was very skeptical. It was introduced to me by a lab partner at El Camino College where I was taking a Physics lab. My lab partner, Matt Esquivel, works at Aestiva and recommended I take a look.
First, I want to say I really like PhP. It was my first Web-oriented computer language after Perl. I'm not a newbie either. I've been programming since my early teens. That's why, for me, H2O was such a surprise.
When Matt told me about a computer language better than PhP I told him it was unlikely. I argued the point too. But that was last month, before I tried H2O.
In the span of a few weeks, after completing my first project using the language, I can safely say H2O is a generation ahead of PhP. This is my report on why that is.
Back to Comparison Areas
INTRODUCTION
In preparing to write this report I first did a bit of searching on the Web to see how other PhP comparisons were written. I found a lot of raving about how PhP is free. Since H2O is also free I figured there was no need to go there. Plus, free or "open source" doesn't mean better. Apache and Linux are free and they're great. But there's a lot free stuff that's terrible too. H2O is free, which is great, but that's not why I recommend it. I recommend it because it allows me to program faster, better and do more.
To show you why I think H2O is better, I wrote down a list of comparison areas and notes on each. I present them here. After reading my notes I'm sure you'll understand why.
By the way, while comparing PhP to H2O I did run into a few areas where H2O could stand some improvement. I mention them in my notes. Despite these few areas however, I found little to suggest PhP is better than H2O. On the contrary. The advantages H2O has over PhP are so significant they're profound. Read my notes and you'll see what I mean.
Back to Comparison Areas
MY NOTES
Session Management
Before learning H2O I thought PhP had sophisticated session management. In PhP, to create a session I simply registered the session variable turning it into a "superglobal." I then accessed it implicity using a variable name or explicity using the $_SESSION[] array. Depending on my PhP build I could use database or cookie-based session handling.
H2O couldn't be more different. First of all, variables are automatially "superglobals." There's no dependency on the "build" of the engine. No need for cookies or a database to store session variables. H2O takes care of the session-handling automatically.
In H2O, if you need a local variable, you declare it in a function. In other words, it's exactly the opposite of PhP. PhP is a programming language patched to support session variables. H2O is a multi-page environment with support for local variables.
Because variables are "global," programming in H2O is more normal. You don't dedicate programming time to managing variables. Also, since the build of PhP determines how variables are handled, PhP applications cannot be moved from one server to another unless you have a matching PhP build. This architectural flaw comes up over and over. It hurts portability in PhP and makes programming more complicated than necessary. In H2O there is no "build" of the engine.
Back to Comparison Areas
The Development Environment
H2O and PhP have different development approaches. Whereas PhP looks at Web site construction as a bit of Apache work, a bit of building PhP and a bit of PhP programming, H2O has no build and doesn't care about Web server configuation.
The H2O programmer cares only about programming the application.
This makes programming easier. Not only are applications portable (since you have an engine that acts in only one manner), there's no PhP build to know about and learn and no Apache server to learn about. My code runs the same whether I'm on my own box or at a shared hosting account. I do not have to require or not require a "Mod" build of the Apache server, and so on. All of those technicalities were more burdensome than helpful anyway. Now I spend my time working on the application. Programming is more efficient.
Another major difference is how code is placed in the HTML document. Like PhP,
H2O is processed with the HTML code. But HTML/OS code can be processed before, in-line, and after HTML code. This makes programming easier because it cuts the number of source documents in half.
Also it means my source documents are related to the code being done on that Web page. My code is better organized.
(When thinking how to do this in PhP I realized I could get close by building specific statements to handle the flow of code. But doing so resulted in highly convoluted code. The flow of code in H2O is a natural part of the environment.)
Another difference with H2O is there is no new document type to deal with (just .html), whereas with PhP there is usually a PhP document type (not a big deal, but another unneccesary requirement).
Another difference is that H2O commands are universal. Apps work across all configurations of the engine. Once again, there's no worry about whether the command is in the "build."
Another difference is apps are automatically server-independent because H2O commands are server-independent. The H2O language, in other words, fosters portability. In PhP that's not the case.
H2O even provides a packaging tool called BundleBee. The utility allows me to package up an application into a single platform-independent file. A file can be installed easily onto other copies of H2O using a Control Panel built into H2O. No such thing exists in PhP because PhP doesn't separate server configuration from the application.
I think the way H2O keeps server admin functions (the installation of H2O) separate from application development is smart. H2O reflects real life. Small businesses want to operate at hosting providers where the Sysop is not the programmer. PhP practically forces the small business to run their own server which many don't want to do. Large businesses don't do much better. Big corporations have IT departments that maintain Web servers. The programmer may be in a different department. With H2O there's no back-and-forth between administrators and programmers. Programmers can be in a different department without becoming a burden on the IT staff. In PhP you need close coordination between programmer and IT which is a real headache for everyone.
Back to Comparison Areas
Adding a Database
Here too the approach taken by H2O is different than PHP. H2O provides an upgrade path to HTML/OS, a 4GL database engine. PhP is designed to work with MySQL. Both H2O and PhP can connect to other database engines, but each has their preference.
The HTML/OS database engine is 4GL (Fourth Generation Language). It is a lot more powerful than MySQL, so H2O, as far as I'm concerned, is a lot better in the "Adding a Database" category.
This is because people typically use the database engine that comes most natural to the language they use. People who use PhP typically use MySQL. People who use H2O typically use HTML/OS. In other words, if I program in PhP I write SQL. If I program in H2O I write 4GL.
This means the PhP programmer has no ability to use true 4GL. In PhP I need to create a database connection before working with the database. Databases aren't platform-portable, which may lead to recreating connection objects (ie: rewriting code). Result sets must be parsed. There's a lot more code to write too. It's so different than using a 4GL.
With the 4GL in HTML/OS you always stay connected. You don't open and close sockets. The 4GL appears as extra commands in the language. One 4GL command to query a database and fill a variable. One 4GL command to load data from an HTML form to a database record. One command to load the fields from a database record into an HTML form. And so on. No sockets to worry about. No database server to maintain. Code is easier, faster, and more robust. It's so much more civilized. :-)
The downside for H2O is that the HTML/OS database is not free whereas MySQL is. On the other hand, companies are more than willing to pay for a high-power database engine. Especially an engine that has no database server that needs to be maintained for the life of the application. (One of the cool things about HTML/OS is it has no database server. It's maintenance-free.) Plus, I'd rather work with a more powerful database engine. My first project with H2O involved the construction of a database application which got deployed in a hotel. I was able to build a complete multi-user application that supported hotel employees, managers, and administrators, plus learn the H2O language and the 4GL, all in the span of a week. Need I say more?
Back to Comparison Areas
Ease of Syntax
Overall, the H2O language looks and feels like a macro language. It's less complicated than PhP. Reserved words and variables are case insensitive too. It's a very nice language.
That's not to say PhP isn't a good language. It is. But it has a lot more syntax rules. PhP isn't as easy to read as H2O. For example, I can read other people's H2O code and instantly understand it. The language is so readable it barely needs to be commented. In my opinion, that's another big plus for H2O.
One of the things I like in PhP that doesn't exist in H2O is regular expressions. H2O has its own pattern matching which works fine, but I think Aestiva should add regular expressions. It's a nice convenience.
Back to Comparison Areas
Working with Arrays
Perhaps one of the most annoying aspects of PhP, now that I'm getting familiar with H2O, is the way it handles multi-dimensional data. In PhP variables hold one piece of information and arrays extend in n-dimensions. Accessing array contents means referencing all dimensions, always.
PhP nests arrays in order to create n-dimensions. This may sound like a plus. After all, you might think extending to n-dimensions is better than one or two. But to accomodate this PhP leaves it up to the programmer to code functionality to access and manipulate arrays to the n-th dimension. This is more complicated than the approach used in H2O.
In H2O all variables are intrinsically 2-dimensional arrays, though they can be referenced as variables, 1-dimensional or 2-dimensional on-the-fly. For example, you can write X[4,5], X[5] or X. Writing X[4,5] refers to column 4, row 5 of the array X. Writing X[5] refers to column 5, row 1. Writing X refers to the array X, in total. Writing X=3 means create the 1 column by 1 row table and fill with 3. Variables are called "tables" because they have columns and rows.
H2O has plenty of array manipulation functions. Functions can manipulate array columns and rows simultaneously and perform spreadsheet-like operations. The operations are easy to learn because visualizing data in tables is much simpler than PhP's nested arrays.
The approach makes sense since databases, delimited text files, and most organized data is 2-dimensional, not n-dimensional. H2O is better matched with how data is organized. Using n-dimensional arrays may sound powerful, but it makes programming more difficult. In retrospect, standardizing on n-dimensions in PhP is about as silly as requiring all arrays be XML structures. It makes little practical sense.
Finally, H2O 2-dimensionality doesn't stop with variables. The language makes it easy to move 2-dimensional data back and forth between variables, database records, and text files. Even HTML forms can read and write to 2-dimensional arrays. Their approach is far better than PhP's n-dimensional array approach. It makes advanced programs easier to think about, faster to write, and easier to debug.
Back to Comparison Areas
Working with Files
In PhP working with files is more difficult than with H2O. In PhP you must open a file to create a stream. Then read or write to/from that stream. Then close the stream. PhP has limited parsing too. It places lines in an array. But what if I want to read a delimited file with multiple lines in a cell? I must program the parsing myself.
H2O is more high-level. There's no need to open or close streams. Entire contents of file can be stored to a variable. Need to read in a delimited file? H2O supports "OpenText," a way of defining most kinds of delimited text files. Want to fill a file into a variable? It takes a single COPY tag. Even uncommon file formats can be read this way. I can set the delimiter, boundary character and escape characters when I load a file into a variable or visa versa.
Back to Comparison Areas
Working with HTML Forms
Once again PhP is at a disadvantage. In PhP form elements, when submitted, become global variables in the document. As a convenience, these elements automatically become set as variables that have the same name value for PhP. For example:
<input type="text" name="firstname">
<!-- When this form is submitted, PhP sets $firstname -->
<input type="checkbox" name="likesblue" value="yes">
<!-- If checked, PhP sets $likesblue to 'yes' -->
But PhP doesn't automatically set HTML form elements (the reverse function). A lot of times, a person not only wants to keep form data in a variable of some sort, but they also want to be able to access that data should they return to the same form. In HTML, the default value for form elements are usually blank values and unchecked (for radios and checkboxes) unless explicitly stated. So, in order to make a form behave as if the data is retained, PhP must be coded to either set the values or check the appropriate areas. For example:
<input type="text" name="firstname" value="<?= $firstname ?>">
<input type="checkbox" name="likesblue" value="yes"
<?= ($likesblue == 'yes') ? 'checked' : '' ?>>
<!-- note: different input types require different PhP code in order to retain the data -->
When compared to a language like Perl (which PhP often is), it was a nice convenience to not have to convert form element values into PhP arrays. But not being able to do the reverse almost defeats the purpose.
In H2O all form elements become variables to H2O. For example:
<input type="text" name="firstname">
<!-- When this form is submitted, H2O sets a variable named 'firstname' -->
<input type="checkbox" name="likesblue" value="yes">
<!-- H2O grabs the form value as well as a checked/unchecked value -->
In addition, H2O also sets form element values to variable data, should they share the same name. This added convenience means I do not have to worry about the initial state of a form element. From the above example, if one wanted to retain the value of firstname and have the form show that value on the web page, no additional changes are necessary from the above code.
Better yet, H2O internally handles this for all the different types of form elements. Programming is easier because there's no difference between HTML "form variables" and H2O variables. A programmer can create an entire Web site without ever setting one form value in HTML.
Back to Comparison Areas
SECURITY-BY-DEFAULT
A particularly important feature of H2O is its security-by-default architecture.
There are lots of different resources in books and on the Web regarding the security issues of PhP. But as a programmer, I honestly want to focus more on the functionality of an application as opposed to the security. I do not pretend to be a security expert, and I don't know many PhP programmers who think of themselves as security experts either.
Security issues are usually addressed and researched by system administrators and security advisors, not programmers. And this is the way it should be. But despite this, PhP places security in the hands of programmers. When I program in PhP, it's my responsibility not only to generate clean-cut, functional code, but also make sure that the interfaces are as secure as possible. It makes it even more confusing when realizing that the security workarounds and measures all depend on what features a particular PhP build include. It's a no-win situation for most PhP programmers.
In H2O security measures are enabled by default. A programmer can work without knowing about security. Access to Web pages is denied unless explicitly allowed. As much as possible, variables, pages and path locations are hidden from the outside world.
The security measures can still be adjusted or overridden when necessary, so the security approach does not limit the programmer. But it has to be done explicitly so it reminds the H2O programmer to take the necessary safeguards.
For example, by default, all variables submitted in HTML forms are stripped of HTML code, but a programmer can disable that feature in a specific form element. The PhP programmer needs to write data validation code for all variables submitted. The H2O programmer usually has no security code to write and only needs to worry about the situations where security is deliberately relaxed.
In PhP the programmer must find all the possible security holes with no help from the language. In H2O the language makes it hard to unwittingly create security holes. This is a major architectural advantage.
Back to Comparison Areas
COMPARISON CHART
I created a chart below to make it easy to see how PhP compares to H2O. For each category I gave a rating of 1 to 10, 10 being the best. Of course, the comparison is just my opinion, but hopefully it gives you a valuable snapshot of the differences between PhP and H2O.
Note: Light gray lines indicate areas where H2O is significantly better than PHP. Dark Gray lines are areas where PhP is non-competitive because it lacks the necessary technology or architecture altogether.| Category | PhP | H2O | | Adding a Database | 7 | 9 | | Ease of Learning | 4 | 9 | | Ease of Programming | 5 | 10 | | Functions - Math | 9 | 9 | | Functions - Strings | 9 |
9 | | Functions - Arrays | 6 | 10 | | Portability | 2 | 10 | |
| Security-by-Default |
0 | 10 | | Session Management | 5 | 10 | | Speed of Execution | 9 | 10 | | Web Networking |
0 | 10 | | Web Software Packaging | 0 | 10 |
Web Copy Protection | 0 | 10 | | Working with Files | 7 | 9 | | Working with HTML Forms | 8 | 9 |
|
This chart includes three areas I did not mention much in my notes. They're Web Networking, Web Copy-Protection and Web Software Packaging. I explain these areas below.
- Web Networking pertains to the ability of H2O to "network" with other copies of H2O. It's built in. Link copies together and they behave as one. Let's say one copy of H2O is called "A" and the other "B." Then a page on "A" with the link <A HREF="B:/page.html>Page On B</A> would keep its variables, as the user moved to the page on the B server. This concept of "SuperSuperGlobals" is not available in PhP.
- Web Copy Protection is a technology that protects your code if you decide it needs to be protected. The H2O engine can read HTML docs or scrambled docs. This source code protection technology is not available in PhP.
- Web Software Packaging is a technology that allows one to bundle up applications into server-independent, hardware-independent, OS-independent files. And then load them point-and-click. H2O includes this ability. PhP does not.
Back to Comparison Areas
Summary
I think I can safely say H2O is a generation ahead of PhP. The language is equal or significantly better in every category. In some areas it provides capabilities simply unavailable in PhP. I recommend, if you haven't yet programmed with H2O, that you start. |
