View ember-serviceworker.md

Ember.js currently doesn't have baked in support for Service Worker. They want this and there's an ember-cli RFCS thread discussing strategies however a number of tooling efforts exist to help fill in this gap today.

Note: you can of course just write vanilla Service Worker code for your Ember.js apps and that will work just fine. This doc tracks tooling and libraries that lower the friction for getting this setup

Service Worker Libraries

These static resource precaching and runtime caching libraries are lower-level than Broccoli, but can be used directly

View pwas.md

React HN (Universal rendering, Offline caching, optimisations)

React + Webpack application using the PRPL pattern

View draft.md

Inspiration: https://twitter.com/samccone/status/722826060161617923

Modern JavaScript engines support an increasing intersection of ES2015 (and above) features which simply don't require transpilation in order to be successfully parsed and executed. This project lays out a proposal for a lightweight Autoprefixer-style tool that takes as input a target set of browsers (A) which check against a source of data for supported ES features (Kangax ES6 tables (B) (see https://github.com/kangax/compat-table/blob/gh-pages/data-es6.js) and generate a mapping to Babel transforms for features requiring transpilation that are not supported (C) or not fully supported (e.g behind flags or staged but not flipped on to default).

To avoid the introduction of even more configuration files, this tool could piggyback off of some config we could

View throttling.sh
#!/bin/bash
# if you do not have access to run the script, run "chmod 755 throttling"
# to run enter in terminal "./throttling [speed]"
# full (no throttling)
# fast (3000Kbit)
# medium (100Kbit)
# slow (10Kbit)
# wwdc (1Kbit)
# off (blocks connection)
View 12-days.js
// adapted from https://tonicdev.com/n3dst4/twelve-days-of-emoji
// full credit to n3dst4. I just rewrote this to be browser developer tools friendly.
const pressies = [
"🐦🍐🌳",
"🐒🐦",
"πŸ‡«πŸ‡·πŸ”",
"πŸ“žπŸ¦",
"πŸ’›πŸ’",
"🐦🍳 ",
"🐦🏊",
View app.yaml
application: your-app-name
version: 1
runtime: python27
api_version: 1
threadsafe: true
default_expiration: "30d"
handlers:
# web files
View state.md

tl;dr: no / it's quite hard :'(

Afaik, it's incredibly difficult to restore a highly multi-threaded system to a set state in time - doing so is non-trivial, but also comes with a heavy cost as quite a few different systems need to be in a relatively stable/safe state so you know what to save. For V8, saving state doesn't guarantee that it's possible to gather all of the information necessary to get you back to where you were in a random point in time given the various execution contexts your code is likely running in. You also need to factor in somehow serializing the different contexts in which your closures and other constructs exist in which is again not straight-forward.

For example, we might not be able to traverse the heap at that point, there may be threads that are still locked, not fully-initialized objects and so on. So at best you would be capturing an incomplete state of the world which may not scale when trying to restore the state of something quite complex. If it were possible to save state,

View suggest.md

All platforms where Chrome ships now support suggesting answers directly inside the Omnibox (Chrome's address bar). We currently suggest answers across a few different categories including weather, finance and general knowledge (people/places/auto).

Some examples of queries to test out the feature:

  • weather
  • weather tokyo
  • how old is obama?
  • how tall is chewbacca?
  • what's the capital of spain?
  • population of china
View polymer-perf-bookmarklet.js
javascript:(function(){(function printStats(){var loadTimes=window.chrome.loadTimes();firstPaint=loadTimes.firstPaintTime*1000;firstPaintTime=firstPaint-(loadTimes.startLoadTime*1000);console.info('First paint took',firstPaintTime,'ms');console.info('Load took',performance.timing.loadEventStart-performance.timing.navigationStart,'ms');var instances=0;if(parseFloat(Polymer.version)<1){instances=[].slice.call(document.querySelectorAll('html /deep/ *')).filter(function(el){return el.localName.indexOf('-')!=-1||el.getAttribute('is');}).length;}else{instances=Polymer.telemetry.instanceCount;}console.info('Custom element instances:',instances);var reflectCount=0;if(Polymer.telemetry){console.info('=== Properties set to reflectToAttribute ===');Polymer.telemetry.registrations.forEach(function(el){for(var prop in el.properties){if(el.properties[prop].reflectToAttribute){console.log(el.is+'.'+prop);reflectCount++;}}});}else{console.info('=== Properties set to reflect ===');Polymer.elements.forEach(function(el){for(var
View monday.md

Morning team!,

Hope y'all had a fantastic weekend. As requested, here's a strawman for some things we could focus on this week:

  • Wishlist for 1.1 - what do our users (and us) want to see in there? We're looking for specific features, components, docs you think we should tackle & balance with what our us. For anything we want to target, let's open an issue and consider for the 1.1 milestone unless one already exists.
  • 1.1 milestone prioritisation. We can do this later in the week.
  • Review / continue landing 1.1 PRs - feel free to grab-bag existing 1.1 PRs and continue to review/land for 1.1. If there's anything contentious, we can talk about it.
  • 1.0.4 blog post & regression fixes (if any) - we'll get the post out today. So far it's looking like .4 is stable, but let's watch the tracker
  • 1.1 target date. Sergio and I are currently thinking October 15th may be a realistic goal. A good chunk of September will be eaten up by Polymer Summit, talks, codelabs & Google perf reviews. SG?
  • Identify site fixes