O'Reilly《HTML5与JavaScript Web应用指南》详解

需积分: 10 98 浏览量更新于2024-07-24 收藏 4.73MB PDF 举报

《HTML5与JavaScript Web Apps（O'Reilly出版社）》是由Wesley Hales编著的一本权威指南，针对HTML5和JavaScript这两种关键技术在Web应用开发中的应用进行了深入讲解。本书的ISBN号为978-1-449-32051-5，由O'Reilly Media出版，这是一家在全球范围内享有盛誉的技术图书出版商，以其高质量的技术书籍而闻名。该书不仅提供了理论知识，还注重实践，适合希望通过HTML5和JavaScript构建现代、交互式Web应用的开发者。作者确保了内容的全面性，包括HTML5的新特性如离线存储、音频视频处理、Canvas绘图等，以及JavaScript的核心概念、框架（如jQuery、Node.js）和异步编程。书中还涵盖了如何利用HTML5和JavaScript创建响应式设计，适应不同设备和平台。作为一本"禽兽书"（O'Reilly出版社对深入且实用技术书籍的昵称），《HTML5与JavaScript Web Apps》的特点是结构清晰，深入浅出，通过实例驱动学习，使读者能够快速掌握新技术并在实际项目中运用。它不仅适合初学者系统地学习HTML5和JavaScript，也适合有一定经验的开发者提升技能和知识体系。编辑团队包括Simon St. Laurent和Meghan Blanchette，他们负责整体的内容策划和质量把控；Production Editor Christopher Hearse负责生产流程管理；Copyeditor Linda Laflamme、Proofreader Linley Dolby以及Indexer Meghan Jones则确保了内容的专业性和准确性。封面设计由Randy Comer操刀，内部设计和插图由David Futato和Rebecca Demarest完成。首次发行日期为2012年10月26日，并提供在线版本供读者方便获取。O'Reilly出版社还为读者提供了详细的错误报告和修订历史，确保信息的及时更新。通过这本书，读者可以系统地学习HTML5和JavaScript，从而在Web开发领域取得竞争优势。

Unlike 20 years ago, browsers—the client-side platforms of today—are much more

owerful, 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

Thi

s 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 p

lug-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

t’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

cent 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页未读，继续阅读

Hanlos

粉丝: 9
资源: 5

O'Reilly《HTML5与JavaScript Web应用指南》详解

HTML5与JavaScript web应用：Wesley Hales解读

构建HTML5与JavaScript企业级Web应用

HTML/CSS/JavaScript打造iPhone应用指南：2010年O'Reilly经典

HTML5 and JavaScript Web Apps.pdf 英文版

Vue.js_Up and Running_Building Accessible and Performant Web Apps-O’Reilly(2018)

Learning JavaScript(O'Reilly,3ed,2016)

Building Android Apps with HTML, CSS, and JavaScript

Building iPhone Apps with HTML, CSS, and JavaScript

Building Android Apps with HTML,CSS,and.JavaScript(2nd,2012.01)

Android.Apps.with.HTML.CSS.and.JavaScript.Oct.2010.pdf

最新资源