实战HTML5与JavaScript应用开发

需积分: 9 33 浏览量更新于2024-07-25 收藏 11.37MB PDF 举报

"HTML5 and JavaScript Web Apps" 是一本实践性的书籍，专注于提供关于HTML5、JavaScript MVC框架和最新W3C规范的实用方法，帮助读者构建广泛支持各种主流网络浏览器和设备的移动及桌面Web应用。作者Wesley Hales深入探讨了Web Storage、Web Workers、Geolocation、Device Orientation和WebSockets等API的实际用例，提供了真实世界的使用示例。 HTML5是现代Web开发的关键技术，它扩展了HTML语言，引入了许多新的元素和特性，如语义化标签（如<header>、<nav>和<footer>）、离线存储（Web Storage）、多媒体支持（<audio>和<video>标签）、图形绘制（Canvas）以及表单控件增强等。这些特性使得开发者可以创建功能更强大、交互性更强的网页应用。 JavaScript是与HTML5紧密关联的重要脚本语言，用于实现动态和交互功能。在本书中，JavaScript MVC（Model-View-Controller）框架，如AngularJS、React、Vue.js或Ember.js等，被介绍作为组织复杂Web应用结构的有效工具。MVC模式有助于分离数据、用户界面和业务逻辑，从而提高代码可维护性和可测试性。 Web Storage提供了比传统Cookie更高效的数据存储方式，分为localStorage和sessionStorage，允许开发者在本地存储大量数据，且在页面会话期间保持数据持久性。 Web Workers允许在后台线程中执行密集计算任务，避免阻塞主线程，从而改善应用性能和响应速度。通过Web Workers，开发者可以实现复杂的计算或长时间运行的任务而不影响用户体验。 Geolocation API允许获取用户的地理位置信息，为位置感知应用提供了基础。开发者可以利用这一特性创建导航系统、本地搜索服务或其他基于位置的服务。 Device Orientation API提供了对设备方向和运动的访问，使得开发游戏、运动追踪应用或增强现实应用成为可能。 WebSockets是一种提供全双工通信信道的协议，允许服务器和客户端之间实时、双向数据传输，为实时通信应用如聊天室、在线游戏等提供了高效解决方案。本书适合有一定JavaScript、CSS和HTML基础知识的开发者，通过实际案例和详细解释，引导读者深入了解HTML5的各项API，并掌握构建跨平台Web应用的技巧和架构设计。无论你是希望优化现有Web应用，还是探索新的开发领域，这本书都是一份宝贵的参考资料。

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 manip‐

ulation 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 gold‐

en. (See Figure 1-2.)

Figure 1-2. Output of a JSF data grid component

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 conver‐

sions, better SEO rankings, and lower costs in the data center.

Before HTML5

Before HTML5 and mobile devices, frontend (or UI) developers didn’t care that much

about the architecture behind the user interface. The scene was full of hacks and pro‐

2 | Chapter 1: Client-Side Architecture

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

More Code on the Client | 3

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 book 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.

4 | Chapter 1: Client-Side Architecture

剩余170页未读，继续阅读

羁魂

粉丝: 4
资源: 12

实战HTML5与JavaScript应用开发

HTML5 and JavaScript Web Apps【PDF新书】

HTML5 and JavaScript Web Apps.pdf 英文版

html5 and javascript web apps

Beginning iPhone and iPad Web Apps Scripting with HTML5 CSS3 and JavaScript 2010

Beginning iPhone and iPad Web Apps - Scripting with HTML5, CSS3 and JavaScript

Beginning iPhone and iPad Web Apps Scripting with HTML5, CSS3, and JavaScript

Apress.Pro.Android.Web.Apps.Developing.HTML5.JavaScript.CSS.and.Chrome.OS.Web.Apps

Pro-Android-Web-Apps-Developing-HTML5-JavaScript-CSS-and-Chrome-OS-Web-Apps.pd

Metro Revealed: Building Windows 8 apps with HTML5 and JavaScript

Metro Revealed-Building Windows 8 apps with HTML5 and JavaScript

最新资源