HTML and CSS Reference
In-Depth Information
prietary plug-ins. Many developers focused on supporting browsers like IE6, Firefox,
Safari, and maybe a few others. They wrote clean, semantic markup and worried about
how valid their XHTML was. They imported the occasional JavaScript library to create
some nice effects, and
prototype.js
or jQuery was the backbone (no pun intended) of the
application.
Once developers worked around the browser quirks and bugs of a given application,
things pretty much stayed the same. The architecture of advanced web applications was
mostly managed on the server. Applications were dependent on how fast the incoming
HTTP request could be handled and how fast markup could be rendered back to the
user's web browser. With server-side templating and component frameworks, the server
parsed the template and data was interlaced with regular XHTML or HTML markup.
For Java, you might have used JSP, Velocity, Tiles, GWT, or JSF to achieve this. For Ruby,
it was ERB, HAML, or RedCloth, and the list goes on. Every server-side web framework
had an accompanying UI templating engine to go along with it or to choose from. This
was the way of UI development for the past 10 years or more, and it probably will
continue for a while yet. But it doesn't have to. The time has come to rethink how we
build our new generation of web applications.
You might ask, “Why do we need to change the way in which our frontend is generated?”
or “Why are we moving all our code to run inside the web browser and not on the
server?” The first answer that comes to mind is that the web browser is becoming a
platform. Our applications now live inside of platforms (or browsers) that are orders of
magnitude more capable than their ancestors. Today's web applications are just that:
they're apps. We're not creating sites anymore; we're creating robust applications with
HTML5, CSS, and JavaScript at the core, as you can see in the HTML5 badge shown in
Figure 1-3
.
Figure 1-3. HTML5 badge
It's time to take a step back and look at how we're building our applications and level
the client-side playing field. Developers must understand which frameworks and ap‐
proaches are needed to build a scalable, rock-solid user interface for any given applica‐
tion.
More Code on the Client
The balance is undeniably moving from traditional server-side templating to JavaScript
templating. With so many new JavaScript frameworks out there, we may seem to be
