HTML and CSS Reference
In-Depth Information
going a little overboard, but this is what happens as technology shifts and then finds a
decent balance. The technology that drives our UI is changing as browsers become more
mobile and as they're given more hardware access through JavaScript APIs. To some
degree, the concept of building a user interface remains the same across both client and
server approaches. They all have data that needs to be presented and data that needs to
be gathered. We're still adding framework-specific tags or attributes to our code so that
the data knows where to be displayed, but the dependence on the server is gone. We are
now getting objects and data back from intermittent RESTful or WebSocket connections,
which are automatically bound to the UI through a client-side, JavaScript framework.
Our applications now have the ability to occasionally sync data and the power to func‐
tion offline.
To harness this power and to handle the different states of our applications, we must
consider new approaches for managing client-side code. JavaScript libraries like jQuery
and prototype must not define our frontend development models. Cross-browser DOM
manipulation libraries should be taken very seriously, but the complexities of a scalable
client-side architecture deserve much more attention than they have been given in the
past. Organizing code and your application structure with mature techniques gathered
from the classic Design Patterns: Elements of Reusable Object-Oriented Software by Erich
Gamma, et al., (Addison-Wesley Professional, 1995), is just the beginning. More than
40 MVC JavaScript frameworks now claim to be MVC, but they should be called MV* .
They all use different techniques for managing models, views, and controllers, and many
seriously depart from the original Smalltalk MVC concepts. And even though JavaScript
frameworks give us a nice way to organize and structure our code, we must deal with
browser APIs that expose hardware-level access, such as Geolocation or Web Workers,
on our own. The architecture of heavy, HTML5-driven user interfaces is still in its in‐
fancy, but fortunately you have this topic to help light your path.
The Browser as a Platform
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 choos‐
ing 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 applica‐
tions 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.
Search WWH ::




Custom Search