HN user
I've updated the article to emphasize that this is indeed something we're experimenting with, and explain a bit more how built-in modules go through the standards process (in general and in Chrome).
Article author here,
I probably should have been clearer in the article. I was trying to strike a balance between:
- presenting what I believe to be a compelling and exciting possible future for the web (especially considering it has a viable polyfill story) - getting developers excited about this future and thinking about how it could integrate with existing tooling
and:
- Asking for feedback on the KV Storage and Import Maps APIs themselves. - Encouraging developer to experiment and/or sign up for the origin trial
It's not an easy balance to strike, and in this case I probably should have emphasized more that this is still in the experimentation phase.
I can update the article to make that more clear.
This is not different from existing web APIs, which are also not versioned.
There are links to all the standards work in the article. All of the APIs mentioned are going through the standards process.
It's likely not "blocked" by analytics since pretty much all analytics libraries get loaded async.
However, scripts loaded before the `load` event do delay the load event, and analytics script are typically loaded with the lowest priority, so they're usually last and thus the ones you notice in the bottom-left corner of your window.
But the only way they'd be "blocking" anything is if the site was waiting for the load event to initialize any critical functionality (which it shouldn't be).
That 56K number isn't gzipped, gzipped it's only 18K (plus there's also some inline JS, some webpack boilerplate, and then analytics.js).
The reason for its size is my site is my playground. It's where I get to experiment with all the things I want to experiment with.
I also work on quite a few open source projects, which I usually test on my site before releasing them publicly just to make sure they work in production without errors.
Right, when I said "what's taking so long to run?", in my mind I was thinking there'd be one obviously slow thing that I could just remove or refactor, but it turned out that it wasn't any one single slow function/API causing the problem.
And yes, clearly removing the analytics code would have also solved the problem for me, and in many cases, removing code is the best solution.
In this particular case I couldn't remove any code because I was refactoring an open source library that a lot of people use. I wanted to try to make it better for input responsiveness in general, so people who use the library (and maybe don't know much about performance) will benefit for free.
Also, I wanted to help educate people about how tasks run on the browser's main thread, and how certain coding styles can lead to higher than expected input latency.
Anyway, glad you enjoyed the post!
Article author here. Yep, not hiding that fact (I could have easily used a trace with minified code, but I didn't to point this out).
Two things though:
1. I used to work on Google Analytics, and I've created a lot of open source libraries around Google Analytics, which I use on my own site because I like to test my own libraries (and feel any pain they may be causing). The way most people use Google Analytics does not block for nearly this long.
2. I've updated my Google Analytics libraries to take advantage of this strategy [1], and I'm working with some of my old teams internally to see if they can bake it in to GA's core analytics.js library, because I strongly believe that analytics code should never degrade the user experience.
Article author here. Most of the comments so far are talking about using lots of tabs, but what I think is actually the most interesting part (or parts) of the article hasn't been mentioned at all.
As I was doing my research for the article, I found a lot of things that really surprised me. And I feel pretty confident in saying that most web developers aren't aware of these things either.
Here are my top four:
- We shouldn't use the unload event. Ever.
- The unload event often doesn't fire when closing tabs/app on mobile
- The pagehide/pageshow events even exist (virtually no one I've talked to knows what they do; most people think they're about page visibility).
- In browsers that implement a page navigation cache, you can click a link to navigate away and then navigate back with the back button, and all your JS code is exactly as it was before you navigated.
To this last point. Try doing this in the console:
1. Write a promise that resolves in a setTimeout after 5 seconds.
2. After 1 second, click a link to navigate to a new page.
3. Stay on that page for an hour.
4. Click that back button.
5. Your promise will resolve in 4 seconds!
This isn't true. The proposal was discussed many times in the WebPerf working group and went through a TAG review before shipping.
Microsoft made a public statement of support for the API, and Firefox engineers were actively involved in many of the design and implementation discussions.
You can read more details in the Intent to Ship thread here: https://groups.google.com/a/chromium.org/d/msg/Blink-dev/Na7...
I didn't know about that. I'll look into it!
You're right about it not working for webpack dev server, and I agree that it's unfortunate, but I think webpack will evolve to accommodate this.
[EDIT: it looks like this is already supported, here's the documentation explaining how to do it: https://webpack.js.org/configuration/configuration-types/#ex...]
Service Worker already introduced the need (or you could argue possibility) to have multiple configs since SW code has a much different transpiling baseline compared to legacy browser code. And module code just adds one more level to this.
I think webpack dev server will update if this practice becomes popular, but for the moment I think your idea of only building the es2015 build in dev mode is probably the best temporary solution (as long as you make sure to run your test suite in multiple environments and include the legacy build there).
*she
There is a way.
Every autotrack plugin that sends hits has two configuration options that enable full customization over exactly what fields get sent with each hit.
The options are `fieldsObj` and `hitFilter`: https://github.com/googleanalytics/autotrack/blob/master/doc...
The library is designed to be loaded async, so it shouldn't affect load performance. And it uses new APIs (e.g. IntersectionObserver) and techniques like throttle/debounce for all of its event tracking, so it will likely have no noticeable impact on runtime performance.
As dudus mentions: the GA article posted yesterday includes a recommendation to use this library.
As for a comparison of it vs. the GTM setup used by thenextweb, I briefly explain my thoughts on GTM in another comment here: https://news.ycombinator.com/item?id=13648771
There are tons of things GTM can't do currently, unless you're willing to write custom code. And if you're writing custom code, I'd personally prefer that code to be in my app, under version control, and running through my test suite rather than in a GUI that can be modified by anyone with GTM access.
Here are a few examples off the top of my head of things you can't do with GTM today (without writing custom code):
- Tracking when (and how long) the page was in the visible vs hidden state.
- Tracking anything performance-related.
- Tracking when DOM elements are visible in the viewport (via IntersectionObserver).
- Tracking the active media query / breakpoint.
- Tracking social widget button usage.
- Tracking the use of service worker
- Tracking interactions with native web push notifications.
I think GTM is great for marketing websites, but for better understanding how someone is using a complex web app, I think it makes more sense to have that logic in the application code.
The maxScrollTracker documentation warns against using it with an infinite scroll type of page: https://github.com/googleanalytics/autotrack/blob/master/doc...
As for under reporting of history state changes, have you reported a bug? Also, how are measuring to confirm that there is under reporting?
analytics.js falls back to the older methods in unsupporting browsers.
No, that is an accurate impression. The ultimate goal of Houdini is to give developers the tools to innovate; unlike the current situation were all innovation happens at the spec level, and devs have to wait (often years) for browser adoption.
I guess that depends on how you define debate. I'm referring to that the proposal is made and some people show their distaste for part of what is proposed. Those that made the proposal respond. I see no resistance to the feature being introduced in that, just disagreement on a part of the proposal.
Just to be clear, neither I nor Addy Osmani proposed CSS Custom Properties. We're just excited about the feature and sharing it with others. So when people respond negatively to us, it doesn't feel like debating.
The time for debating was when it was being discussed in the working group; before it was implemented in three different browsers.
Polymer partially polyfills CSS Custom Properties: https://www.polymer-project.org/1.0/docs/devguide/styling.ht...
Also, for what it's worth, not all new JavaScript features are polyfill-able. Proxies, for example, are impossible to polyfill, should they not have been added? WeakMaps are also only partially polyfill-able, are they overdesigned too?
I don't see a lot of "debating" going on. If you want to point me to some constructive debates, that would be nice.
Indeed! That's why I wrote the article :)
No, the point of this tool is that some browsers require a polyfill, and some don't because the feature is natively supported. A transpiler like Babel cannot possibly determine that, so it has to be safe and include polyfills for all features used in the code it's transpiling, reglardless of whether or not the browser you're using already supports the feature.
A good example of this is Promises, which are supported in many modern browsers, but not all.
The tweet starts out: "Google: 90% of our engineers...", which implies that this is information Google told him.
My main complaint with the tweet is that it's almost certainly speculation.
1) Most companies (for legal reasons) don't tell candidates why they weren't offered a job. Maybe it was because of the binary tree question, but maybe it was for some other reason.
2) Homebrew is a Mac-only product, so the likelihood that 90% of Googlers use homebrew is very low. Moreover, Google does not track the software its employees download onto their laptops, so there's no way they would even know the percentage.
When you use gutters sometimes the math doesn't work out quite right. http://codepen.io/anon/pen/xGEMYY
Solved by Flexbox creator here. I wanted to add that if you're using flexbox today, you should also check out this other repo of mine:
https://github.com/philipwalton/flexbugs
A community-curated list of flexbox issues and cross-browser workarounds for them.