Mozilla

Web Developers Articles

Sort by:

View:

  1. Introducing webcompat.com

    For the past few months a small group of contributors inside and outside of Mozilla have been working on webcompat.com. We just recently celebrated moving past the “too broken to share” milestone to the “functional-under-construction.gif” milestone of the project and are eager to share what we’ve been up to.

    There’s a more elaborate description of web compatibility and the site over at http://webcompat.com/about, but the basic premise of this project is: what if you could “file a bug on the internet” in a public space where developers, users and browser vendors could be made aware of compatibility issues?

    You can report issues to browser vendors today, through bug trackers or other feedback mechanisms, some public and some not. But frequently you cannot see the results of such a report—or see what related issues others have reported. It can feel like a black hole experience.

    This is where webcompat.com comes in. We want to provide a simple, open interface to web compatibility issues that affect us all as users of the web, regardless of our browsers or devices of choice. Perhaps more importantly, we hope to foster and enable a community of people who are passionate about a web for everyone to help out.

    So is this a Mozilla-only effort?

    Not at all. Mozilla kindly allows me to work on this project as a part of my full-time responsibilities on the Mozilla Mobile Web Compatibility team—but the project’s goal has always been to create an open resource for all people who use and build things on the internet. We’ve had some positive conversations with some of our browser vendor colleagues that have motivated us to start initial plans around future collaborations. It’s clear to us that Mozilla isn’t the only entity invested in a compatible web.

    OK Neat. What can I do?

    There’s actually quite a bit to do if this type of work is interesting to you.

    Reporting Issues

    Do you happen to notice sites that block you, nag you to install a different browser, or are just plain broken or buggy? Instead of just tweeting sad emoticons or #fail hashtags, you can help make a difference by creating a record of these issues with the form at webcompat.com.

    We’ve also created some browser extensions to make reporting easier—just click the added UI button to open a new tab with some bug report info pre-filled for you. You can grab that for Firefox Desktop, Firefox for Android, Chrome, Opera, and Safari. There’s also a bookmarklet you can install in your bookmark or favorites bar. These are all open source, so feel free to hack away and port them to new platforms.

    Diagnosing Compatibility Issues

    Do you have a knack for figuring out why things are broken and want to hone your internet CSI skills? Have you considered getting a “TypeError: ‘undefined’ is not a function” tattoo? Do you love reading minified code and debugging the entire web stack? We could use your help confirming and diagnosing issues (tattoos not required).

    Site Outreach

    Are you more interested in doing outreach and making sites and developers aware of issues? We need your help too. Stay tuned for better tooling around this role—or hop into the #webcompat irc channel on the Mozilla IRC network and say hi.

    Development

    Do you know or want to get better at JavaScript, Python, CSS, UX, design, GitHub, browser extensions, testing, and more? We’ve got a pile of issues we’re working on over at GitHub and welcome patches, opinions, issues, and feedback.

    What’s coming next?

    Right now two of our biggest priorities are being able to view and interact with issues in the site itself, and creating tools that will enable importing existing web compatibility issues from bug trackers (both open and closed) and exporting compatibility issues on webcompat.com to browser vendors (when the bug lies with the browser, not the site).

    Our project is still in its infancy, but we look forward to your compatibility bug reports and comments!

  2. Take the Developer Economics 7th Global Survey

    I’ve always preferred to think of myself as anything but a Marketer. In business school, there was a clear hierarchy assigned to the functional classifications amongst us. At the very top sat the investment bankers, commanding the most respect and highest paying job offers. And always at the very bottom the Marketing folks groveled, earning less and often viewed by their peers as having a “softer,” less competitive skillset.

    However much I disagreed with this classification — knowing that the digital age has made modern day marketing every bit as analytical and numbers-intensive as corporate financing jobs — it didn’t change the fact that I didn’t want to be called a Marketing person anyway. With the success of the Mad Men series and the constant headlines about privacy invasion and digital media, it seemed impossible to completely shake the Marketing job function from the stereotype of scumbag executives on Madison Avenue, or even a dirty car salesman whose only real skill is the ability to smoothly tell lies.

    In corporate America, no matter what job function you’re in, you’re all there for the same purpose – to drive profits (also referred to by business-schoolers as “maximizing shareholder value”). But the Marketing folks are more directly involved with sales metrics, and so the stereotypes live on. But being a Marketer at Mozilla is different. As a non-profit, mission oriented company, we’re not trying to sell you anything at all. Our only goal is to provide greater value – to our developers, our users, our community, and the world.

    As a Developer (un)Marketer, my job is to make you successful. Does this mean I’m never going to try to get you to do anything? Or could this mean I’m ready to be embrace the Marketing title? Okay, no on both counts. But it does mean that when I ask you to do something, I’m really asking just so I can, in the end, help you.

    Take the Survey

    Surprise – the Marketer that won’t call herself a Marketer writes her first blog post asking you to do something. Mozilla has teamed up with research company VisionMobile to get the latest, most accurate facts and insights surrounding the mobile app economy and developer ecosystem. We need this to make sure we’re prioritizing our efforts to provide you with the tools and resources that help you the most. The research relies heavily on developer surveys, and we want to ensure we get a representative sample of Firefox OS and HTML5 developers around the world. We also need this sample to be large enough to for the data to be statistically significant.

    If you’re an HTML5 or Firefox OS developer, we’d love you to participate in this 10-minute survey for their research report on Developer Economics. This report provides a comprehensive analysis of the app economy and developer ecosystems based on the largest and most global developer surveys. The results of the survey will be available as a free download in July, plus I’ll be back to talk about some of the best challenges and opportunities for developers based on insights from the full report.

    The survey will run until May 9th, and there is also a lucky draw for survey respondents to win prizes! Please help us generate the best research possible with your participation. And please comment or tweet us (@mozhacks) with any thoughts or ideas on the survey questions!

    Survey Methodology

    The research in VisionMobile’s Developer Economics report is based on survey responses from its global developer survey, in addition to one-to-one interviews with mobile app developers. The developer survey is entirely administered online. Respondents for the 5th edition of Developer Economics came from 115+ different countries, led by the US (18.7%), India (13.9%), and the UK (5.9%), followed by Russia, Germany, and France. This is outlined in more detail in Developer Economics: Methodology.

    About the Survey

    Developer Economics is a semi-annual report series published by VisonMobile, providing benchmarking of developer attitudes, trends and monetization by region. The report is now the largest and most global research available on the apps economy, surveying over 6.000 developers worldwide. You can also download a free copy of the 5th Edition (Q3 2013) of the report.

    About VisionMobile

    A leading research firm in the app economy and mobile business models, VisionMobile’s team includes PhDs, MBAs, economists and engineers that analyze the strategies behind the world’s most successful technology companies. Visit their website to learn more.

  3. What Mozilla Hacks is

    With the Mozilla moniker, many people believe that the Hacks blog is only about Mozilla products or news. Therefore, I wanted to take the chance to enlighten you and also invite you to be a part of creating content here.

    What we cover here

    The goal and objective of Mozilla Hacks is to be one of the key resources for people developing for the Open Web; talking about both news and in-depth descriptions of technologies and features. This means that as long as it’s about open technologies, we want to share all that information, tips, tricks and learnings with you.

    We’re Mozilla, and for us it is key to be a web browser agnostic resource, and it’s exactly the same with MDN (Mozilla Developer Network). The content here is written by a lot of different authors, where about half of them aren’t part of or associated with Mozilla in any way – they just do good things for the Open Web, and we believe that deserves exposure, and that it will be beneficial to you.

    Allow me to also emphasize that Mozilla Hacks is not a press release channel, we work hard to make everything we cover to be informational, practical and inspirational for you.

    More information is outlined in the guidelines for Mozilla Hacks.

    Behavior

    Mozilla Hacks is a place based on mutual respect and understanding, and the way we address each other is supposed to reflect that. We expect anyone writing or commenting to use proper language and refrain from insulting other people. If you ask a question here, give feedback and more, you deserve a reply from us. And when we talk about things – even though we might disagree – we all should and are entitled to always be met with respect and a proper behavior.

    Write for us!

    We know that a lot of you reading this have great knowledge, skill sets and experiences, and we would be very happy to help and support you in sharing it with the world and fellow developers.

    We have had hundreds of people writing and collaborating in content for Hacks, and if you write two posts or more, you’ll show up in great company among all our fantastic authors!

    Talk to me

    For me personally, I’ve been running Mozilla Hacks as its Editor for about two years now, and I’m constantly on the lookout for good content that web developers writing for the Open Web, with open technologies, can learn from. I.e. topics that I’d love to read about myself.

    I would be very happy for you to reach out to me at robert [at] mozilla [dot] com or via @robertnyman on Twitter – I’m always interested in discussing the web, technology and the ideas you might have. Talk to me. :-)

  4. Building a persistent Notes app for Firefox OS

    In this tutorial we will be building a notes app (like Evernote) from scratch and deploy it to Firefox OS! See a live demo.

    A persistent notes app needs a place to store all the notes for a user (so no one else can read it). For this we will use my own backend solution called Sproute. Sproute is a hosted web framework for quickly building dynamic webapps.

    First create an account with a unique subdomain then access the Dashboard through http://<mysubdomain>.sproute.io/admin. You must login with the same details used to signup to Sprotue.

    Models

    In Sproute there is a concept called Models. A model defines the dynamic data in our app with properties for data integrity. Create a new model called notes with the following fields and properties:

    • body: Text, Required, Min: 1
    • sharing: Text, Allowed Values: public, private, Default Value: private
    The model form filled out for notes

    The model form filled out for notes

    The body field will store the contents of the note. The sharing field will specify whether the note can be viewed by others (with a direct link) or just the owner. This is all the data we need to define, everything else is covered by built-in fields.

    List notes

    We need a way to list the available notes for a user. This can be done with Pages. A page is HTML with embedded template tags for retrieving and processing data.

    Open the index page. This is the home page when people view your space. We will list the notes here. Add the following:

    {{ get /data/notes?sort=_lastUpdated,desc as notes }}

    All data is retrieved through an HTTP interface so the {{ get }} tag must take a URL. The request above is retrieving all notes for the logged in user and stores the results in a variable called notes. We use a query parameter to sort the results by last modified first (An underscore denotes a built-in field).

    Let’s display each note in a list:

    <ul>
        {{ each notes as note }}
            <li><a href="/view/{{note._id}}">
            {{ word note.body 0 5 }}
            </a></li>
        {{ / }}
    </ul>

    The {{ word }} template tag will extract the first 5 words from the body content. We link to a not-yet-made page with the URL /view/<id>. note._id is a built-in unique identifier.

    Add the above code in the 'index' page

    Add the above code in the ‘index’ page

    Create a note

    Before creating the view page for a note, let’s make a new page for creating a note. Create a new page called create. Add the following HTML:

    <form action="/data/notes?goto=/" method="post">
        <div><textarea name="body"></textarea></div>
        <div><select name="sharing">
            <option value="private">Private</option>
            <option value="public">Public</option>
        </select></div>
        <button type="submit">Create Note</button>
    </form>

    Simple! As mentioned above, all data is retrieved and modified through an HTTP interface. This means we can use a simple HTML form to create a new note. The goto query parameter will redirect the user to that URL.

    Because this is a new page we need to create a new route so the page is accessible. A route is a pattern for a requested URL that will render a page if matched. There will already be a route for the index page. Click Routes and create a new one with the following:

    • Route: /create, Page: create.
    New route to 'create' page

    New route to ‘create’ page

    User login and registration

    User accounts are built into Sproute but we still need to create a Register and Login page. Thankfully this is also a simple HTML form so create a new page called users and add the following:

    <h2>Login</h2>
    <form action="/api/login?goto=/" method="post">
        <label>
            <div>Username:</div>
            <input type="text" name="name" />
        </label>
        <label>
            <div>Password:</div>
            <input type="password" name="pass" />
        </label>
        <button type="submit">Login</button>
    </form>

    You may add the Register form on the same page by copying the login form and replace the action attribute to /api/register. Create two new routes with the following:

    • Route: /login, Page: users
    • Route: /register, Page: users

    View and update a note

    Previously we created a link to view a note. This will also be where we let users modify the note. Create a new page called view and add the following:

    {{ get /data/notes/_id/:params.id?single=true admin as note }}
     
    {{ if note.sharing eq private }}
        {{ if note._creator neq :session.user._id }}
            {{ error This note is private }}
        {{ / }}
    {{ / }}
     
    <form action="/data/notes/_id/{{params.id}}?goto=/" method="post">
        <div><textarea name="body">{{note.body}}</textarea></div>
        <div><select name="sharing">
           <option value="private" selected>Private</option>
           <option value="public">Public</option>
        </select></div>
        <button type="submit">Update Note</button>
    </form>

    We make a request to get the note data for the note that was passed into the URL (through the params object). The query parameter single=true will return just the object instead of a one item collection. admin will run the request with the specified user-type. Next we check whether the note is private. If so throw an error if the user is not the creator.

    The update form is very similar to the create form. We only need to change the action to update notes where the _id matches the one in the URL.

    This page requires a slightly complex route. We need to use a placeholder in the route so that /view/anything will still match the view page and store anything in a variable.

    Create a route with the following:

    • Route: /view/:id, Page: view

    Now you can see where params.id comes from. params is an object for all placeholders in the route and the matched values.

    Permissions

    The last important concept of Sproute is permissions. Permissions are just like routes where a requested URL matches a pattern but instead of pointing to a page, it validates against a required user type.

    Click Permissions and add the following:

    • Method: GET, Route: /data/notes, User: Owner
    • Method: GET, Route: /data/notes/*, User: Owner

    This will make sure the only notes listed will be ones the user has created (i.e. the owner). Because of the second permission, we needed to run the {{ get }} request as admin otherwise it would fail for everyone (except for admins and the creator) even if the note is public.

    Adding a permission to retrieving notes

    Adding a permission to retrieving notes

    Firefox OS support

    Sproute can very easily support hosted apps on Firefox OS by creating a page with the manifest JSON data and the route: /manifest.webapp.

    Create a new page called manifest with the following:

    {
        "name": "{{self.name}}",
        "description": "A persistent notes app",
        "launch_path": "/",
        "icons": {
            "128": "/absolute/path/to/icon"
        }
    }

    Create a Route with the pattern /manifest.webapp pointing to the manifest page.

    We’re done! Test this in the app manager by using the link to the manifest (http://notes.sproute.io/manifest.webapp). Sproute is open-source and on GitHub under the Mozilla Public License v2 so you may clone the repo for private hosting.

    Notes app at mobile width

    Notes app at mobile width

  5. Introducing the Firefox OS App Manager

    The Firefox OS App Manager is a new developer tool available in Firefox 26 that greatly improves the process of building and debugging Firefox OS apps, either in the Simulator or on a connected device. Based on the the Firefox OS Simulator add-on, it bridges the gap between existing Firefox Developer tools and the Firefox OS Simulator, allowing developers to fully debug and deploy their web apps to Firefox OS with ease.

    AppManager

    Additional features made available in Firefox 26 are discussed in this post.

    App Manager In Action

    The App Manager replaces the current Simulator Dashboard and provides an integrated debug and deployment environment for your Firefox OS apps, by leveraging the existing Firefox Developer Tools. You can install hosted or packaged apps and debug them in the Simulator or with a connected device. The App Manager also provides additional information to the developer including the current Firefox OS version of a connected device, the ability to take screenshots, a list of all currently installed apps and a list of all the APIs and what privilege level is required to use each. Here is a screencast of the App Manager showing off some of the features available for Firefox OS Development.

    In addition to debugging your own apps, the App Manager also provides the ability to update, start, stop and debug system level apps. Debugging an app using the Developer Tools is similar to debugging any other Web app and changes made in the Tools are automatically reflected real-time to the app either in the Simulator or the connected device. You can use the Console to see warnings and errors within the app, the Inspector to view and modify the currently loaded HTML and CSS, or debug your JavaScript using the Debugger.

    Developer Tools

    For more information about using the Developer Tools be sure to check out the Developer Tools series on this blog and for the most up to date information take a look at the Developer Tools section of MDN.

    Getting Started with the App Manager

    To get started using the App Manager take a look at the MDN Documentation on Using the The App Manager. Do keep in mind that to see what is shown above you need:

    • Firefox 26 or later
    • Firefox OS 1.2 or later
    • at least the 1.2 version of the Firefox OS Simulator
    • either the ADB SDK or the ADB Helper Add-on

    Details for these are described in the above MDN link.

    Mozilla is very interested in your feedback as that is the best way to make useful tools, so please be sure to reach out to us through Bugzilla or in the comments and let us know what you think about the new App Manager.

  6. Firefox OS Development: Web Components and Mozilla Brick

    In this edition of “Firefox OS: The platform HTML5 deserves” (the previous six videos are published here), Mozilla’s Principal Evangelist Chris Heilmann (@codepo8) grilled Mozilla’s “Senior HTML5 Engineer Angle Bracket Coordinator” Matthew Claypotch (@potch) about the exciting new possibilities of Web Components for Web App developers and how Mozilla’s Brick library, a collection of custom elements to build applications with, can help with the transition. You can watch the interview on YouTube.

    The Why of Web components

    There is a problem with the Web as a platform for applications: HTML, the language that makes it easy to mark up documents and give them meaning doesn’t have enough elements to build applications. There are quite a few new elements in the HTML5 spec, but their support is sketchy across browsers and there are still a lot of widgets missing that other platforms like Flex or iOS give developers out-of-the-box. As a result, developers build their own “widgets” like menu bars, slider controls and calendars using non-semantic HTML (mostly DIV elements) and make them interactive using JavaScript and theme-able using CSS.

    This is a great workaround but the issue is that we add on top of the functionality of browsers instead of extending the way they already function. In other words, a browser needs to display HTML and does a great job doing that at least 60 frames per second. We then add our own widget functionality on top of that and animate and change the display without notifying the browser. We constantly juggle the performance of the browser and our own code on top of it. This leads to laggy interfaces, battery drain and flickering.

    To work around that problem a few companies and standards body members are working on the Web Components specification which allows developers to extend the browser’s understanding of markup with own elements. Instead of writing a slider control and make it work after the browser already displayed the document, you define a slider element and become part of the normal display flow. This means our widgets get more responsive, don’t work against the browser’s rendering flow and all in all perform better. Especially on low spec mobile devices this is a massive win. The whole thing already happens: if you for example add a video element to the document you see a video controller with a timed slider bar, a play button and volume controls. All of these are HTML, CSS and JavaScript and you can even see them in the debugging tools:

    Anatomy of a video element

    Firefox OS, being targeted at low end devices can benefit a lot from widgets that are part of the rendering flow, which is why Mozilla created Mozilla Brick, a collection of custom elements to build applications with. Earlier we introduced the concept using a library called XTags, which powers Brick. Using Brick, it is very simple to create for example a deck based application layout using the following markup:

    <x-deck selected-index="0">
      <x-card>
        0<span>I'm the first card!</span>
      </x-card>
      <x-card>
        1
        <span>
          These cards can contain any markup!<br>
          <img src="../../site/img/grounds_keeping_it_real_s3.gif">
          <img src="../../site/img/grounds_keeping_it_real_s1.gif">
          <img src="../../site/img/grounds_keeping_it_real_s2.gif">
        </span>
      </x-card>
      <x-card>
        2 <img src="../../site/img/thumbs_up.gif">
      </x-card>
    </x-deck>

    The resulting app consists of three decks that can be animated into another without having to do anything but call a deck.shuffleNext(); function.

    Web Components are a huge topic right now and many libraries and frameworks appear each week. We hope that by using Brick we can enable developers to build very responsive apps for Firefox OS quickly and cleanly and leave the pain of making your app perform really well up to the OS.

  7. Mozilla goes to Washington

    Last month, Mozilla Foundation employee Jess Klein was honored by the White House Office of Science & Technology Policy as a Champion of Change for her work with Rockaway Help in the wake of Hurricane Sandy.

    Before the White House event, Mozilla sponsored a Civic Hackers’ Happy Hour in DC at canvas.co. Here’s an excerpt about the event from the Code for Tulsa write-up.


    Mozilla Civic Hackers’ Happy Hour

    We arrived at canvas around noon to arrange all the catering and set everything up. We met fellow civic hackers from Austin to Chicago, Minneapolis to Miami, Oakland to DC, and everywhere in between – hackers and officials representing Code for America, Sunlight Foundation, E-Democracy, United States CTO, Census Bureau, NASA, FEMA, USDA and many others.

    By 8pm we had about 100 people, so we had a few quick presentations – I spoke about Mozilla, Kevin Curry spoke about the Code for America Brigade program, and Garret Miller spoke about Mapbox. Everyone mingled and we learned about some great civic projects going on like the Smart Chicago Collaborative, mspbus.org in Minneapolis, and Keep Austin Fed. We had made a congratulatory card for Jennifer Pahlka, founder of Code for America and recently-appointed Deputy CTO of the US. Everyone had a chance to sign the card, and then… Jennifer showed up! So we presented the card to her in person!


    In my presentation about Mozilla, I discussed how I’ve come to realize that openness, innovation, and opportunity on the web is at the heart of developers improving their communities.

    Cities that think like the web

    In 2011, I found Mozilla Foundation Executive Director Mark Surman’s City of Toronto 2.0 Web Summit presentation from 2008 – A city that thinks like the web.

    Mark tells the story that seems obvious to us now – Mozilla believed that participation could create a better internet, and the tiny non-profit with a global community of volunteers forced open a monopoly browser market with standards and protocols that have created the largest communication platform in the history of the world.

    If openness and participation created a better web, could it create better cities? Mark says yes. After a couple of years hacking my city, I completely agree.

    Tulsa, Oklahoma, USA

    I first started civic hacking in 2011 when our Tulsa Web Devs group took it upon ourselves to put Tulsa Transit on Google Maps. At the time, we knew nothing about transit, and only a little about Google Maps. In a few short hack days with web resources, we taught ourselves everything we needed to convert route shapefiles and schedule csv files into a valid GTFS feed.

    Tulsa Transit GTFS Prototype

    As soon as I saw the prototype working, I was hooked on civic hacking. It was the same feeling I had when I received my first patch for my first open-source project. In a way, my personal journey – from proprietary enterprise software development, to SourceForge, to Mozilla and Code for Tulsa – reflects trends in open technology: open source disrupted proprietary software and brought forth the open web, the open web brought forth open government and civic hacking.

    In Tulsa, we’ve gone on to create civic APIs and apps for citizens, planning organizations, Tulsa Library, Tulsa Fire Department, and the Oklahoma Urban Search & Rescue task forces. Because we build on the web, all our apps are available to every citizen, regardless of device or platform. I jokingly ask, “If we created our Fire Department app for iPhones, would Android users just watch their house burn down?”

    Innovation can come from anywhere

    Here’s the thing – we are just one group (but maybe the best group!) of civic hackers … in Tulsa, Oklahoma. The web enables anyone with a text editor to make these things and deliver them directly to anyone with a web browser. Morgamic says it best in “What do you want the web to be?

    The future of the web won’t be decided by corporations, governments, or shareholders. It will be chosen by people like you and me – passionate individuals with great ideas, who won’t take no for an answer, who won’t settle.

    Having worked with and for corporations, shareholders, and now governments, I know just how true this statement is. On the web, Google’s latest billion-dollar project and Code for Tulsa’s $35 raspberry pi hack are both a single link – a single click. The web platform is the only platform designed to include everyone at an equal level of access.

    Serving the greater good

    Mozilla’s mission is to promote openness, innovation, and opportunity on the web. It’s a lofty goal; sometimes it’s hard to see what that looks like “on the ground.” At our happy hour, I saw it: designers, engineers, programmers, entrepreneurs – hackers experimenting and making amazing things for the betterment of their communities.

  8. New Features in Firefox Developer Tools: Episode 24

    Releases have recently rolled, and there are a slew of new features coming to the developer tools in Firefox 24. Firefox 24 is currently in our alpha channel Firefox Aurora, and will hit the main release channel on September 17th, 2013.

    A little alitteration leads to lots of cool features coming this release. I’m only touching on a few highlights here; to see a comprehensive list of all the new changes to developer tools, check out the full list of bugs fixed since last release.

    Console Clean Ups

    An oft-requested feature, the console will now clear all of the existing logs when you refresh the page. If you need logs to persist across reloads, don’t worry: this behavior is toggle-able in the options panel. Here’s to less clutter!

    Users were also reporting that the “clear” button was confusing. It wasn’t obvious whether it was clearing the logs or the the filter text because the button as adjacent to the filtering search box. We moved it to so that this won’t happen anymore!

    New position of the clear button

    Source Map Sourcery

    Source maps are now enabled by default. If you need to debug the JavaScript generated by your tool or compiler rather than the original source, you can still toggle them on and off in the debugger options.

    Furthermore, because of issues with Internet Explorer, the source map specification was updated so that you link a source map to its script with //#
    sourceMappingURL=...
    rather than the deprecated //@ sourceMappingURL=.... We will still respect the old style, but will warn you that it is deprecated. Here is a summary of the why this change was made.

    Finally, we will load the text of a source mapped source from its source map’s sourcesContent property, if it exists. This property was added to source maps to enable dynamic source map creation, and to bundle your sources into the source map so that you don’t need to juggle extra files on your server.

    Debugger Developments

    Frozen, sealed, and non-extensible objects are now visually distinguished in the debugger’s variables view.

    Frozen, sealed, and non-extensible objects

    Also, when stepping out of a stack frame in the debugger, you will now see either the return value or the exception thrown (depending on why you are exiting the frame) in the variables view labeled <return> and <exception> respectively.

    A stack frame's return value

    A stack frame's exception

    JavaScript-Free Fun

    Need to see how your web page gracefully degrades when JavaScript is disabled? Head on over to the options panel and you can quickly disable JavaScript for the current tab. This persists until either you close the tab or the developer tools.

    Network Monitor Magic

    You can now filter by types of requests in the network monitor. Want to see only requests for stylesheets? Or maybe only XHRs? We’ve got your back. On top of that, there are now total number of requests, file sizes, and response times listed in the bottom that update with you filters, so you can see just how many KBs (or even MBs) of images you are requesting on every page load.

    Filtering only images

    Profiler Pleasantries

    You can now control the profiler from your web app’s code base via console.profile() to start a new profile, and console.profileEnd() to end it. No more trimming your sample range, start and stop profiling in the exact places you want to from your code!

    That’s it for this episode. Keep on hacking the free web!

  9. Speed Up App Development with X-Tag and Web Components

    In the last few years we’ve witnessed an evolution in what ‘app’ means to both developers and consumers. The word app evokes the idea of a rich, task-oriented user experience with highly optimized user interface that responds to its environment and can be used on an array of common devices. In order to make development of rich app experiences easier, native platforms have generated many of their own controls and components that Just Work™.

    For other native technology stacks, extensible components are all but assumed – not so much for the web. Soon, that all changes. We are on the verge of a declarative renaissance that will dramatically advance app development for the web platform, and Web Components will drive it.

    X-Tag and Web Components offer features that obliterate the status quo for layout, UI, and widget development – here’s a few notable Web Component features:

    • Create real custom elements the browser understands
    • Stop the instantiation madness: $$(‘button.super’).initSuperButton()
    • Remove unmanageable HTML widget guts from your app’s view files
    • Work with sharable components, based on standard technologies

    Meet the Web Components Family

    Web Components is a group of W3C specifications, quickly moving toward standardization, that provide a robust HTML component model. You should not assume the following specs are implemented in your browser of choice. While these specifications are in various stages of implementation across browsers, you can use X-Tag (with either Mozilla or Google’s prollyfill) today to create custom elements that work well in recent version of Firefox, Chrome, Safari, and stock mobile browsers. X-Tag is a powerful sugar library primarily focused on wrapping and enhancing one of the draft-state Web Component specs: Custom Elements (document.register). We’ll get to X-Tag shortly – but for now, let’s quickly review the key features of each spec:

    Custom Elements

    Custom Elements provides you a way to create new elements for use in your environment. There are two ways to declare a new custom element, the imperative DOM API – document.register(), and the declarative HTML tag – (whose DOM constructor is HTMLElementElement). After declaration, new custom elements can be created in the same ways native elements are, such as document.createElement, presences in original source (the markup of a page), and innerHTML, etc.

    Here’s an example of what a custom element registration looks like in both the declarative and imperative styles:

    document.register('x-foo', {
      prototype: Object.create(HTMLElement.prototype, {
        readyCallback: { 
          value: function(){
            // do stuff here when your element is created
            this.innerHTML = '<div>Barrrr me matey!</div>';
          }        
        },
        bar: {
          get: function() { return 'bar'; },
        },
        // add more properties to your custom prototype
        // ...
      })
    });
    <element name="x-foo">
      <script>
        if (this !== window) {
          this.register({
            prototype: {
              readyCallback: { 
                value: function(){
                  // do stuff here when your element is created
                  this.innerHTML = '<div>Barrrr me matey!</div>';
                }        
              },
              bar: {
                get: function() { return 'bar'; },
              }
            }
          });
        }
      </script>
    </element>

    Shadow DOM

    The Shadow DOM allows you to encapsulate structural and supporting elements within components. Elements within nodes remain visible for purposes of display UI (depending on the type of element and your styles), but are hidden from the rest of your application code, unless you explicitly cross the shadow boundary.

    HTML Templates

    HTML Templates bring simple DOM templating and markup reuse to the web platform – which are often shimmed today using the HTMLScriptElement + DocumentFragment hack-pattern.

    HTML Imports

    HTML Imports are external HTML documents that contain declarative component definitions. HTML component documents can by imported using the link element with the rel attribute value import. Imported resources may themselves contain additional sub-imports, which the browser then retrieves and performs automatic dependency resolution upon.

    Web Components + X-Tag = WINNING

    Mozilla’s X-Tag library enhances the imperative (JavaScript) route for creating custom elements. X-Tag’s primary interface is the xtag.register() method – it wraps the soon-to-be standard document.register() DOM API with features and functionality that make development of amazing custom elements effortless.

    Creating a Custom Element

    Here’s a quick example of what registering a custom element looks like using X-Tag:

    xtag.register('x-pirate', {
      lifecycle: {
        ready: function(){
          this.innerHTML = '<blockquote>' +
                             '<img src="pirate-1.png"/>Barrr me matey!' +
                           '</blockquote>';
        }
      },
      accessors: {
        src: {
          // X-Tag's attribute sugar relays any value passed to the src 
          // setter on to the src attribute of our <x-pirate> and its
          // <img> element (specified by CSS selector), and vice versa.
          attribute: { selector: 'img' },
          set: function(){
            // When a <x-pirate>'s src attribute/setter is changed, we 
            // stop everything to announce the arrival of a new pirate.
            // Ex: doc.querySelector('x-pirate').src = 'pirate-2.png';
            alert("There's a new captain on deck ye scurvy dogs!");
          }
        }
      },
      events: {
        // This is an example of X-Tag's event and pseudo systems. The
        // "tap" custom event handles the dance between click and touch,
        // the ":delegate(img)" pseudo ensures our function is only 
        // called when tapping the <img> inside our <x-pirate>.
        'tap:delegate(blockquote > img)': function(){
          alert("A pirate's life for me!");
        }
      }
    });

    To the Democave Batman!

    We’re actively working on a custom element UI toolkit and style pack that will make development of app interfaces a breeze. It’s still in very early stages, but we have a few demos for you.

    Get the Code

    Head over to X-Tags.org and grab the code to develop custom elements of your own. After you get the hang of things, start contributing to our open source effort!

  10. How to Spread The Word About Your Code

    You spent an entire weekend building a library, jQuery plugin, build tool, or other great piece of code you wanted to share far and wide, but after some tweets and a failed attempt to make the front page of Hacker News, your creation languished, unloved, in a GitHub repo. A common situation for many developers nowadays, but one you can avoid.

    As the editor of several programming newsletters, I frequently get two types of e-mails from developers. Those reaching out to ask if I can mention their projects, and those expressing surprise and excitement that their work has been featured. If you’re a developer doing good work but feel more like you’d be in that second group, the three steps in this article are for you.

    Before we get started, there’s a stumbling block we need to kick away. Terms like ‘marketing’ and ‘advertising’ are dirty words for many developers and it’s not uncommon for developers to be reluctant to do much promotion. ‘Build it and they will come’ used to work when exciting open source projects were few and far between but now everyone seems to be working on something and making a noise about it. Few of the successes you see come through pure luck but because developers are actively promoting their work or, at least, making it discoverable. It’s time to join them!

    Step 1: Get your project ready

    Before you can promote your project, you need to make it attractive to potential users and evangelists (including general wellwishers, the media, and other developers).

    A good name

    Ensure your project has a palatable name. It doesn’t need to be clever or even descriptive, but it’s worth avoiding innuendos that may present a problem down the line. For example, the popular Testacular and Authgasm projects, are now named Karma and Authlogic respectively after users raised a fuss.

    You should perform a search for the name you choose to be sure you’re not clashing with anything else that’s popular or trademarked (did you know Firefox was called Phoenix and Firebird prior to Firefox?). The US Patent and Trademark Office has an online trademark search facility.

    A benefit of having a relatively unique or uncommon name is so you can search for it over time (or even set up a Google Alerts notification for the name) and find mentions of your project without many irrelevant results popping up. If you want to have something descriptive but unique, consider joining two words together. For example, when I created a Ruby library to do natural language detection, I called it WhatLanguage and it’s easy to search for.

    An official homepage or project URL

    The term ‘homepage’ is a bit outdated but you ideally need a single ‘home’ URL that you can promote and point people to in relation to your project. You don’t need to splash out on a fancy template or even a domain name, but your project needs a focal point. That could be an entire site with its own domain, such as those for Yeoman or HTML5 Boilerplate, a simple single page on an existing domain, such as that for RoughDraft.js, or even a regular GitHub repo, such as for vague.js.

    If you have the freedom to do so, make sure your site looks good on the major browsers (including mobile), hook up some analytics to your page and ensure the <title> tag is well written. Use a title like “MyProject – A JavaScript Library to X, Y and Z” instead of just “MyProject – About” or a blank title. With social bookmarking, this matters as you can’t guarantee your evangelists will write a good title of their own.

    If you’re not a Web designer, don’t have the time to spend making a complete design, but still want a complete site rather than just a GitHub repo and README, consider using a framework like Bootstrap as it’ll provide a clean layout out of the box and you can forget about many cross browser and device issues.

    Documentation and copywriting

    It’s only just a cliché that developers don’t like to write documentation, but you need something for potential users to fall back on, and time invested in producing useful documentation up front will pay dividends later.

    At a cynically bare minimum, you need to write enough documentation that someone will be confident about sharing your link or promoting your project and not feel like they’re sending their own followers into a black hole of misunderstanding. This means your homepage or README needs to cover a few angles. You’ll need to:

    • Prominently feature a “[noun] is” paragraph. An alarming number of project homepages don’t explain, in simple terms, what the project is actually for or does. If you’ve built a JavaScript library that does language detection, say, you have to say so. For example: “LanguageDetect is a JavaScript library for detecting the natural language of text.”

      An excellent example of this in action is on libcinder.org where it states right up front: “Cinder is a community-developed, free and open source library for professional-quality creative coding in C++.” Perfect!

    • Write clear titles, subheadings, and support copy. At a bare minimum, ensure titles, subtitles, and any sort of writing on your homepage are straightforward and clear. Write for the lowest common denominator on your homepage. You can get more advanced elsewhere.

    • Write a beginner’s tutorial and link to it from your home page. Unless everything’s simple enough to explain on a single page, quickly write a tutorial that covers basic installation and usage and either include it in your README file or put it on the Web and link to it from your README and/or homepage.

    • State dependencies and requirements clearly. Does your library only work on a specific version of Node? Is it a browser extension for Firefox? Does your code require PostgreSQL, Redis, or another specific database? Be sure to include a bulletpoint list of dependencies and requirements for your project to be usable so as not to disappoint potential users.

    • Specify the license for your code. While you could get away with keeping your licensing information tucked away in a LICENSE file in your GitHub repo, specifying what license your code is released under up front and center will help put many developers at ease. Likewise, if your project is commercial is nature and costs money, don’t hide that detail away and mislead visitors.

    • If your project is a library or API, feature some example code on the homepage. Unless your library is particularly complex, let visitors see an example of its usage on the project homepage. If your API is good, this could be a great way to get an ‘easy sale.’ I’m not a huge fan of the code example chosen but the homepage for Ruby shows off this technique.

    Extra materials

    A blog post is a great way to introduce a project that might need more background or have more of a story than it’s practical to tell on a homepage or within documentation. If there’s any sort of story behind your project, a blog post is a great way to tell it. Be sure to link to the post from your project’s homepage and consider promoting the blog post separately to relevant sites within your niche.

    If you have the ability, recording a screencast or other sort of video can help. Could you put together a simple 5 minute screencast of how to install and use your library? Or have you built a game that could be demonstrated in a few minutes of gameplay? Record a simple video, put it on YouTube, and embed it on your homepage. Your accent doesn’t have to be as crisp as a newsreader’s and you don’t even have to appear within the video. All that matters is you get to the point quickly and your audio is tolerable (not muffled, clipping, or drowned in background music).

    As the editor of several programming newsletters, I look at thousands of projects each year, and it’s still uncommon to see simple screencasts, yet they certainly help a project stand out and, as a consequence, make it more likely for me to talk about it. You can see a perfect example on Punch’s homepage. The early popularity of Ruby on Rails also depended upon a popular ‘build a blog engine in 15 minutes’ video, back when the concept of using video to promote an open source project was very novel.

    If you’re sticking to the straight up, GitHub README approach (and it’s certainly not a bad idea for a simple library), a bonus tip is to create a tiny screencast of your code in action and convert it to an animated GIF for inclusion in your README. Richard Schneeman outlines this technique in Use GIFs in your Pull Request for Good, not Evil. The result is striking and could help your README stand out.

    For further ideas on how to make your project stand out before you begin promoting it, check out the great How to Make Your Open Source Project Really Awesome by Michael Klishin. It digs into more detail about versioning, announcements, having a changelog and writing good documentation.

    Step 2: Get the word out

    You’ve polished your project, got a URL to promote, and you’re ready to get the news out.

    A word of caution, however. Don’t use every technique on day one. You could overload your site with traffic or, worse, be subjected to a barrage of online criticism if your work or site is broken. With something like a library or tool, a gentler approach will work well and building up small streams of visitors and users over time will give you a much better time.

    Social networking

    Your own social networking profiles are always a good place to start if you have them. You’ll get more immediate feedback from people who actually know you and if your project is particularly interesting, it could go viral even from a single mention.

    A great example of a simple project going viral was YouTube Instant by Feross Aboukhadijeh. Feross built YouTube Instant quickly, mentioned it on Facebook before going to bed, and woke up to a flood of traffic and press mentions.

    If you like to experiment and have several bucks going spare, you could also consider paying for a promoted post on Facebook. This will give your post more visibility in your news feed, but is best reserved for if your Facebook friends are mostly developers or people likely to be interested in your project. If not, and you’d still like to spend some money, consider an ad on Reddit or a relevant programming blog instead.

    Influencers, bloggers, and niche media

    Whether you’re working on a JavaScript library, Firefox extension, backend app in Rails, or a theme for Bootstrap, your code will fit into one or more niches and every technical niche has a variety of ‘influencers’, people and publications who are popular and well known for the topic at hand.

    Getting a tweet, retweet, or even an entire blog post from an influencer could have a significant impact on your project, as could being invited to blog elsewhere (Mozilla Hacks, for example!). If Brendan Eich tweeted about your JavaScript library, Lea Verou wrote a blog post about a CSS trick you discovered, or Paul Irish mentioned a Web development tool you built in a talk, you would attract a lot of interest quickly. It is key, however, to realize there are many great influencers in every space and you’ll achieve nothing by hounding any one person so be prepared to move on.

    Spend some time working out who the influencers and key publications are in your niche. For Twitter, Followerwonk is a handy tool that searches Twitter biographies for certain words. If you search for “javascript” the first page includes several users who would be useful to reach out to if you had a particularly interesting JavaScript-related release to promote. Reaching out on Twitter can be as simple as a single tweet and many busy folks prefer Twitter as it takes less time to reply than an e-mail. A single tweet from @smashingmag could drive thousands of visitors your way, so consider tweeting them, and other similar accounts, when you have something relevant.

    I’d also advise looking for blogs and e-mail newsletters in your niche. Start with something as simple as Googling for “javascript blog”, “javascript newsletter”, “css blog” or whatever’s relevant to your project. Most bloggers or e-mail newsletter publishers will not be offended by you sending them a quick note (emphasis on quick) letting them know about your work. Indeed, some weeks there can be a shortage of interesting things to write about and you might be doing them a huge favor.

    If you choose to e-mail people (and your project will probably be more substantial than a few hours’ work to justify this), take care not to make demands or to even expect a reply. Many bloggers and influential people have overflowing inboxes and struggle to reply to everything they receive. Make your e-mail as easy to process as possible by including a single URL (to your now superb homepage or README) and include your “[noun] is” paragraph. Don’t take a non-response as an insult but keep moving on to the next most relevant person. You might even consider taking a “Here’s my project that does X, Y and Z. No reply needed, I just thought you might like it” approach. Softly, softly works here, as long as you get to the point quickly.

    How to get attention from internet celebrities by Jason Cohen and How to Write the Perfect Outreach Email by Gregory Ciotti go into more detail about e-mail etiquette when promoting your work to influencers. While you might not need to contact any ‘celebrities’ in your niche, the principles of keeping it short, including a call to action, and ensuring your work is appropriate to the person are really true for anyone you’re sending unsolicited messages to.

    Podcasters are an often forgotten source of promotion opportunities too. While some podcasts don’t cover news or new releases at all, many do, and being on the radar of their hosts could help you get a mention on a show. Smashing Magazine has put together a list of tech podcasts covering the areas of design, user experience, and Web development in general. Again, keep your e-mails short and sweet with no sense of expectation to get the best results.

    User curated social news sites

    As well as reaching influencers and niche media, sometimes reaching the public ‘firehose’ of news can work too, and there are few better examples of these in the modern world of development than Hacker News or Reddit.

    Hacker News in particular is notoriously hard to reach the front page on and ‘gaming’ it by getting other people to vote up your post can backfire. (Indeed, it will backfire if you link people to your post on Hacker News and encourage them to upvote. They have ways of detecting this behavior. Get people to manually find your post instead.) If you do reach the front page of Hacker News, of course, you can certainly expect an audience of many thousands of developers to be exposed to your work, so be sure to try.

    With Reddit, the key isn’t to dive straight into a huge sub-Reddit like /r/programming but to look for sub-Reddits more directly related to your project. For a JavaScript library, I’d post to /r/javascript or possibly /r/webdev. Reddit ads can also perform well if you’re OK with spending some money and these can be targeted to specific sub-Reddits too.

    There are many similar sites that are less well known but which are respected in their niches and can drive a lot of interested visitors, including Designer News (mobile and Web design), DZone (general developer stuff), EchoJS (JavaScript), RubyFlow (Ruby and Rails), and Lobste.rs (general hacker and developer stuff). Finding the right site like this and taking time to make an on-topic, well written post will help a lot.

    The mass media / press

    This article is primarily focused on the promotion of open source and front-end projects and these are typically not frequently covered in print or on the TV or radio. If, however, you think the mass media would be relevant for your project, here are some other articles packed with handy tips:

    Step 3: Maintain momentum

    You’ve built up some interest, your GitHub stars, Reddit votes, and pageviews are all rocketing up, but now you want to capitalize on the attention and maintain some momentum.

    User support

    Whether you’ve built an open source project or a cool tool, you’re going to end up with users or fellow developers who want to provide feedback, get help, or point out issues with your work. On GitHub, the common way to do this is through the built-in ‘issues’ tracker, but you might also find people start to e-mail you too.

    Be sure to define a policy, whatever it is. Users won’t feel good about opening issues on your GitHub repo if there are already many unresolved issues there and your project could stagnate. Ensure you respond to your audience or at least make your policy clear within your README or on your site. If you don’t want issues raised or code contributions, make this clear up front.

    Extending your reach

    For many projects, create a dedicated Twitter account, blog, Facebook page, or Google+ page in advance is overkill, but if your project starts to take off, consider these things. They’ll provide an extra way not only for users to remain in touch with your project but also a way for them to help promote it by retweeting things you post or by directing potential new users your way.

    You can also extend your reach in person by going to user groups and conferences and, if you’re really lucky, you can speak about your work too. This is a great way to get new users as people are much more likely to look into your work if they’ve met you in person.

    Avoid being defensive

    If your project does well on sites like Hacker News or Reddit, you’ll be tempted to read all of the comments your peers leave, but be careful. Comments about your work will, naturally, seem magnified in their intensity and critical comments that might not actually be mean spirited may seem as if they are to you.

    It’s hard, but the best policy is to not let any overtly mean comments get to you, duly correct any observations that are wrong, and to thank anyone who goes out of their way to compliment your work. Even if you’re in the right, with the lack of body language and verbal cues, being too defensive can look bad online and result in the post becoming a lightning rod for drama. Engage as best you can, but if it feels wrong to reply to something, listen to your gut.

    Be careful if you go into a new community to promote your work and get negative feedback. Most communities have rules or expectations and merely entering a community to promote your work is frequently considered a faux pas. Be sensitive to people’s environments and try to abide by a community’s rules at all times.

    The long term

    If your project does particularly well, you could be presented with the opportunity of turning it into a business in its own right. Many simple open source projects, often started by a single developer, have turned into long term work or even entire companies for their creators.

    Back in 2010, Mitchell Hashimoto released Vagrant, a Ruby-based tool for building a deploying VirtualBox-based virtualized development environments. In late 2012, Mitchell launched Hashicorp, a company providing Vagrant consulting services to enterprise customers. An even higher profile example is Puppet Labs, a company built around the Puppet open-source configuration management tool and which has taken total funding of $45.5 million so far.

    If your project becomes respected and heavily used within its field, you might also be approached to write a book or article about it or even speak at a conference. This is a good sign that your project has ‘made it’ to some extent as publishers and event organizers are in the business of working out what it makes business sense to present.

    Putting it all together: A checklist

    This has only been a basic introduction to promoting your work and with practice you’ll come up with tons of tips of your own (it’d be excellent if you could share some in the comments here). Based on all of the ideas above, here’s a basic checklist to run through next time you release a new project and want to get some added exposure:

    • Focus most of your efforts on your project’s homepage or README.
    • Check your project’s name doesn’t clash with anything else and is unique enough to find references to your work later.
    • Promote your work to your closest social group first to unbury any problems with your work.
    • Record a screencast or write a blog post about your project if some extra background would be useful for others.
    • Work out a perfect *”[project name] is”* sentence to describe what your project is or does.
    • Use your *”[project name] is”* sentence to give your page a descriptive title.
    • Find influential people, blogs, podcasts, and e-mail newsletters in your niche and send them a short, pleasant note.
    • Post to social news and bookmarking sites. Ensure your title is descriptive.
    • Use your *”[project name] is”* sentence in e-mails and contacts with influencers.
    • Take a positive, “look on the good side” approach to responding to comments about your work.

    Good luck!