-
At Airbnb, we’ve learned a lot over the past few years while building rich web experiences。 We dove into the single-page app world in 2011 with our mobile web site, and have since launched Wish Lists and our newly-redesigned search page, among others。 Each of these is a large JavaScript app, meaning that the bulk of the code runs in the browser in order to support a more modern, interactive experience。33217
- 上一篇：网络安全英文文献和中文翻译
- 下一篇：数据库管理系统英文文献和中文翻译
This approach is commonplace today, and libraries like Backbone。js, Ember。js, and Angular。js have made it easier for developers to build these rich JavaScript apps。 We have found, however, that these types of apps have some critical limitations。 To explain why, let’s first take a quick detour through the history of web apps。
JavaScript Grows Up
Since the dawn of the Web, the browsing experience has worked like this: a web browser would request a particular page (say, “http://www。geocities。com/”), causing a server somewhere on the Internet to generate an HTML page and send it back over the wire。 This has worked well because browsers weren’t very powerful and HTML pages represented documents that were mostly static and self-contained。 JavaScript, created to allow web pages to be more dynamic, didn’t enable much more than image slideshows and date picker widgets。
After years of advances in personal computing, creative technologists have pushed the web to its limits, and web browsers have evolved to keep up。 Now, the Web has matured into a fully-featured application platform, and fast JavaScript runtimes and HTML5 standards have enabled developers to create the rich apps that before were only possible on native platforms。
The Single-Page App
It wasn’t long before developers started to build out entire applications in the browser using JavaScript, taking advantage of these new capabilities。 Apps like Gmail, the classic example of the single-page app, could respond immediately to user interactions, no longer needing to make a round-trip to the server just to render a new page。
Libraries like Backbone。js, Ember。js, and Angular。js are often referred to as client-side MVC (Model-View-Controller) or MVVM (Model-View-ViewModel) libraries。
The bulk of the application logic (views, templates, controllers, models, internationalization, etc。) lives in the client, and it talks to an API for data。 The server could be written in any language, such as Ruby, Python, or Java, and it mostly handles serving up an initial barebones page of HTML。 Once the JavaScript files are downloaded by the browser, they are evaluated and the client-side app is initialized, fetching data from the API and rendering the rest of the HTML page。
This is great for the user because once the app is initially loaded, it can support quick navigation between pages without refreshing the page, and if done right, can even work offline。
This is great for the developer because the idealized single-page app has a clear separation of concerns between the client and the server, promoting a nice development workflow and preventing the need to share too much logic between the two, which are often written in different languages。
Trouble in Paradise
In practice, however, there are a few fatal flaws with this approach that prevent it from being right for many use cases。
SEO
An application that can only run in the client-side cannot serve HTML to crawlers, so it will have poor SEO by default。 Web crawlers function by making a request to a web server and interpreting the result; but if the server returns a blank page, it’s not of much value。 There are workarounds, but not without jumping through some hoops。
Performance
By the same token, if the server doesn’t render a full page of HTML but instead waits for client-side JavaScript to do so, users will experience a few critical seconds of blank page or loading spinner before seeing the content on the page。 There are plenty of studies showing the drastic effect a slow site has on users, and thus revenue。 Amazon claims that each 100ms reduction in page load time raises revenue by 1%。 Twitter spent a year and 40 engineers rebuilding their site to render on the server instead of the client, claiming a 5x improvement in perceived loading time。