The framework shuffle: web developments 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
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
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
Many new tech companies and their communities spend time bashing
the “old guard” (see the entertaining comment threads here
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
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
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.”
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