Web Platform Posts

5 ways to improve battery life in your app

Tips and tricks to squeeze the most out of your mobile UI

mobile_html5 Editor’s Note: Mobile HTML5 is a book by front-end engineer and frequent speaker Estelle Weyl. It is packed with hands-on examples to make you a stronger web developer–including best practices for SVG, Canvas, and CSS3 tailored to fit mobile devices. In the excerpt below, Estelle walks you through five easy things you can do to improve battery life in your mobile web apps. As throughout the book, the tips she provides come from her own real-life experience with these technologies.

Unlike desktop computers that are tethered to the wall at all times, and even laptop computers that are generally used by stationary users, mobile users do not recharge their devices throughout the day. Mobile users expect their devices to last, at a minimum, 24 hours between recharging.

Your users do realize that calls and GPS usage consume battery power. However, if they think they’re just using their browser to surf the Web, they don’t consider that different websites will drain their battery faster than other sites. It is our job, as developers, to manage the power consumption of our code.

You have likely noticed that CPU usage drains the battery on your laptop when unplugged. CPU usage drains the battery on mobile devices just as effectively. Anything that makes your laptop churn, warm up, or turns your computer’s fan on will also drain the battery of mobile devices (if they’re not plugged in). Code defensively: expect that your mobile device users are not plugged in.

To manage the energy consumption of our code, we need to manage CPU usage. Avoid reflows. Minimize both size and activity of your JavaScript. Don’t continuously reawaken the radio with unnecessary AJAX calls. Always use CSS, rather than JavaScript, for animations. And even though the marketing teams of devices that support WebGL insist that their devices are optimized, don’t serve WebGL to mobile devices. At least, not yet. WebGL battery performance is improving.

Read more…

Comment: 1 |

Can We Extend the Web Cleanly?

The DOM and human nature create some challenges

“Design by Committee” is rarely a compliment. Can the Web shift away from that model, retaining some order without falling into troublesome chaos?

The Manifesto

Part of the excitement around the Extensible Web Manifesto was that it wanted to move the Web to more of an evolutionary model:

We aim to tighten the feedback loop between the editors of web standards and web developers.

Today, most new features require months or years of standardization, followed by careful implementation by browser vendors, only then followed by developer feedback and iteration. We prefer to enable feature development and iteration in JavaScript, followed by implementation in browsers and standardization.

This sounds great. Web standards have always been difficult, their universal goals making it difficult to bring together different vendors and even different standards organizations. Developers are impatient, and most of us have little connection to the kinds of reasoning that drive vendors, consortia, and yes, committees. Open source and similar models have taught us that many eyes are valuable, and small experiments seem less likely to break the Web than specifications that lurch the wrong direction.

Unfortunately, extensibility is not, as we learned from XML, a magical way to speed things up and make committees disappear. The rest of the Extensible Web Manifesto explains how it hopes to make this work, but the key piece is the very first item:

Focus on adding new low-level capabilities to the web platform that are secure and efficient.

Read more…

Comment |

The Power of HTML

Acknowledging the source of the Web's strength

For a growing number of developers, “web” means “JavaScript”. Programmers like to focus on programming languages, but the Web’s basic power comes from its support for communications, not programming.

I asked Jen Simmons, host of the Web Ahead podcast, to keynote Fluent after seeing her give a talk on responsive layouts at the ARTIFACT conference last year. It wasn’t just a great talk on responsive layout, but an exploration of the Web foundations that make responsive layout possible. Responsive layout’s foundations are deep in HTML, which contained those multi-device values from the beginning.

At Fluent, Simmons delivered A Love Letter to HTML, exploring HTML’s origins. The goals driving a memo written 25 years ago gave the Web strengths that developers need to study today.

Highlights of her keynote include:

  • “The Web has changed us so much already.” [0:34]

Read more…

Comment: 1 |

Facebook’s Hack, HHVM, and the Future of PHP

What is Hack and what does it mean for the future of PHP?

Photo: thebusybrain https://www.flickr.com/photos/thebusybrain/3283201861/
Facebook recently released Hack, a new programming language that looks and acts like PHP. Underneath the hood, however, are a ton of features like static typing, generics, native collections, and many more features for which PHP developers have long been asking. Syntax aside, Hack is not PHP. Hack runs only on Facebook’s HipHop virtual machine (HHVM), a competitor to the traditional PHP Zend Engine.

Why did Facebook build Hack?

Much of Facebook’s internal code is first written with PHP. Facebook can onboard new developers quickly with PHP because the language is notoriously easy to learn and use. Granted, much of Facebook’s PHP code is likely converted to a C derivative before being pushed into production. The point is Facebook depends strongly on the PHP language to attract new talent and increase developer efficiency.

Strict Typing

Unfortunately, PHP may not perform as well as possible at Facebook’s scale. PHP is a loosely typed language and type-related errors may not be recognized until runtime. This means Facebook must write more tests early to enforce type checking, or spend more time refactoring runtime errors after launch. To solve this problem, Facebook added strict typing and runtime-enforcement of return types to Hack. Strict typing nullifies the need for a lot of type-related unit tests and encourages developers to catch type-related errors sooner in the development process.

Instantaneous Type Checking

To make the development process and error-catching process even easier, Facebook includes a type-checking server with its HHVM engine. This server runs locally and monitors Hack code as it is written. Developers’ code editors and IDEs can use this type-checking server to immediately report syntax or type-related errors during code development.
Read more…

Comments: 3 |

Transforming the Web (through transformation)

Decorating content may no longer be enough

Photo: http://commons.wikimedia.org/wiki/File:Metamorphosis_frog_Meyers.pngThousands of people invented it independently. Millions use it without thinking about a broader context. It’s time to name it so we can talk about it.

Transformation is changing the way we look at the balance between clients and servers, our approach to formatting and layout, and our expectations of what’s possible on the Web. As applications shift from transformation on the server toward transformation on arrival on the client, transformation’s central role becomes more visible.

“Templating” doesn’t quite capture what’s happening here. While templates are often a key tool, describing that tool doesn’t explain the shift from server to client. Templating also misses the many cases where developers are using plain JavaScript to insert, delete, and modify the document tree in response to incoming data.

These practices have been emerging for a long time, in many different guises:

  • In the Dynamic HTML days, scripts might tinker with the DOM tree as well as modify CSS presentation.
  • Transformation was supposed to be a regular and constant thing in the early XSLT plans. Stylesheets on the client would generate presentation from clean blocks of XML content.
  • Ajax opened the door to shell pages, apps that set up a UI, but get most of their content elsewhere, using JavaScript to put it in place.
  • New data format options evolved at about the same time that Ajax emerged. JSON offered a more concise set of programmer-friendly content tools. Many apps include a ‘bind JSON to HTML before showing it to the user’ step.
  • Template systems now run on the client as well as the server. In many systems, templates on the server feed data to the client, which applies other templates to that data before presenting it to users.
  • The HTTP powering Ajax still created a long slow cycle of interaction. WebSockets and WebRTC now offer additional approaches for collecting content with less overhead, making it easier to create many more small transformations.
  • Some developers and designers have long thought of the document tree as a malleable collection of layout boxes rather than a deliberately coherent base layer. Separation of concerns? A dead horse, apparently. Recent debates over CSS Regions highlighted these issues again.

Read more…

Comment |

Yes, CSS is code

Learning from "The Humble Border-Radius"

One of the best things I overheard at the Fluent Conference was (more or less):

“CSS live coding? I was like, that isn’t code. But then it was.”

Lea Verou had changed the mind of a skeptic.

CSS is not Turing complete (Update: Lea points out that I’m wrong about that), and I’ve long been grateful that it wasn’t designed as an imperative programming language. It can be too much code for designers, too little code for programmers, and yet it’s code.

I think about the graphics work I tried to do with shapes and sprites and assorted kinds of vectors over the years, and then watch this keynote. Even with the glitches and coming improvements she notes, it’s clear that whatever tools I was using at the time, they weren’t declarative enough. (I’d also just seen this JSFest talk on CSS box-shadow by Vince Allen, so I was looking forward to more CSS graphics magic.)

Read more…

Comments: 3 |

The Web is eating software

Web technologies have become the default, and are spreading

photo: KF - http://en.wikipedia.org/wiki/User:KF/DetailsA few years ago, venture capitalist Marc Andreessen wrote that “software is eating the world”:

Six decades into the computer revolution, four decades since the invention of the microprocessor, and two decades into the rise of the modern Internet, all of the technology required to transform industries through software finally works and can be widely delivered at global scale.

That may be true, but Andreessen seems to have left out some of his earlier, more Web-centric visions (though perhaps he considers them complete).

Software may be eating the world, but the Web has been “eating software” in a similar sense for as long as the Web has been visible.

On the front end, the browser has grown from being a strange dumb terminal of documents and forms to a full partner. The browser not only provides a window into the world of classic websites, but helps us deal with devices that we can reach over a network. Their interfaces may be invisible or basic on the physical device, but offer much more when accessed through a browser. Web apps, though frequently not as capable as their desktop competition, long ago passed the point where their collaborative possibilities were more valuable than the details they lack.

Read more…

Comments: 2 |

Choosing a Templating Language in Clojure

A brief look at Enlive, Hiccup, and Selmer

One thing that is striking when working in the Clojure ecosystem is the breadth of options available to tackle any given task. The community strives to write simple, interoperable libraries and what results is a daunting number of choices, all with their own benefits and trade-offs. Templating libraries in Clojure are no exception to this rule. The Clojure Toolbox alone lists eleven template languages at last count, and it is not even an exhaustive count of the wide array of techniques available for templating web pages.

In the forthcoming Clojure Cookbook, we cover three such libraries: Enlive, Hiccup, and Selmer. Let’s take a brief look at each of these libraries and discuss their places in the ecosystem.

Hiccup—Pure data, plain and simple

Of the three libraries we’ll cover, Hiccup is the most simple of the bunch. In Hiccup, HTML tags are just vectors of Clojure data; no HTML, no template files, no interpolation (per se), just data. An HTML node is represented as a vector of three parts: tag, attributes (optional), and contents (optional, any number).

Take an anchor tag, for example:

Which represents the following HTML:

To nest multiple elements like you might do in an unordered list, replace the content portion of the vector with the additional child nodes:

Which renders as:

Read more…

Comment |

Stacks in JavaScript

Practical data structures for practical purposes

US_patent_1242674_figure_3In a previous blog post, I discussed why it is important for JavaScript developers to learn how to implement the classic data structures of computer science, such as stacks, lists, queues, and so on. I also talked about how in many cases, the problem being solved will suggest a particular data structure, resulting in an algorithm that almost writes itself. In this post I would like to provide an example of just such a case.
Let’s examine the problem first. We are asked to examine a text and find all the words that are palindromes. A palindrome is a word that is spelled the same forwards and backwards. Some examples of palindromes are “bob” and “racecar.”

Stacks in a Nutshell

The data structure we want to use to solve this problem is a stack. A stack is a list structure where access is only allowed at the top. Think of how you interact with a stack of trays in a cafeteria. If you want to get a tray, you get the tray that is on top; if you want to replace a tray, you place it on the top of the stack. That is how you interact with the data stored in a stack.

Read more…

Comments: 3 |

Event-driven application design with JavaScript

Look beyond jQuery to an MV* approach

When you start building dashboards for interacting with data, such as calculators, editors, or result browsers, understanding JavaScript and client-side MVC becomes important. Why do you need an event-driven application design and a separation of interface state and behavior? Let me walk you through some examples.

You’ve probably seen seen simple example editors, where the browser acts as an editor for to-do lists. In these applications, you edit to-do items, consisting of a text and a state (pending or done). These small editors are very helpful for studying monitoring events from the keyboard and partially updating page content. These are the main principles for building applications in web browsers.

Once you going beyond to-do list editors, the requirements quickly increase. For example, you might work with multiple counters that observe the cursor position, or the number of words in a text box. You might need to support multiple editing modes or text formatters, or edit actions and state synchronization with a backend.

Read more…

Comment |