GOPHERSPACE.DE - P H O X Y
gophering on hngopher.com
HN Gopher Feed (2017-10-28) - page 1 of 10
 
___________________________________________________________________
I Watched All of the Chrome Dev Summit 2017 Videos
133 points by fanf2
https://redfin.engineering/i-watched-all-of-the-chrome-dev-summi...
___________________________________________________________________
 
daphneokeefe - 4 hours ago
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?
 
  kinlan - 4 hours ago
  I can categorically say no, that is not the reason. It's to make
  the web experiences better, instant and accessible and available
  to everyone.There needs to be pressure on the entire ad industry
  (including Google's products) to not hurt the users experience
  with crappy and bloaty ads the ruin the hard work product teams
  make to build on the web. I do believe (I am biased as I am on
  the Chrome team) that the Chrome team want to do the right thing
  for the users of the web.
 
    gkya - 4 hours ago
    I guess we need a kind of CE mark for websites.  Some
    standardisation and an approval mechanism for security and
    reliability.  We wouldn't trust our closest friendss with our
    banking accounts but we do use websites without any guarantees
    whatsoever.  Software that is vital to us (banking, health,
    govt stuff) is subject to less regulation than cheese or wine.
 
      briandear - 3 hours ago
      And who do you trust to do such certifications? The US
      government struggled with what was essentially an easy site
      for Obamacare exchanges. State and local governments are
      partying like its 1999 for the most part and the ?big?
      enterprises like Equifax, various large health insurers,
      banks and Yahoo are subject to nearly constant reports of
      vulnerabilities and hacks.Really the only people I might
      trust would be google, but there is a conflict of interest I
      think considering they have a vested interest in enabling
      things like tracking.So who does this ?certification??
      Hopefully not the same people who call for 8 digit passwords
      you have to chance arbitrarily every three months or people
      who?s idea of security comes from circa 1996 Microsoft
      documentation.
 
        gkya - 3 hours ago
        Calm down.  I can trust the academicians in the field.
        Also the world is more than the US.  And I'm fed up with
        having to trust my data with possibly/usually incompetent
        people (and sometimes one really has to, e.g. my schools
        online services).  Trained staff and mandatory third-party
        security tests are a nice place to commence.  It's nice
        that on the internet you can hack together a thing and get
        going, but it's not one's email address the only thing at
        the stakes.  I would like to be able to differentiate
        between the hack and the proper service.  And ATM the only
        thing we have is intuition and the https in the domain.
 
  abalone - 4 hours ago
  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 - 3 hours ago
    And yet Google refuses to allow web apps / PWAs on their Play
    store.
 
      kinlan - 3 hours ago
      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
      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 - 2 hours ago
        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 - 1 hours ago
          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.
 
    dfabulich - 4 hours ago
    I agree. Elsewhere in this thread, @kinlan on the Google
    Developer Relations team says that their goal is "to make the
    web experiences better, instant and accessible and available to
    everyone," and that's true, but Google makes money by making
    the web better. The more people use the web, the more people
    use Google search, and the more valuable Google's ads are.If
    the web is slow or unusable (especially on mobile in India, for
    example), then Google search is useless on mobile in India, so
    nobody will want to buy mobile search ads in India.
 
microcolonel - 5 hours ago
> 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.
 
  kinlan - 4 hours ago
  Did they fix it? Did they care about fixing it?
 
    microcolonel - 4 hours ago
    Nah, it's still trash, and they expanded it to more markets!
    The good-but-not-great software consulting firm they replaced
    us with (lower per-head rate, and they don't question the tech
    lead) sometimes still emails me to try to get ideas about how
    to fix it, but they never bite the bullet. They're thinking of
    doing things which will actually make it even slower and
    fatter.This is what happens when you hire people who are
    foolisher, lazier, or more short-sighted than you, they rot
    your company from the inside out. ;- )
 
      shitRabbits - 7 minutes ago
      This comment depresses me. It just sounds like everyone had
      no experience and just threw their hands up and said fuck it.
 
  Cacti - 38 minutes ago
  Man, thats like the past decade in a nutshell.
 
  pryelluw - 1 hours ago
  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.
 
    eru - 18 minutes ago
    What about the Google front page?(And Wikipedia?)
 
nawitus - 8 hours ago
"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 - 6 hours ago
  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.
 
    dmitriid - 3 hours ago
    > But I don't really get the "Web Components APIs are
    unpleasant" line of criticism. The WC APIs are just ...dozens
    of lines of tedious boilerplate for the most basic things like
    ?create a property, and an attribute, and a custom event?The
    sad thing is that WebComponents proponents are absolutely blind
    to the fact that WebComponents API is complete and utter
    crap.Well, most proponents don?t propose WebComponents. They
    propose Polymer.
 
      spankalee - 1 hours ago
      > create a propertyThis is a criticism of Objects, not Web
      Components, and most framework/component libraries out there
      assists in creating properties that can be observed, from
      Ember to Angular to Polymer. That Web Components don't solve
      a problem that applies to the whole of JavaScript, but Web
      Components libraries do, does not seem like a very serious
      criticism to me.> and an attributeAdding an attribute name to
      `observedAttributes` and listening for the change in
      `attributeChanged` callback is not very onerous, and similar
      to frameworks that have attributes callbacks. How else do you
      propose listening to an attribute? Regardless, and again,
      libraries help do this small bit for you, and combine it with
      a property for a single, declarative property/attribute
      definition.> and a custom event"Defining" a custom event is
      as simple as firing it, and since they're standard DOM
      events, if you find the CustomEvent/dispatchEvent API too
      difficult to use, you could write or use a small helper. I'm
      not totally sure what it would do, since those APIs are so
      simple. And yet again, libraries like Polymer include firing
      events when properties change as a declarative option, to
      make it even simpler.I know you have a major axe to grind
      with Web Components on Twitter. I'm not sure what set you off
      about them, and I know I won't change your mind. I only
      responded for other readers here.
 
    dfabulich - 6 hours ago
    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"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 - 5 hours ago
      Sam's tweet has no specifics, neither does your article,
      about which APIs are painful. Care to add any?
 
        dmitriid - 3 hours ago
        This article: https://medium.com/@emilrmoeller/grow-with-
        the-browser-learn...?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...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 - 1 hours ago
          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.
 
    nawitus - 30 minutes ago
    "Polymer's API _is_ the Web Components API, with some helpers
    added for reacting to property changes, augmenting templating
    and a few others."For that reason I think they're different
    APIs, even though Polymer's API can be considered a superset of
    the Web Components API.
 
spankalee - 6 hours ago
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
StencilA 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 - 6 hours ago
  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
  themIt'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.
 
Viper007Bond - 2 hours ago
> Dan from Automattic came up to say that their closed-source
Jetpack plugin for WP also offers preliminary PWA support.Closed so
urce?https://github.com/Automattic/jetpackhttps://github.com/Automa
ttic/jetpack/pull/7963
 
curt15 - 3 hours ago
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 - 4 hours ago
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 - 4 hours ago
  https://outweb.io/ and https://pwa-directory.appspot.com/ have
  collections of progressive web apps. They all have differing
  levels of offline support based on their needs.
 
fiatjaf - 6 hours ago
If they want PWAs they should stop promoting and encouraging native
apps.
 
josteink - 2 hours ago
> 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 AndroidWhy does Google
even bother making this?
 
inglor - 7 hours ago
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.
 
  _alastair - 6 hours ago
  I have a tiny insight into this, as I've been working on a
  Service Worker implementation for iOS webviews (i.e. in apps, not
  Safari):https://github.com/gdnmobilelab/SWWebViewI'd disagree
  with your assertion that it's not that much work :) Service
  Workers are their own self-contained JavaScript environments with
  complicated lifecycles after all.That said, I've been surprised
  by now much is possible just using public APIs, but I'm not sure
  you could pull request a full OS implementation. For example,
  adding an app to home screen. That's going to need to wire into
  non-WebKit iOS and macOS code, which AFAIK is not open source.
  Workers also sometimes run when the browser is not active, and
  that wouldn't be a trivial thing to add.Also, Apple started
  working on the Service Worker APIs recently. It's not clear
  exactly how much they'll implement, but it's a very positive
  step.
 
  kinlan - 7 hours ago
  Service Worker and Manifest are in development in Safari. It's
  quite a significant amount of work to land the APIsIt'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 - 6 hours ago
    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 - 6 hours ago
      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...
 
kinlan - 7 hours ago
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.
 
  pas - 6 hours ago
  (I've asked this on Reddit too, but maybe others want to chime
  in.)Maybe somewhere in that 10 hour someone talks about it, but
  let me ask about this problem: Google is big, and has many sides,
  fronts, faces and eyes; what is Chrome, where is Chrome in
  relation to all the other web-related, web-facing web-targeted
  things?Where is Chrome, Polymer, Angular, and Android compared to
  each other (and the big Google itself)? Should I wait for Angular
  to adopt the Chrome PWA guidelines? Should I just wait for the
  Android team to stop developing the native APIs and focus on the
  WebView and make the whole Android platform more web-compatible?
  If now, what's Chrome's thoughts on what these other
  teams/projects/products/faces-of-Google are doing?
 
    kinlan - 6 hours ago
    That's a good question that I don't know how to answer
    clearly.We are a big company with many facets and no clear web
    direction owner and also lots of platforms (android, web,
    assistant etc). Generally, it's lots of groups working to reach
    users on the web. Chrome works on what it can work on and tries
    to influence other teams as best it can.Angular team has been
    very supportive of the PWA story, but it wasn't clear in this
    conference for sure.For those not at the event, we had a large
    forum area where we had more Google teams (AMP and Angular) and
    many other browsers have a space to talk to developers.... But
    this wasn't clear by just looking at the videos.I think the big
    thing for me, is we are not going to say don't do Android. We
    should be clearer on why things like Trusted Web activities
    help you deliver web experiences with native though and we can
    keep being clearer about why we think the web is good and how
    best to deploy on it.
 
      pjmlp - 4 hours ago
      Regarding Android, it always feels strange to sometimes watch
      jabs at native development from Web talks at IO, as if
      Android wasn't a Google product.
 
        kinlan - 4 hours ago
        Do you have specific examples? I know we frequently talk
        about the benefits of distribution and reach of the web in
        comparison to other platforms including Android.
 
          pjmlp - 4 hours ago
          Not without watching all talks again.Usually has to do
          with remarks on why to bother with native approaches, how
          PWAs are going to conquer the mobile experience or how
          doing web is so much better than native.For the exact
          wording I would need to go again through the Chrome,
          Polymer, Angular and PWA talks, so just take it with a
          grain of salt.
 
    dfabulich - 6 hours ago
    Author here. This question came up several times at the
    "leadership panel." You can see my notes on questions like
    these in the article, but I encourage you to pull that video up
    and just watch
    it.https://www.youtube.com/watch?v=TU8fy8PHAl0Google accepts
    that they're going to have competing approaches inside the
    company, and this even has significant advantages. We all just
    have to deal with it.
 
  nojvek - 5 hours ago
  I would just say, please don't forget the people who make dev
  summit great. Especially the underrepresented females.There were
  open complaints on Twitter about the dev summit organizers being
  sexist.I won't go into details but multiple female Google
  employees have voiced their opinions regarding this.Don't be that
  guy.
 
    kinlan - 4 hours ago
    I saw your email to the team and I have reply coming shortly
    (if it wasn't sent out already).For context, for everyone on
    the thread. We had a wrap-up video
    (https://www.youtube.com/watch?v=2n69vkYvo9g) of the event that
    didn't have the MC's included and given they were the face of
    the event, it was a mistake that we made and we didn't have
    time to fix and are in the process of rectifying. We also had a
    dedicated video planned just for the MC's but it takes time to
    create and put together.
 
  xenadu02 - 2 hours ago
  > We had strict union regulationsCan you clarify what this
  means?In my experience it means paying for more audio, video, and
  venue staff because the existing folks have been on duty all day
  but the conference organizers don?t want to pay or can?t afford
  to pay for a) more people or b) overtimeI?ve done a bit of mix
  engineering and conference organizers are very myopic: why can?t
  I be as excited about their stuff as they are? They don?t think
  about what happens when this is your day job and if you don?t
  bring the hammer down you?ll end up working unpaid overtime every
  day of every week because every conference thinks they are the
  hottest most exciting shit since sliced bread.One can assume
  Google is able to pay more but made the perfectly reasonable
  business decision not to. The mystery for me is why you?re
  blaming it on the union?Perhaps the venue completely prohibits
  longer days but every rate sheet I?ve ever seen simply quotes
  higher prices if you exceed a ?normal? conference day length.(I?m
  genuinely curious here but also being slightly sensitive: there
  are certainly abusive unions - Philly conference centers come to
  mind where you have to pay master electricians to carry tables
  and chairs into the venue - but it is far more common for people
  to be cheap-asses & blame the unions)
 
    kinlan - 1 hours ago
    I'm not blaming the union if it came out that way it wasn't
    intentional. I had to work around a number of constraints, with
    timings based on regulations as well as rates, budget
    constraints and other factors that came in at the last minute,
    as well as people on our sides own ability to work the long
    hours and I chose to balance of them all and it meant having
    talks at 30 minutes and the breaks based around all these
    factor.... I mean, I am happy with the content and the pace and
    the quality of the work from everyone involved especially the
    event crew.It's just a factor how we chose to run the event and
    the content and that is what I was trying to articulate.
 
      xenadu02 - 36 minutes ago
      That makes sense; as I said there are perfectly valid
      business (or other) reasons to limit the length of each
      day.FWTW: I don?t see a problem with shorter sessions.
 
  inglor - 7 hours ago
  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.
 
    dalmaer - 40 minutes ago
    A good place to see those talks is
    BlinkOn:https://www.youtube.com/user/blinkontalks
 
    kinlan - 6 hours ago
    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 - 2 hours ago
      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 - 1 hours ago
        :) thank you - it's a balance...
 
therealmarv - 3 hours ago
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.