ENTRIES TAGGED "javascript"

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 |

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 |

Tailoring for performance

One source does not fit all

Like a lot of web teams, O’Reilly’s web group has increased its focus on using global components to better scale maintenance and optimize workflow. From a load-time measurement perspective, our performance ratings stay near benchmarks. However, after a recent analysis, using metrics other than load time, we found that our global efforts may have sacrificed performance on a handful of highly visible and heavily visited web pages.

Identifying the popular pages, we sought to improve the use of global components with server side logic, regex, and asynchronous loading. After re-measuring these popular pages, we arrived at faster load times with improved perception of speed.

Taking a closer look
After the Velocity 2014 site was produced, I got the following results from PageSpeed Insights and Webpagetest (WPT) while testing the homepage. These results are close to our average benchmarks for load time but revealed further elements to fix.

PageSpeed Insights pointed out render-blocking scripts and advised how I can optimize CSS delivery. WPT provided a visual UI to demonstrate the user’s perception of speed and gave me an average load time and start render time. Together, these tools gave many angles of approach to improving load times and the perception of speed.

vel-before-js-removal

Even though the load and start render times from WPT weren’t bad, the PageSpeed Insights score demonstrated that further improvements could be made.

Read more…

Comments: 2 |

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 |

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 |

A concrete approach to learning how to program

A solid foundation on which more meaningful learning can happen

578px-Perspectiva-1.svgAs someone who has previously taught computer programming for nearly a decade, I’m often asked questions that involve “what’s the best way to go about learning to program computers,” or “what’s the best way to get a software engineering job,” or “how can I learn to build mobile or web apps?”

Most of the readers of this blog have probably faced the same question at some point in their career. How did you answer it? I’ve seen many different responses: “come up with an idea for an app and build it,” or “get a computer science degree,” or “go read The Little Schemer,” or “join an open-source project that excites you,” or “learn Ruby on Rails.”

The interesting thing about these responses is that, for the most part, they can be classified into one of two categories: top-down approaches or bottom-up approaches. Top-down approaches are informed by the opinion that it’s better to be thrown in the middle of an application or a framework which encourages the learner to piece together knowledge in that context. Many books and online tutorials use an explicit top-down approach, often starting with the basics of a popular methodology, framework or technology. The most visible example of this are books on Ruby on Rails — they almost always inevitably begin with a description of the Model-View-Controller design pattern, but defer the incredible number of non-obvious ideas that make it up (Object-Oriented Programming, for instance).

On the other hand, a bottom-up approach starts with the basics/fundamentals of programming and then slowly builds your knowledge over time. In contrast to top-down approaches, bottom-up approaches try to minimize the number of these non-obvious ideas that the learner has to take for granted. Khan Academy and Code Academy are two examples of online sites that use a bottom-up approach to teaching programming. For the most part, they completely leave out any specific framework and focus on fundamentals of programming.

Read more…

Comments: 5 |

Understand the four layers of JavaScript OOP in one short lesson

6 highlights from Axel Rauschmayer's webcast

Last week Axel Rauschmayer presented “The Four Layers of JavaScript OOP.” His approach to teaching JavaScript OOP is doing so incrementally, through layers. Each of the four layers builds upon the last. The lesson runs just under an hour.

  • The live audience (1,500 attendees) brought certain foreknowledge to the course, represented by this graph (based on a live poll). Most individuals had knowledge of object oriented programming, whether with JavaScript or another language, and fewest had knowledge of prototype chains.  [at 01:30]
  • Axel walked through an overview of the 4 layers of JavaScript OOP and summarized each. [at 2:25]
  • Layer 1, Single object. [at 3:55]
  • Layer 2, Prototype chain. [at 14:52]

Layers 1 and 2 together form a simple core, which you can refer back to if confusion sets in. This way you can re-ground yourself at any point in the foundations of the course.

  • Layer 3, Constructor. [at 22:02]
  • Layer 4, Constructor Inheritance. [at 32:42]

Read more…

Comment |

Javascript without the this

Using closures in a different way

One of JavaScript’s many wrinkles is the way that this works. It can be quite confusing, since the semantics are quite different from the purely lexical scoping rules which apply for regular variables in JavaScript. What this references can often be totally unrelated to the lexical scope of a function. To work around that we often see tricks like:

Anyone who’s done much JavaScript development has felt this pain. Imagine if that was never needed. How could we get there? Well, one way would be to just never use this. Sounds crazy? Let’s see.

Read more…

Comments: 24 |

How to (semi-)automate JavaScript refactoring

Disposable robot assassins and spreadsheets

Computers aren’t ready to write much of our code for us, but they can still help us clean and improve our code.

At Fluent 2013, O’Reilly’s Web Platform, JavaScript and HTML5 conference, Giles Bowkett demonstrated a wide variety of ways to write code that helps refactor code, showing developers a variety of ways to clean up and simplify their JavaScript. He gave ‘disposable robot assassin at large’ as his title, but it fit better with the code he was demonstrating.

Bowkett explored many options and iterations of his automation ideas,

  • The roots: Martin Fowler’s classic Refactoring. [at 00:50]
  • “Probably the first time ever you see a developer or hacker enthusiastic about using a spreadsheet… I am that fluke.” [at 01:48]
  • Matching method names with the ack and wc Unix command line utilities, and finding some useless methods. [at 5:58]
  • “More complex information… surfacing an implicit object model.” [at 7:45]
  • Filter scripts and text streams [at 14:45]
  • “Towlie, because it liked to make things DRY”, using similarity detection in Ruby. [at 16:37]
  • Building on JSLint [at 20:10]
  • Switching to a Ruby parser for JavaScript to calculate differences [at 21:49]
  • JavaScript parsers: Esprima [at 27:26]
  • “Have script that… tells you this file is the one that people have edited most frequently. [at 30:29]
  • Grepping through git history [at 32:53]
  • “Automatic refactoring will let you get to better code much faster.” [at 36:25]

It’s an amazing mix of capabilities that let you build your own robot (code) assassins.

If the Web Platform, JavaScript, and HTML5 interest you, consider checking out our growing collection of top-rated talks from Fluent 2013.

Comment |

An introduction to TypeScript

At Fluent 2013, O’Reilly’s conference dedicated to the Web Platform, JavaScript and HTML5, Microsoft’s Luke Hoban spoke about TypeScript, a strict superset of JavaScript that adds optional static typing, modules, and classes.

In Introduction to TypeScript, Luke presented a 40 minute introduction to the language, how it relates to JavaScript and ECMAScript 6, and how TypeScript looks and behaves in IDE environments and within the context of complete applications.

TypeScript is an open source project from Microsoft that aims to help developers work on larger applications that could benefit from features like static typing but without eschewing JavaScript and its wealth of libraries and tools. As TypeScript is a strict superset of JavaScript, all JavaScript code is legitimate TypeScript code and TypeScript compiles down to idiomatic JavaScript so it runs on any runtime that JavaScript does too.

Some key parts of Todd’s talk include:

  • What is TypeScript? [at 01:48]
  • A demo of TypeScript [at 05:14]
  • A look at how typing helps [at 06:40]
  • How classes in TypeScript work [at 16:20]
  • The TypeScript ecosystem / community [at 21:53]
  • TypeScript 0.9 [at 25:48]
  • A look at generics support [at 29:18]
  • TypeScript in the context of a full app [at 34:40]

If you want to learn more about TypeScript, check out the official TypeScript homepage which includes a simple tutorial and an interactive playground that lets you type TypeScript code on the left hand side of the screen and see the JavaScript translation on the right.

Comment |