Skip navigation
Help

Paul Irish

warning: Creating default object from empty value in /var/www/vhosts/sayforward.com/subdomains/recorder/httpdocs/modules/taxonomy/taxonomy.pages.inc on line 33.
Original author: 
Addy Osmani

  

Today we’ll discuss how to improve the paint performance of your websites and Web apps. This is an area that we Web developers have only recently started looking at more closely, and it’s important because it could have an impact on your user engagement and user experience.

Frame Rate Applies To The Web, Too

Frame rate is the rate at which a device produces consecutive images to the screen. A low frames per second (FPS) means that individual frames can be made out by the eye. A high FPS gives users a more responsive feel. You’re probably used to this concept from the world of gaming, but it applies to the Web, too.

Long image decoding, unnecessary image resizing, heavy animation and data processing can all lead to dropped frames, which reduces the frame rate, resulting in janky pages. We’ll explain what exactly we mean by “jank” shortly.

Why Care About Frame Rate?

Smooth, high frame rates drive user engagement and can affect how much users interact with your website or app.

At EdgeConf earlier this year, Facebook confirmed this when it mentioned that in an A/B test, it slowed down scrolling from 60 FPS to 30 FPS, causing engagement to collapse. That said, if you can’t do high frame rates and 60 FPS is out of reach, then you’d at least want something smooth. If you’re doing your own animation, this is one benefit of using requestAnimationFrame: the browser can dynamically adjust to keep the frame rate normal.

In cases where you’re concerned about scrolling, the browser can manage the frame rate for you. But if you introduce a large amount of jank, then it won’t be able to do as good a job. So, try to avoid big hitches, such as long paints, long JavaScript execution times, long anything.

Don’t Guess It, Test It!

Before getting started, we need to step back and look at our approach. We all want our websites and apps to run more quickly. In fact, we’re arguably paid to write code that runs not only correctly, but quickly. As busy developers with deadlines, we find it very easy to rely on snippets of advice that we’ve read or heard. Problems arise when we do that, though, because the internals of browsers change very rapidly, and something that’s slow today could be quick tomorrow.

Another point to remember is that your app or website is unique, and, therefore, the performance issues you face will depend heavily on what you’re building. Optimizing a game is a very different beast to optimizing an app that users will have open for 200+ hours. If it’s a game, then you’ll likely need to focus your attention on the main loop and heavily optimize the chunk of code that is going to run every frame. With a DOM-heavy application, the memory usage might be the biggest performance bottleneck.

Your best option is to learn how to measure your application and understand what the code is doing. That way, when browsers change, you will still be clear about what matters to you and your team and will be able to make informed decisions. So, no matter what, don’t guess it, test it!

We’re going to discuss how to measure frame rate and paint performance shortly, so hold onto your seats!

Note: Some of the tools mentioned in this article require Chrome Canary, with the “Developer Tools experiments” enabled in about:flags. (We — Addy Osmani and Paul Lewis — are engineers on the Developer Relations team at Chrome.)

Case Study: Pinterest

The other day we were on Pinterest, trying to find some ponies to add to our pony board (Addy loves ponies!). So, we went over to the Pinterest feed and started scrolling through, looking for some ponies to add.

Screen Shot 2013-03-25 at 14.30.57-500
Addy adding some ponies to his Pinterest board, as one does. Larger view.

Jank Affects User Experience

The first thing we noticed as we scrolled was that scrolling on this page doesn’t perform very well — scrolling up and down takes effort, and the experience just feels sluggish. When they come up against this, users get frustrated, which means they’re more likely to leave. Of course, this is the last thing we want them to do!

Screen Shot 2013-03-25 at 14.31.27-500
Pinterest showing a performance bottleneck when a user scrolls. Larger view.

This break in consistent frame rate is something the Chrome team calls “jank,” and we’re not sure what’s causing it here. You can actually notice some of the frames being drawn as we scroll. But let’s visualize it! We’re going to open up Frames mode and show what slow looks like there in just a moment.

Note: What we’re really looking for is a consistently high FPS, ideally matching the refresh rate of the screen. In many cases, this will be 60 FPS, but it’s not guaranteed, so check the devices you’re targeting.

Now, as JavaScript developers, our first instinct is to suspect a memory leak as being the cause. Perhaps some objects are being held around after a round of garbage collection. The reality, however, is that very often these days JavaScript is not a bottleneck. Our major performance problems come down to slow painting and rendering times. The DOM needs to be turned into pixels on the screen, and a lot of paint work when the user scrolls could result in a lot of slowing down.

Note: HTML5 Rocks specifically discusses some of the causes of slow scrolling. If you think you’re running into this problem, it’s worth a read.

Measuring Paint Performance

Frame Rate

We suspect that something on this page is affecting the frame rate. So, let’s go open up Chrome’s Developer Tools and head to the “Timeline” and “Frames” mode to record a new session. We’ll click the record button and start scrolling the page the way a normal user would. Now, to simulate a few minutes of usage, we’re going to scroll just a little faster.

Screen Shot 2013-05-15 at 17.57.48-500
Using Chrome’s Developer Tools to profile scrolling interactions. Larger view.

Up, down, up, down. What you’ll notice now in the summary view up at the top is a lot of purple and green, corresponding to painting and rendering times. Let’s stop recording for now. As we flip through these various frames, we see some pretty hefty “Recalculate Styles” and a lot of “Layout.”

If you look at the legend to the very right, you’ll see that we’ve actually blown our budget of 60 FPS, and we’re not even hitting 30 FPS either in many cases. It’s just performing quite poorly. Now, each of these bars in the summary view correspond to one frame — i.e. all of the work that Chrome has to do in order to be able to draw an app to the screen.

screen434343-500
Chrome’s Developer Tools showing a long paint time. Larger view.

Frame Budget

If you’re targeting 60 FPS, which is generally the optimal number of frames to target these days, then to match the refresh rate of the devices we commonly use, you’ll have a 16.7-millisecond budget in which to complete everything — JavaScript, layout, image decoding and resizing, painting, compositing — everything.

Note: A constant frame rate is our ideal here. If you can’t hit 60 FPS for whatever reason, then you’re likely better off targeting 30 FPS, rather than allowing a variable frame rate between 30 and 60 FPS. In practice, this can be challenging to code because when the JavaScript finishes executing, all of the layout, paint and compositing work still has to be done, and predicting that ahead of time is very difficult. In any case, whatever your frame rate, ensure that it is consistent and doesn’t fluctuate (which would appear as stuttering).

If you’re aiming for low-end devices, such as mobile phones, then that frame budget of 16 milliseconds is really more like 8 to 10 milliseconds. This could be true on desktop as well, where your frame budget might be lowered as a result of miscellaneous browser processes. If you blow this budget, you will miss frames and see jank on the page. So, you likely have somewhere nearer 8 to 10 milliseconds, but be sure to test the devices you’re supporting to get a realistic idea of your budget.

Screen Shot 2013-03-25 at 14.34.26-500
An extremely costly layout operation of over 500 milliseconds. Larger view.

Note: We’ve also got an article on how to use the Chrome Developer Tools to find and fix rendering performance issues that focuses more on the timeline.

Going back to scrolling, we have a sneaking suspicion that a number of unnecessary repaints are occurring on this page with onscroll.

One common mistake is to stuff just way too much JavaScript into the onscroll handlers of a page — making it difficult to meet the frame budget at all. Aligning the work to the rendering pipeline (for example, by placing it in requestAnimationFrame) gives you a little more headroom, but you still have only those few milliseconds in which to get everything done.

The best thing you can do is just capture values such as scrollTop in your scroll handlers, and then use the most recent value inside a requestAnimationFrame callback.

Paint Rectangles

Let’s go back to Developer Tools → Settings and enable “Show paint rectangles.” This visualizes the areas of the screen that are being painted with a nice red highlight. Now look at what happens as we scroll through Pinterest.

Screen Shot 2013-03-25 at 14.35.17-500
Enabling Chrome Developer Tools’ “Paint Rectangles” feature. Larger view.

Every few milliseconds, we experience a big bright flash of red across the entire screen. There seems to be a paint of the whole screen every time we scroll, which is potentially very expensive. What we want to see is the browser just painting what is new to the page — so, typically just the bottom or top of the page as it gets scrolled into view. The cause of this issue seems to be the little “scroll to top” button in the lower-right corner. As the user scrolls, the fixed header at the top needs to be repainted, but so does the button. The way that Chrome deals with this is to create a union of the two areas that need to be repainted.

Screen Shot 2013-05-15 at 19.00.12-500
Chrome shows freshly painted areas with a red box. Larger view.

In this case, there is a rectangle from the top left to top right, but not very tall, plus a rectangle in the lower-right corner. This leaves us with a rectangle from the top left to bottom right, which is essentially the whole screen! If you inspect the button element in Developer Tools and either hide it (using the H key) or delete it and then scroll again, you will see that only the header area is repainted. The way to solve this particular problem is to move the scroll button to its own layer so that it doesn’t get unioned with the header. This essentially isolates the button so that it can be composited on top of the rest of the page. But we’ll talk about layers and compositing in more detail in a little bit.

The next thing we notice has to do with hovering. When we hover over a pin, Pinterest paints an action bar containing “Repin, comment and like” buttons — let’s call this the action bar. When we hover over a single pin, it paints not just the bar but also the elements underlying it. Painting should happen only on those elements that you expect to change visually.

Screen Shot 2013-03-25 at 14.35.46-500
A cause for concern: full-screen flashes of red indicate a lot of painting. Larger view.

There’s another interesting thing about scrolling here. Let’s keep our cursor hovered over this pin and start scrolling the page again.

Every time we scroll through a new row of images, this action bar gets painted on yet another pin, even though we don’t mean to hover over it. This comes down more to UX than anything else, but scrolling performance in this case might be more important than the hover effect during scrolling. Hovering amplifies jank during scrolling because the browser essentially pauses to go off and paint the effect (the same is true when we roll out of the element!). One option here is to use a setTimeout with a delay to ensure that the bar is painted only when the user really intends to use it, an approach we covered in “Avoiding Unnecessary Paints.” A more aggressive approach would be to measure the mouseenter or the mouse’s trajectory before enabling hover behaviors. While this measure might seem rather extreme, remember that we are trying to avoid unnecessary paints at all costs, especially when the user is scrolling.

Overall Paint Cost

We now have a really great workflow for looking at the overall cost of painting on a page; go back into Developer Tools and “Enable continuous page repainting.” This feature will constantly paint to your screen so that you can find out what elements have costly paint times. You’ll get this really nice black box in the top corner that summarizes paint times, with the minimum and maximum also displayed.

screenshot43234242-500
Chrome’s “Continuous Page Repainting” mode helps you to assess the overall cost of a page. Larger view.

Let’s head back to the “Elements” panel. Here, we can select a node and just use the keyboard to walk the DOM tree. If we suspect that an element has an expensive paint, we can use the H shortcut key (something recently added to Chrome) to toggle visibility on that element. Using the continuous paint box, we can instantly see whether this has a positive effect on our pages’ paint times. We should expect it to in many cases, because if we hide an element, we should expect a corresponding reduction in paint times. But by doing this, we might see one element that is especially expensive, which would bear further scrutiny!

Screen Shot 2013-06-10 at 09.46.31_500_mini
The “Continuous Page Repainting” chart showing the time taken to paint the page.

For Pinterest’s website, we can do it to the categories bar or to the header, and, as you’d expect, because we don’t have to paint these elements at all, we see a drop in the time it takes to paint to the screen. If we want even more detailed insight, we can go right back to the timeline and record a new session to measure the impact. Isn’t that great? Now, while this workflow should work great for most pages, there might be times when it isn’t as useful. In Pinterest’s case, the pins are actually quite deeply nested in the page, making it hard for us to measure paint times in this workflow.

Luckily, we can still get some good mileage by selecting an element (such as a pin here), going to the “Styles” panel and looking at what CSS styles are being used. We can toggle properties on and off to see how they effect the paint times. This gives us much finer-grained insight into the paint profile of the page.

Here, we see that Pinterest is using box-shadow on these pins. We’ve optimized the performance of box-shadow in Chrome over the past two years, but in combination with other styles and when heavily used, it could cause a bottleneck, so it’s worth looking at.

Pinterest has reduced continuous paint mode times by 40% by moving box-shadow to a separate element that doesn’t have border-radius. The side effect is slightly fuzzy-looking corners; however, it is barely noticeable due to the color scheme and the low border-radius values.

Note: You can read more about this topic in “CSS Paint Times and Page Render Weight.”

Screen Shot 2013-03-25 at 15.47.40-500
Toggling styles to measure their effect on page-rendering weight. Larger view.

Let’s disable box-shadow to see whether it makes a difference. As you can see, it’s no longer visible on any of the pins. So, let’s go back to the timeline and record a new session in which we scroll the same way as we did before (up and down, up and down, up and down). We’re getting closer to 60 FPS now, and that’s just from one change.

Public service announcement: We’re absolutely not saying don’t use box-shadow — by all means, do! Just make sure that if you have a performance problem, measure correctly to find out what your own bottlenecks are. Always measure! Your website or application is unique, as will any performance bottleneck be. Browser internals change almost daily, so measuring is the smartest way to stay up to date on the changes, and Chrome’s Developer Tools makes this really easy to do.

Screen Shot 2013-03-25 at 15.50.25-500
Using Chrome Developer Tools to profile is the best way to track browser performance changes. Larger view.

Note: Eberhard Grather recently wrote a detailed post on “Profiling Long Paint Times With DevTools’ Continuous Painting Mode,” which you should spend some quality time with.

Another thing we noticed is that if you click on the “Repin” button, do you see the animated effect and the lightbox being painted? There’s a big red flash of repaint in the background. It’s not clear from the tooling if the paint is the white cover or some other affected being area. Be sure to double check that the paint rectangles correspond to the element or elements that you think are being repainted, and not just what it looks like. In this case, it looks like the whole screen is being repainted, but it could well be just the white cover, which might not be all that expensive. It’s nuanced; the important thing is to understand what you’re seeing and why.

Hardware Compositing (GPU Acceleration)

The last thing we’re going to look at on Pinterest is GPU acceleration. In the past, Web browsers have relied pretty heavily on the CPU to render pages. This involved two things: firstly, painting elements into a bunch of textures, called layers; and secondly, compositing all of those layers together to the final picture seen on screen.

Over the past few years, however, we’ve found that getting the GPU involved in the compositing process can lead to some significant speeding up. The premise is that, while the textures are still painted on the CPU, they can be uploaded to the GPU for compositing. Assuming that all we do on future frames is move elements around (using CSS transitions or animations) or change their opacity, we simply provide these changes to the GPU and it takes care of the rest. We essentially avoid having to give the GPU any new graphics; rather, we just ask it to move existing ones around. This is something that the GPU is exceptionally quick at doing, thus improving performance overall.

There is no guarantee that this hardware compositing will be available and enabled on a given platform, but if it is available the first time you use, say, a 3D transform on an element, then it will be enabled in Chrome. Many developers use the translateZ hack to do just that. The other side effect of using this hack is that the element in question will get its own layer, which may or may not be what you want. It can be very useful to effectively isolate an element so that it doesn’t affect others as and when it gets repainted. It’s worth remembering that the uploading of these textures from system memory to the video memory is not necessarily very quick. The more layers you have, the more textures need to be uploaded and the more layers that will need to be managed, so it’s best not to overdo it.

Note: Tom Wiltzius has written about the layer model in Chrome, which is a relevant read if you are interested in understanding how compositing works behind the scenes. Paul has also written a post about the translateZ hack and how to make sure you’re using it in the right ways.

Another great setting in Developer Tools that can help here is “Show composited layer borders.” This feature will give you insight into those DOM elements that are being manipulated at the GPU level.

layer_folders_addy_500_mini
Switching on composited layer borders will indicate Chrome’s rendering layers. Larger view.

If an element is taking advantage of the GPU acceleration, you’ll see an orange border around it with this on. Now as we scroll through, we don’t really see any use of composited layers on this page — not when we click “Scroll to top” or otherwise.

Chrome is getting better at automatically handling layer promotion in the background; but, as mentioned, developers sometimes use the translateZ hack to create a composited layer. Below is Pinterest’s feed with translateZ(0) applied to all pins. It’s not hitting 60 FPS, but it is getting closer to a consistent 30 FPS on desktop, which is actually not bad.

Screen Shot 2013-05-15 at 19.03.13-500
Using the translateZ(0) hack on all Pinterest pins. Note the orange borders. Larger view.

Remember to test on both desktop and mobile, though; their performance characteristics vary wildly. Use the timeline in both, and watch your paint time chart in Continuous Paint mode to evaluate how fast you’re busting your budget.

Again, don’t use this hack on every element on the page — it might pass muster on desktop, but it won’t on mobile. The reason is that there is increased video memory usage and an increased layer management cost, both of which could have a negative impact on performance. Instead, use hardware compositing only to isolate elements where the paint cost is measurably high.

Note: In the WebKit nightlies, the Web Inspector now also gives you the reasons for layers being composited. To enable this, switch off the “Use WebKit Web Inspector” option and you’ll get the front end with this feature in there. Switch it on using the “Layers” button.

A Find-and-Fix Workflow

Now that we’ve concluded our Pinterest case study, what about the workflow for diagnosing and addressing your own paint problems?

Finding the Problem

  • Make sure you’re in “Incognito” mode. Extensions and apps can skew the figures that are reported when profiling performance.
  • Open the page and the Developer Tools.
  • In the timeline, record and interact with your page.
  • Check for frames that go over budget (i.e. over 60 FPS).
  • If you’re close to budget, then you’re likely way over the budget on mobile.
  • Check the cause of the jank. Long paint? CSS layout? JavaScript?

Screen Shot 2013-05-15 at 19.36.22-500
Spend some quality time with Frame mode in Chrome Developer Tools to understand your website’s runtime profile. Larger view.

Fixing the Problem

  • Go to “Settings” and enable “Continuous Page Repainting.”
  • In the “Elements” panel, hide anything non-essential using the hide (H) shortcut.
  • Walk through the DOM tree, hiding elements and checking the FPS in the timeline.
  • See which element(s) are causing long paints.
  • Uncheck styles that could affect paint time, and track the FPS.
  • Continue until you’ve located the elements and styles responsible for the slow-down.

fixing-500_mini
Switch on extra Developer Tools features for more insight. Larger view.

What About Other Browsers?

Although at the time of writing, Chrome has the best tools to profile paint performance, we strongly recommend testing and measuring your pages in other browsers to get a feel for what your own users might experience (where feasible). Performance can vary massively between them, and a performance smell in one browser might not be present in another.

As we said earlier, don’t guess it, test it! Measure for yourself, understand the abstractions, know your browser’s internals. In time, we hope that the cross- browser tooling for this area improves so that developers can get an accurate picture of rendering performance, regardless of the browser being used.

Conclusion

Performance is important. Not all machines are created equal, and the fast machines that developers work on might not have the performance problems encountered on the devices of real users. Frame rate in particular can have a big impact on engagement and, consequently, on a project’s success. Luckily, a lot of great tools out there can help with that.

Be sure to measure paint performance on both desktop and mobile. If all goes well, your users will end up with snappier, more silky-smooth experiences, regardless of the device they’re using.

Further Reading

About the Authors

Addy Osmani and Paul Lewis are engineers on the Developer Relations team at Chrome, with a focus on tooling and rendering performance, respectively. When they’re not causing trouble, they have a passion for helping developers build snappy, fluid experiences on the Web.

(al)

© Addy Osmani for Smashing Magazine, 2013.

0
Your rating: None
Original author: 
(author unknown)

I know you’ve been asked this plenty of times already, but: no new vendor prefixes, right? Right?

Nope, none! They’re great in theory but turns out they fail in practice, so we’re joining Mozilla and the W3C CSS WG and moving away them. There’s a few parts to this.

Firstly, we won’t be migrating the existing -webkit- prefixed properties to a -chrome- or -blink- prefix, that’d just make extra work for everyone. Secondly, we inherited some existing properties that are prefixed. Some, like -webkit-transform, are standards track and we work with the CSS WG to move ahead those standards while we fix any remaining issues in our implementation and we’ll unprefix them when they’re ready. Others, like -webkit-box-reflect are not standards track and we’ll bring them to standards bodies or responsibly deprecate these on a case-by-case basis. Lastly, we’re not introducing any new CSS properties behind a prefix.

Pinky swear?

Totes. New stuff will be available to experiment with behind a flag you can turn on in about:flags called “Experimental Web Platform Features”. When the feature is ready, it’ll graduate to Canary, and then follow its ~12 week path down through Dev Channel, Beta to all users at Stable.

The Blink prefix policy is documented and, in fact, WebKit just nailed down their prefix policy going forward. If you’re really into prefix drama (and who isn’t!) Chris Wilson and I discussed this a lot more on the Web Ahead podcast [37:20].

How long before we can try Blink out in Chrome?

Blink’s been in Chrome Canary as of the day we announced it. The codebase was 99.9% the same when Blink launched, so no need to rush out and check everything. All your sites should be pretty much the same.

Chrome 27 has the Blink engine, and that’s available on the beta channel for
Win, Mac, Linux, ChromeOS and Android. (See the full beta/stable/dev/canary
view
).

While the internals are apt to be fairly different, will there be any radical changes to the rendering side of things in the near future?

Nothing too alarming, layout and CSS stuff is all staying the same. Grid layout is still in development, though, and our Windows text rendering has been getting a new backend that we can hook up soon, greatly boosting the quality of webfont rendering there.

We’re also interested in better taking advantage of multiple cores on machines, so the more we can move painting, layout (aka reflow), and style recalculation to a separate thread, but the faster everyone’s sites will render. We’re already doing multi-threaded painting on ChromeOS and Android, and looking into doing it on Mac & Windows. If you’re interested in these experimental efforts or watching new feature proposals, take a look at the blink-dev mailing list. A recent proposed experiment is called Oilpan, where we’ll look into the advantages of moving the implementation of Chrome’s DOM into JavaScript.

Will features added to Blink be contributed back to the WebKit project? Short term; long term?

Since Blink launched there’s been a few patches that have been landed in both Blink and WebKit, though this is expected to decline in the long-term, as the code bases will diverge.

When are we likely to start seeing Blink-powered versions of Chrome on Android? Is it even possible on iOS, or is iOS Chrome still stuck with a Safari webview due to Apple’s policies?

Blink is now in the Chrome Beta for Android. Chrome for iOS, due to platform limitations, is based on the WebKit-based WebView that’s provided by iOS.

Part of this move seems to be giving Google the freedom to remove old or disused features that have been collecting dust in WebKit for ages. There must be a few things high on that list—what are some of those things, and how can we be certain their removal won’t lead to the occasional broken website?

A few old ’n crusty things that we’re looking at removing: the isindex attribute, RangeException, and XMLHttpRequestException. Old things that have little use in the wild and just haven’t gotten a spring cleaning from the web platform for ages.

Now, we don’t want to break the web, and that’s something that web browser engineers have always been kept very aware of. We carefully gauge real-world usage of things like CSS and DOM features before deprecating anything. At Google we have a copy of the web that we run queries against, so we have a pretty OK idea of what CSS and JavaScript out there is using.

Blink also has over 32,000 tests in its test suite, and manual confirmation that over 100 sites work great before every release ships. And we’re working closely with the W3C and Adobe to share tests and testing infrastructure across browsers, with the goals of reducing maintenance burden, improving interoperability, and increasing test coverage. Eventually we’d like all new features to ship with shared conformance tests, ensuring interoperability even as we add cutting-edge stuff.

Still, any deprecation has to be done responsibly. There’s now a draft Blink process for deprecating features which includes:

  • Anonymous metrics to understand how much any specific feature is used “in the wild”
  • ”Intent to deprecate” emails that hit blink-dev months before anything is
    removed
  • Warnings that you’ll find in your DevTools console if you’re using anything
    deprecated
  • Mentions on the Chromium blog like this Chrome 27
    wrap-up
    .

Did part of the decision to branch away from WebKit involve resistance to adding a Dart VM? WebKit’s goals explicitly mention JavaScript, and Apple representatives have been fairly vocal about not seeing a need.

Nope, not at all. The decision was made by the core web platform engineers. Introducing a new VM to a browser introduces considerable maintenance cost (we saw this with V8 and JavaScriptCore both in WebKit) and right now Dart isn’t yet ready to be considered for an integration with Blink. (more on that in a sec). Blink’s got strong principles around compatibility risk and this guides a lot of the decisions around our commitments to potential features as they are proposed. You can hear a more complete answer here from Darin Fisher, one of the Chrome web platform leads.

Have any non-WebKit browsers recently expressed an interest in Dart? A
scripting language that only stands to work in one browser sounds a little
VBScript-y.

Not yet, but since Dart compiles to JavaScript and runs across the modern web, it’s not gated by other browsers integrating the VM. But it’s still early days, Dart has not yet reached a stable 1.0 milestone and that there are still technical challenges with the Dart VM around performance and memory management. Still, It’s important to point out that Dart is an open source project, with a bunch of external contributors and committers.

Let me take a moment to provide my own perspective on Dart. :) Now, as you know, I’m a JavaScript guy, so early on, I took a side and and considered Dart an enemy. JavaScript should win; Dart is bad! But then I came to realize the Dart guys aren’t just setting out to improve the authoring and scalability of web application development. They also really want the web to win.  Now I’ve recently spoke about how The Mobile Web Is In Trouble, and clarified that my priorities are seeing it provide a fantastic user experience to everyone. For me, seeing the mobile web be successful trumps language wars and certainly quibbling over syntax. So I’m happy to see developers embrace the authoring advantages of Coffeescript, the smart subset of JavaScript strict mode, the legendary Emscripten & asm.js combo, the compiler feedback of TypeScript and the performance ambitions of Dart. It’s worth trying out technologies that can leapfrog the current expectations of the user experience that we can deliver. Our web is worth it.

Will Opera be using the Chromium version of Blink wholesale, as far as you know? Are we likely to see some divergence between Opera and Chrome?

As I understand it, Opera Mobile, Opera Desktop, and Opera Mini will all be based on Chromium. This means that they’ll not only share the exact version of Blink that Chrome uses, but also the same graphics stack, JavaScript engine, and networking stack. Already, Opera has contributed some great things to Blink and we’re excited about what’s next.

Why the name “Blink,” anyway?

Haha. Well… it’s a two parter. First, Blink evokes a certain feeling of speed and simplicity—two core principles of Chrome. Then, Chrome has a little tradition of slightly ironic names. Chrome itself is all about minimizing the browser chrome, and the Chromebook Pixel is all about not seeing any pixels at all. So naturally, it fits that Blink will never support the infamous <blink> tag. ;)

<3z

0
Your rating: None
Original author: 
GoogleDevelopers


Blink Questions Answered

Answers to the top questions (listed with timecodes here http://chromium.org/blink/developer-faq#TOC-Q-A-Video) asked by the developer community about Blink....
From:
GoogleDevelopers
Views:
21599

207
ratings
Time:
31:31
More in
Science & Technology

0
Your rating: None


The Breakpoint Ep 3: The Sourcemap Spectacular with Paul Irish and Addy Osmani

Ask and vote for questions at goo.gl Take Coffeescript to Javascript to Minified and all the way back with source maps. In addition to a new Coffeescript sourcemap workflow, we'll cover the latest sourcemap updates so you can understand how to dramatically improve your debugging experience. Finally, Paul and Addy will be joined by special guest—Yeoman core contributor Sindre Sorhus—to discuss what big new changes are coming to the project.
From:
GoogleDevelopers
Views:
2490

49
ratings
Time:
41:15
More in
Science & Technology

0
Your rating: None


GDL Presents: Make Web Magic | Part II

Using the latest open web technologies, the developers creating some of the most inspired Chrome Experiments showcase their latest web experiments and discuss how they are making the web faster, more fun, and open in this 3-episode hangout. Host: Paul Irish, Developer Advocate, Chrome Guest: Mark Danks
From:
GoogleDevelopers
Views:
645

12
ratings
Time:
17:41
More in
Science & Technology

0
Your rating: None


GDL Presents: Make Web Magic | Part I

Using the latest open web technologies, the developers creating some of the most inspired Chrome Experiments showcase their latest web experiments and discuss how they are making the web faster, more fun, and more open in this 3-episode hangout. Happy experimenting. Host: Paul Irish, Developer Advocate, Chrome Guest: Michael Deal
From:
GoogleDevelopers
Views:
2052

34
ratings
Time:
31:44
More in
Science & Technology

0
Your rating: None


HTML5Rocks Live, Episode 1

In this episode of HTML5Rocks Live, Boris, Eric and Paul join us to show some great new libraries and performance tips. Please leave your comments on our plus page at goo.gl In the first chapter, Paul shows how to use some of Chrome's new developer tools to understand how things are rendering and get improved performance. In the second chapter (21:25), Boris shows off his new device.js library to help make development of mobile web applications and sites easier. Eric closes the hangout (40:00) and talks about his new file system API polyfill that uses indexed db as it's back end. 02:15 Scroll Effects Demo goo.gl 23:04 - Media Queries Site goo.gl 24:15 - WURFL goo.gl 26:40 - Boris' Device Library goo.gl 29:28 - Device.js Demo goo.gl 33:25 - Bug to add touch-enabled media query to Chrome, please star goo.gl 35:00 - Chrome's DevTools for Mobile Development 38:56 - Paul Irish's Touch Demos goo.gl 40:43 - File System API Book goo.gl 43:10 - Eric's idb.filesystem.js goo.gl 44:27 - idb.filesystem HTML5 File System Demo goo.gl 47:33 - HTML5 Filesystem Playground goo.gl
From:
GoogleDevelopers
Views:
11028

209
ratings
Time:
52:29
More in
Science & Technology

0
Your rating: None

  

I don’t think anyone can deny that the Web has changed the way people teach, learn, and do research. Of course, this doesn’t mean that everything we read online is true and accurate—far from it. But I believe that through honest discussion and objective collaboration, accurate and useful information is much more likely to be the end result of any educational endeavor.

In the final week of November 2011, a smart group of developers launched a project called Move The Web Forward, which you can read more about in Addy Osmani’s Smashing Magazine article.

For this post, I want to focus on one piece of advice given by those developers in that project, under the heading “Write”.

The advice is: Publish what you learn.

As soon as I read that exhortation (which originated with this tweet), I knew this was a project made by a group of people who cared about the Web and that they understand what it takes to move forward as developers, and as an industry.

Let’s explore those four simple words, because I believe that concept is at the heart of how much progress has been made in the front-end development niche. And it’s something that could help almost any industry, in any field.

Just Do It

Very few blogs start out with much traffic at all. Unless the blog is based on an already existing brand that has a lot of exposure, most blogs will begin with very few readers. Even Smashing Magazine, who now has millions of readers, subscribers, and followers, started out with nothing.

CSS-Tricks is another good example of a blog that started out as nothing, and has grown into a thriving, collaborative community. Its founder and curator, Chris Coyier, certainly couldn’t have predicted how much that website would grow. And I’m sure we could come up with additional examples of websites that went from zero to hero in a relatively short time.

Why did they become successful? Because they published what they learned. At one time I somewhat favored the view that too many blogs were being launched. But I think the benefits of so much being published in so many different places outweigh any drawbacks.

Of course, this is not to suggest that the reason you want to publish your thoughts is to “make it big”—that should be secondary, if considered at all. In fact, what you publish doesn’t necessarily have to be on a run-of-the-mill monetized WordPress blog. It could be a GitHub account, a Wiki-style website, a Tumblr feed, or even a bunch of quick tips on a simple Twitter account.

Which brings us to another important supplement to this theme. Immediately after the folks at Move The Web Forward told us to publish what we learn, they made an equally important statement.

Don’t Be Afraid To Make Mistakes

You might be thinking: “Wait. What? Me? Publish a blog? I’ve been coding websites for a measly six months (or some other ostensibly short period of time). Even if people visit my website and read it, my articles will probably get torn to shreds!”

That doesn’t matter. What’s important is that you recognize the value in researching, teaching, collaborating, and correcting mistakes. That’s why the Move The Web Forward folks went on to encourage writers to “keep your posts updated.”

And that’s why Rebecca Murphey, when discussing how to get better at writing JavaScript, said:

“The number one thing that will make you better at writing JavaScript is writing JavaScript. It’s OK if you cringe at it six months from now. It’s OK if you know it could be better if you only understood X, Y, or Z a little bit better. Cultivate dissatisfaction, and fear the day when you aren’t disappointed with the code you wrote last month.”

In this case, Rebecca was talking about actually writing code, not writing about code. But the same principle applies: you will get better when you make mistakes and correct them.

And if you think you’ve made some progress and you have something unique and educational to share, don’t be afraid to offer it to one of the many design and development blogs that will gladly pay you for content.

Comments Are Part Of The Content

There are too many websites that view the readers’ comments as secondary content that is not nearly as valuable as what the author has to say in the main article. Every website should continually make changes or updates to content that is clearly shown to be incorrect. This shows that the publisher wants to provide accurate information, and that they respect the views of their readers.

In fact, you could make the argument that without reader comments, the quality of content on many design and development blogs would not be as strong as it is today. On my own website, I’ve written so many things that were just downright wrong. In some cases, things can be a matter of opinion and personal preference. But in other cases, they’re just factually incorrect. In indisputable cases, I’ve always tried to post updates to articles and credit the commenters who pointed them out.

Teachers Learn By Teaching

Randy Rhoads, a popular rock guitarist (who died in a plane crash in 1982), was well-known for being a guitar teacher. He once said:

“I’ve been playing about 18 years and I started to get a style when I started teaching.”

In other words, he believed that his success as a guitarist was largely impacted by the fact that he spent time teaching his skill to others. The same can be true for any one of us.

I’ve learned so much from readers’ comments and from doing research on stuff that I plan to publish. I’ve even learned from content I never actually did publish. The Move The Web Forward project, once again, summarizes this point quite nicely:

“Teaching is a great learning tool as well. So, even if you are getting started in an area, you’re helping yourself by writing about it as well.”

GitHub Gets It Right

The collaboration level on many projects from the “social coding” website GitHub is truly amazing, and is something that shows how revolutionary the Web really is.

GitHub's method of social coding is revolutionary

Think about a large project like HTML5 Boilerplate. When that project was first released, many front-end devs were amazed at how much front-end knowledge had been packed into a single starting template. Many were even intimidated by it. But what it is today is nothing compared to what it was when it first launched.

Why? Because from the get-go the contributors to the project had the same attitude that Paul Irish expressed in the launch post of his blog:

“I’m very interested in your contributions… what else deserves to be in this base template?”

With those words, Paul began what might be the most important front-end development project in the Web’s short history. And the collaboration continues today. In fact, there have been over 1000 issues opened and closed on that repo. All because Paul Irish—who has every right to never solicit feedback, because he’s so dang smart—encouraged collaboration.

Blog Posts Should Be Like GitHub Repos

The collaboration on apps like GitHub should be exactly what happens on blog posts. The readers posting comments should read the entire article, and should offer constructive, polite criticism and suggestions, without any unnecessary negativity.

An end to negativity

If the author feels the advice is not accurate or best practice, than he should explain why. If it’s established that the point needs clarification and/or correction, then he should humbly accept this and post an update, crediting the person or persons that brought it up. Personally, I’ve seen too many posts where the author doesn’t make corrections, even when clear technical or factual errors are pointed out.

This doesn’t mean that “majority rules”—that would be ridiculous, and would probably cause more problems than it solves (particularly in matters of opinion, where often there are no hard-and-fast rules).

But if it’s a technical matter, then the author has the responsibility to make updates and keep the information fresh, practical, and relevant. This is especially important if readers are finding the article via search. The “copy-and-paste-but-don’t-read” mentality is common among developers looking for quick solutions. We all face tight budgets and even tighter deadlines, so the last thing we want to do is verify a piece of code’s quality by reading a 900-word accompanying article along with 50+ comments.

If you notice a lot of search traffic coming in for older articles on your website, that might very well be incentive to update those older posts, and ensure you’re not promoting something that you no longer believe is accurate or best practice. And this has a twofold benefit: It will get you even more traffic, and your readers will have accurate information that they can trust.

So let’s do our best to imitate collaborative communities like those found on GitHub and StackOverflow, and continue making progress by correcting our errors. This will help all of us overcome the fears inherent in publishing what we learn.

The “TL;DR” Conclusion

If you don’t read this entire post, or if you take nothing else away from it, then just remember these points:

  • When you learn something, write about it, and don’t do it just to make money off it.
  • Don’t be afraid to make mistakes.
  • Teaching others will help you learn.
  • Encourage collaboration by allowing a free flow of constructive comments.
  • If you make a mistake, fix it.

I think this is a winning strategy for all those who are involved in design or development blogging, as well as tutorial writing.

When we’re willing to put ourselves out there, listen to what our peers have to say, and improve as needed, we will become better developers, and will help each other solve design and development problems in a more effective manner.

As this article suggests, your voice is just as important in this discussion. What do you think? Are you motivated to publish what you learn? Do you think collaboration and constructive feedback is an important part of moving the Web forward? We’d love to hear your thoughts.

Image used on frontpage: opensourceway.

(il) (jvb)

© Louis Lazaris for Smashing Magazine, 2012.

0
Your rating: None