How to get your dream house

The framework shuffle: web development’s long evolution


Liferay’s James Falkner explores the ever-evolving world of web development – from its early static HTML days to the modern frameworks of today.

If you wanted to build a house 60,000 years ago, your design and tooling options were rather limited. The world was new, and there weren’t a lot of experienced tradespeople sharing knowledge about their craft or building fancy tools to make the job easier. For hammers, your choices were made up of the different rocks lying around your cave. Lumber and nails? Forget it. As time progressed, we found better and more efficient ways of doing things. Entire factories have now been built just to make hammers, or to make the factories that make the hammers, and now you have many choices when it comes to your preferred tool.

A lot of trial and error went into the development of these tools and techniques, and as a result it’s a lot easier for an average person to build a house today. Just go to your local home improvement store, buy a hammer or two, and tons of nails and lumber, and build your dream house. It may fall down, but you’ll learn a lot in the process, and your next house will undoubtedly be better.

In the world of web development, we’ve gone through a similar evolutionary path. In the dawn of the web, your choices for developing websites were rather limited. You could make static HTML web pages with hyperlinks, and… static HTML web pages with hyperlinks. If you wanted your webpage to change, you had to go in and change it manually, every single time.

Building complex shopping sites or employee intranets was impossible. Of course, it didn’t take long to realize the possibilities in this new world, and as our collective experience with the web grew, so did the number of standards, frameworks, and techniques dedicated to making better use of it. Today, the number of choices for developing the web is daunting, but it took a lot of trial and error to get to where we are today.

How did we get here?

After Berners-Lee gave us static HTML, we wanted more. We wanted to dynamically generate content based on things that changed, such as the user’s input or the time of day. And we wanted to code our dynamic content in languages like C, shell script, or Perl. CGI was born, and we were soon on a slippery slope to the dynamic web we know today.

A host of new web application frameworks began to appear over the next few years, some under the auspices of well-heeled companies and their enterprise-y needs, but many others from a small group of experienced open source developers looking for something that better fit their problem space and time constraints. These frameworks began to abstract away the underlying complexities of the web, starting down the same road travelled by other fledgling creative and technical endeavors. Especially in open source, the most useful frameworks and languages enjoyed a lot of success and usage due to their low barrier to entry and even lower cost, and became de facto standards well before being officially standardized (if at all).

As with any new technology area, there were undoubtedly mistakes made. In the case of web application design, the occasional over-rotation into a beast that can do almost anything produced high levels of complexity that up-and-coming web developers would not accept. For example, early versions of Sun Microsystems’ EJB framework promised portability, scalability, and security, but its complexity, fragility, and testing difficulty caused developers to seek alternatives such as Spring. High profile web service providers like Twitter and Foursquare fled traditional XML transport protocols for JSON and REST. Developers began to rethink the necessity of ACID relational databases in the face of the rising scale and usage model of today’s social web.

The process of considering alternatives to entrenched programming paradigms, standards, and frameworks was dramatically accelerated during the economic downturn in the early 21st century. Companies were forced to downsize and reduce R&D spending, while at the same time a new generation of open source developers were leaving universities without the legacy baggage of the last two decades and creating a new generation of developer-friendly software tools and frameworks to match the ways in which modern web apps are used. Today, new languages and frameworks appear almost daily, giving developers a rich tech tapestry on which to develop new apps.

Do we really need all that complexity and choice?

Many new tech companies and their communities spend time bashing the “old guard” (see the entertaining comment threads here and here). “Java EE is dead, Node rocks!” says one commenter. “No wait… Node is just a toy, Python is where it’s at!” remarks another. “Threads are dead, long live event-driven apps!” declares a third. And so on. The truth is that each has its own strengths and weaknesses, and each should be weighed against the design requirements of the system being developed as well as the experiences of the developers doing the work.

The best part about all of this is the number of choices we now have to build our dream homes, with very little upfront cost. Newer frameworks like Node and friends enjoy a lot of attention and adoption, especially from experienced JavaScript developers, but have a way to go before matching the maturity and level of comfort that enterprises, big enterprises like banks and airlines, enjoy with established frameworks such as Java EE and friends.

One may argue that having too many choices is a bad thing. Charlie Collins, notable mobile developer and author, disagrees: “When buying jam, yes, I want to make a 5 second decision and not have ‘too many choices.’ When choosing a spouse, buying a house, or making any kind of long term or expensive commitment like selecting a framework I will be using for the next few years, I don’t want less choice, I WANT MORE.”

What now?

Technology shifts quickly, and all of the specific technologies mentioned above continue to evolve to meet the needs of their communities. Although buzzwords such as “mobile”, “cloud” and “big data” are quite abstract, they represent major shifts in the way people interact with computing in general, and will continue to have significant impacts on web development in the near future. Standardization is key to avoiding the insanity and solidifying best practices into law, and many of the technologies mentioned in this post will eventually contribute to the formation of one or more standards. But true standardization is a slow process (even the standards bodies recognize this), so de facto standards are even more important to the evolution of the web, giving fledging ideas “airtime” amongst a large set of peers. In the end, we all win through this process, and the web is a better place because of it.

Author Bio: James Falkner is the Community Manager at Liferay, a provider of enterprise-class open source portals. 

Image courtesy of Martin Pettitt

James Falkner is the Community Manager at Liferay, a provider of enterprise-class open source portals.

Inline Feedbacks
View all comments