> "non-leaking" -- What about this one? What kind of leaks--is it things > that get held on to for way too long, or something else? Can tools help > here? What about education? > > Finding Mozilla leaks is confusing and hard, at least for me. Especially in contrast to a Chrome tool that came up during the last memshrink meeting: http://gent.ilcore.com/2011/08/finding-memory-leaks.html
The two nice things there: 1) seeing a graph over time about the amount of memory used by a website (in this case, our chrome code) 2) being able to snapshot and compare
With this tool, it was easy to see any DOM nodes that were still around but no longer in the DOM.
> "production-quality and readable" -- Is this basically non-bugginess, UX, > polish, that sort of thing? There is a lot of detail work there no matter > what. But I would have to think there are differences between XUL and HTML: > one or the other has got to have more control over appearance or less > semantic corner cases. Which one is really better? > > It's less about the technology, more about writing tests. My personal, uncomfortably honest anecdote ahead.
I've been bitten too many times trying to land some major refactoring like e10s, replacing canvas tiles with cross-process async scrolling, and sidebar panning for Fennec. Inevitably there would be months of fixing regressions and a general gut-wrenching feeling that the code is becoming ungainly with all the workarounds that get glued on top as an afterthought. Fixing some regressions would cause new regressions. I quickly learned a bad lesson: stop trying to rewrite code by making it better, faster, smaller. Just fix the problem with as little change as possible. There are better things to spend my time on, and they'll make me feel a lot happier.
This is because we have poor test coverage. Our "net" that tells us what has changed is full of giant holes, so we step lightly and try not to touch anything we don't understand. And so comes the nugget of wisdom: we need more test coverage!
What I've learned is that we can tell ourselves to write more tests until we're blue in the face. That doesn't mean we will.
I find writing frontend tests to be an exercise in frustration. I feel that the test infrastructure is 1) unreliable (land something, random orange, backout) 2) takes a long time to write and run tests (could be days and days of sending to try because there's some leak on Windows) 3) no proper line between functional and unit tests and 4) just plain no fun.
I'm an imperfect being and I know I should write much more tests than I do. I will continue fighting the urge to just ignore tests and keep telling myself why they are so crucial. I'm trying to be part of the solution, and I've committed a few mochitest patches along the way. What Mozilla could do to help me significantly is to give me great tools, and I highly recommend they ask some of our web developers about their favorite frameworks.
FWIW, I think Jetpack is on the path to salvation. I wish I could use it for browser work.