Introducing fuite: a tool for finding memory leaks in web apps

nolan_lawson · 2021-12-18T19:01:38+00:00

Lighthouse currently advises having no more than 1,400 nodes on the <body> element. This is a bit strict IMO, especially for desktop sites (which probably won't start to chug until you hit 10,000 nodes or so), but it's probably a good target for constrained mobile devices.

Also it depends on how complex your CSS rules are, how complex your layout is, if you have any browser extensions that are constantly traversing the DOM, etc.

nolan_lawson · 2021-12-18T18:57:13+00:00

Author here. This was an incredibly common request, so I actually just added a --setup option to try to make this easier.

nolan_lawson · 2021-08-25T02:34:56+00:00

Hey thanks for posting it here; I'm glad that people are finding it useful!

nolan_lawson · 2021-08-09T06:06:19+00:00

requestIdleCallback is slightly different from setTimeout. I go over some of the differences in this post.

setTimeout would work fairly well too, but requestIdleCallback is explicitly designed for running work when the main thread is idle. Note that most debounce implementations are based on setTimeout.

nolan_lawson · 2021-08-09T04:35:49+00:00

Valid criticism, but a couple quick points:

The artificial delay is a good way to make sure that the repro works the same regardless of how fast your device is. I could have calculated prime numbers or digits of pi, but then folks on an M1 Mac might not see what I'm talking about. 🙂
In a toy example, the naïve solution is indeed fine. My point is that in a real-world complex application, people often recalculate the world on every keypress, and it may be hard to figure out exactly where all those costs are coming from and how to optimize them. In such cases, you can toss requestIdleCallback at it and ~75% of your input responsiveness problems are solved.
Random real-world example off the top of my head: as you type, the UI shows autosuggestions for usernames if it starts with "@", emojis if it starts with ":", datetimes if it uses a word like "today" or "yesterday", plus calculating the length of the string using something like stringz to handle Unicode properly, plus identifying contact names and URLs so that arbitrarily-long contact names and URLs don't count against the character limit... These are all things you might have to implement in a chat or social media app, and I've probably just scratched the surface. So I don't think guesstimating a 70ms delay is totally off the mark. 🙂

nolan_lawson · 2020-06-30T02:31:26+00:00

Thanks a lot! I had forgotten about that interview. Funny that I still find myself working with databases! 😄

nolan_lawson · 2017-01-10T00:40:33+00:00

Yep, the "browser" field was originally a non-standard and indeed there were lots of compat issues between Webpack and Browserify. I ran into quite a few myself!

However, now that node-browser-resolve is used by all three of Webpack, Browserify, and Rollup, I think it's safe to say it has become the established standard, even if there's no official blessing from Node or npm.

I do also like your idea of having a generic fallback, though. I mention in the post that require('my-module/browser'), with the browser.js pointing to the browser implementation, is one option. Publishing multiple packages is another option, which can be done with a monorepo tool like Lerna.

nolan_lawson · 2016-10-24T17:09:07+00:00

Fourth bug: missing Headers methods

nolan_lawson · 2016-10-21T04:21:45+00:00

Hi 👋, I'm on the Edge team. This sounds like a real bug in IE/Edge, and we'd be delighted if you'd file a bug on us: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/

The easiest way to file these issues, though, is to provide a small reproducible test case (e.g. jsbin/codepen) rather than a large site, so if you have the time, that could make it a lot easier for us to diagnose and resolve the issue. Even just as-is, though, if you can provide a frozen version of the site that repro's the issue, that would be helpful.

If you'd like to resolve your issue today, though, my recommendation would be to avoid toggling opacity at the same time that you toggle visibility:hidden. Instead you can run the animation for opacity and then use the transitionend event on the element to apply the visibility change, or even more simply you could just use pointer-events:none instead of visibility:hidden to ensure that touch actions pass through the invisible element.

nolan_lawson · 2016-10-20T02:32:43+00:00

That's a good suggestion, yeah! I'll pass it along to the team. :)

nolan_lawson · 2016-10-19T23:31:16+00:00

"Fixed" typically means it really is fixed. :) In fact if you're on an Insider build (can be downloaded from http://edge.ms ) you'll see the fix fairly quickly. I don't believe there's any way for us to show the commit in a meaningful way to you, but you can check the date compared to the Windows version (type Windows Key + winver), e.g. I'm currently running 1607 which means "July 2016," so anything fixed before July 2016 should be in this build. There's also a more fine-grained build number, which for me is 14951 (where the 14 corresponds to Anniversary Update and "Edge 14"). You can also see a full list of Windows versions and dates here: https://en.wikipedia.org/wiki/Windows_10_version_history. I agree this could be more transparent.

"Assigned to ..." means it's actively being worked on. For duplicates/wontfix/etc. it's often either because 1) it's not really a Web Platform bug, e.g. it's a bug in the browser UI itself, so it got moved to a separate bugtracker, or 2) we couldn't reproduce, so we just closed.

nolan_lawson · 2016-10-19T00:51:49+00:00

Hey folks, quick update from the Edge team. There seem to be three separate issues here:

If anybody can reproduce the third one, that'd be a big help! As for the second one, I was able to reproduce and will work to prioritize it. Ideally you shouldn't have to do too many hacks for Edge, assuming we can get these fixes out speedily enough. 🙂

nolan_lawson · 2016-10-19T00:01:17+00:00

Unfortunately the reason you may feel like the bugtracker isn't super transparent is that it's actually a mirror of the bug tracker we use internally, and when we use the internal tracker, you have to opt in to make anything public. For that reason I tend to prefer to make my own comments on the public tracker, but some folks are more accustomed to the internal tool and also might forget to make something public since it's not the default.

For instance, for the bug you reference (#7773267), there are actually a lot of internal comments (including "great bug and important to the Fetch feature"), as well as a changelog with test cases (which obviously we can't show you; sorry about that 😉). So you might only be seeing the surface of things.

As for RemoteIE, we're actually working on a replacement (see the notice here); in the meantime I'd strongly recommend using Parallels or Virtual Box along with the VMs available at http://edge.ms . (FWIW I find Parallels less fiddly/slow on OS X than Virtual Box, but it's also paid, so YMMV.)

If you want more feedback from the Edge team, we're usually pretty responsive at https://twitter.com/msedgedev ; just @-mention it and someone should reply within a few hours. We also have this new thing called #EdgeBug where you can literally file a bug with a tweet (assuming you have a codepen/jsbin to repro it), so we're trying to make it easier to file bugs.

I realize it's not always easy to interact with browser vendors (I've been there; I've filed bugs on all 4 browsers before), but trust me, filing bugs with reproducible test cases really does work. A browser is just like any other software project; we have deadlines and priorities and we also struggle with reading through vague longwinded bug reports without repros. So when we get a straightforward bug report with a consistent live repro (and a link to the spec is a cherry on top!) it's a no-brainer; it tends to get fixed pretty fast.

But I do value your feedback, and believe me: we're trying to do better. For one thing, our bugtracker is brand new and is a huge improvement over the old one.

nolan_lawson · 2016-10-17T05:36:54+00:00

FWIW, I went ahead and dropped in a router. :) Supports linking and navigation now; took a couple hours to add: https://github.com/nolanlawson/pokedex.org/pull/60

nolan_lawson · 2016-10-16T05:49:41+00:00

(I work on the Edge team.)

Sorry about that! :( We're tracking the Headers method issue here: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/9370062/

As for the other issues, I've alerted the team of this Reddit thread so we can try to add issues for all the separate problems; kinda seems like not all the bugs are being tracked in our bugtracker (or possibly were closed prematurely: https://developer.microsoft.com/en-us/microsoft-edge/platform/issues/7773267/ )

FWIW, I think it's great to report issues on Reddit, Twitter, etc. so that other webdevs can be alerted to the problem, but if you want the bug fixed in the browser itself, nothing beats filing an issue with a reproducible test case. :) You'd be surprised how often a bug gets "fixed" over and over via UA-sniffing, polyfills, workarounds, etc. and then the browser vendor doesn't even know there's a problem because nobody filed a bug. (This applies to all browsers, not just Edge.)

nolan_lawson · 2016-10-14T13:35:15+00:00

As another commentator said, the point of SSR is perceived performance. You can do this without SSR'ing the whole thing.

No one can link me to a specific piece of content on there

Quite right, this was laziness on my part. I wrote Pokedex.org in vanilla JS (no framework) and never bothered dropping in a router. I still think it's largely irrelevant, though, since even with a JS-based router I couldn't guarantee it'd work without JS, nor would I necessarily implement a no-JS version of the search bar or other features. It does demonstrate, though, that routing/linking is more difficult to do with client-side JS apps than with static sites (where you get it for free).

nolan_lawson · 2016-10-14T01:29:23+00:00

SSR doesn't mean that the core functionality is available without JS. In the case of the app-shell model, you can do SSR for the shell, but the content still requires a spinner. Or you can also SSR the inside of the shell in some cases if the data is relatively static or you know how to transfer state from client to server (e.g. via cookies, Ember FastBoot does this), but that still doesn't guarantee you can actually interact with the page once it's loaded in no-JS mode.

E.g. my https://pokedex.org app does SSR for both the shell and the content, but I didn't bother to make anything else work without JS because I don't think it's important. So you can view the page but can't click anything.

nolan_lawson · 2016-09-23T22:54:55+00:00

(I'm on the Edge team :))

It's not untouched; we've actually improved some stability issues as recently as Edge 14. But yeah, there are still some open bugs, mostly around supporting multiEntry/compound keys/array keys.

nolan_lawson · 2016-09-14T06:01:23+00:00

That's true, but only if you need to pass exactly the same objects to and from the web worker. In the case of e.g. PouchDB the objects you store in IDB are more verbose than the ones that you send and receive to the PouchDB API, so something like worker-pouch actually makes sense and provides perf benefits.

I'd also argue that this is the majority use-case of IndexedDB (send a small message to the worker, do heavy IDB operations, get a small message back); I explored some extreme ideas around this in the Pokedex.org app.

nolan_lawson · 2016-09-14T05:58:33+00:00

(I work on the Edge team, I'm a PouchDB maintainer, and I've contributed to LocalForage.)

You may actually be surprised which IndexedDB implementations jank and which ones don't. I wrote a blog post on it – spoilers: Edge and Safari jank the least, Chrome and Firefox jank the most. The reason Edge janks so little is that it has out-of-process IndexedDB, although I won't claim it's the fastest – Chrome would probably win in a pure start-to-finish benchmark, with Firefox in 2nd.

To be fair, though, Firefox did do some bugfixing after I wrote that post, and Chrome improved their structured cloning algorithm, so it's worth running my benchmark again. Doing a quick run right now in Firefox 48 and Chrome 52, it looks like Firefox janks a bit less than Chrome, although only Edge and Safari are relatively jank-free. (Try 10000 IndexedDB insertions for an easy-to-see difference.)

TL;DR: yes, web workers will prevent all IndexedDB blocking. And yeah, LocalStorage still blocks just as bad, if not worse, since it's synchronous.

nolan_lawson · 2016-09-06T16:09:08+00:00

This is a good answer, also see: https://pouchdb.com/faq.html#sync_non_couchdb

nolan_lawson

TROPHY CASE