Build a technology stack for mobile Web applications

There are a number of technical decisions to make when writing a Web application. I recently came back to write a modern web application and wanted to summarize some ideas that had been fragmented during the development cycle. This article is about a set of frameworks that are helpful to the author's recently developed projects. I have revisited some of the most important framework types, each of which can be expanded to write an article. This is not a wide range of existing products compared to just one part of the author's recent use of technology.

Although the author's focus is on mobile first, the author believes that this set of technologies can be applied in general Web applications. The author's decisions and data support have taken into account several requirements:

• Based on JavaScript (Coffeescript,dart, definitely worth looking at, but I want to avoid causing radical choices)
• Must work well in modern browsers (IOS 5,android 4)

　　Pick an MVC framework

In the application development of the local UI, the Model view controller pattern has been used for decades. The basic idea is to separate the presentation layer (user interface, animation, input) and data layer (storage, communication, data). There are other similar patterns, such as MVVM's (model view of ViewModel), but the main idea is to have a well-defined separation between presentation and data layers, for cleaner code and long-term maintenance:

There are many JavaScript Model view controller frameworks for the product. Some, such as Backbone.js and Spine.js, are written in pure code, while others like knockout.js and angular rely on DOM data properties for binding. MVC systems that rely on detached views and data for HTML5 data Dom properties are considered to be incorrect. This does not include the knockout.js and angular frameworks. Spine.js is easier than coffeescript, excluding coffeescript according to my initial requirements.

Backbone.js is more popular than most frameworks (perhaps, except Javascriptmvc, it seems like a dead project) and has a growing open source community. For the author's application stack, the author chooses Backbone.js. For more information on picking an MVC, check out TODOMVC, which uses different MVC frameworks to implement the same TODO application. You can also see the comparison of this MVC framework, which strongly endorses Ember.js, a relatively late frame. I haven't had the opportunity to use it yet, but it's on my list.

　　Select a template engine

To build a rigorous application on the Web, you inevitably build large dom trees. If you use the JavaScript API to manipulate the DOM, it is easier and more efficient to write HTML using a string-based template. JS template has gradually formed a strange convention, embedded template content into the script tag: <script id= "My-template" type= "text/my-template-language" ... </script >. The basic approach to using all of the template engines is to load the template as a string, build the template parameters, and then run through template engine templates and parameters.

Backbone.js relies on underscore.js, which has a somewhat limited template engine with detailed syntax. There are other options available, including jquery templates, Handlebars.js,mustache.js and many others. The jquery template is ready to be discarded by the jquery team, so I didn't consider this option. Mustache is a cross-language templating system that has simple and mature decisions to support as little logic as possible. In fact, the most complex construct in mustache is the way to iterate over an array of objects. Handlebars.js is built on mustache, adding some nice features, such as precompiled templates and template expressions. For the author, do not need these additional features, and then chose the author of the template platform Mustache.js.

In general, the author's impression is that the existing template framework can be compared to the function is very few, so the decision to a large extent is a matter of personal preference.

　　Select a CSS Framework

The CSS framework is an essential tool to extend the convenient set of features such as variables such as CSS, the way to create layered CSS selectors, and some of the more advanced features. This essentially creates a new language: an enhanced version of the CSS (let's call it css++). For ease of development, some frameworks implement a JavaScript css+ + interpreter in the browser, while some other frameworks let you monitor a css+ + file and compile it whenever there is a change. All CSS frameworks should provide command-line tools to compile css++ into CSS for development.

Like the template language, there are many choices. The author's choice is out of personal grammatical preference, I prefer scss, because it avoids the weird grammar like @. One drawback of scss is that it doesn't come with a JavaScript interpreter (there's an unofficial, I haven't tried yet), but a command line monitor is available. There are other similar CSS frameworks, including less and stylus.

　　How to Layout view views

HTML5 provides a variety of ways to lay out content, and the MVC framework has no requirement for the use of these layout techniques, leaving developers with a bit of a problem.

In general, the relative location of documents is appropriate, except for apps. Absolute positioning should be avoided, like tables. Many web developers have turned to using the float attribute to align elements, but this is only the second ideal of building an application's perspective, as it does not have a similar application layout, leading to many strange problems and notorious clearfix hacks.

After years of layout and experiments with various network technologies, the author believes that a combination of fixed positioning and flex box models is an ideal choice for mobile internet applications. The author uses fixed positioning of interface elements (header, sidebar, footer, etc.) on the screen. The Flex box model is great (horizontal or vertical) for stacking views on the page layout (stacked view). Only the CSS box model is significantly optimized for interface design, very similar to the Android LinearLayout manager. For more information about the Flex box model, read Paul's article and note that the specification is being superseded by a new, non-backward-compatible version.

　　Adaptive Web Application

In the last section, on this issue: the author strongly advocates the creation of a device-specific user interface. This means that the part of the view code is rewritten for different forms of the screen. Fortunately, the MVC pattern makes it easier to reuse the business logic model for multiple views, such as tablets and phones.

IOS Flipboard demonstrates this idea very well, and it provides a highly customizable experience for tablet and mobile users for each device's form factor. The mobile user interface is optimized for vertical clicks, allowing one-handed use. The flat panel UI makes the device work well with both hands and tails.

　　Considerations for Input

The primary way for mobile users to interact with your application is by touching the screen with your finger. This is quite different from mouse-based interactions because there is an additional 9 points in the trace screen, which means that when developers write mobile applications, they need to discard mobile mouse events. In addition, there is a problem with 300ms latency clicks on mobile mouse events (there is a famous touch-style workaround). For more information on using these events in mobile browsers, see the articles on my touch events.

Only s/mousedown/touchstart/of all event handlers is sufficient. A new set of user-expected touch device gestures, such as tapping, navigating through the image list. While Apple has a little-known gesture API, it does not have an open specification for gesture detection on the web. We really need a JavaScript gesture detection library to handle some of the more common gestures.

　　How to make it work offline

For an application to work offline, you need to make sure that two things are true:

• Assets assets available (via AppCache, file system API, etc.)
• Data is available (via LOCALSTORAGE,WEBSQL,INDEXEDDB, etc.)

In practice, setting up off-line applications on the web is a tricky issue. In general, offline functionality should be added to your application from the start. It is particularly difficult to have existing Web applications without significant rewrite code running offline. In addition, offline technology has a variety of unknown storage limits, and unknown behavior occurs when the limit is exceeded. Finally, there are some technical issues in the offline technology stack, most notable of which is AppCache, as I mentioned in previous articles.

Writing a real off-line feature app is a very interesting approach that is "offline first". In other words, if there is no Internet connection all written locally, when there is an Internet connection, the synchronization data synchronization layer is implemented. In the Backbone.js MVC model, this can be well adapted to custom Backbone.sync adapters.

　　Unit Test

Unit testing your UI is difficult. However, because you're using the MVC model, it's completely isolated UI and data results, so it's easy to test. Qunit is a pretty good choice, especially since it allows the use of its start () and Stop () method units to test asynchronous code.

　　Summarize

In short, I use backbone.js as the MVC framework, mustache.js as a template, scss as a CSS framework, CSS Flex box display interface views, custom touch events and Qunit unit testing tools to write the author's mobile Web application. Offline support, I still try to use various techniques, and hope to continue to write an article in the future. Although I strongly believe that it is necessary to list each tool (such as MVC) here, I also believe that many of the specific technologies described here are interchangeable (such as handlebars and mustache).

One more thing: January 17, 2012, Thorax announced the announcement. This is a set of development libraries based on backbone, very similar to the ideas I described in this article. The author has not studied in any depth, but the name is great:)

Use a similar set of frameworks? What's your favorite? Do you think the author lacks an important framework? Let the author know!

Source: English Original, Chinese compilation: it addiction.

Build a technology stack for mobile Web applications