Mozilla

Featured Articles

Sort by:

View:

  1. ES6 In Depth: Rest parameters and defaults

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    Today’s post is about two features that make JavaScript’s function syntax more expressive: rest parameters and parameter defaults.

    Rest parameters

    A common need when creating an API is a variadic function, a function that accepts any number of arguments. For example, the String.prototype.concat method takes any number of string arguments. With rest parameters, ES6 provides a new way to write variadic functions.

    To demonstrate, let’s write a simple variadic function containsAll that checks whether a string contains a number of substrings. For example, containsAll("banana", "b", "nan") would return true, and containsAll("banana", "c", "nan") would return false.

    Here is the traditional way to implement this function:

    function containsAll(haystack) {
      for (var i = 1; i < arguments.length; i++) {
        var needle = arguments[i];
        if (haystack.indexOf(needle) === -1) {
          return false;
        }
      }
      return true;
    }
    

    This implementation uses the magical arguments object, an array-like object containing the parameters passed to the function. This code certainly does what we want, but its readibility is not optimal. The function parameter list contains only one parameter haystack, so it’s impossible to tell at a glance that the function actually takes multiple arguments. Additionally, we must be careful to start iterating through arguments at index 1 not 0, since arguments[0] corresponds to the haystack argument. If we ever wanted to add another parameter before or after haystack, we would have to remember to update the for loop. Rest parameters address both of these concerns. Here is a natural ES6 implementation of containsAll using a rest parameter:

    function containsAll(haystack, ...needles) {
      for (var needle of needles) {
        if (haystack.indexOf(needle) === -1) {
          return false;
        }
      }
      return true;
    }
    

    This version of the function has the same behavior as the first one but contains the special ...needles syntax. Let’s see how calling this function works for the invocation containsAll("banana", "b", "nan"). The argument haystack is filled as usual with the parameter that is passed first, namely "banana". The ellipsis before needles indicates it is a rest parameter. All the other passed parameters are put into an array and assigned to the variable needles. For our example call, needles is set to ["b", "nan"]. Function execution then continues as normal. (Notice we have used the ES6 for-of looping construct.)

    Only the last parameter of a function may be marked as a rest parameter. In a call, the parameters before the rest parameter are filled as usual. Any “extra” arguments are put into an array and assigned to the rest parameter. If there are no extra arguments, the rest parameter will simply be an empty array; the rest parameter will never be undefined.

    Default parameters

    Often, a function doesn’t need to have all its possible parameters passed by callers, and there are sensible defaults that could be used for parameters that are not passed. JavaScript has always had a inflexible form of default parameters; parameters for which no value is passed default to undefined. ES6 introduces a way to specify arbitrary parameter defaults.

    Here’s an example. (The backticks signify template strings, which were discussed last week.)

    function animalSentence(animals2="tigers", animals3="bears") {
        return `Lions and ${animals2} and ${animals3}! Oh my!`;
    }
    

    For each parameter, the part after the = is an expression specifying the default value of the parameter if a caller does not pass it. So, animalSentence() returns "Lions and tigers and bears! Oh my!", animalSentence("elephants") returns "Lions and elephants and bears! Oh my!", and animalSentence("elephants", "whales") returns "Lions and elephants and whales! Oh my!".

    The are several subtleties related to default parameters:

    • Unlike Python, default value expressions are evaluated at function call time from left to right. This also means that default expressions can use the values of previously-filled parameters. For example, we could make our animal sentence function more fancy as follows:

      function animalSentenceFancy(animals2="tigers",
          animals3=(animals2 == "bears") ? "sealions" : "bears")
      {
        return `Lions and ${animals2} and ${animals3}! Oh my!`;
      }
      

      Then, animalSentenceFancy("bears") returns "Lions and bears and sealions. Oh my!".

    • Passing undefined is considered to be equivalent to not passing anything at all. Thus, animalSentence(undefined, "unicorns") returns "Lions and tigers and unicorns! Oh my!".

    • A parameter without a default implicitly defaults to undefined, so

      function myFunc(a=42, b) {...}
      

      is allowed and equivalent to

      function myFunc(a=42, b=undefined) {...}
      

    Shutting down arguments

    We’ve now seen that rest parameters and defaults can replace usage of the arguments object, and removing arguments usually makes the code nicer to read. In addition to harming readibility, the magic of the arguments object notoriously causes headaches for optimizing JavaScript VMs.

    It is hoped that rest parameters and defaults can completely supersede arguments. As a first step towards this, functions that use a rest parameter or defaults are forbidden from using the arguments object. Support for arguments won’t be removed soon, if ever, but it’s now preferable to avoid arguments with rest parameters and defaults when possible.

    Browser support

    Firefox has had support for rest parameters and defaults since version 15.

    Unfortunately, no other released browser supports rest parameters or defaults yet. V8 recently added experimental support for rest parameters, and there is an open V8 issue for implementing defaults. JSC also has open issues for rest parameters and defaults.

    The Babel and Traceur compilers both support default parameters, so it is possible to start using them today.

    Conclusion

    Although technically not allowing any new behavior, rest parameters and parameter defaults can make some JavaScript function declarations more expressive and readable. Happy calling!


    Note: Thanks to Benjamin Peterson for implementing these features in Firefox, for all his contributions to the project, and of course for this week’s post.

    Next week, we’ll introduce another simple, elegant, practical, everyday ES6 feature. It takes the familiar syntax you already use to write arrays and objects, and turns it on its head, producing a new, concise way to take arrays and objects apart. What does that mean? Why would you want to take an object apart? Join us next Thursday to find out, as Mozilla engineer Nick Fitzgerald presents ES6 destructuring in depth.

    Jason Orendorff
    ES6 In Depth editor

  2. Developer Edition 40: Always active network monitoring, CSS rules filtering, and much more

    Firefox 40 was just uplifted, and we have a lot of updates to share. This release took a major effort by Developer Tools contributors to address feedback we’ve heard directly from people using our tools. Grab a copy of the Developer Edition browser and check it out.

    Experimental Multi-process Support: A Request

    When you update to Developer Edition 40, you’ll be prompted to opt in to test multi-process Firefox. Please consider helping us test this new feature and providing feedback around any issues you see.

    New in the Inspector

    • There is now a filter box in the CSS Rules view that lets you find rules that match a string. See the Filter Styles screencast or the screenshot below. (Development notes: 1120616 and 1157293.)

    Inspector Filter Styles Screenshot

    • There is a new CSS documentation tooltip for CSS properties. Right click on any property in the CSS Rules view and select “Show MDN Docs” to see more information about that property. (Development notes.)

    MDN Tooltip In Inspector Screenshot

    • Inspector search now includes results from iframes and also includes class / id results without the CSS prefix. (Development notes: 873443 and 1149346.)
    • There is a new CSS Filter Editor Tooltip added by Mahdi Dibaiee. Check out the CSS Filter Editor Tooltip screencast for a demo, or try it on the filter demos page in Developer Edition. (development notes)
    • The Animation Inspector has had some major updates. It now shows subtree animations, playback rate can be controlled, and it previews and highlights animated DOM nodes. (Development notes: 1155651, 1155653, and 1144615.)

    There are too many changes to list in this post, but here are a few more interesting updates you may come across in the Inspector:

    • The Box Model view has legends for the regions and tooltips to show which CSS rule invoked the computed value. (Development notes: 1141571 and 1151956.)
    • shift+clicking a color swatch switches between color unit formats in place. (Development notes.)
    • New Scroll Into View, Open Link in New Tab, Copy Link, Open In Style Editor, and Open in Debugger context menu items in the Markup View. (Development notes: 901250, 921102, and 1158822.)

    Network Monitor News

    Cached network requests in Network Monitor Screenshot

    Here’s a selection of other changes and improvements in this release:

    • New Copy Response, Copy URL parameters, and Copy Request/Response Headers context menu items on each request. (Development notes: 955933, 1150717, and 1150715.)
    • Search box to filter requests. (Development notes.)
    • IP address included in Domain tooltip for network monitor. (Development notes.)
    • Added access keys to the request context menu. (Development notes.)

    Web Console

    • New console method: console.dirxml(). (Development notes.)
    • New filter options in the web console to show console messages from workers. (Development notes.)
    • Quotes in strings are no longer added if logged via console.log. Thanks to new contributor Dmitry Sagalovskiy for adding this feature! (Development notes.)

    Debugger

    General

    Special thanks to all the people who contributed patches to Firefox Developer Tools this release! Here is a list of all the DevTools bugs resolved for Firefox 40. Kudos to the many contributors.

    Do you have feedback, bug reports, feature requests, or questions? As always, you can comment here, get in touch with the team at @FirefoxDevTools, or share your constructive feedback and feature requests on our Firefox Dev Tools feedback channel.

  3. Diving into Rust for the first time

    Rust programming languageRust is a new programming language which focuses on performance, parallelization, and memory safety. By building a language from scratch and incorporating elements from modern programming language design, the creators of Rust avoid a lot of “baggage” (backward-compatibility requirements) that traditional languages have to deal with. Instead, Rust is able to fuse the expressive syntax and flexibility of high-level languages with the unprecedented control and performance of a low-level language.

    Choosing a programming language usually involves tradeoffs. While most modern high-level languages provide tools for safe concurrency and memory safety, they do this with added overhead (e.g. by using a GC), and tend to lack performance and fine-grained control.

    To deal with these limitations, one has to resort to low-level languages. Without the safety nets of most high-level languages this can be fragile and error-prone. One suddenly has to deal with manual memory management, resource allocation, dangling pointers, etc. Creating software that can leverage the growing number of cores present in today’s devices is difficult — making sure said code works correctly is even harder.

    So how does Rust incorporate the best of both worlds in one language? That’s what we’ll show you in this article. Rust 1.0.0 stable has just been released. The language already has a vibrant community, a growing ecosystem of crates (libraries) in its package manager, and developers harnessing its capabilities in a variety of projects. Even if you’ve never touched a lower-level language, it’s a perfect time for you to dive in!

    The community has celebrated Rust's first stable release worldwide at 'Rust release parties'Rust t-shirts celebrate the release of Rust 1.0 worldwide.

    Use cases for Rust today

    So for systems hackers, Rust seems like a great choice, but how about those who are not familiar with low-level languages? Maybe the last time you heard the words “C” and “stack/heap allocation” was 10 years ago in CompSci 101 (or maybe never). Rust provides the performance typically seen only in low-level systems languages — but most of the time it certainly feels like a high-level language! Here are a few examples of how you can leverage Rust now in practical applications:

    I want to hack on hardware/write Internet-of-Things applications

    The IoT era and the expansion of the maker movement enables a real democratization of hardware projects. Whether it is the Raspberry Pi, Arduino, or one of the young titans like the BeagleBone or Tessel, you can choose from a slew of languages to code your hardware projects, including Python or JavaScript.

    There are times, however, when the performance these languages offer is simply not adequate. At other times, the microcontroller hardware you are aiming for is not suited to the runtimes these languages require: slow chips with tiny memory reserves and ultra-low-power applications still require a close-to-the-metal language. Traditionally that language has been C — but as you might have guessed, Rust is the new kid on the block.

    Rust supports a wide variety of exotic platforms. While some of this is still experimental, support includes generic ARM hardware, the Texas Instruments TIVA dev board, and even the Raspberry Pi. Some of the newest IoT boards like the Tessel 2 even come with official, out-of-the-box Rust support!

    I’m operating high-performance computing applications that scale to multiple cores

    Studies suggest Rust is already great for HPC (high-performance computing). You don’t even have to rewrite your whole application in Rust: its flexible Foreign Function Interface (FFI) provides efficient C bindings that let you expose and call Rust code without any noticable overhead. This allows you to rewrite your app module by module, slowly transitioning towards a better developer experience that will result in performance on par with the old code or better. You also get a more maintainable codebase with fewer errors, which scales better on a high number of cores.

    I simply need something fast!

    Rust is great for rewriting performance-sensitive parts of your application. It interfaces well with other languages via FFI and has a tiny runtime that competes with C and C++ in most cases, even when resources are limited.

    Despite the work-in-progress nature of the language, there are already business-critical, live production applications that have been making good use of Rust for some time: Yehuda Katz’s startup, Skylight uses high-performance Rust code embedded in a ruby gem for data-crunching. The 1.0.0 stable release is also an important milestone in that no breaking changes should happen from now on. That makes it safe to recommend Rust for even the most demanding and robust applications!

    Watch Yehuda Katz and Tom Dale talk about the basics of Rust programming and how they used Rust with Ruby in their app.

    Getting started with Rust

    There are many tutorials covering Rust in general, as well as specific aspects of the language. For example, the Rust blog has great articles on various facets of developing Rust applications. There are also excellent introductory talks such as Aaron Turon’s talk at Stanford University. He explains the main concepts and motivations behind Rust nicely, and the talk serves as the perfect appetizer, starting you on your journey:

    Talks and tutorials are no substitute for writing code, right? Rust’s got you covered in that regard, too! The Rust Book was conceived to help you get started — from installation to that first Hello World to providing an in-depth reference for all the core language features.

    Another resource worth mentioning is Rust by Example, which guides you through Rust’s key features, from the basics to the arcane powers of traits, macros, and the FFI. Rust By Example offers invaluable live-editable, in-browser examples with all of the articles. You don’t even have to download and compile Rust, as you can try (and edit) all of these examples from the comfort of your living room couch, just as they are. There is also a Rust Playpen for the exact same purpose.

    Not that downloading and installing Rust is much trouble, anyway. Head to the Rust homepage and download the appropriate binary/installer there. The downloads contain all the tools you need to get started (like rustc, the compiler, or cargo the package manager), and are available pre-built for all platforms (Windows, Linux, and OSX).

    What is it then, that makes Rust so unique, so different?

    The Rust Way

    Arguably it’s Rust’s unique ownership model that allows it to really shine — eliminating whole classes of errors related to threading and memory management, while easing development and debugging. It is also invaluable in keeping the language runtime minimal and the compiler output lean and performant.

    The ownership model

    The basic principle of Rust’s ownership model is that every resource can belong to one and only one “owner.” A “resource” can be anything — from a piece of memory to an open network socket to something more abstract like a mutex lock. The owner of said resource is responsible for using, possibly lending out the resource (to other users), and finally cleaning it up.

    All this happens automatically, with the help of scopes and bindings: bindings either own or borrow values, and last till the end of their scope. As bindings go out of scope, they either give their borrowed resource back, or in case they were the owner, dispose of the resource.

    What’s even better is that the checks required for the ownership model to work are executed and enforced by the Rust compiler and “borrow checker” during compilation, which in turn results in various benefits.

    Zero-cost abstractions

    Since the correct operation of a program is asserted at compilation time, code that compiles can generally be considered safe with regard to most common types of memory and concurrency errors (such as use-after-free bugs or data races). This is possible because Rust complains at compilation time if the programmer attempts to do something that violates the principles above, which in turn helps keep the language runtime minimal.
    By deferring these checks till compilation time, there’s no need to perform them during runtime (code is already “safe”), and no runtime overhead. In the case of memory allocations, there is no need for runtime garbage collection, either. This — advanced language constructs with little to no runtime overhead — is the basic idea of “zero-cost abstractions.”

    Though a thorough explanation of the ownership model is outside the scope of this article, the Rust Book (linked above) and various talks and articles excel in explaining its principles. The principles of ownership and the borrow checker are essential for understanding Rust, and are key to other powerful aspects of the language, like its handling of concurrency and parallelism.

    Two birds, one language construct

    Shared mutable state is the root of all evil. Most languages attempt to deal with this problem through the mutable part, but Rust deals with it by solving the shared part.
    The Rust Book

    Aside from memory safety, paralellism and concurrency are the second most important focus in Rust’s philosophy. It might seem surprising, but the ownership system (coupled with a few handy traits) also provides powerful tools for threading, synchronization, and concurrent data access.

    When you try some of the built-in concurrency primitives and start digging deeper into the language, it may come as a surprise that those primitives are provided by the standard library, rather than being part of the language core itself. Thus, coming up with new ways to do concurrent programming is in the hands of library authors — rather than being hard-wired into Rust, restricted by the language creators’ future plans.

    Performance or expressiveness? Choose both!

    Thanks to its static type system, carefully selected features, and having no garbage collector, Rust compiles into performant and predictable code that’s on par with code written in traditional, low-level languages (such as C/C++).

    By moving the various checks out of the runtime and getting rid of garbage collection, the resulting code mimics the performance characteristics of other low-level languages, while the language itself remains much more expressive. The (seemingly) high level constructs (strings, collections, higher order functions, etc.) mostly avoid the runtime performance hit commonly associated with them. Since the Rust compiler’s output is in the LLVM intermediate representation, the final machine code makes good use of the LLVM compiler’s cross-platform benefits and all additional (current and future) optimizations automatically.

    We could go on for hours about how with Rust you never have to worry about closing sockets or freeing memory, how traits and macros give you incredible flexibility for overloading operators, or even working with Rust’s functional aspect, juggling iterators, closures and higher order functions. But we wouldn’t want to overwhelm you early on! Sooner or later you will come across these anyway — and it’s more fun to discover for yourself exactly how deep the rabbit hole is.

    So now instead, let’s finally look at some code.

    Say hello to Rust

    Without further ado — your very first Rust code:

    fn main() {
        println!("Hello, Rust!");
    }

    Open this snippet in the Online Rust Playpen >>

    Wait, is that it? This may seem a bit anti-climactic, but there are only so many ways to write a Hello World in Rust. Bear with us while we share a slightly more complex example — and another timeless classic.

    What’s all this Fizzbuzz about

    We are going old-school with the FizzBuzz program! Fizzbuzz is an algorithm in which we count upwards for all eternity, replacing some of the numbers with fizz (for numbers evenly divisible by 3), buzz (for numbers divisible by 5), or fizzbuzz (divisible by both 3 and 5).

    Also to show our point (and to help familiarize you with Rust’s semantics), we have included the C and Python versions of the same algorithm:

    Imperative fizzbuzz – C version

    #include 
    
    int main(void)
    {
        int num;
        for(num=1; num<101; ++num)
        {
            if( num%3 == 0 && num%5 == 0 ) {
                printf("fizzbuzz\n");
            } else if( num%3 == 0) {
                printf("fizz\n");
            } else if( num%5 == 0) {
                printf("buzz\n");
            } else {
                printf("%d\n",num);
            }
        }
    
        return 0;
    }
    
    Imperative fizzbuzz – Python version

    for num in xrange(1,101):
        if num%3 == 0 and num%5 == 0:
            print "fizzbuzz"
        elif num%3 == 0:
            print "fizz"
        elif num%5 == 0:
            print "buzz"
        else:
            print num
    
    Imperative fizzbuzz – Rust version

    fn main() {
        for num in 1..101 { // Range notation!
            match (num%3, num%5) { // Pattern Matching FTW!
                (0, 0) => println!("fizzbuzz"),
                (0, _) => println!("fizz"),
                (_, 0) => println!("buzz"),
                     _ => println!("{}", num) 
            }
        }
    }
    

    Open this snippet in the Online Rust Playpen >>

    Even on such a small snippet, some of Rust’s power starts to show. The most obvious difference might be that we are using pattern matching, instead of traditional if statements. We could use those, however match is a very useful addition to a Rustacean‘s arsenal.

    The other thing to note is the range notation in the for-loop’s declaration (similar to its Python counterpart). It interesting, though, that in this case we could not have used a “traditional” C-like for loop instead — as it is by design unsupported in Rust. Traditional for loops are considered error-prone and are replaced with the safer and more flexible iterable concept.

    Here’s a more elaborate look at what happens in the pattern-matching phase of our fizzbuzz example:

    ...
     
    // For pattern matching, we build a tuple, containing
    // the remainders for integer division of num by 3 and 5
    match (num%3, num%5) {
        // When "num" is divisible by 3 AND 5 both
        // (both remainders are 0)
        // -> print the string "fizzbuzz"
        (0, 0) => println!("fizzbuzz"),
    
        // When "num" is divisible by 3 (the remainder is 0)
        // Is "num" divisible by 5? -> we don't care
        // -> print the string "fizz"
        (0, _) => println!("fizz"),
    
        // When "num" is divisible by 5 (the remainder is 0)
        // Is "num" divisible by 3? -> we don't care
        // -> print the string "buzz"
        (_, 0) => println!("buzz"),
    
        // In any other cases, just print num's value
        // Note, that matching must be exhaustive (that is,
        // cover all possible outcomes) - this is enforced
        // by the compiler!
             _ => pintln!("{}", num)
    }
    ...
    

    This is not the place to go deep on how pattern matching or destructuring work, or what tuples are. You’ll find excellent articles on these topics in the Rust Book, the Rust Blog, or over at Rust By Example, but we think it’s a great way to demonstrate the features and nuances that make Rust both powerful and effective.

    How about some functional Fizzbuzz

    To expand on the last example and demonstrate Rust’s true flexibility, in our second example we’ll crank our fizzbuzz up a notch! Rust calls itself multi-paradigm. We can put that to the test by rewriting our fizzbuzz example in functional style. To help put the code in perspective, we will also show the implementations in JavaScript (the ECMAScript 6 flavor), too:

    Functional fizzbuzz – JavaScript (ES6) version

    Array.from(Array(100).keys()).slice(1)
        .map((num) => {
            if (num%3 === 0 && num%5 === 0) {
                return "fizzbuzz";
            } else if (num%3 === 0) {
                return "fizz";
            } else if (num%5 === 0) {
                return "buzz";
            } else {
                return num;
            }
        })
        .map(output => console.log(output));
    
    Functional fizzbuzz – Rust version

    fn main() {
        (1..101)
            .map(|num| {
                match (num%3, num%5) { // Pattern Matching FTW!
                    (0, 0) => "fizzbuzz".to_string(),
                    (0, _) => "fizz".to_string(),
                    (_, 0) => "buzz".to_string(),
                         _ => format!("{}", num) 
                }
            })
            .map(|output| { println!("{}", output); output })
            .collect::<Vec<_>>();
    }
    

    Open this snippet in the Online Rust Playpen >>

    Not only can we mimic JavaScript’s functional style with closures and functional method calls, but thanks to Rust’s powerful pattern matching, we can even trump JavaScript’s expressiveness a bit.

    Note: Rust’s iterators are lazy, so we actually need the .collect() call (which is called a consumer) for this to work — if you leave that out, none of the above code will execute. Check out the consumers section of the Rust Book to learn more.

    Picking a project

    You’re eager to dive into Rust and ready to start something cool. But what to build? You could start small—write a small app or a tiny library, and upload it to crates.io. People have created many exciting projects in Rust already — from pet *nix-like kernels to embedded hardware projects, from games to web server frameworks, proving that the only limit is your imagination.

    If you want to start small, but contribute something useful while learning the intricacies of Rust programming, consider contributing to some of the projects already thriving on GitHub (or even the Rust compiler itself — which is also written in Rust).
    Or, you could start by rewriting small parts of your production app, and experimenting with the results. Rust’s Foreign Function Interface (FFI) is intended as a drop-in replacement for C code. With minimal effort you could replace small parts of your application with Rust implementations of the same code. But interoperability doesn’t stop there — these C bindings work both ways. This means you can use all standard C libraries in your Rust apps — or (since many programming languages come with standard C interface libraries) make calls back-and-forth between Rust and Python, Ruby, or even Go!

    Watch Dan Callahan’s talk “My Python’s a little Rust-y on how to hook up Rust with Python.

    There are virtually no languages that don’t work with Rust: want to compile Rust to JavaScript or use inline assembly in your code? Yes, you can!

    Now get out there and build something awesome.

    Please don’t forget — Rust is not simply a programming language — it’s also a community. Should you ever feel stuck, don’t be shy to ask for help, either on the Forums or IRC. You could also share your thoughts and creations on the Rust Reddit.

    Rust is already great — it’s people like you who are going to make it ever more awesome!

  4. ES6 In Depth: Template strings

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    Last week I promised a change of pace. After iterators and generators, we would tackle something easy, I said. Something that won’t melt your brain, I said. We’ll see whether I can keep that promise in the end.

    For now, let’s start with something simple.

    Backtick basics

    ES6 introduces a new kind of string literal syntax called template strings. They look like ordinary strings, except using the backtick character ` rather than the usual quote marks ' or ". In the simplest case, they really are just strings:

    context.fillText(`Ceci n'est pas une chaîne.`, x, y);
    

    But there’s a reason these are called “template strings” and not “boring plain old strings that don’t do anything special, only with backticks”. Template strings bring simple string interpolation to JavaScript. That is, they’re a nice-looking, convenient way to plug JavaScript values into a string.

    There are one million ways to use this, but the one that warms my heart is the humble error message:

    function authorize(user, action) {
      if (!user.hasPrivilege(action)) {
        throw new Error(
          `User ${user.name} is not authorized to do ${action}.`);
      }
    }
    

    In this example, ${user.name} and ${action} are called template substitutions. JavaScript will plug the values user.name and action into the resulting string. This could generate a message like User jorendorff is not authorized to do hockey. (Which is true. I don’t have a hockey license.)

    So far, this is just a slightly nicer syntax for the + operator, and the details are what you would expect:

    • The code in a template substitution can be any JavaScript expression, so function calls, arithmetic, and so on are allowed. (If you really want to, you can even nest a template string inside another template string, which I call template inception.)

    • If either value is not a string, it’ll be converted to a string using the usual rules. For example, if action is an object, its .toString() method will be called.

    • If you need to write a backtick inside a template string, you must escape it with a backslash: `\`` is the same as "`".

    • Likewise, if you need to include the two characters ${ in a template string, I don’t want to know what you’re up to, but you can escape either character with a backslash: `write \${ or $\{`.

    Unlike ordinary strings, template strings can cover multiple lines:

    $("#warning").html(`
      <h1>Watch out!</h1>
      <p>Unauthorized hockeying can result in penalties
      of up to ${maxPenalty} minutes.</p>
    `);
    

    All whitespace in the template string, including newlines and indentation, is included verbatim in the output.

    OK. Because of my promise last week, I feel responsible for your brain health. So a quick warning: it starts getting a little intense from here. You can stop reading now, maybe go have a cup of coffee and enjoy your intact, unmelted brain. Seriously, there’s no shame in turning back. Did Lopes Gonçalves exhaustively explore the entire Southern Hemisphere after proving that ships can cross the equator without being crushed by sea monsters or falling off the edge of the earth? No. He turned back, went home, and had a nice lunch. You like lunch, right?

    Backtick the future

    Let’s talk about a few things template strings don’t do.

    • They don’t automatically escape special characters for you. To avoid cross-site scripting vulnerabilities, you’ll still have to treat untrusted data with care, just as if you were concatenating ordinary strings.

    • It’s not obvious how they would interact with an internationalization library (a library for helping your code speak different languages to different users). Template strings don’t handle language-specific formatting of numbers and dates, much less plurals.

    • They aren’t a replacement for template libraries, like Mustache or Nunjucks.

      Template strings don’t have any built-in syntax for looping—building the rows of an HTML table from an array, for example—or even conditionals. (Yes, you could use template inception for this, but to me it seems like the sort of thing you’d do as a joke.)

    ES6 provides one more twist on template strings that gives JS developers and library designers the power to address these limitations and more. The feature is called tagged templates.

    The syntax for tagged templates is simple. They’re just template strings with an extra tag before the opening backtick. For our first example, the tag will be SaferHTML, and we’re going to use this tag to try to address the first limitation listed above: automatically escaping special characters.

    Note that SaferHTML is not something provided by the ES6 standard library. We’re going to implement it ourselves below.

    var message =
      SaferHTML`<p>${bonk.sender} has sent you a bonk.</p>`;
    

    The tag here is the single identifier SaferHTML, but a tag can also be a property, like SaferHTML.escape, or even a method call, like SaferHTML.escape({unicodeControlCharacters: false}). (To be precise, any ES6 MemberExpression or CallExpression can serve as a tag.)

    We saw that untagged template strings are shorthand for simple string concatenation. Tagged templates are shorthand for something else entirely: a function call.

    The code above is equivalent to:

    var message =
      SaferHTML(templateData, bonk.sender);
    

    where templateData is an immutable array of all the string parts of the template, created for us by the JS engine. Here the array would have two elements, because there are two string parts in the tagged template, separated by a substitution. So templateData will be like Object.freeze(["<p>", " has sent you a bonk.</p>"].

    (There is actually one more property present on templateData. We won’t use it in this article, but I’ll mention it for completeness: templateData.raw is another array containing all the string parts in the tagged template, but this time exactly as they looked in the source code—with escape sequences like \n left intact, rather than being turned into newlines and so on. The standard tag String.raw uses these raw strings.)

    This gives the SaferHTML function free rein to interpret both the string and the substitutions in a million possible ways.

    Before reading on, maybe you’d like to try to puzzle out just what SaferHTML should do, and then try your hand at implementing it. After all, it’s just a function. You can test your work in the Firefox developer console.

    Here is one possible answer (also available as a gist).

    function SaferHTML(templateData) {
      var s = templateData[0];
      for (var i = 1; i < arguments.length; i++) {
        var arg = String(arguments[i]);
    
        // Escape special characters in the substitution.
        s += arg.replace(/&/g, "&amp;")
                .replace(/</g, "&lt;")
                .replace(/>/g, "&gt;");
    
        // Don't escape special characters in the template.
        s += templateData[i];
      }
      return s;
    }
    

    With this definition, the tagged template SaferHTML`<p>${bonk.sender} has sent you a bonk.</p>` might expand to the string "<p>ES6&lt;3er has sent you a bonk.</p>". Your users are safe even if a maliciously named user, like Hacker Steve <script>alert('xss');</script>, sends them a bonk. Whatever that means.

    (Incidentally, if the way that function uses the arguments object strikes you as a bit clunky, drop by next week. There’s another new feature in ES6 that I think you’ll like.)

    A single example isn’t enough to illustrate the flexibility of tagged templates. Let’s revisit our earlier list of template string limitations to see what else you could do.

    • Template strings don’t auto-escape special characters. But as we’ve seen, with tagged templates, you can fix that problem yourself with a tag.

      In fact, you can do a lot better than that.

      From a security perspective, my SaferHTML function is pretty weak. Different places in HTML have different special characters that need to be escaped in different ways; SaferHTML does not escape them all. But with some effort, you could write a much smarter SaferHTML function that actually parses the bits of HTML in the strings in templateData, so that it knows which substitutions are in plain HTML; which ones are inside element attributes, and thus need to escape ' and "; which ones are in URL query strings, and thus need URL-escaping rather than HTML-escaping; and so on. It could perform just the right escaping for each substitution.

      Does this sound far-fetched because HTML parsing is slow? Fortunately, the string parts of a tagged template do not change when the template is evaluated again. SaferHTML could cache the results of all this parsing, to speed up later calls. (The cache could be a WeakMap, another ES6 feature that we’ll discuss in a future post.)

    • Template strings don’t have built-in internationalization features. But with tags, we could add them. A blog post by Jack Hsu shows what the first steps down that road might look like. Just one example, as a teaser:

      i18n`Hello ${name}, you have ${amount}:c(CAD) in your bank account.`
      // => Hallo Bob, Sie haben 1.234,56 $CA auf Ihrem Bankkonto.
      

      Note how in this example, name and amount are JavaScript, but there’s a different bit of unfamiliar code, that :c(CAD), which Jack places in the string part of the template. JavaScript is of course handled by the JavaScript engine; the string parts are handled by Jack’s i18n tag. Users would learn from the i18n documentation that :c(CAD) means amount is an amount of currency, denominated in Canadian dollars.

      This is what tagged templates are about.

    • Template strings are no replacement for Mustache and Nunjucks, partly because they don’t have built-in syntax for loops or conditionals. But now we’re starting to see how you would go about fixing this, right? If JS doesn’t provide the feature, write a tag that provides it.

      // Purely hypothetical template language based on
      // ES6 tagged templates.
      var libraryHtml = hashTemplate`
        <ul>
          #for book in ${myBooks}
            <li><i>#{book.title}</i> by #{book.author}</li>
          #end
        </ul>
      `;
      

    The flexibility doesn’t stop there. Note that the arguments to a tag function are not automatically converted to strings. They can be anything. The same goes for the return value. Tagged templates are not even necessarily strings! You could use custom tags to create regular expressions, DOM trees, images, promises representing whole asynchronous processes, JS data structures, GL shaders...

    Tagged templates invite library designers to create powerful domain-specific languages. These languages might look nothing like JS, but they can still embed in JS seamlessly and interact intelligently with the rest of the language. Offhand, I can’t think of anything quite like it in any other language. I don’t know where this feature will take us. The possibilities are exciting.

    When can I start using this?

    On the server, ES6 template strings are supported in io.js today.

    In browsers, Firefox 34+ supports template strings. They were implemented by Guptha Rajagopal as an intern project last summer. Template strings are also supported in Chrome 41+, but not in IE or Safari. For now, you’ll need to use Babel or Traceur if you want to use template strings on the web. You can also use them right now in TypeScript!

    Wait—what about Markdown?

    Hmm?

    Oh. ...Good question.

    (This section isn’t really about JavaScript. If you don’t use Markdown, you can skip it.)

    With template strings, both Markdown and JavaScript now use the ` character to mean something special. In fact, in Markdown, it’s the delimiter for code snippets in the middle of inline text.

    This brings up a bit of a problem! If you write this in a Markdown document:

    To display a message, write `alert(`hello world!`)`.
    

    it’ll be displayed like this:

    To display a message, write alert(hello world!).

    Note that there are no backticks in the output. Markdown interpreted all four backticks as code delimiters and replaced them with HTML tags.

    To avoid this, we turn to a little-known feature that’s been in Markdown from the beginning: you can use multiple backticks as code delimiters, like this:

    To display a message, write ``alert(`hello world!`)``.
    

    This Gist has the details, and it’s written in Markdown so you can look at the source.

    Up next

    Next week, we’ll look at two features that programmers have enjoyed in other languages for decades: one for people who like to avoid an argument where possible, and one for people who like to have lots of arguments. I’m talking about function arguments, of course. Both features are really for all of us.

    We’ll see these features through the eyes of the person who implemented them in Firefox. So please join us next week, as guest author Benjamin Peterson presents ES6 default parameters and rest parameters in depth.

  5. Trainspotting: Firefox 38

    Trainspotting is a series of articles highlighting features in the latest version of Firefox, that are live now in production code, ready for you to use in your work. A new version of Firefox is shipped every six weeks – we at Mozilla call this pattern “release trains.”

    Has it been six weeks already?? Firefox 38 is here, and with it come some snazzy new additions to the Web platform. Here are a few highlights:

    For a full list of changes and additions, take a look at the Firefox 38 release notes.

    Responsive Image Support

    Support for both the <picture> element and <img srcset> are now in a stable Firefox! There are lots of great articles available to get you familiar with the new techniques, and a polyfill available so you can take advantage of them today! There is one caveat for Firefox 38 – responsive images will load using the correct media queries, but presently do not respond to viewport resizing. This bug is being actively worked on and tracked here, and will be fixed in a near-future version of Firefox.

    You got WebSockets in my Web Worker!

    Firefox 38 now allows code running in a Web Worker to open up a WebSocket connection. This is great for games or other collaborative applications, which can now do their multiplayer/realtime logic in a separate thread from the UI.

    HTML5 <ruby> markup support

    Ruby Annotation

    Better typography for Japanese and Chinese language sites is now possible without clunky libraries or extensions by using <ruby> markup.

    BroadcastChannel- postMessage All the Windows!

    If you’re building a webapp with multiple tabs or windows, keeping them all in sync, apprised of events and state changes can be a pain. BroadcastChannel is a fully client-side message passing API that lets any scripts running on the same origin broadcast messages to their peers.

    // one tab
    var ch = new BroadcastChannel('test');
    ch.postMessage('this is a test');
    
    // another tab
    ch.addEventListener('message', function (e) {
        alert('I got a message!', e.data);
    });
    
    // yet another tab
    ch.addEventListener('message', function (e) {
        alert('Avast! a message!' e.data);
    });

    Developer Tools

    Network requests coming from XMLHttpRequest are now marked in the Web Console:

    XMLHttpRequest requests marked in the Web Console

    Need to grab a value from your page? The special copy method available in the Web Console has you covered:

    consolecopy

    But Wait

    There are tons more improvements and bug fixes in Firefox 38 I haven’t covered here – check out the Firefox 38 release notes, Developer Release Notes, or even the list of bugs fixed in this release for more information.

    Enjoy!

  6. ES6 In Depth: Generators

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    I’m excited about today’s post. Today, we’re going to discuss the most magical feature in ES6.

    What do I mean by “magical”? For starters, this feature is so different from things that already existed in JS that it may seem completely arcane at first. In a sense, it turns the normal behavior of the language inside out! If that’s not magic, I don’t know what is.

    Not only that: this feature’s power to simplify code and straighten out “callback hell” borders on the supernatural.

    Am I laying it on a bit thick? Let’s dive in and you can judge for yourself.

    Introducing ES6 generators

    What are generators?

    Let’s start by looking at one.

    function* quips(name) {
      yield "hello " + name + "!";
      yield "i hope you are enjoying the blog posts";
      if (name.startsWith("X")) {
        yield "it's cool how your name starts with X, " + name;
      }
      yield "see you later!";
    }
    

    This is some code for a talking cat, possibly the most important kind of application on the Internet today. (Go ahead, click the link, play with the cat. When you’re thoroughly confused, come back here for the explanation.)

    It looks sort of like a function, right? This is called a generator-function and it has a lot in common with functions. But you can see two differences right away:

    • Regular functions start with function. Generator-functions start with function*.

    • Inside a generator-function, yield is a keyword, with syntax rather like return. The difference is that while a function (even a generator-function) can only return once, a generator-function can yield any number of times. The yield expression suspends execution of the generator so it can be resumed again later.

    So that’s it, that’s the big difference between regular functions and generator-functions. Regular functions can’t pause themselves. Generator-functions can.

    What generators do

    What happens when you call the quips() generator-function?

    > var iter = quips("jorendorff");
      [object Generator]
    > iter.next()
      { value: "hello jorendorff!", done: false }
    > iter.next()
      { value: "i hope you are enjoying the blog posts", done: false }
    > iter.next()
      { value: "see you later!", done: false }
    > iter.next()
      { value: undefined, done: true }
    

    You’re probably very used to ordinary functions and how they behave. When you call them, they start running right away, and they run until they either return or throw. All this is second nature to any JS programmer.

    Calling a generator looks just the same: quips("jorendorff"). But when you call a generator, it doesn’t start running yet. Instead, it returns a paused Generator object (called iter in the example above). You can think of this Generator object as a function call, frozen in time. Specifically, it’s frozen right at the top of the generator-function, just before running its first line of code.

    Each time you call the Generator object’s .next() method, the function call thaws itself out and runs until it reaches the next yield expression.

    That’s why each time we called iter.next() above, we got a different string value. Those are the values produced by the yield expressions in the body of quips().

    On the last iter.next() call, we finally reached the end of the generator-function, so the .done field of the result is true. Reaching the end of a function is just like returning undefined, and that’s why the .value field of the result is undefined.

    Now might be a good time to go back to the talking cat demo page and really play around with the code. Try putting a yield inside a loop. What happens?

    In technical terms, each time a generator yields, its stack frame—the local variables, arguments, temporary values, and the current position of execution within the generator body—is removed from the stack. However, the Generator object keeps a reference to (or copy of) this stack frame, so that a later .next() call can reactivate it and continue execution.

    It’s worth pointing out that generators are not threads. In languages with threads, multiple pieces of code can run at the same time, usually leading to race conditions, nondeterminism, and sweet sweet performance. Generators are not like that at all. When a generator runs, it runs in the same thread as the caller. The order of execution is sequential and deterministic, and never concurrent. Unlike system threads, a generator is only ever suspended at points marked by yield in its body.

    All right. We know what generators are. We’ve seen a generator run, pause itself, then resume execution. Now for the big question. How could this weird ability possibly be useful?

    Generators are iterators

    Last week, we saw that ES6 iterators are not just a single built-in class. They’re an extension point of the language. You can create your own iterators just by implementing two methods: [Symbol.iterator]() and .next().

    But implementing an interface is always at least a little work. Let’s see what an iterator implementation looks like in practice. As an example, let’s make a simple range iterator that simply counts up from one number to another, like an old-fashioned C for (;;) loop.

    // This should "ding" three times
    for (var value of range(0, 3)) {
      alert("Ding! at floor #" + value);
    }
    

    Here’s one solution, using an ES6 class. (If the class syntax is not completely clear, don’t worry—we’ll cover it in a future blog post.)

    class RangeIterator {
      constructor(start, stop) {
        this.value = start;
        this.stop = stop;
      }
    
      [Symbol.iterator]() { return this; }
    
      next() {
        var value = this.value;
        if (value < this.stop) {
          this.value++;
          return {done: false, value: value};
        } else {
          return {done: true, value: undefined};
        }
      }
    }
    
    // Return a new iterator that counts up from 'start' to 'stop'.
    function range(start, stop) {
      return new RangeIterator(start, stop);
    }
    

    See this code in action.

    This is what implementing an iterator is like in Java or Swift. It’s not so bad. But it’s not exactly trivial either. Are there any bugs in this code? It’s not easy to say. It looks nothing like the original for (;;) loop we are trying to emulate here: the iterator protocol forces us to dismantle the loop.

    At this point you might be feeling a little lukewarm toward iterators. They may be great to use, but they seem hard to implement.

    It probably wouldn’t occur to you to suggest that we introduce a wild, mindbending new control flow structure to the JS language just to make iterators easier to build. But since we do have generators, can we use them here? Let’s try it:

    function* range(start, stop) {
      for (var i = start; i < stop; i++)
        yield i;
    }
    

    See this code in action.

    The above 4-line generator is a drop-in replacement for the previous 23-line implementation of range(), including the entire RangeIterator class. This is possible because generators are iterators. All generators have a built-in implementation of .next() and [Symbol.iterator](). You just write the looping behavior.

    Implementing iterators without generators is like being forced to write a long email entirely in the passive voice. When simply saying what you mean is not an option, what you end up saying instead can become quite convoluted. RangeIterator is long and weird because it has to describe the functionality of a loop without using loop syntax. Generators are the answer.

    How else can we use the ability of generators to act as iterators?

    • Making any object iterable. Just write a generator-function that traverses this, yielding each value as it goes. Then install that generator-function as the [Symbol.iterator] method of the object.

    • Simplifying array-building functions. Suppose you have a function that returns an array of results each time it’s called, like this one:

      // Divide the one-dimensional array 'icons'
      // into arrays of length 'rowLength'.
      function splitIntoRows(icons, rowLength) {
        var rows = [];
        var nRows = Math.ceil(icons.length / rowLength);
        for (var i = 0; i < icons.length; i += rowLength) {
          rows.push(icons.slice(i, i + rowLength));
        }
        return rows;
      }
      

      Generators make this kind of code a bit shorter:

      function* splitIntoRows(icons, rowLength) {
        var nRows = Math.ceil(icons.length / rowLength);
        for (var i = 0; i < icons.length; i += rowLength) {
          yield icons.slice(i, i + rowLength);
        }
      }
      

      The only difference in behavior is that instead of computing all the results at once and returning an array of them, this returns an iterator, and the results are computed one by one, on demand.

    • Results of unusual size. You can’t build an infinite array. But you can return a generator that generates an endless sequence, and each caller can draw from it however many values they need.

    • Refactoring complex loops. Do you have a huge ugly function? Would you like to break it into two simpler parts? Generators are a new knife to add to your refactoring toolkit. When you’re facing a complicated loop, you can factor out the part of the code that produces data, turning it into a separate generator-function. Then change the loop to say for (var data of myNewGenerator(args)).

    • Tools for working with iterables. ES6 does not provide an extensive library for filtering, mapping, and generally hacking on arbitrary iterable data sets. But generators are great for building the tools you need with just a few lines of code.

      For example, suppose you need an equivalent of Array.prototype.filter that works on DOM NodeLists, not just Arrays. Piece of cake:

      function* filter(test, iterable) {
        for (var item of iterable) {
          if (test(item))
            yield item;
        }
      }
      

    So are generators useful? Sure. They are an astonshingly easy way to implement custom iterators, and iterators are the new standard for data and loops throughout ES6.

    But that’s not all generators can do. It may not even turn out to be the most important thing they do.

    Generators and asynchronous code

    Here is some JS code I wrote a while back.

              };
            })
          });
        });
      });
    });
    

    Maybe you’ve seen something like this in your own code. Asynchronous APIs typically require a callback, which means writing an extra anonymous function every time you do something. So if you have a bit of code that does three things, rather than three lines of code, you’re looking at three indentation levels of code.

    Here is some more JS code I’ve written:

    }).on('close', function () {
      done(undefined, undefined);
    }).on('error', function (error) {
      done(error);
    });
    

    Asynchronous APIs have error-handling conventions rather than exceptions. Different APIs have different conventions. In most of them, errors are silently dropped by default. In some of them, even ordinary successful completion is dropped by default.

    Until now, these problems have simply been the price we pay for asynchronous programming. We have come to accept that asynchronous code just doesn’t look as nice and simple as the corresponding synchronous code.

    Generators offer new hope that it doesn’t have to be this way.

    Q.async() is an experimental attempt at using generators with promises to produce async code that resembles the corresponding synchronous code. For example:

    // Synchronous code to make some noise.
    function makeNoise() {
      shake();
      rattle();
      roll();
    }
    
    // Asynchronous code to make some noise.
    // Returns a Promise object that becomes resolved
    // when we're done making noise.
    function makeNoise_async() {
      return Q.async(function* () {
        yield shake_async();
        yield rattle_async();
        yield roll_async();
      });
    }
    

    The main difference is that the asynchronous version must add the yield keyword each place where it calls an asynchronous function.

    Adding a wrinkle like an if statement or a try/catch block in the Q.async version is exactly like adding it to the plain synchronous version. Compared to other ways of writing async code, this feels a lot less like learning a whole new language.

    If you’ve gotten this far, you might enjoy James Long’s very detailed post on this topic.

    So generators are pointing the way to a new asynchronous programming model that seems better suited to human brains. This work is ongoing. Among other things, better syntax might help. A proposal for async functions, building on both promises and generators, and taking inspiration from similar features in C#, is on the table for ES7.

    When can I use these crazy things?

    On the server, you can use ES6 generators today in io.js (and in Node if you use the --harmony command-line option).

    In the browser, only Firefox 27+ and Chrome 39+ support ES6 generators so far. To use generators on the web today, you’ll need to use Babel or Traceur to translate your ES6 code to Web-friendly ES5.

    A few shout-outs to deserving parties: Generators were first implemented in JS by Brendan Eich; his design closely followed Python generators which were inspired by Icon. They shipped in Firefox 2.0 back in 2006. The road to standardization was bumpy, and the syntax and behavior changed a bit along the way. ES6 generators were implemented in both Firefox and Chrome by compiler hacker Andy Wingo. This work was sponsored by Bloomberg.

    yield;

    There is more to say about generators. We didn’t cover the .throw() and .return() methods, the optional argument to .next(), or the yield* expression syntax. But I think this post is long and bewildering enough for now. Like generators themselves, we should pause, and take up the rest another time.

    But next week, let’s change gears a little. We’ve tackled two deep topics in a row here. Wouldn’t it be great to talk about an ES6 feature that won’t change your life? Something simple and obviously useful? Something that will make you smile? ES6 has a few of those too.

    Coming up: a feature that will plug right in to the kind of code you write every day. Please join us next week for a look at ES6 template strings in depth.

  7. ES6 In Depth: Iterators and the for-of loop

    ES6 In Depth is a series on new features being added to the JavaScript programming language in the 6th Edition of the ECMAScript standard, ES6 for short.

    How do you loop over the elements of an array? When JavaScript was introduced, twenty years ago, you would do it like this:

    for (var index = 0; index < myArray.length; index++) {
      console.log(myArray[index]);
    }
    

    Since ES5, you can use the built-in forEach method:

    myArray.forEach(function (value) {
      console.log(value);
    });
    

    This is a little shorter, but there is one minor drawback: you can’t break out of this loop using a break statement or return from the enclosing function using a return statement.

    It sure would be nice if there were just a for-loop syntax that looped over array elements.

    How about a for-in loop?

    for (var index in myArray) {    // don't actually do this
      console.log(myArray[index]);
    }
    

    This is a bad idea for several reasons:

    • The values assigned to index in this code are the strings "0", "1", "2" and so on, not actual numbers. Since you probably don’t want string arithmetic ("2" + 1 == "21"), this is inconvenient at best.
    • The loop body will execute not only for array elements, but also for any other expando properties someone may have added. For example, if your array has an enumerable property myArray.name, then this loop will execute one extra time, with index == "name". Even properties on the array’s prototype chain can be visited.
    • Most astonishing of all, in some circumstances, this code can loop over the array elements in an arbitrary order.

    In short, for-in was designed to work on plain old Objects with string keys. For Arrays, it’s not so great.

    The mighty for-of loop

    Remember last week I promised that ES6 would not break the JS code you’ve already written. Well, millions of Web sites depend on the behavior of for-in—yes, even its behavior on arrays. So there was never any question of “fixing” for-in to be more helpful when used with arrays. The only way for ES6 to improve matters was to add some kind of new loop syntax.

    And here it is:

    for (var value of myArray) {
      console.log(value);
    }
    

    Hmm. After all that build-up, it doesn’t seem all that impressive, does it? Well, we’ll see whether for-of has any neat tricks up its sleeve. For now, just note that:

    • this is the most concise, direct syntax yet for looping through array elements
    • it avoids all the pitfalls of for-in
    • unlike forEach(), it works with break, continue, and return

    The for-in loop is for looping over object properties.

    The for-of loop is for looping over data—like the values in an array.

    But that’s not all.

    Other collections support for-of too

    for-of is not just for arrays. It also works on most array-like objects, like DOM NodeLists.

    It also works on strings, treating the string as a sequence of Unicode characters:

    for (var chr of "😺😲") {
      alert(chr);
    }
    

    It also works on Map and Set objects.

    Oh, I’m sorry. You’ve never heard of Map and Set objects? Well, they are new in ES6. We’ll do a whole post about them at some point. If you’ve worked with maps and sets in other languages, there won’t be any big surprises.

    For example, a Set object is good for eliminating duplicates:

    // make a set from an array of words
    var uniqueWords = new Set(words);
    

    Once you’ve got a Set, maybe you’d like to loop over its contents. Easy:

    for (var word of uniqueWords) {
      console.log(word);
    }
    

    A Map is slightly different: the data inside it is made of key-value pairs, so you’ll want to use destructuring to unpack the key and value into two separate variables:

    for (var [key, value] of phoneBookMap) {
      console.log(key + "'s phone number is: " + value);
    }
    

    Destructuring is yet another new ES6 feature and a great topic for a future blog post. I should write these down.

    By now, you get the picture: JS already has quite a few different collection classes, and even more are on the way. for-of is designed to be the workhorse loop statement you use with all of them.

    for-of does not work with plain old Objects, but if you want to iterate over an object’s properties you can either use for-in (that’s what it’s for) or the builtin Object.keys():

    // dump an object's own enumerable properties to the console
    for (var key of Object.keys(someObject)) {
      console.log(key + ": " + someObject[key]);
    }
    

    Under the hood

    “Good artists copy, great artists steal.” —Pablo Picasso

    A running theme in ES6 is that the new features being added to the language didn’t come out of nowhere. Most have been tried and proven useful in other languages.

    The for-of loop, for example, resembles similar loop statements in C++, Java, C#, and Python. Like them, it works with several different data structures provided by the language and its standard library. But it’s also an extension point in the language.

    Like the for/foreach statements in those other languages, for-of works entirely in terms of method calls. What Arrays, Maps, Sets, and the other objects we talked about all have in common is that they have an iterator method.

    And there’s another kind of object that can have an iterator method too: any object you want.

    Just as you can add a myObject.toString() method to any object and suddenly JS knows how to convert that object to a string, you can add the myObject[Symbol.iterator]() method to any object and suddenly JS will know how to loop over that object.

    For example, suppose you’re using jQuery, and although you’re very fond of .each(), you would like jQuery objects to work with for-of as well. Here’s how to do that:

    // Since jQuery objects are array-like,
    // give them the same iterator method Arrays have
    jQuery.prototype[Symbol.iterator] =
      Array.prototype[Symbol.iterator];
    

    OK, I know what you’re thinking. That [Symbol.iterator] syntax seems weird. What is going on there? It has to do with the method’s name. The standard committee could have just called this method .iterator(), but then, your existing code might already have some objects with .iterator() methods, and that could get pretty confusing. So the standard uses a symbol, rather than a string, as the name of this method.

    Symbols are new in ES6, and we’ll tell you all about them in—you guessed it—a future blog post. For now, all you need to know is that the standard can define a brand-new symbol, like Symbol.iterator, and it’s guaranteed not to conflict with any existing code. The trade-off is that the syntax is a little weird. But it’s a small price to pay for this versatile new feature and excellent backward compatibility.

    An object that has a [Symbol.iterator]() method is called iterable. In coming weeks, we’ll see that the concept of iterable objects is used throughout the language, not only in for-of but in the Map and Set constructors, destructuring assignment, and the new spread operator.

    Iterator objects

    Now, there is a chance you will never have to implement an iterator object of your own from scratch. We’ll see why next week. But for completeness, let’s look at what an iterator object looks like. (If you skip this whole section, you’ll mainly be missing crunchy technical details.)

    A for-of loop starts by calling the [Symbol.iterator]() method on the collection. This returns a new iterator object. An iterator object can be any object with a .next() method; the for-of loop will call this method repeatedly, once each time through the loop. For example, here’s the simplest iterator object I can think of:

    var zeroesForeverIterator = {
      [Symbol.iterator]: function () {
        return this;
      },
      next: function () {
        return {done: false, value: 0};
      }
    };
    

    Every time this .next() method is called, it returns the same result, telling the for-of loop (a) we’re not done iterating yet; and (b) the next value is 0. This means that for (value of zeroesForeverIterator) {} will be an infinite loop. Of course, a typical iterator will not be quite this trivial.

    This iterator design, with its .done and .value properties, is superficially different from how iterators work in other languages. In Java, iterators have separate .hasNext() and .next() methods. In Python, they have a single .next() method that throws StopIteration when there are no more values. But all three designs are fundamentally returning the same information.

    An iterator object can also implement optional .return() and .throw(exc) methods. The for-of loop calls .return() if the loop exits prematurely, due to an exception or a break or return statement. The iterator can implement .return() if it needs to do some cleanup or free up resources it was using. Most iterator objects won’t need to implement it. .throw(exc) is even more of a special case: for-of never calls it at all. But we’ll hear more about it next week.

    Now that we have all the details, we can take a simple for-of loop and rewrite it in terms of the underlying method calls.

    First the for-of loop:

    for (VAR of ITERABLE) {
      STATEMENTS
    }
    

    Here is a rough equivalent, using the underlying methods and a few temporary variables:

    var $iterator = ITERABLE[Symbol.iterator]();
    var $result = $iterator.next();
    while (!$result.done) {
      VAR = $result.value;
      STATEMENTS
      $result = $iterator.next();
    }
    

    This code doesn’t show how .return() is handled. We could add that, but I think it would obscure what’s going on rather than illuminate it. for-of is easy to use, but there is a lot going on behind the scenes.

    When can I start using this?

    The for-of loop is supported in all current Firefox releases. It’s supported in Chrome if you go to chrome://flags and enable “Experimental JavaScript”. It also works in Microsoft’s Spartan browser, but not in shipping versions of IE. If you’d like to use this new syntax on the web, but you need to support IE and Safari, you can use a compiler like Babel or Google’s Traceur to translate your ES6 code to Web-friendly ES5.

    On the server, you don’t need a compiler—you can start using for-of in io.js (and Node, with the --harmony option) today.

    (UPDATE: This previously neglected to mention that for-of is disabled by default in Chrome. Thanks to Oleg for pointing out the mistake in the comments.)

    {done: true}

    Whew!

    Well, we’re done for today, but we’re still not done with the for-of loop.

    There is one more new kind of object in ES6 that works beautifully with for-of. I didn’t mention it because it’s the topic of next week’s post. I think this new feature is the most magical thing in ES6. If you haven’t already encountered it in languages like Python and C#, you’ll probably find it mind-boggling at first. But it’s the easiest way to write an iterator, it’s useful in refactoring, and it might just change the way we write asynchronous code, both in the browser and on the server. So join us next week as we look at ES6 generators in depth.

  8. WiFi Debugging for Firefox OS

    I am excited to announce that we’re now shipping WiFi debugging for Firefox OS! It’s available in Firefox OS 3.0 / master with Firefox Nightly on desktop.

    WiFi debugging allows WebIDE to connect to your Firefox OS device via your local WiFi network instead of a USB cable.

    The connection experience is generally more straightforward (especially after connecting to a device the first time) than with USB and also more convenient to use since you’re no longer tied down by a cable.

    Background

    Since quite early on in the development of Firefox OS, you’ve been able to debug a device over a USB cable. However, this comes with various drawbacks:

    • You have to connect a cord whenever debugging is needed
    • Drivers are required on some OSes, which causes a lot of confusion
    • The cord requirement makes it harder to debug a phone during a user test

    The mobile device just generally feels a bit less like itself when it’s tied down with a cord.

    We’ve thought about adding some form of WiFi access on the DevTools team for some time. Our key goals were:

    • Ease of use
    • Secure connection

    While we certainly wanted to make this feature available, we wanted to be sure it would be an improvement over the USB method, while also being secure as well. This is important over a shared network like WiFi, since the debugging process by its nature exposes many details of your activity, including potentially private request data. If you’re working at a coffee shop, you don’t want others to have access to this.

    Simplicity

    When connecting over WiFi, there could be many possible devices to pick from on the same network. To avoid this problem, we use a discovery mechanism, similar to Bonjour or mDNS. When you want to connect, your computer sends a multicast ping to look for nearby devices. If there are any, they’ll reply with their name and what services they support. This allows us to present a simple list of device names, instead of dealing with IP addresses.

    The setup process is also nicer than the USB method, which relied on ADB from the Android project. With WiFi debugging, there are no drivers to install on Windows or udev rules to configure on Linux.

    Security

    A large portion of this project has gone towards making the debugging connection secure, so that you can use it safely on shared network, such as an office or coffee shop.

    We use TLS for encryption and authentication. The computer and device both create self-signed certificates. When you connect, a QR code is scanned to verify that the certificates can be trusted. During the connection process, you can choose to remember this information and connect immediately in the future if desired.

    How to Use

    You’ll need to assemble the following:

    • Firefox 39 (2015-03-27 or later)
    • Firefox OS 3.0 (2015-04-16 or later)

    Firefox OS 3.0 is still under heavy development, so it’s not yet available on devices in stores. If you have a Flame device, you can update your Flame to 3.0 / master using a nightly build. For other devices, you may need to build for your device from source to update it.

    On Firefox OS, enable WiFi debugging:

    1. Go to Developer Settings on device (Settings -> Developer)
    2. Enable DevTools via Wi-Fi
    3. Edit the device name if desired

    Firefox OS WiFi Debugging Options

    To connect from Firefox Desktop:

    1. Open WebIDE in Firefox Nightly (Tools -> Web Developer -> WebIDE)
    2. Click “Select Runtime” to open the runtimes panel
    3. Your Firefox OS device should show up in the “WiFi Devices” section
    4. A connection prompt will appear on device, choose “Scan” or “Scan and Remember”
    5. Scan the QR code displayed in WebIDE

    WebIDE WiFi Runtimes

    WebIDE Displays the QR Code

    After scanning the QR code, the QR display should disappear and the “device” icon in WebIDE will turn blue for “connected”.

    You can then access all of your remote apps and browser tabs just as you can today over USB. All of the Firefox DevTools are available over WiFi to inspect, debug, and explore. This is purely a change in how DevTools packets are exchanged, so there are no limits on what tools you can use.

    Supported Devices

    This feature should be supported on any Firefox OS device. So far, I’ve tested it on the Flame and Nexus 4.

    Known Issues

    The QR code scanner can be a bit frustrating at the moment, as real devices appear to capture a very low resolution picture. Bug 1145772 aims to improve this soon. You should be able to scan with the Flame by trying a few different orientations. I would suggest using “Scan and Remember”, so that scanning is only needed for the first connection.

    If you find other issues while testing, please file bugs or contact me on IRC.

    Acknowledgments

    This was quite a complex project, and many people outside of DevTools from teams like Networking and Security provided advice and reviews while working on this feature, including:

    • Brian Warner
    • Trevor Perrin
    • David Keeler
    • Honza Bambas
    • Patrick McManus
    • Jason Duell
    • Panos Astithas
    • Jan Keromnes
    • Alexandre Poirot
    • Paul Rouget
    • Paul Theriault

    I am probably forgetting others as well, so I apologize if you were omitted.

    What’s Next

    I’d like to add this ability for Firefox for Android next. Thankfully, most of the work done here can be reused there. Additionally, we should update other tools like node-firefox to use WiFi to connect to devices. We may also leverage some of this work to make the Browser Toolbox more secure on Firefox desktop.

    If there are features you’d like to see added, file bugs or contact the team via various channels.

  9. Firefox OS, Animations & the Dark Cubic-Bezier of the Soul

    I’ve been using Firefox OS daily for a couple of years now (wow, time flies!). While performance has steadily improved with efforts like Project Silk, I’ve often noticed delays in the user interface. I assumed the delays were because the hardware was well below the “flagship” hardware I’ve become accustomed to with Android and iOS devices.

    Last year, I built Firefox OS for a Nexus 4 and started using that as my daily phone. Quickly I realized that even with better hardware, I sometimes had to wait on Firefox OS for basic interactions, even when the task wasn’t computationally intensive. I moved on to a Nexus 5 and then a Sony Z3 Compact, both with better specs than the Nexus 4, and experienced the same thing.

    Time passed. Frustration grew. Whispers of a nameless fear…

    Running the numbers

    While reading Ralph Thomas’s post about creating animations based on physical models, I wondered about the implementation of animations in Firefox OS, and how that might be involved in this problem. I performed an audit of the number of instances of different animations, grouped by their duration. I removed progress indicators and things like the boot shutdown animation. Here are the animation and transition durations in Firefox OS, grouped by duration, for transitional interactions like scaling, opening, closing and sliding:

    • 0.1s: 15
    • 0.2s: 57
    • 0.3s: 79
    • 0.4s: 40
    • 0.5s: 78
    • 0.6s: 8

    A couple of things stand out. First, we have a pretty wide distribution of animation durations. Second, the vast majority of the animations are more than 300ms long!

    In fact, in more than 80 animations we are making the user wait more than half a second. These slow animations are dragging us down, resulting in a poorer overall experience of Firefox OS.

    How did we get here?

    The Firefox OS UX and interaction designers didn’t huddle in a room and design each interaction to be intentionally slow. The engineers who implemented these animations didn’t ever think to themselves “this feels really responsive… let’s make it slower!”

    My theory is that interactions like these don’t feel slow while you’re designing and implementing them, because you’re working with a single interaction at a time. When designing and developing an animation, I look for fluidity of motion, the aesthetics of that single action and how the visual impact enhances the task at hand, and then I iterate on duration and effects until it feels right.

    We do have guidelines for responsiveness and user-perceived performance in Firefox OS, written up by Gordon Brander, which you can see in the screenshot below. (Click the image for a larger, more readable version.) However, those guidelines don’t cover the sub-second period between the initial perception of cause and effect and the next actionable state of the user interface.

    Screenshot 2015-04-18 09.38.10

    Users have an entirely different experience than we do as developers and designers. Users make their way through our animations while hurriedly sending a text message, trying to capture that perfect moment on camera, entering their username and password, or arduously uploading a bunch of images one at a time. People are trying to get from point A to point B. They want to complete a task… well, actually not just one: Smartphone users are trying to complete 221 tasks every day, according to a study in the UK last October by Tecmark. All those animations add up! I assert that the aggregate of those 203 animations in Gaia that are 300ms and longer contributes to the frustrating feeling of slowness I was experiencing before digging into this.

    Making it feel fast

    So I tested this theory, by changing all animation durations in Gaia to 200ms, as a starting point. The result? Firefox OS feels far more responsive. Moving through tasks and navigating around the OS felt quick but not abrupt. The camera snaps to readiness. Texting feels so much more fluid and snappy. Apps pop up, instead of slowly hauling their creaky bones out of bed. The Rocketbar gets closer to living up to its name (though I still think the keyboard should animate up while the bar becomes active).

    Here’s a demo of some of our animations side by side, before and after this patch:

    There are a couple of things we can do about this in Gaia:

    1. I filed a bug to get this change landed in Gaia. The 200ms duration is a first stab at this until we can do further testing. Better to err on the snappy side instead of the sluggish side. We’ve got the thumbs-up from most of the 16 developers who had to review the changes, and are now working with the UX team to sign off before it can land. Kevin Grandon helped by adding a CSS variable that we can use across all of Gaia, which will make it easier to implement these types of changes OS-wide in the future as we learn more.
    2. I’m working with the Firefox OS UX team to define global and consistent best-practices for animations. These guidelines will not be correct 100% of the time, but can be a starting point when implementing new animations, ensuring that the defaults are based on research and experience.
    If you are a Firefox OS user, report bugs if you experience anything that feels slow. By reporting a bug, you can make change happen and help improve the user experience for everyone on Firefox OS.

    If you are a developer or designer, what are your animation best-practices? What user feedback have you received on the animations in your Web projects? Let us know in the comments below!

  10. ES6 In Depth: An Introduction

    Welcome to ES6 In Depth! In this new weekly series, we’ll be exploring ECMAScript 6, the upcoming new edition of the JavaScript language. ES6 contains many new language features that will make JS more powerful and expressive, and we’ll visit them one by one in weeks to come. But before we start in on the details, maybe it’s worth taking a minute to talk about what ES6 is and what you can expect.

    What falls under the scope of ECMAScript?

    The JavaScript programming language is standardized by ECMA (a standards body like W3C) under the name ECMAScript. Among other things, ECMAScript defines:

    What it doesn’t define is anything to do with HTML or CSS, or the Web APIs, such as the DOM (Document Object Model). Those are defined in separate standards. ECMAScript covers the aspects of JS that are present not only in the browser, but also in non-browser environments such as node.js.

    The new standard

    Last week, the final draft of the ECMAScript Language Specification, Edition 6, was submitted to the Ecma General Assembly for review. What does that mean?

    It means that this summer, we’ll have a new standard for the core JavaScript programming language.

    This is big news. A new JS language standard doesn’t drop every day. The last one, ES5, happened back in 2009. The ES standards committee has been working on ES6 ever since.

    ES6 is a major upgrade to the language. At the same time, your JS code will continue to work. ES6 was designed for maximum compatibility with existing code. In fact, many browsers already support various ES6 features, and implementation efforts are ongoing. This means all your JS code has already been running in browsers that implement some ES6 features! If you haven’t seen any compatibility issues by now, you probably never will.

    Counting to 6

    The previous editions of the ECMAScript standard were numbered 1, 2, 3, and 5.

    What happened to Edition 4? An ECMAScript Edition 4 was once planned—and in fact a ton of work was done on it—but it was eventually scrapped as too ambitious. (It had, for example, a sophisticated opt-in static type system with generics and type inference.)

    ES4 was contentious. When the standards committee finally stopped work on it, the committee members agreed to publish a relatively modest ES5 and then proceed to work on more substantial new features. This explicit, negotiated agreement was called “Harmony,” and it’s why the ES5 spec contains these two sentences:

    ECMAScript is a vibrant language and the evolution of the language is not complete. Significant technical enhancement will continue with future editions of this specification.

    This statement could be seen as something of a promise.

    Promises resolved

    ES5, the 2009 update to the language, introduced Object.create(), Object.defineProperty(), getters and setters, strict mode, and the JSON object. I’ve used all these features, and I like what ES5 did for the language. But it would be too much to say any of these features had a dramatic impact on the way I write JS code. The most important innovation, for me, was probably the new Array methods: .map(), .filter(), and so on.

    Well, ES6 is different. It’s the product of years of harmonious work. And it’s a treasure trove of new language and library features, the most substantial upgrade for JS ever. The new features range from welcome conveniences, like arrow functions and simple string interpolation, to brain-melting new concepts like proxies and generators.

    ES6 will change the way you write JS code.

    This series aims to show you how, by examining the new features ES6 offers to JavaScript programmers.

    We’ll start with a classic “missing feature” that I’ve been eager to see in JavaScript for the better part of a decade. So join us next week for a look at ES6 iterators and the new for-of loop.