slightlyoff

Do you see them requiring only one browser engine on all of the Android devices they sell? No.

The requirements of carriers are orthogonal to browser choice post-sale.

An update on devices, networks, browsers, and the new baseline scenario for web performance.

`.entries()` returns an iterator one can use directly in for-of loops:

https://developer.mozilla.org/en-US/docs/Web/API/NodeList/en...

Hey, author of the patch here.

The restrictions are wire size. `bootstrap.min.js` is ~10KiB on the wire, which means it comfortably fits (as do jQuery, most analytics packages, etc.).

That said, the prototype does break a lot of the web, but that's not a crisis. The intent isn't to have this rolled out everywhere against unwitting content, but rather (like TLS), to let developers opt-in to a single set of rules when they see value. There are also places (e.g. PWAs) where the browser-imposed quality bar needs to be high. Blocking PWA install for sites that don't send the opt-in header seems like a reasonable place to start.

Hi, author of the NSM patch. Still very much under development, but most of the important considerations aren't technical, and making progress on a system like this is more about how to roll things out rather than implementation.

It's great to seeing WebKit folks thinking along the same lines, and I hope to be able to discuss with them. Coalitions -- like the Mozilla/Chrome work on TLS adoption -- are critical in making progress in large ecosystems.

Author of the patch here. Note that the limits are wire size, not disk size. jQuery, post gzip, is closer to ~30KiB, meaning it fits nicely under the per-file restriction. The total JS limit per-interaction is 500KiB gzipped. Uncompressed, that's often more than 3MiB. That's a whole lotta code!

The per-image limit is currently set at 1MiB (not 200KiB).

Hope that helps.

The entire post is premised on frustration in my ability to share what I know in order to avoid punching down. That I can't share specifics is the whole reasonto try another tack.

See also: https://wpostats.com

Author of the article here; you'd be truly shocked.

JavaScript can be evaluated top-level function by top-level function and file-by-file, modulo variable hoisting. You can create situations where everything is blocked, but that's not the norm.

WASM streaming compilation is possible today and runtimes are adding tiered compilers: https://v8project.blogspot.com/2018/08/liftoff.html

Regardless, as long as you're network-bound in the critical-path, that will only help to the extent that partial execution works well. That is baked into HTML/CSS/JS; not so much with WASM.

Images aren't as expensive as critical-path code as we (the browser) parse and raster them off-thread. Outlined some of the costs here: https://infrequently.org/2017/10/can-you-afford-it-real-worl...

Excited to see how much smaller a good linker can make this.

The "hello world" demo app appears to require ~1.3MB of transfer, nearly all of it critical-path: https://blazor-demo.github.io/

This future isn't better.

Howdy; author of the article here.

TTI would be pushed back regardless of where the script was included so long as it executed for more than 50ms (very likely). I used a trivial document that contains many pathologies I see in traces to illustrate the point, not to suggest what ideal apps will do.

The abuse considerations were what led us to implement the engagement check. An API for this would absolutely be spammy.

If everyone is going to be calling it on every page-load, and if the browser is (predictably) not going to allow that to show every time (see window.open()), then why provide an API when we could just treat meeting the criteria we'd look for anyway as the same thing as calling such an API?

That's what the Chrome system does: you've implicitly called "addToHomescreen()" on every page load where your app meets the criteria. When we allow it to show is still mediated by the browser.

Chrome 44 is going to allow a measure of control: http://updates.html5rocks.com/2015/03/increasing-engagement-...

The event is cancelable, meaning that if you don't want it to show on a particular page, it'll trigger again on the next. We'll also be adding a way for you to delay the load; cancel and re-trigger inside the same page. The way to think about it is that you sometimes get a golden ticket. We'll give you the ability to spend it when you want in the near future, but making you do an API call when the intent is already clear just seemed like bad design.

Chrome for Android had the same buried "add to homescreen" thing for a long time: https://developer.chrome.com/multidevice/android/installtoho...

Chrome for Windows has had "Create Application Shortcut" for roughly forever: https://support.google.com/chrome/answer/95710?hl=en

Neither indicated that a site would work well in that mode. That's a big part of the change: detection that a site meets the quality criteria + prompting.

Those features have all launched; see: http://blog.chromium.org/2015/03/chrome-42-beta-push-notific...

I realize that I'm an outlier but I support prefixing as a possible solution to this sort of thing; but that's even more out of favor with the CSS WG than what's being proposed (AFAICT).

Looking forward to timely www-style feedback, it's much appreciated.

That's moving the goalposts. The full context of your statement was:

> it'll be other vendors' pain as they have to reverse engineer Blink's implementation

Which was the salient point I was replying to. Quoting out of context to imply I made statements I did not is...disheartening.

Meaningful progress is progress for the most people. To achieve that, it's often most effective to create coalitions to help you achieve that progress in areas you yourself cannot. This is where collaboration and standards come in.

What's going on now is a request for collaboration. It has been somewhat de-railed, but I have hope. Barring consensus, we feel the risks are outweighed by the gains for developers in having changed things in the bit of the world our codebase addresses.

Perhaps you weren't looking for a real answer, but there's one anyway.

Hi Jacob,

I sympathize with the hesitation that you must feel regarding a request to analyze a feature on a short timeframe, it is however the case that MSFT has in the recent past (Pointer Events, which are GREAT) used its prerogative to ship features ahead of standardization. That contrasts with the current scenario in which agreement by the WG on the names of the APIs _would in fact change our course_.

I noted the timeline as I understand it here: https://news.ycombinator.com/item?id=7187024

The web platform is behind. It's regrettable that we are, but that's the current situation. If you'd like to help, I encourage you to help weigh alternative in the www-style thread.

Engagement on the content and not the process would go a long way at this moment.

The details of both the semantics and syntax in question have been widely discussed and understood. It's pure hyperbole to appeal to "reverse engineer Blink's implementation" (which, as you might be aware, is Open Source).

Here's a refresher for those who missed it: https://docs.google.com/a/chromium.org/document/d/1cxW4MtsDb...

Progress delayed is progress denied. If you want a better web platform, that means wanting one that is different than the one we have today. It is also the case that standards committees are not outfitted with effective fitness functions (the ability to predict market success, e.g.). The best we can do is to iterate and be data-driven. I do not know what "correctly" means in this context, and I submit that you don't either. What we _are_ doing is making the progress we can with the best available data we can gather (polyfilling via Polymer, building large-scale apps, observing existing libraries and their challenges, etc.). It's fine to critique the method, but bring data.

If you have specific concerns regarding their utility or design of these specs, I'm hopeful they can be aired as we continue to iterate. Shipping is not the end; it's a new beginning.

A previous solution based on explicit naming of "parts" of shadow DOMs was withdrawn several months ago. And update was given the the CSS WG last November that outlined the changes. FWIW, the "::part()" solution would have _worked_. It's entirely feasible that we could have improved the world by providing Shadow DOM with that as the primary styling mechanism. Not ideal, though. So we have been willing to change course in response to feedback.

Here's the Blink bug: https://code.google.com/p/chromium/issues/detail?id=309504

All of this happened in the open, in consultation with other vendors (not necessarily at WG meetings, which aren't where you design features anyway).

Remember the context here: Googlers have been doing the heavy lifting on this front for _years_. It's exciting that others are starting to pay attention to the problem space. That they don't think providing Shadow DOM to users is as urgent as we do is their right. We, however, are willing to take some pain in this (relatively small) instance, should they not be willing to help us work through the naming issue in short-order (which, as you can see from the thread, is the actual request; our goal is to improve things through web developers, preferably via collaboration.

Just to be clear, Googlers (myself included) have been constantly participating in the standards process both pre-and-post fork. There's nothing "brand new day" here; conscientious standards engagement is just how we roll here on the Blink team.

Regarding charges of this being "rushed", note that it has been clear for 3+ years (since we started talking about these features publicly and engaging in the standards process for them) that we needed a way to style shadow DOM that enabled author and component-author styles to co-exist and be selectively populated into the eventual tree. This isn't new, nor has it been "rushed". Many iterations of the design have lead to this point.

How many more years of bottle-aging & iteration do you suggest? On what basis?

...and 10 = (

Luckily, those IE 9 users are less of an issue if IE 11 includes WebGL as they tend to be auto-upgraded. The IE 8 users are a harder case.

Chrome Frame won't be available for consumers to install any more. Chromium Embedded is a separate project and they can maintain whatever patches they need to make things fly, methinks.

This misunderstands what happens inside implementations. There ARE low-level bits "down there", but they aren't spec'd. That what the Navigation Controller is: a spec for the low-level bits.

As a part of that process (and Web Components before it), the goal isn't to throw out what has come before (we don't get that luxury out here on successful, non-proprietary platforms), but to re-cast it in the light of a lower-level thing that explains it.

You can go the other way too. Noodle on this to get a sense for it: how much of the <audio> element can be implemented with some JS and the Web Audio spec? Since those connections make sense, why isn't <audio> spec'd in terms of Web Audio, such that you can plug in/out the bits you need when you need something slightly different?

Yeah, you are misinterpreting. See my other comment.

Hi Matthew,

So, first, it's not the mark of failure for their to only be a high or low-level version of some capability in the platform; at least not immediately. The issue arises when, having exposed one or the other, we [users|vendors|spec-authors] think the job is done.

It's like saying you've got a map of a continent having mapped either the outer shoreline or the inland lakes. It's a nonsensical thought, but it's where we tend to leave things today.

Your brought up AppCache -- which, as it happens, is a topic near and dear to my heart as I'm currently trying to engineer its low-level explanation: https://github.com/slightlyoff/NavigationController.

AppCache had relatively well-known, overwhelming deficiencies early in life...yet instead of attempting to peel the onion and explain the layers below the manifest format, the spec process rewarded piling into the clown-car of declarative configuration. It's the natural thing to do, after all.

What we're after here is _connecting_ the high and low levels. Creating a fully descriptive map that has texture, color, and major features marked and named.

We must always start somewhere, but we must also be anxious to know and describe what we can sense but can't yet explain. And that requires a sense of urgent investigation.

And THAT is what is missing today.

Regards

Object.create() creates no closure. You've already paid for in the context in which you're .create()-ing. In any case, performance optimization is what happens when something becomes common enough to work its way into benchmarks. And calling out a delta now that's probably not your bottleneck seems...um...less than useful.