- React: https://github.com/insin/react-hn (PWA)
- VueJS 2.0: https://github.com/vuejs/vue-hackernews-2.0 (PWA)
- Angular 2.0: https://github.com/housseindjirdeh/angular2-hn (PWA)
- Ember: https://github.com/chancancode/hn-reader
- Preact: https://github.com/addyosmani/preact-hn (PWA)
- Inferno: https://github.com/infernojs/inferno-hn
- Type chrome://flags into your browser
- Scroll down to “Enable Developer Tools experiments” and click enable
- Restart Chrome
- Open up DevTools
- Click on the gear icon — it’s typically on the top right or bottom right
- Select experiments from the menu on the left
- Hit shift 6 times to show hidden experiments
- Enable 'V8 Runtime Call Stats on Timeline'
We are hoping to turn this feature on by default soon so the above steps are not needed.
- Yoav: This can particularly be an issue on mobile. Same files getting parsed all the time for users. Theoretically if we moved the parsing work to the server-side, we would have to worry about it less.
- We've been talking about this topic over the last few weeks a bit with V8. There were three main options proposed.
- Similar to what optimize-js does. Identify IIFEs and mark them as such so the browser and VMs heuristics will catch them and do a better job than today. optimize-js only tackles IIFE bu
|Flexbox CSS helpers from the Polymer team. Extracted from https://github.com/PolymerElements/iron-flex-layout for use as just CSS.|
|Copyright (c) 2017 The Polymer Project Authors. All rights reserved.|
|This code may only be used under the BSD style license found at http://polymer.github.io/LICENSE.txt|
|The complete set of authors may be found at http://polymer.github.io/AUTHORS.txt|
|The complete set of contributors may be found at http://polymer.github.io/CONTRIBUTORS.txt|
RAIL encouraged loading a site in under 1000ms on cable and (not well documented) between 3000ms and 5000ms on 3G. This loosely correlates to Google's research that 53% of mobile users will abandon a site if it doesn't load in 3s. So 5s is the headroom we give you for loading and becoming interactive so a user can realistically tap on a part of your user interface and have something useful happen. Loading is more nuanced than we as web developers once thought however.
It's is a pretty broad term and we don'the think it's enough for the page to "look" done. It should be engagable.
This is a little backwards, especially when apps are used under real-world network (3G) and device
Problem: "Is there a nice pattern for using Critical via Gulp for CSS across a site with many pages which might be subtly different?"
The way I've tackled this in the past is breaking down the pages that might be slightly different into groups which each have their
own Gulp task. For the sake of simplicity, we could have a set of pages that fall under
blue-theme etc. For each group,
critical.generate() against the set of URLs for the group (so,
red-theme URLs) and allow it to inline the CSS for just that group.
The benefit of thinking about this problem in a group for each task is if you need to apply additional customisations, config or build-time
fixes per variation of page/theme, it's pretty trivial to do so. You then just run all of the critical group tasks near the end of your
build and this should work.
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