In this Firefox OS Treehouse Quick Tip, we talk about the Web Apps Manifest.

To watch more videos like this, go to http://trhou.se/start-free-yt
And don’t forget to subscribe on YouTube: http://trhou.se/subscribe-treehouse-yt

Connect with Treehouse!
Website: http://www.teamtreehouse.com
Twitter: http://trhou.se/treehouse-twitter
Facebook: http://trhou.se/treehouse-facebook
Google+: http://trhou.se/treehouse-google-plus

Each week, we’ll release:

- New episodes of ‘The Treehouse Show’ – up to date news and tips on web design, coding, and more.
- ‘Quick Tip’ videos – these are short how-to videos on today’s most relevant web technologies.
- and much more!

The post The Web Apps Manifest | Firefox OS Quick Tip appeared first on Treehouse Blog.

W3C has published a new edition of Standards for Web Applications on Mobile, an overview of the various technologies developed in W3C that increase the power of Web applications, particularly in the mobile context.

A deliverable of the webinos project, this edition of the document highlights changes since November 2012, including the advancement of HTML5 to Candidate Recommendation. This edition integrates and highlights technologies identified in the Core Mobile Web Platform 2012, a report published by the Core Mobile Web Community Group. In addition, key topics now link to related materials on WebPlatform Docs or in a W3DevCampus on-line training course. The report covers key standards track events as well as upcoming work.

Learn more about the Web and Mobile Devices.

by Sara Leidner

1. People identify themselves by which county they grew up in, or which high school they attended.
2. People use (or know) the term "Delmarva."
3. All the place names refer to English royals, nobles and locales.
4. Lacrosse is a big deal. (For David and everyone from Southern California, LAX is an airport).
5. The War of 1812 is a big deal.
6. The place you go to get or renew a driver's license is called the "MVA." (In other states it's called the Department of Motor Vehicles--DMV--or Bureau of Motor Vehicles--BMV).
7. Counties are known by acronyms like BalCo, HoCo or MoCo. (Really, in other states nobody talks about counties!).
8. High school student governments are called SGA's. (In other states they're called student councils).
9. So many people know when the state legislative session begins and ends.
10. So little travel time is required to experience so many different kinds of terrain.
11. The state flag has four different, highly contrasting colors.
12. So many people live in so many rowhouses.

Everyone likes stuff that moves about on the Web, right? Remember how you cried joyful tears when you first used <marquee>? I do. I nearly sobbed all the water out of my body as I gazed upon “JAKE’S COOL WEBSITE” bobbing back and forth in uppercase serif. Of course, we’re more mature as an industry these days.

We’ve learned that users don’t want websites to look like a CSI console having a personal crisis; instead, we go for smooth transitions that enhance the experience, rather than being the experience themselves. In terms of animation APIs, we’ve been poorly catered to, leaving us to hack around with timers that weren’t really built for animation. Things have been steadily improving in that area, but the new Web Animation specification looks set to shake things up a lot.

So, why do we need a new animation spec? Don’t we have enough ways to animate things already?

Optimizing the way to makes things move.

Let’s Animate A Thing!

Imagine we wanted to animate something horizontally from one left position to another, over three seconds, and then do something on completion. We can do this without JavaScript, using CSS animations, but if the start and end positions are programmatically determined, then we’ll need something that we can control from script.

Using requestAnimationFrame

If you’re performing visual updates with JavaScript, then you should be using requestAnimationFrame. It synchronizes itself to real screen updates, giving you as much time as possible to get everything ready for rendering. If the browser is on a 60 Hz screen (most are) and your frames can be constructed in less than a 60th of a second, then you’ll get 60 frames per second (FPS). requestAnimationFrame prevents you creating frames that don’t have time to display. Synchronizing to the screen’s rate is important; 30 FPS looks smoother than 40 FPS because 40 doesn’t divide into the screen’s native 60 Hz. HTML5 Rocks has a great article on syncing to the screen.

Unfortunately, jQuery uses setInterval, which isn’t as smooth as requestAnimationFrame. requestAnimationFrame doesn’t trigger while the tab or window isn’t visible, which is A Good Thing. Unfortunately, this has created backwards incompatibility with websites that rely on setInterval’s less optimal behavior of continuing to run in the background. You can opt into requestAnimationFrame via a plugin. Go and add that to all of your pages using jQuery animation now — I promise to wait for you — just make sure that switching tabs doesn’t break your animations.

Anyway, enough chatting. Here’s a simple animation using raf, moving a box horizontally from 250px to 500px. Note that the box starts at 0px, so there’s a jump to 250px when the animation starts; this proves we can start the animation from a point other than its current rendered position.

Here’s the code:

    // On button press…
    animateLeft(elm, '250px', '500px', function() {
      console.log("Done!");
    });
    
    // The implementation
    function animateLeft(elm, from, to, done) {
      // Turn our CSS values into numbers
      // We're being lazy and assuming they're in px
      from = parseInt(from, 10);
      to = parseInt(to, 10);
      // Work out the amount we need to move the box
      var diff = to - from;
    
      var duration = 3000;
      var startTime = performance.now();
    
      // Set initial position
      elm.style.transform = 'translate(' + from + 'px, 0)';
    
      function frame(time) {
        // How long has the animation been running?
        var animTime = time - startTime;
        // Are we done?
        if (animTime >= duration) {
          // It's likely that the last rendered position wasn't the
          // final position, so we set it here.
          elm.style.transform = 'translate(' + to + 'px, 0)';
    
          done();
        }
        else {
          // What position should the box be in?
          var position = from + (animTime / duration * diff);
          elm.style.transform = 'translate(' + position + 'px, 0)';
          // Request our next frame
          requestAnimationFrame(frame);
        }
      }
      // request our first frame
      requestAnimationFrame(frame);
    }
    

The above is the ideal according-to-specification code. In the working example, I had to deal with vendor prefixes on requestAnimationFrame and transform. We’re animating using transform and translate, rather than left, because they allow for subpixel positioning and, therefore, smoother animation, one of the advantages that Flash had over HTML for so long.

This is a pretty large and stinky chunk of code to simply animate a thing, and it would get a lot larger if we handled differing CSS units and easing. Of course, you could stick all of the complicated bits in a library and give yourself a simpler API. Here’s the frame-by-frame breakdown:

This is the timeline view of Chrome Developer Tools while the animation is running. Each frame executes some JavaScript, recalculates the style and layout, paints the box, and then sends that to the GPU, which composites it to the page. The draw time spikes a few times, resulting in a jolt in the animation. This is caused by delays in interacting with the GPU (the gray spikes) or delays caused by other JavaScript (the yellow spikes).

This highlights a performance bottleneck of JavaScript-driven animation:

Here, another bit of JavaScript does some stuff and takes 250 milliseconds to do it. While this is happening, our animation can’t move. In the real world, this could be a social-media button waking up and doing something slow, or it could be some of your own script triggered by a user interaction. In the example above, I made a button that performs a while loop for 250 milliseconds (I’m pretty sure this code is in every social-media button). If you press it during the animation, it will block the animation and look nasty.

I recently sung the praises of requestAnimationFrame for animating canvas, so why am I hatin’ on it now? JavaScript-driven animations aren’t a bad practice — they give you full control frame by frame and pixel by pixel when combined with <canvas> — but returning to JavaScript land 60 times a second is overkill for DOM animations that have a defined start and end. Ideally, we want to tell the browser all about our animation and leave it to do its thing, while we get on with something else.

Of course, we kinda have this already.

Using CSS Transitions

    .whatever {
       transform: translate(250px, 0);
       transition: transform 3s linear;
    }
    .whatever:hover {
       transform: translate(500px, 0);
    }
    

CSS transitions and animations let the browser make all kinds of optimizations because it knows the end point of the animation. They’re not blocked by JavaScript on some platforms, such as Chrome for Android and desktop Chrome with threaded compositing enabled in about:flags (expect threaded compositing to arrive in more browsers).

Let’s script it!

    function animateLeft(elm, from, to, done) {
      // Set initial position
      elm.style.transform = 'translate(' + from + ', 0)';
      // Define the transition type
      elm.style.transition = 'all 3s linear';
    
      function transitionEnd(event) {
        // Beware of bubbled events
        if (event.target != elm) { return; }
        // Clear the transition
        elm.style.transition = '';
        // We don't want that listener firing for future anims
        elm.removeEventListener('transitionend', transitionEnd);
    
        done();
      }
    
      // Listen for end of transition
      elm.addEventListener('transitionend', transitionEnd);
      // start the transition
      elm.style.transform = 'translate(' + to + ', 0)';
    }
    

Here’s a live example. It’s much simpler than our raf example, but a bug has crept in. The from is ignored; the animation starts from the element’s current position, even though we’ve explicitly set it to something else. Why?

    // Set initial position
    elm.style.transform = 'translate(' + from + ', 0)';
    // Define the transition type
    elm.style.transition = 'all 3s linear';
    // …and later…
    // Start the transition
    elm.style.transform = 'translate(' + to + ', 0)';
    

Changing properties in the style object doesn’t change the element’s computed style. The style is computed only when the browser needs to know the impact that those styles will have on the page (for example, when the element needs to be drawn). The element doesn’t need to be drawn between the two assignments to elm.style.transform, so the first assignment is ignored.

Of course, we can hack it:

    // Set initial position
    elm.style.transform = 'translate(' + from + ', 0)';
    // Abracadabra!
    elm.offsetWidth;
    // Define the transition type
    elm.style.transition = 'all 3s linear';
    // …and later…
    // start the transition
    elm.style.transform = 'translate(' + to + ', 0)';
    

offsetWidth returns the rendered width of an element, including padding. To calculate this, the browser needs to take into account all of the styles on the page, including the transform that we set for the initial position. That works. Check out the live example.

Performance is steady at 60 FPS. And we can see that each frame is a simple composite; all of the heavy lifting is farmed out to the GPU.

However, relying on offsetWidth to force the element into its starting position is hacky, and it’s conceivable that a future browser release will find a way to optimize out the reflow, breaking our hack.

Reflows are not without cost either:

The Developer Tools warn us about this use of offsetWidth, because the browser calculates a layout that it never draws. The test page is very basic, so the layout cost is cheap, but things can be very different in the real world.

So, is there a less hacky, more reliable way?

Enter CSS Animations

CSS animations have explicit keyframe values. Let’s script them:

    function animateLeft(elm, from, to, done) {
      // Create a style element for our animation
      var style = document.createElement('style');
      // Generate a unique name
      var animName = 'anim' + Date.now() + Math.floor(Math.random() * 10000);
    
      // Build the CSS
      style.textContent = '' +
        '@keyframes ' + animName + ' { ' +
          'from { ' +
            'transform: translate(' + from + ', 0);' +
          '}' +
          'to {'
            'transform: translate(' + to + ', 0);' +
          '}' +
        '}';
    
      // Add it to the page
      document.head.appendChild(style);
    
      function transitionEnd(event) {
        // Beware of bubbled events
        if (event.target != elm) { return; }
        // Clear the animation
        elm.style.animation = '';
        // Clean up the DOM
        document.head.removeChild(style);
        // Retain the final position
        elm.style.transform = 'translate(' + to + ', 0)';
        // We don't want that listener firing for future anims
        elm.removeEventListener('animationend', transitionEnd);
    
        done();
      }
    
      // Listen for end of transition
      elm.addEventListener('animationend', transitionEnd);
    
      // Start the animation
      elm.style.animation = animName + ' 3s linear forwards';
    }
    

Ugh! All of that just to move a thing? It works, but all of that DOM work is heavy-handed for what we’re trying to achieve. Also, if an animation is cancelled halfway through (for example, if the animation style is changed), then animationend will not fire — meaning that our done callback won’t fire or, worse, it’ll fire at the end of some future unrelated animation. There is no animationcancel event.

Web Animations, Save Us From This Mess!

It’s early days for the Web Animations specification, but it’s pretty exciting. It brings a boatload of animation performance and synchronization features natively to the DOM that JavaScript libraries currently have to hack their way through.

The specification itself is kinda terrifying. My heart sank as I opened the page and watched the scrollbar get smaller and smaller. But, thankfully, most of it is implementation detail.

Here’s how we’d script our animation in the brave new world of Web Animation:

    // Set our start position
    elm.style.transform = 'translate(250px, 0)';
    // Animate to the end position
    var anim = elm.animate({
      transform: 'translate(500px, 0)'
    }, 3);
    // Do something on completion
    anim.onend = function() {
      console.log('Done!');
    };
    

Here, elm is an HTMLElement. The API is intuitive, especially if you’ve created animations with something like jQuery.

Like CSS animations and transitions, it gives the browser the full story up front, so we get all of the same optimizations without having to dynamically build CSS. Web Animations solves this by allowing us to tell the browser the full story of what we’re going to do. Then, the browser can go off and animate things itself.

Web Animations give us the scripting API to browser-driven animation that’s sorely missing. Above is the “Hello world” example. The specification includes advanced easing, path-based animation, parallelization, synchronization, interrupting and adapting, all in a way that the browser can take away from JavaScript land and optimize accordingly.

It’s still very early days, so don’t throw out your animation libraries yet. But if you want to experiment with the new API and provide feedback, a polyfill is tracking the rapidly evolving spec. Exciting times!

(al)

© Jake Archibald for Smashing Magazine, 2013.

Advertise here with BSA

Over the last two years of working at Buffer, I’ve come to learn that there are a few preconceived notions, stereotypes, clichés, and commonsense knowledge about startups that simply aren’t true.

I’d like to share some myths that I’ve discovered while working at a tech startup.

Myth 1: "You Need to Have Deadlines"

It’s hard to find companies, new or old, that don’t have deadlines. It’s in the business culture to set deadlines. And deadlines, on the surface, seem even more important in a newly launched Internet startup as a gauge of rapid progression.

And, honestly, in the beginning, we got sucked into thinking that deadlines were important to our success.

Here’s what we’d do: We’d set a deadline, work like crazy as the date arrives, and then, once the task is finally finished, we could relax.

As most of you probably already know, that never works when you’re trying to do something innovative and new; when you don’t have a manual to refer to on how to perform your tasks. And having deadlines didn’t make us happy either.

So, instead, we decided to apply the idea of pace. We help everyone on the team perform their work at a fast pace. We never try to build up to a big launch anymore.

At Balsamiq, we don’t have deadlines. Ever."

- Giacomo "Peldi" Guilizzoni, founder and CEO of Balsamiq Studios

Myth 2: "You Need Everybody in the Same Room"

This is may be the most obvious — and surprisingly still prevalent — myths about working at a company.

I have to admit that I was very skeptical about working in a remote team. My thinking went like this: "Yes, you can probably have a good team working remotely, but what about a great one?"

The truth is that you can build better remote teams than ever before, and most likely an even better one than having everyone in one place because you remove the geographical factor when you hire team members.

The people on the Buffer team live in Australia, U.S. and Europe.

I believe that embracing remote teams is one of the most important elements going forward.

"The technology to successfully run and manage remote teams has never been better."

- David Heinemeier Hansson, creator of Ruby on Rails and partner at 37signals

"WooThemes will always stay true to our remote roots."

- Adii Piernaar, co-founder of WooThemes

Myth 3: "You Don’t Need a Company Culture at the Start"

So, you’re a team of 4 or 6 or 10. The intuitive thinking in this situation is that company culture is a huge waste of time.

You’re small. You’re just starting out. What you need right now is users, marketing strategies, and beautiful code.

Who cares (or has time to think) about company culture?

Building a company culture from Day 1 was one of the most important elements in Buffer’s growth.

I remember that when I first got on board, Joel (the company’s founder) and I wrote a short document called "The personality of Buffer." This simple document helped us in staying aligned with our vision whenever new ideas or challenges came in.

Culture, I believe, should be solidly in place before any feature update, marketing campaign, significant code-writing, and so forth. It doesn’t have to be elaborate; it could be a short document like ours that guides you in the proper direction.

"If I could do it all over again, I would roll out our core values from Day 1."

- Tony Hsieh, chief executive of Zappos.com

Myth 4: "You Have to Work A Lot, Never Sleep and Feel Miserable"

One of the most common beliefs about the tech startup life is that it’s a miserable one.

You are spending day and night in the office, fueled by energy drinks and pizza, without anything else in your life going on.

We’ve found that discouraging crazy work hours and instead building up an incredibly solid daily routine is much more powerful.

What we do is in fact quite counterintuitive to the prevalent notion that work hours at a startup has to be long — we even ask people to go home even if they’re in a good flow!

You can’t sacrifice today for tomorrow.

"Happiness is not something you postpone for the future; it is something you design for the present."

- Jim Rohn, American entrepreneur, author and motivational speaker

Myth 5: "You Can’t Make Money Until You Become Big"

Making money in the early stages of a startup is often equated to "You’re doing it wrong."

The thinking goes: If you’re focusing on monetization at the start, then you’re not putting all of your attention on growth, which is the most important thing for a startup.

On the contrary, there’s nothing better for a startup than making money early. And it’s not just for the obvious reasons.

"Charging for something is the best way to truly validate your idea," is a line from Joel, Buffer’s founder.

"Making money > Raising money."

- Hiten Shah, co-founder of Crazy Egg and KISSmetrics

Myth 6: "You Need to Hurry!"

This misconception about startup companies is similar to the one about needing deadlines.

The idea is often this: You’re a small startup, you need to outrun the competition and everything needs to happen quickly and in a hurry.

That’s a recipe for burning out and for making huge mistakes.

At our company, we try many things to create a balance between being fast-paced and not rushing our work.

One of the best ways to accomplish this, I’ve found, is with deliberate reflection. Recently we introduced "Daily Pair Calls" where two members of the team have a daily call to reflect and discuss their previous days. It’s a great way to slow down in order to speed up.

"Breaking things in right requires a certain amount of patience. You don’t want to push a new engine too hard. You certainly can’t sit still. And the last thing you need is to stall on the interstate."

- Todd Razor, founder of Three Razor

Myth 7: "You Need to Focus on Hiring the Best People"

Here is another myth that definitely needs some explanation first.

We see that new CEO, VP or SVP being hired away from Google to Amazon, from Twitter to Facebook, and so on. And slowly a myth develops.

You can call it the "rockstar" myth.

The "rockstar" myth is the idea that the best engineers, marketers, designers, etc. are 10x better than us regular folks, and that these are the only people you need to be working with in a startup in order to ensure success.

But, at a startup, is it practical to focus your time and resources searching for that perfect "10x" programmer?

Wouldn’t you be missing out on working with many amazing people if you limited your options to that elusive "10x" designer that probably already works for someone else paying them much more than you can afford?

Instead, at our company, we evaluate candidates based on:

1. Do they fit our company’s culture?
2. Do we have a real need for the person’s talent and skills right now?

However, if we find someone who is an exceptional fit to our company’s culture, we will still hire the person, even if the position isn’t immediately obvious.

"Your goal shouldn’t be to buy players, your goal should be to buy wins."

- From the movie, Moneyball

Myth 8: "Be Miserable Now, So You Can Enjoy Your Life Later"

Another key misconception about working in a startup is that it involves sacrificing a few years of your life so you’re able to sell your company for a good profit and then live happily ever after.

You don’t need to sacrifice your health and happiness when you work at a startup.

A lot of our values and work at Buffer evolve around happiness. Everyone on the team has a daily call with another team member to discuss his or her daily improvement towards increased happiness, which I believe is important in maintaining a high level of productivity in our company.

"Instead of wondering when your next vacation is, you ought to set up a life you don’t need to escape from."

- Seth Godin, American entrepreneur, author and public speaker

Myth 9: "You Launch Lean, And Then You Can Build Things the Old Way"

So, you’ve read and understood Lean Startup. You decide you’re launching lean with your MVP until you find product market fit, doing all the customer development you can. And then you stop and revert to the "traditional" way of running a company when you’ve gotten a bit of a foothold in the industry.

That’s what we did near the beginning of our startup journey.

Instead, I think being lean should be a continual process, even well after you outgrow the title of "startup" and become a mega-huge company.

The most impressive case study of this is Eric Ries’s (the pioneer of Lean Startup) own company, IMVU. The company’s clear focus on lean throughout all processes is something we try to see as an amazing example to follow at our startup.

Myth 10: "You Can’t Share Numbers or Sensitive Details"

Another myth that we strongly aim to work against is that, as a startup, you have to keep your numbers under the hood.

After all, you’re a small company and if you share your innermost secrets, the competition will crush you!

We found the opposite to be true. We openly shared how we met each of our investors, how much revenue we are generating and have plans of turning into a full-fledged Open company over the next few months.

I believe that being transparent and sharing our progress has helped us gain goodwill with our users and also within the industry.

Your Turn

I’m sure that you could come up with lots more myths and misconceptions about startups.

Share your thoughts and experiences on the subject.

Related Content

• Common Misconceptions about Web Designers
• Letting Bad Design Decisions Happen
• Tips for Building Trust with Your Clients
• Related categories: Project Management and Resources

About the Author

Leo Widrich is co-founder of Buffer, a better way to post to Twitter, Facebook and LinkedIn. He also blogs about insights on lifehacks, business and productivity on the Buffer blog. You can say “hello” to him on Twitter @leowid (he is a super nice guy).