ebidel

6 ms·

1.
by ebidel 8y ago
Yes and no. In some cases (3rd party content that you don't control), there's no way to know what script/iframe is going to do/use. For example, ads script that uses `document.write()` and kills perf. Turning on certain
2.
by ebidel 9y ago
full example of screenshoting a DOM element: https://github.com/GoogleChrome/puppeteer/issues/306#issueco...
3.
Automated testing with Headless Chrome(developers.google.com)
1 points by ebidel 9y ago|0 comments
4.
by ebidel 9y ago
Make sure you're using Chrome 59. If you don't have that yet, try Chrome Canary.
5.
by ebidel 9y ago
It's just a bug :) https://news.ycombinator.com/item?id=14240460
6.
by ebidel 9y ago
As noted, you'll need the --disable-gpu flag for now. Hopefully that will go away around ~Chrome 60. See - https://bugs.chromium.org/p/chromium/issues/detail?id=546953... - https://bugs.chromi
7.
by ebidel 9y ago
FWIW, we created the Github issue tracker b/c it's a bit more approachable for everyone. Github is also a much better place for discussions.
8.
by ebidel 9y ago
Windows support is coming. You can follow along at https://bugs.chromium.org/p/chromium/issues/detail?id=686608
9.
by ebidel 10y ago
If your app uses a huge amount of code, then yes. But that's really the fault of the app developer. Not the library. What developers often do is pull in a ton of components from the web components catalog and not realize that every com
10.
by ebidel 10y ago
Also relevant: "Cache-Aware Server Push (Client Side)" https://docs.google.com/document/d/1HhmyzKUPuWcCs8wG_GLSu3mv... The Chrome team is hashing out potential solutions to the server push <-> brow
11.
by ebidel 10y ago
In using shadow DOM, one thing that's become clear is that it is a developer productivity tool (built in the browser). With React, you have to use inline styles ( https://facebook.github.io/react/tips/inline-st
12.
Shadow DOM v1: self-contained web components(developers.google.com)
2 points by ebidel 10y ago|0 comments
13.
by ebidel 11y ago
Non-comprehensive list of Google properties and Chrome-team efforts using: https://github.com/Polymer/polymer/wiki/Who's-using-Polymer%... Obviously doesn't include stuff in the works :)
14.
by ebidel 11y ago
Polymer itself is 47KB. If you add the web component polyfills (16KB), that's 63KB minified and gzipped. I tend not to consider the polyfills because they're not Polymer and are a stop-gap that goes away over time.
15.
by ebidel 11y ago
Perspective is important :) Putting 1000 material design inputs on a page isn't something a sane web app would do. The same is true for a native app. Re. "bloat" of components. I think it's important to remember everythi
16.
by ebidel 11y ago
MS: https://dev.modern.ie/platform/status/shadowdom/ "we intend to begin development soon" FF: https://bugzilla.mozilla.org/show_bug.cgi?id=1205323
17.
by ebidel 12y ago
Yep, service worker is amazingly powerful! FWIW, Chrome has a bug where SW doesn't intercept URLs changed using history.pushState(). If you're using the web app in Chrome 40, turning off wifi and navigating the site will show &quo
18.
by ebidel 12y ago
It's still behind the web components flag in FF nightly. The master bug for web components is: https://bugzilla.mozilla.org/show_bug.cgi?id=811542
19.
by ebidel 12y ago
Beers! It's 100% bizarre to think about elements that don't render UI. Honestly, I'm still wrapping my head around it. If you think about it though, there are plenty examples today that don't render UI (directly) but ser
20.
by ebidel 12y ago
These are legitimate concerns to have. There are many new technologies at play in this space and a lot of new concepts. > What really remains to be seen is whether this reduces or increases complexity. One word: scoping This is an import
21.
by ebidel 13y ago
Can you explain why it feels heavy? I would love to know more. Polymer's entire stack is a la carte: * platform.js - polyfills if you just want to use vanilla web component apis, today * polymer.js - build declarative custom elements t
22.
by ebidel 13y ago
It's a common misconception that Shadow DOM is required to create a "web component". What it brings to the table is style and dom encapsulation. Not using it means components won't have those benefit (by default), but th
23.
by ebidel 13y ago
Adding powerful new APIs to the web platform benefits more than just Angular, no? The set of evolving standards-based technologies behind "web components" (templates, Shadow DOM, HTMLImports, custom elements) can be utilized by a
24.
by ebidel 13y ago
The Custom Elements[1] and Shadow DOM[2] specifications have little to do with each other. The former is useful for defining new elements in HTML, along with properties and methods. The latter can be used to encapsulate the style/dom o
25.
by ebidel 13y ago
See my post [1] on SO on "Polymer elements (e.g. web components) vs. Angular directives". Essentially, Angular directives allow you to create new elements in HTML. That's done through JavaScript because the proper API primiti
26.
by ebidel 13y ago
Thanks for the heads up. Fixed through the magic of PRs! https://github.com/Polymer/docs/commit/1b9f0c361f84ce0157a13...
27.
by ebidel 13y ago
The foundational layer goes away over time. Everyone's app gets better/stronger/fast :) The opinionated sugaring layer on top of Web Components (the Polymer layer) won't go away. That said, one goal is to have a continuous feedback loop wit
28.
by ebidel 13y ago
Correct. In that example, the value attribute is bound to the element's age property. Basically, anything in {{}}. > <input value="{{firstName}} {{lastName}}"> This will work as you expect ( http://jsbin.com/ecejiy/6/edit ). Plu
29.
by ebidel 13y ago
Dart's Web UI is built on top of Web Components. At least in the case of Polymer and Dart, Web Components are the "framework" :)
30.
by ebidel 13y ago
Data binding happens at the property level. For example, you can remove the id/for attributs from those elements and things still work correctly: http://jsbin.com/ecejiy/2/edit

More ›