THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ THIS NEW POST AND ALL FOLLOWING POSTS...
The title of this post may surprise you, but it's not as ridiculous as you think. I see value in both techniques within the same problem domain. The comparison in this article can be described as "doing things a different way" vs. "making the existing way a whole lot easier".
Any experienced web developer intuitively feels there's something wrong with traditional web development. Developers embrace new frameworks like Struts, JSF, Spring, Hibernate, AJAX, etc. because they recognize the improvements in those frameworks. Before seeing these solutions, they have little explicit knowledge about the problem they're solving though. The choice of techniques is a bit more random than your customers might have hoped.
From XForms to Rails in less than a year
In the exact same way I found out about XForms a few years ago. A funny detail is that I wasn't interested in web development that much. A lot of it's added value also applies to the world of client side applications.
Innovations in ICT are hard to predict. The value of technical solutions greatly depends on customer adoption, hypes and popularity. I saw potential in XForms and I can still make a good argument for their adoption. Nevertheless, I lost my faith in XForms as a widely accepted standard supported by all browsers on all platforms.
Although elegant, XForms are overly complicated. Although an XForms plug-in is being implemented in Mozilla, the development of this plug-in takes longer than the birth of a human baby. Although standardized by the W3C as part of XHTML 2.0, XForms are widely ignored as "the next big thing".
In the mean time, the world has been talking about AJAX, social networking and mash-ups. A few clever developers became well known for inventing simple mechanisms to apply the latest innovations in your own web sites. These simple mechanisms are available free of charge, they are not standardized but so widely adopted that their continuity is guaranteed.
One of the greatest surprises in this category is the Ruby on Rails framework. While everyone was locked in to Java, dotNet, PHP and Python, who would have thought of using yet another unpopular scripting language with a questionable reputation for performance? Who would have thought it was even remotely possible to convince experienced Java developers to switch to this unknown alternative?
Who would have thought of actually explicitly investigating the actual flaws in web development before figuring out what solution solves the flaws appropriately?
David Heinemeier Hansson did. He found out that the greatest evil in web development is caused duplication of knowledge through the application. By focusing only on duplication, he found out that the best solution is not in a framework. The elimination of duplication starts with a programming language designed for this purpose starting at the bottom.
The best development frameworks are not designed to be frameworks by themselves. Instead, adequate frameworks are extracted from successful software implementations. By continually improving software design and abstracting away from details, a project reaches a certain point where abstraction and implementation can be separated. The abstraction without specific problem implementation is the foundation for the new framework.
The majority of web applications are built by solving similar issues already solved thousands of times by other developers. The repetitive effort of solving common issues can be avoided by reusing the framework abstractions from earlier solutions.
This is exactly what Rails is about. Solving every-day challenges in the simplest possible way. Common frameworks are limited to providing reusable implementations. Rails does more than just that. It is designed to prevent any knowledge duplication in your web applications. And it does this amazingly well.
On top of that, Rails has some extra selling points:
- Rails has built-in support for all the latest hypes, buzzwords and innovations. Using AJAX in Rails is simplified to be as trivial as any other standardized feature.
- Rails is a so-called full stack framework. This means that it helps developers with every aspect of a common web application. Including database management, object-relational-mapping, modeling business logic, separating presentation from implementation (MVC) and many more details.
- Specialized plug-ins can be injected into projects for less common requirements. These plug-ins are designed to be non-intrusive and loosely coupled.
- Rails encourages its developers to further extend the platform following the philosophy of the existing components.
At least there seems to be a down side to Rails at first sight. When I first saw source code for Rails, it didn't make much sense to me. Even though I already knew the advantages and supported its philosophy, I thoroughly disliked what I saw and tried to convince myself that it's just another framework like all others. Nothing that can't be done similarly in Java or any other language.
For a while I experimented with Python on TurboGears. Python already had my sympathy, TurboGears is a pythonic full-stack framework in the Rails philosophy and it seemed to me that the widely adopted Python would blow away Ruby.
My initial positive experiences with TurboGears opened my mind to really consider Rails as a serious alternative. My colleague, Jeroen Zwartepoorte, used the power of demonstration to convince me of the potential of Rails. In no more than two days he ported an existing Java web app to Rails adding improvements on the way. Seeing great and elegant results in so little time, I could no longer deny there must be something about Ruby on Rails to make it special and unique. I started studying the RoR framework for real.
I analyzed that my main objection to RoR was the fact that I couldn't intuitively read Ruby code. Because code readability is on top of my priorities, I started with the basics of Ruby. When I put my mind to it and translated my objections to open questions, it turned out that Ruby is just as easy as Python. In fact there are a lot of similarities.
These are some of my conclusions:
- Python wins over Ruby for basic readability because I didn't need to learn Python to be able to understand the code.
- Python wins over Ruby on performance aspects because Python classes are compiled to byte code on the fly.
- Ruby wins over Python when avoiding duplication without introducing tightly coupled components because of advanced dynamic language features.
- Ruby wins over Python for the declarative nature of its source code. The notation of method calls make them seem like sets of rule specifications.
A large majority of software geeks make the world think that the main purpose of software is instructing the computer to perform series of actions. This is a crucial mistake.
The main purpose of software is communication between people. Instructing computers is just an important means of achieving this goal. The best software is a piece of art; poetic literature expressing the thoughts of the developer for future generations. To be maintainable, it has to be readable. To be usable, it should be maintainable to extend functionality. For performance, it must allow minor modifications without harming readability.
Comparing XForms and Rails
If I recall correctly, I started this article commenting on the title. At this point in the discussion, it should be more obvious why the comparison is more reasonable than it seemed at first. Although very different, both XForms and RoR are solutions to the same flaws. At this point we can list flaws and compare techniques.
Relational databases have a static nature and take a lot of effort and SQL knowledge to maintain. Software deployment requires manual action for database modifications. Transferring data between similar but slightly different database definitions cannot be done without affecting the quality of the data.
XForms treats data structures as semi-structured XML documents and assumes they can also be stored in a Native XML Database or on a file system. XML Schema definitions of data structures are easier to maintain and distribute. Also, they can easily be extended for specific problem domains without harming the quality of more general fields in the document. The maintenance problem is solved by doing things a completely different way. When applied to the appropriate problems, this works extremely well. Note that I'm talking about theoretical back-ends for XForms here. These back-ends are not defined by XForms in any way.
Ruby on Rails introduces the concept of versioned database migrations expressing metadata definitions in native Ruby instead of SQL. Changes in the database later on are automatically rolled out when updating the web application. To be safe and complete, migrations can also be rolled back if you want to revert to an old version of your application. Rails solves the maintenance problem by making existing techniques easier and standardized in the web app. It reduces knowledge requirements by providing native Ruby helpers.
Native XML databases are still an exception. Most companies are used to working with relational databases. To stick with the standards makes it easier for your clients to adopt your technology. For this reason I think that Rails is the winner here.
Native access to databases is unnatural in programming languages and mapping databases to object oriented code takes a lot of effort and duplication of logic
XForms use semi-structured document definitions instead of structured table definitions. Semi-structured data allows more degrees of freedom while preserving definition of all items in the document. Because XML can be stored in native format, there are no mapping issues. XForms solves the problem by doing things differently.
Rails expresses data models extending a technique called ActiveRecord. Duplication is avoided by dynamically reading column names from the database instead of specifying them in the model. In code, the column names can be accessed with the same notation as explicitly defined fields. Under the hood, Ruby uses a mechanism similar to Dynamic Proxies in Java. The key difference is that Java requires explicitly defined interfaces to implement its methods. Being a script language, Ruby just sends a message to a generic dynamic implementation. If you specify the nature of relationships with other entities in the model, the same dynamic implementation helps you to find related data for specific items.
The reasoning for the previous conclusion still applies here. I must admit that ActiveRecord avoids duplication. At the same time I prefer having my program logic in a single place and not scattered over both the database and the model. Even though I could read the column names in the migration code without accessing the database, it makes the code more error prone and harder for IDEs to offer auto-completion and auto-checking. The TurboGears platform has a different approach. At the cost of maintainability, there are no migrations. Column definitions are part of the model class. Databases can be generated from the models automatically. Because TurboGears is not part of this contest, I call this issue in favor of XForms. Not only because it works around the problem, but mostly because of the extensibility of the solution while preserving standardization of shared data definitions.
Proper software development separates presentation logic from business logic and use case implementations (MVC pattern). For new projects it takes a lot of repetitive efforts to set up a basic framework for MVC.
XForms is part of the XHTML 2.0 standard natively designed to separate MVC concerns on the client side. XForms is different from traditional HTML and client side forms because it keeps the model document in memory and processes changes in the model real time. In the XForm itself, there is some mixing of presentation with business rules. The presentation details are in CSS as usual. XForms try to eliminate the need for controlling code by abstracting them away to the form of business rules.
Rails is natively built up following the MVC pattern in a way that is almost obsessive. Rails encourages its users to separate MVC concerns by making it easy, logical, natural and intuitive. Up until now, I considered MVC to be difficult for inexperienced developers and only appreciated with substantial work experience. With the additional steps required to follow MVC in Java, beginners are easily lured into doing things the ugly way "temporarily, just for now, I'll fix it later on". Because Rails prefers convention over configuration, following MVC is easier than trying to mix things up. Some special properties in the Ruby language make method calls seem like declarations of logical business rules. Notation outweighs actual implementation here.
When considering the separation of models, views and controllers (MVC) of XForms and Ruby on Rails, I should take into account that XForms is just a client side helper and RoR is a full-stack framework. Considering the additional effort required to handle the server side aspects of XForms, it comes nowhere near the RoR framework. If I ignore this issue to make a fair comparison, I still think RoR wins over XForms. The declarative rules in XForms are nice for common implementation concerns. The limited size of the solution library in XForms are nowhere near the toolbox provided by Rails. Rails wins in the MVC department.
Traditional web applications impose a lot of duplication on developers. Duplication is avoided most easily in special purpose frameworks. These frameworks have something in common: they avoid duplication by choosing declarative problem specification models over executable programming instructions. Given the model, the implementation is taken care of under the hood.
Declarative specification of business logic targeted at XML structures is one of the key selling points of XForms. This is proven by the fact that OpenOffice borrowed the logic model from XForms without implementing the rest of the XForms standard. Specification and implementation of business logic is a very powerful feature in XForms, but the domain for its appliance is limited. XForms logic beats any other technique when used in XML documents with semi-structured nature. XForms logic is based on XML specifications and XPath queries. This notation requires a thorough understanding of XML, creativity with XPath, trial and error, and great talent for logical puzzles. For someone with the knowledge and experience of a software architect, the simple tools in XForms can be the building blocks of a very advanced and intelligent application.
Compared to other regular programming languages, Ruby's declarative features are outstanding. In the exceptional comparison to XForms it does a good job when it comes to simplicity. To draw a conclusion I have to acknowledge the fact that RoR rules only appear to be declarative while in fact they're just method calls. This is sufficient for calls in a limited scope. When looking at the bigger picture, business logic is best described in a rule base supported by a logical inference engine. Rules can recursively influence any other part of the model. Rules can be processed by making queries to the engine without worrying about it's implementation. In my earlier XForms tutorial I learned that I can push the logical model way beyond anything I have seen in a browser so far. Rails wins on avoiding duplication, XForms wins on processing pure declarative logic.
Many companies are replacing their client side applications with web based alternatives. IT departments love this, but end users are missing some of the richness and responsiveness of their old clients. The latest trend is to put usability on top of the priority list.
XForms offers great value but only for a limited domain. Fast responding dynamic forms with advanced data structures are a lot easier in XForms than in Rails. Advanced forms are great for administrative business application running on an intranet. For the great majority of web sites forms are small and simple. XForms logic is complete overkill here. Because the simplified AJAX support in Rails can be used for an endless number of different purposes, Rails wins when it comes to adding dynamic behavior.
Choosing open source software, it is easy to forget about the commercial aspects because it's free anyway. All software contains bugs. You may encounter them or you may use the software in such a way the bug is never revealed. The first time you start thinking about commercial aspects is the moment of finding a bug. Who can I ask for help? Who's going to solve it and when will the solution be available? Is the producer of my commercial application willing to support the product when it depends on open source plug-ins? Can my plug-in be replaced by another standardized alternative?
XForms is an official W3C standard and part of XHTML 2, the successor of the widely adopted XHTML 1.1. As long as XHTML 2 is a draft and no attempts are made to offer implementation in Internet Explorer and Firefox, there is little value in this standardization. Agreed, you may transfer your XForm to a commercial implementation based on AJAX or Flash. But it just isn't the same. The Mozilla XForms plug-in project is taking too long to release a final version.
Ruby on Rails is not an official standard, but its de-facto-standardization value is a lot higher. There are regular releases of stable new versions, there is an open development process releasing ongoing work frequently. There is an enthusiastic community on the internet offering help provided you ask the right questions. RoR follows the latest W3C standards for producing web content. It uses other open source components for specific functionality. There is a growing number of independent companies offering support for Rails. The working with rails site lists specific consultants in your area. Given the successful adoption of RoR in production environments with millions of daily customers, assuming capable technical skills, Rails is a safe bet. Performance requires some fine tuning but that's no different in any other environment.
Personally I prefer de-facto-standardization over official standardization. Ruby on Rails wins easily with its fast paced adoption.
Software in 2007 should be innovative, rapidly evolving and buzzword compliant.
Initially, XForms was something new and fundamentally different. The open source community behind Mozilla decided against its implementation because it was too complex. A few large companies saw the value of XForms for their own applications and pushed the decision to implement an XForms plug-in in Mozilla Firefox. For being innovative, rapidly evolving and buzzword compliant, the companies should have invested in a large development team and delivered the implementation in less than 3 months. This way, they would have been earlier than the top of the AJAX hype and may have had a chance to compete. With the slowly evolving Mozilla plug-in, XForms lost momentum and became so-yesterday! I think it is a huge waste of potential.
The conclusion is almost trivial here. Rails wins easily when it comes to innovation and buzzword compliance. Rails deserves extra credit for having clear visions and goals in the adoption of new technology. Innovation makes sense in Rails, it's not just there because it happens to be new. Especially for an open source project, clear visions and goals are a strong asset. It is a sign of strong leadership and a no-nonsense pragmatic community.
The end conclusion: successful projects are based on pragmatism
XForms is more elegant than pragmatic. It is a solution designed on paper instead of extracting it out of the real world. It is designed to solve common real world problems in a limited scope and fails to further evolve from implementation experience. The XForms concept was born from a vision but it is being implemented like a mandatory school assignment. The key advantages of XForms have an academic nature. This is the exact reason why I like them myself. It is also the exact reason why it fails in the real world. History teaches us that all famous theories, models and ideas in any possible science, have one thing in common. Simplicity! The complexity of the XForms specification grew out of proportions. No amount of pragmatism is able to fix that once the harm is done.
My proposal is to split XForms into sub-components and improve each of those separately:
- Declarative logic component
- Separating data instance document from XForm doc
- Support for semi-structured nature of data
- Standardizing common client side code in declarative library
- Submitting data in XML and other formats
- Native support for rich UI controls like date choosers and sliders
- Support for fine-grained CSS, dynamically changing presentation details based on the state of specific elements
- Simplification of XPath element query specification
Ruby on Rails is a role model example for pragmatism. In Rails, pragmatism never gets out of proportions. There are high standards for code elegance, readability and standard-compliance. While rapidly developing to meet short-term goals, Rails never forgets about quality on the long run. It seems to acknowledge that long term quality wins over quick and dirty even in short term development.
Looking at the simplified support for AJAX and thinking about XForms dynamic visualization of ongoing changes I suspect Rails can push the AJAX framework even further to match the power of XForms.
I think this requires the following features in Rails:
- Rule based inference engine influencing object models with a much wider scope
- Simplified native support for presenting subforms with add/remove/up/down buttons
- Improved automated support for updating multiple parts of a web page based on changes anywhere in the model
- Support for Native XML Databases instead of Relational Databases
- Binding model classes to XML documents instead of SQL tuples
The end choice between XForms and Ruby on Rails can be simplified by rephrasing the question. If you have to choose between never using XForms anymore or never using Ruby on Rails in your whole life, which one would you choose?
The only risk there is that XForms is a W3C recommendation and might become a widely adopted standard after all. Don't sweat it, this is just a hypothetical question based on current knowledge helping the decision.
For me, right now, I prefer Ruby on Rails over XForms. If not for other reasons, then mostly because it offers a lot more features in a larger problem domain. I'm convinced Ruby on Rails can be very helpful in my daily work and saves substantial development time.
Tags: XForms | Ruby | Rails
THIS POST IS SUPERSEDED BY A NEW SERIES OF ARTICLES ON XML TECHNOLOGIES AND XFORMS... READ THIS NEW POST AND ALL FOLLOWING POSTS...