But is all of this just a repeat of the past? Haven’t we already gone through the fat-client phases of the ’80s and ’90s, illustrated in Figure 1-1?
Unlike 20 years ago, browsers—the client-side platforms of today—are much more powerful, not to mention mobile. Plus, today’s clients can report all kinds of interesting data, such as your location’s latitude and longitude, through the browser and over a cell network.
One other small fact that’s pushing the browser as a platform is that multiple companies—Google, Apple, Mozilla, and Microsoft—are pushing thousands of commits per week into improving their hybrid, thick-client technology platforms.
In the past, building applications that were heavily tied to the server made perfect sense. This gave hardcore, backend developers the freedom not to worry about DOM manipulation and CSS. If you could get a data grid or paging component that tied into your backend code and generated IE6- through IE8-compatible markup, then you were golden. (See Figure 1-2.)
This autogenerated markup comes at a cost, however, especially in today’s world of fast moving, fragmented browsers. The need for flexible, controllable markup is at an all-time high. The Open Web is moving faster than ever, and user interfaces can no longer allow the server to be the bottleneck between stale ideas of the past and lightning-fast, scalable, frontend code. Developers have never been more concerned with performance in the browser. How markup is rendered and asynchronous resources are loaded can make or break your application. Faster and leaner frontends equal more lead conversions, better SEO rankings, and lower costs in the data center.
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.
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 approaches are needed to build a scalable, rock-solid user interface for any given application.
The web browser is becoming, or already is, an additional platform for our application stacks. It gets just as much, if not more, consideration than the server-side when choosing what our applications must support. Our frontend code is now packaged in native apps, extensions, and operating systems that are all driven by HTML5. As we are seeing with Google’s Chrome OS and Mozilla’s Boot 2 Gecko projects, the Open Web is very clearly being considered the platform for which web applications should and will be written.
HTML5, the Open Web, and mobile devices have helped push the browser-as-a-platform forward, giving browsers the capabilities of storing data and running applications in an offline state. But many of the newer standards driving this platform may not be finalized or implemented consistently across all the web browsers you wish to target. The good thing is that there are workarounds in the majority of cases and browser vendors such as Microsoft, Opera, Google, Apple, and Mozilla are clearly taking the stance of providing a platform for developers with their respective browsers (see Figure 1-4).