
I Watched All of the Chrome Dev Summit 2017 Videos - fanf2
https://redfin.engineering/i-watched-all-of-the-chrome-dev-summit-2017-videos-so-you-dont-have-to-9b62a593c3cb
======
microcolonel
> _It’s difficult to convince to most web developers to accept these limits,
> especially if you don’t anticipate selling a lot of products to “emerging
> markets” nations. Hitting Google’s recommended target often requires a
> ground-up rewrite, discarding well-loved JS frameworks._

That's why their target for "emerging markets" devices is _five whole seconds
of JavaScript compilation_ , which would hardly be considered acceptable on a
device five times as expensive, but that device is not five times as fast on a
given core, it's probably something more like one and a half or two, maybe two
and a half if you include faster main memory and caches.

Added: I once worked on an ecommerce site where I told my team early on that
we would probably do worse than we planned if we built and tested on the
latest iPhones and Galaxy devices, and was vindicated basically every week
after a certain point. It was so bad that, on 802.11ac WiFi connected to a
gigabit downlink with about 15ms round trip latency to the servers, the
homepage would take about 10 seconds to display anything at all on an iPhone
6s, and another 8 seconds to finish loading the visible content. Unbelievably,
more than three quarters of that time was spent parsing and compiling
JavaScript. You don't even want to know what happens when you try to open that
site on anything slower than a late 2015 flagship device.

~~~
pryelluw
After hurricane Maria hit Puerto Rico, I had to drive 15 minutes to get mobile
signal. Every website except HN and Gmail (html version) was too slow to load.
This experience has lead me to reconsider my opinions regarding performance.

~~~
katastic
Gmail on my AMD FX-8370 at 4 GHZ with 32GB RAM (and 60 MBit connection)
takes... 5 seconds to load.

Gmail (HTML)... takes 0.5 seconds. (And about the same on my Netbook with a
Celeron)

Guess which one I use? It's like the entire world has forgotten what
productivity is.

~~~
Too
On the other hand, once you are in gmail, everything is literally instant,
opening the next email is faster than many desktop clients. It's designed for
longer use, not drive-by. How long does it take to open a new mail in gmail
lite? Do you have autocomplete on contacts and keyboard shortcuts for
navigation and labeling?

------
kinlan
Organizer of Chrome Dev Summit here.

Please do keep sending feedback and thoughts through on how can keep
improving.

In terms of session length, I can see that being an issue. We had strict union
regulations, and a lot of content to get through and I took the decision for
more but shorter length talks that we can expand with textual content after
the event.

We also tried to keep the theme for day 1 to everything we've learnt in the
last year, so what is the new minimum bar for web experiences, how to load
them quickly and how we've done it in the real world with commerce and media
experiences and wordpress and pwa.

On day 2 I wanted us to showcase where we think the web could be heading in
the next year, specifically with more of a focus on developer experience
(devtools etc, polymer, lit etc)

Not saying we hit all those goals, but I do feel pretty happy with the event
as a whole.

~~~
inglor
Hey, thanks for taking feedback!

As someone who was invited to attend - I really wished the talks were more low
level and technical. I'd really enjoy talks about how things are implemented
in Chrome, how the underlying APIs (for PWAs for example) work and so on.

~~~
kinlan
We are talking about that for next year.

We need to do a better job at audience segmentation because we have ranges
from senior dev to student, and CxO's etc and that's roughly why we stay a tad
higher level with a lot of case studies.

We might end up with different days or different events for the audiences.

~~~
ldd
I wish to voice the opposite view from OP: I love the fact that you stay at a
'higher level'. My primary focus when watching these talks is knowing the
current state of chrome, and some information directly from the source on what
you worked and will be working in the future.

Because of this, I want to say thank you _precisely_ for not giving more
lower-level details in your talks.

~~~
kinlan
:) thank you - it's a balance...

------
spankalee
Regarding lit-html, which I wrote the majority of, lit-html is not a new
framework, but simply a template library. This is called out specifically in
the talk.

> You can wrap lit-HTML in WCs, just like you can wrap React components up as
> WCs, but you gain nothing from it.

This isn't true either. lit-html has no component model, so by using it to
implement WCs, you get a component model.

> it’ll be in direct competition with Polymer, Angular, Svelte, Skate, and
> Stencil

A template library is not in direct competition with Web Component base
classes/frameworks, but can be used by them. It's already integrated with
Skate, will be integrated with Polymer soon, and Stencil is looking into using
it too.

~~~
dfabulich
Author here. I must begin by saying that lit-HTML is really interesting, and I
hope it does well. It will be particularly exciting if Polymer 3 or Polymer 4
or whatever primarily uses lit-HTML out of the box.

> lit-html is not a new framework, but simply a template library.

Nobody wants to be called a framework, do they? For years, React developers
insisted that it was nothing but a "view" layer, because everybody knows that
"frameworks" suck.

> lit-html has no component model, so by using it to implement WCs, you get a
> component model.

I think you mis/underestimate the extent to which you have a component model
already. What you already have is the equivalent of React's "functional
components," where the component is nothing but its render method.

> A template library is not in direct competition with Web Component base
> classes/frameworks, but can be used by them

It's great that WCs let you interop with all WC-based frameworks, but some
folks will avoid lit-HTML in favor of Stencil's JSX approach, or in favor of
Svelte's Vue-alike HTML components, or more generally to decide whether to
_observe_ changes and respond to them or whether to regenerate the UI as a
function of state.

Interop doesn't mean you're not in competition.

~~~
rictic
> I think you mis/underestimate the extent to which you have a component model
> already. What you already have is the equivalent of React's "functional
> components," where the component is nothing but its render method.

When we (Polymer folks) think of a component model, we think of a lifecycle.
Being notified when you boot up, when you're activated, when you're
deactivated, and when the state you care about changes. React has that, Web
Components have that, lit doesn't.

Agreed that there's a lot of baggage on the term `framework`, it's probably a
good idea to taboo the word and break it apart into the pieces that we care
about. IMO that's:

    
    
        - how big is the cost of adding the dependency – mostly this is 
          the size of the library
        - how big is the ecosystem of code that it can play nicely with
        - are there well documented best practices
        - is there a complicated black box of internals that do a bunch 
          of magic, or is it composed of small modular pieces that can 
          be understood in isolation

------
nawitus
"Specifically, they’d like you to use Polymer. The problem is that the Web
Component API is really unpleasant to use directly, especially compared to
React. That’s really holding Polymer back in the framework marketplace. Other
WC-based frameworks like Svelte, Skate, and Stencil abstract away from WCs,
treating them as a compilation target."

That argument feels like a non-sequitur. Polymer's API is different from the
Web Component API, so even if the Web Component API would be unpleasant to use
directly, that is not a criticism of a different API (in this case the Polymer
API). Polymer's API is "similar" to the native Web Component API though, but
it's designed to be easier to use than the native API.

~~~
spankalee
Polymer's API _is_ the Web Components API, with some helpers added for
reacting to property changes, augmenting templating and a few others. Polymer
is simply a base class for your elements that sits between HTMLElement and
your component class.

But I don't really get the "Web Components APIs are unpleasant" line of
criticism. The WC APIs are just the element constructor, connectedCallback,
disconnectedCallback, attributeChangedCallback and what methods and properties
you define on your component. These lifecycle methods are nearly identical to
what you get in React and just about every other framework. If those don't
have unpleasant APIs, Web Components don't.

~~~
dfabulich
Author here. It's not just me saying that Web Components are unpleasant. In
the article, I linked to Sam Saccone of Google saying that the WC developer
experience is significantly worse than React's developer experience.

[https://twitter.com/samccone/status/914528725852663808](https://twitter.com/samccone/status/914528725852663808)

"This of course is coming from someone who has used web components every work
day for the last 2 years. Hard to ignore the DX gap that exists."

To which Alex Russell, also of Google and one of the architects of the WC API,
replies, "Who's ignoring it?"

There are certainly some developers who compare and contrast Polymer and React
and prefer Polymer, but it's fair to say that the vast majority of developers
who have made this comparison have preferred React's developer experience.
Even Polymer's advocates seem to be holding their nose and using it because
they appreciate the long-term promise of Web Components interop.

Why? It's hard to say exactly, but I think it has to do with React's
guarantees that the UI will be a pure function of state. Lots of nifty React
features emerge from that. Polymer components make no such guarantees.

I'm actually pretty enthusiastic about lit-HTML as a way to close the gap.
We'll see how it goes.

~~~
spankalee
Sam's tweet has no specifics, neither does your article, about which APIs are
painful. Care to add any?

~~~
dmitriid
This article: [https://medium.com/@emilrmoeller/grow-with-the-browser-
learn...](https://medium.com/@emilrmoeller/grow-with-the-browser-learn-web-
component-fundamentals-86c2b1c8ac08)

“To do this automatically” is followed by dosens of lines of tedious
bolierplate. And that’s _for a single most common use case of adding a
property, and an attribute that are synced_. It’s then followed by yet more
boilerplate for adding a custom event.

A lot of stuff here: [https://jeremenichelli.io/2017/10/the-web-components-
experie...](https://jeremenichelli.io/2017/10/the-web-components-experience/)

To quote:

To achieve pretty basic mutations on small components, children references and
data manipulation there’s a lot of heavy lifting that really compromises the
developer experience.

And it’s a big deal, since developer experience is one of the reasons why
React or Vue are widely used in production.

Also, web components being included in a magical global store difficults
declarative and deterministic views or any other concept which hangs on a
visual map of dependencies like code splitting.

UNFORTUNATELY THE DEVELOPER EXPERIENCE OF BUILDING AN APPLICATION WITH WEB
COMPONENTS TODAY IS QUITE PAINFUL SAM SACCONE

—- end quote —-

~~~
spankalee
I replied in general below, but I'll take some extra time to respond to the
complaint about getters and setters.

Any JavaScript class that wants to define observable properties has to define
a getter/setter pair.

Manually, this usually looks like this:

    
    
        class C {
          get foo() { return this._foo; }
          set (foo(v) { this._foo = v; this._somethingChanged(); }
        }
    

From the part of the article you reference, you're complaining that Web
Components don't "solve" observable properties. This is because in JavaScript
there are already ways to do this with with getters, setters,
Object.defineProperty, and while that does involve some amount of
"boilerplate" there are helpers for both Web Components and plain classes that
will create these properties for you.

I really don't see why it's a valid criticism of Web Components that they
don't magically solve this problem when it's just the way JavaScript works. Of
course frameworks like Angular solve this problem by generating accessors for
you - _but so does every major Web Components library_. They all include some
way of letting an author declare observable properties and syncing them with
attributes. Given that the end result in DX is exactly the same as with other
frameworks, why the ding on Web Components? Why are Web Components held to a
higher standard and expected to "fix" JavaScript?

To show how absolutely easy this is, and how off-base the DX complain is,
here's how easy a Polymer 2 + TypeScript element is (TypeScript just to use
decorators, which will be standards JS someday...)

    
    
        class MyElement extends Polymer.Element {
          @property({notify: true, reflect: true}) foo: number;
        }
    

That will create an observable property, fire a "foo-changed" event and set
the "foo" attribute when it changes, and listen for the "foo" attribute and
deserialize it to the foo property when the attribute is set.

Even without decorators, this is pretty damn easy to do, and the first thing
any Polymer developer learns:

    
    
        class MyElement extends Polymer.Element {
          properties = {
            foo: {type: Number, notify: true, reflect: true}
          }
        }
    

Other Web Components libraries like Skate and Stencil include their own way of
declaring properties, just like other frameworks like Angular and Ember do.

The second article is also comparing raw Web Components with no helpers to a
framework that's full of helpers. You could just as easily saw JavaScript has
a broken DX if you tried to do React-style components without React. The
higher expectation for Web Components here is kind of ridiculous, to be
honest.

~~~
dmitriid
> Javascript > you complain about objects > don't magically solve > raw WCs vs
> helpers

etc. etc. etc.

And then you wonder why I'm so set against WebComponents. Because you (and Rob
Dodson and other WebComponent proponents) are entirely blind to how bad
WebComponent APIs are. I dunno, maybe your goal isn't to "sell" WebComponents,
but to sell Polymer.

WebComponent API is bad not because "we complain about how Javascript objects
are". We complain because WebComponents API is _horrendously bad_ , and that
was a _deliberate design choice_.

Current line of defence is "oh, it's just low level API" or "oh, it's just how
Javascript is", both of which are at best patently false.

Here's code to create _one single property with one single synced attribute_.
One. single. property/attribute pair. One.

    
    
          set transitionDuration(value) {
            this.setAttribute('transition-duration', value);
          }
          
          get transitionDuration() {
            return this.getAttribute('transition-duration');
          }
          
          static get observedAttributes() {
            return ['transition-duration'];
          }
          
          attributeChangedCallback(name, oldVal, newVal) {
            if (name === 'transition-duration') {
              // do something
            }
          }
    

There is no reality where this is good API design. There is no reality where
"this is how objects work in Javascript" is an excuse.

This is objectivly bad API design. Bad developer experience. However, you and
all other webcomponent proponents completely ignore this fact, and dismiss any
and all complaints out of hand.

Of course you do. You've got Polymer to promote [1]. If WebComponents had
better APIs, there would be no need for Polymer, would there. Because here's
how Polymer solves the problem, despite this being "oh, that's how Javascript
works".

    
    
        static get properties() {
            return {
              transitionDuration: {
                type: Number,
                readOnly: false,
                reflectToAttribute: true,
                observer: 'methodName'
              }
            }
          }
    

Oh. My. God. This is doable without any excuses about how Javascript works?
Really? Who would've thunk it?

[1] Hell, even in your "rebuttal" of criticism towards _WebComponents_ here's
what you write:

> To show how absolutely easy this is, and how off-base the DX complain is,
> here's how easy a _Polymer 2_ \+ TypeScript element is

Were we talking about the bad DX of Polymer? No. You are totally entirely
absolutely blind to the fact though. Because in your mind WebComponents ===
Polymer. And, sadly, for all intents and purposes it's true.

 _edit: removed some erroneously pasted code_

~~~
nawitus
"maybe your goal isn't to "sell" WebComponents, but to sell Polymer."

The goal of Web Components are to sell a interop layer that is supported by
many (or even all) frameworks. It's not supposed to be a framework that has
the best developing experience.

The Polymer API is better than the Web Components API. The Polymer API is more
high level than the Web Components API. This is not by mistake, it's by
design. The higher level the Web Components API is, the more difficult it is
to use by a large number of wildly different frameworks.

"We complain because WebComponents API is horrendously bad, and that was a
deliberate design choice."

I don't think it matters much to be honest, because developers should use
frameworks, just like they are using frameworks at the moment.

"Here's code to create one single property with one single synced attribute.
One. single. property/attribute pair. One."

You need a "synced attribute" only for some frameworks, not all. Also, your
example is misleading, because the two last methods are only needed to be
defined once, so if you want 2 synced properties, the total number of methods
is 6, not 8.

"Bad developer experience."

Use a framework.

"If WebComponents had better APIs, there would be no need for Polymer, would
there."

The risk is too high to use the Polymer API for the Web Componenets API. In
addition, the more complex the API is, the more likely it is for the browsers
not to implement the API. It's better to have a simple native API and provide
different frameworks for a good user experience.

"Because in your mind WebComponents === Polymer."

Or maybe he thinks that frameworks should be used, as intended.

~~~
dmitriid
> The goal of Web Components are to sell a interop layer that is supported by
> many > Or maybe he thinks that frameworks should be used, as intended.

Translation: instead of providing a good DX we're going to sell Polymer

> The Polymer API is more high level than the Web Components API. This is not
> by mistake, it's by design.

Indeed. By crappy design with horrible developer experience

> The higher level the Web Components API is, the more difficult it is to use
> by a large number of wildly different frameworks.

Hmm... How about "let's reduce the need for and dependency on multiple
frameworks"? When will that ever be a goal?

> You need a "synced attribute" only for some frameworks, not all.

Surprise, Polymer's API provides a possibility to define that.

> Also, your example is misleading, because the two last methods are only
> needed to be defined once, so if you want 2 synced properties, the total
> number of methods is 6, not 8.

Oh. Right. 6, not 8. I wonder if I ever complained about the number of methods
required? Nope, what I complained about is _the amount of tedious boilerplate
you need to write to implement the most basic and common of things_.

If I need 1 more synced property/attribute pair, I will need:

\- 1 extra setter

\- 1 extra getter

\- 1 extra item in the attributes list

\- 1 extra if clause in the callback.

>> "Bad developer experience." > Use a framework.

How about: platform provides a well-designed API that doesn't require a
framework for the most basic and common functionality?

As an example:

\- DOM APIs are horrible, and quickly devolve into tedious error-prone
boilerplate

\- jQuery API is amazing

\- Does this mean that DOM APIs _suddenly_ become developer friendly? Does
this mean they are beyond any criticism?

Same with WCs

~~~
nawitus
"Hmm... How about "let's reduce the need for and dependency on multiple
frameworks"? When will that ever be a goal?"

That's not a realistic goal, because there's no common agreement on the
framework API. If there were, every framework would have the same API already.

"Surprise, Polymer's API provides a possibility to define that."

Your point being?

"Oh. Right. 6, not 8. I wonder if I ever complained about the number of
methods required? Nope, what I complained about is the amount of tedious
boilerplate you need to write to implement the most basic and common of
things."

You're not intellectually honest, so I will stop this discussion.

~~~
dmitriid
The moment I call you out twisting my words, you call me intellectually
dishonest. Suit yourself. This entire discussion shows the actual intellectual
dishonesty of people who defend WebComponents.

> Your point being

You, and others are completely entirely blind to the fact that:

\- WebComponent API is horrible DX

\- WebComponent API can be made better _within the platform_ , without the
need to rely on third-party frameworks.

However, if the goal is not to push WebComponents forward, but to sell Polymer
to as many devs as possible, it’s not surprising.

------
daphneokeefe
I attended the event in person, and overall enjoyed it. But I keep wondering:
is the reason Google wants us to squeeze our file sizes and page load time
down to the bare minimum because they want to maximize the bandwidth available
for more and larger ads?

~~~
abalone
No, it's a much larger existential threat. It because they're fighting to keep
the web competitive with native apps. The more that the world shifts from the
web to native apps, the less people use their web search engine.

~~~
colordrops
And yet Google refuses to allow web apps / PWAs on their Play store.

~~~
kinlan
We don't refuse or disallow. We just don't take an arbitrary URL and list it
in the store automatically.

We announced Trusted Web activities
[https://developers.google.com/web/updates/2017/10/using-
twa](https://developers.google.com/web/updates/2017/10/using-twa) which give
you a fullscreen surface for web content in an Android App in the store and
allow you to offer more integration with the Android operating system
(protocol and scheme handling, quick links etc)... I do think this is
interesting, I worked on the Chrome Web Store when it launched and the number
one complaint was that the experiences "were just bookmarks" and I think
Trusted Web activities give us a chance to experiment with deeper web
integrations on the host platform before we are able to standardize it.

~~~
colordrops
Trusted web activity is not the same as a PWA. They are not cross platform.
Why can't PWAs go through a similar getting process to apps to get onto Play?

~~~
kinlan
The process of getting apps onto Play, is to create an Android app... so I'm
not clear on what you mean. Someone will create the tooling that will
automatically create this.

Trusted Web activity is just a general way to launch you PWA fullscreen from
an Android actitivy.

~~~
colordrops
How does that jive with the fact that Play also has books and movies? Those
are not Android apps. There is absolutely no technical reason that Play
couldn't also serve as a discovery and installation (i.e. icon on the desktop)
mechanism for PWA-compliant applications. Users would never know the
difference.

------
inglor
If they'd like us to start building progressive web apps - they should pull-
request webkit with PWA APIs.

Safari doesn't have those because Apple doesn't see them as a priority - but
after talking to Apple engineers who work on Safari it turns out that it's
mostly because it isn't prioritized and not because they don't want the
feature.

It's not _that_ much work either on their end.

If I knew I could get PWA capabilities on an iPhone - I would definitely
consider PWAs for replacing native development entirely.

~~~
kinlan
Service Worker and Manifest are in development in Safari. It's quite a
significant amount of work to land the APIs

It's not as simple as just forcing it in. SW can require deeper integration
with the OS and network stacks that we don't have the ability to change on iOS
or macOS.

~~~
inglor
Thanks for answering. You are correct that they are under development but
they're moving pretty slowly and I got the feeling contribution would be
really appreciated.

For example, `fetch` in service workers - caching and request intercepting
could really improve the "default" iPhone experience in PWAs.

I realize that getting this request is annoying (Build a feature in another
browser) but I really think it could significantly push the web as a whole.

It would also be great to see the Chrome team fix some of the more annoying
bugs in the existing APIs (WebRTC has some really annoying ones).

~~~
kinlan
Re: web rtc .. yes... And getting the screen share API in would be nice too.

Re: helping. I think we have some engineers supporting our predictablity
efforts on WebKit (i.e helping to smooth out edge cases) but I don't think we
are working pushing larger features in...

------
josteink
> It’s the Google Payment API. After replacing Google Checkout with Google
> Wallet, and then replacing that Android Pay, the docs have the audacity to
> call it “The newest way to pay with Google.”

> The Google Payment API only works in Chrome on Android

Why does Google even bother making this?

~~~
ascorbic
Chrome for Android is the most popular browser in the world, so it's certainly
worth bothering, even if it's not a desirable thing for them to be doing.

------
therealmarv
At least Google addresses the problems we have with Internet in
countries/continents like e.g. Afrika or Philippines.

Really... it's a whole different world if you only have 500Kbit/s download
rate and you can see easily who has done their homework good to address
countries with slow internet and who did not. Some websites will get
completely unusable in this areas! And you will find out that Opera Mini is
your new best friend.

Only want to mention one heavy media company which has done a near perfect
job: Instagram. This app is even blazing fast with slow internet. Well done,
really.

------
curt15
Given that Chrome apps are on their way out, a nice demonstration of
Progressive Web Apps would be to make Gmail into one to replace the
functionality of Gmail Offline.

------
seanwilson
Are there any good examples of progressive web apps? I made a web app recently
that had to work offline for use as a visitor display...I looked into service
workers for this (there's a Webpack plugin that helps) but they seemed
complicated plus difficult to debug. It seems like you have to be careful you
don't lock your users out with a service worker bug because now a browser
refresh might not do the same thing for everyone now.

~~~
kinlan
[https://outweb.io/](https://outweb.io/) and [https://pwa-
directory.appspot.com/](https://pwa-directory.appspot.com/) have collections
of progressive web apps. They all have differing levels of offline support
based on their needs.

------
Viper007Bond
> Dan from Automattic came up to say that their closed-source Jetpack plugin
> for WP also offers preliminary PWA support.

Closed source?

[https://github.com/Automattic/jetpack](https://github.com/Automattic/jetpack)

[https://github.com/Automattic/jetpack/pull/7963](https://github.com/Automattic/jetpack/pull/7963)

------
ronaldj
Service Workers creep me out, but maybe I'm in the minority. I don't want web
pages to be able to execute code if I'm not actually on their page. To be
honest, I don't even want most apps to background refresh on my phone.

------
Illniyar
Why should I use service workers to cache urls as opposed to using checksum
urls with cache control (I.e. script.hz15cbsj.js etc...)

Unless my site can actually do something offline, service workers for caching
is just an extra headache

------
swyx
as someone considering if I should adopt service workers or just wait for the
next shiny thing can I just ask - if service workers were on iOS today, would
any of you still have other reasons NOT to adopt it? thank you in advance

------
fiatjaf
If they want PWAs they should stop promoting and encouraging native apps.

~~~
threeaccents
PWAs are not supposed to replace native apps just to augment today's web apps.

