> 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.
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.
In my recent travel to India, I realized that "normal" broadband speed is usually 1Mbps. Almost everything on Internet comes to crawl. Vimeo and GitHub is surprisingly bad. I can't even download the releases of project > 1 GB due to timeouts and errors in Chrome. So I'd to VPN to my US computer, download it to dropbox and then wait for sync in my India machine :).
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?
Connection needs to be stable as well. It usually isn't in developing countries. Yesterday Hacker news was talking about 3+ seconds to load. Today it loads instantly. When the speed varies you just wait for the page to load. Nobody thinks it's JavaScript they assume net is slow.
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. ;- )
I've thought at times about contacting the CEO or the board of the company to let them know that their executive might be screwing them out of tens (if not hundreds) of millions of dollars by being lazy and selfish, but I'm beginning to think that this is just the way it's supposed to be.
Maybe it's for the best that they don't make a smooth end-to-end ecommerce user flow, more money in common folks' pockets in Taiwan and Western Europe, and more money in the pockets of developers.
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.
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) overtime
I’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)
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.
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.
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.
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.
This is an issue with nearly every conference I've been to. Most attendees seem ok with higher level talks, though whenever there is a deeply technical and interesting topic the room is always overflowing.
If there are multiple tracks on the same day, maybe consider a high and low level track?
The only conference I've been to that felt targeted to me was Django Under The Hood, which is billed as very technical talks about the innards of a framework.
(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?
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.
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.
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.
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.
Google 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.
This way you give people a chance to prepare more specific presentations around a specific theme: tooling, components, apps, deployment, distribution, development, what have you.
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.
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.
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.
> 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
> decide whether to observe changes and respond to them or whether to regenerate the UI as a function of state
These things don't conflict with each other though. In Polymer, you usually observe changes to fire off requests and stuff, but the UI is pretty much described as a function of state.
"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.
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.
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.
"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.
“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.
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
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...)
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:
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.
> 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.
IMO, React feels better and more productive in part because it doesn't have/need observables. It's the difference between a UI in "retained mode" and "immediate mode."
> 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".
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.
"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.
> 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?
"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.
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.
Web components are a set of web platform APIs that allow you to create new custom, reusable, encapsulated HTML tags to use in web pages and web apps. Custom components and widgets build on the Web Component standards, will work across modern browsers, and can be used with any JavaScript library or framework that works with HTML.
--- end quote ---
They don't allow any of that, do they? Because, as you so eloquently put, "use a framework". As I'm already using a framework (there are dozens of them out there), what is the selling point of WCs exactly?
My point differs from the opinion of someone else (not sure who you quoted).
" As I'm already using a framework (there are dozens of them out there), what is the selling point of WCs exactly?"
To provide interop between frameworks, so that we don't need to write the same components 10 times for each framework. We can just implmenet it once, and use a native API to use it from any framework.
"Oh, right. "Use Polymer", how can I ever forget."
There are and will be other frameworks which support the Web Components API.
You're disingenuous, so this will be my only response:
In your first example you have code for using raw Web Components, and presumably it's "bad" user experience compared to a framework that generates this code for you. It's not a valid comparison.
Either compare a Web Components library, like Polymer, Skate, or Stencil, that generates this code for you against a framework, or compare raw Web Components against raw JavaScript without a framework. You'll find that making state observable and syncing it across attributes will require even more code than Web Components.
In your second example you're showing a high-level declarative API, that has opinions about property name to attribute name to event name mapping, includes a format for per-property meta-data, options for triggering observer methods, whether or not to sync attributes, and how to deserialize from attributes.
There's no way that level of API and opinion are appropriate for the underlying platform, which has to be responsible first for the capabilities of the system, the low-level hooks, and how the components interoperate with the host and other components. Higher-level libraries can automatically implement the hooks with opinions.
Even in raw JavaScript, it takes boilerplate to make an observable property, and libraries can generate that for you. Why are you holding Web Components to a higher standard than JavaScript?
> Even in raw JavaScript, it takes boilerplate to make an observable property, and libraries can generate that for you. Why are you holding Web Components to a higher standard than JavaScript?
Because WebComponents are not raw Javascript. It’s an API.
There’s nothing stopping you from providing an API with good DX. Except one fact: you are entirely blind to the fact that WebComponent API is bad.
It’s also funny how you call me disingenuous when your line of defence is “DX criticism is invalid because see how easy it is with Polymer”.
If for every single point your answer is “use polymer/helper”, it only means one thing: the API is bad, and you don’t care.
I think ya'll are kinda talking past each other, and you may agree more than it appears.
The DX for raw web components, without any library, is awkward and verbose to handle observing changes well. I think the point of departure is that we (Polymer) see this as a problem that's true of all JS, not just Web Components, and it would be better to solve it for all JS through a mechanism like decorators, which is going through the standards process now and we're big supporters of it.
So, yes, creating getters and setters and observing changes is awkward. Yes we should fix it for web components, but the best place to do that is to fix it is actually at the javascript level, which is in process! :D
This 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 attribute
Adding 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.
What's the download tariff on Polymer vs React (I'll admit, I haven't checked library sizes for polymer since 2014) Do they allow for this 150k initial bundle?
It's pretty small. I'm working on an internal application using Polymer 3.0-rc1 currently, with some basic Paper elements (button, input, icon, spinner, tabs, app-route). The whole app bundle (made with rollup + babel-minify) is ~90k gzipped, ~200k uncompressed.
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?
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.
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.
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.
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?
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.
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.
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.
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.
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.
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.
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.
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.
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).
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...
I'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.
> 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
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.
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.
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.
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.
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.
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
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.