Putting the project itself aside (which does seem quite useful), am I the only one who finds it intriguing the fact that Google is not using Google Code to host some of their recent open source projects?
Not really surprising. The goal of this project is to help developers make their web apps faster, not to make google code more popular. What's good for the web in general is good for Google and more important than the popularity of a product that doesn't make them much money anyway (google code).
It would be great if there was a tool to push/pull projects from Google Code to Github that handled not just moving the code but migrating issues and wiki content all the other details that aren't straightforward but could be automated like creating a gh-pages site for the project, migrating downloads, notifying/adding project admins, emailing issue watchers, etc. Even better if Google and Github collaborated so that it could handle redirecting traffic.
That would have suggested dominance of bureaucracy in Google. Guidelines suggesting projects to be put on Google Code, etc. This seems more decentralized.
Usually the justifications these companies give for such mandates is how it would look to outsiders if they are not using their own tools.
On the other hand I remember reading about how Google has a corporate mandate that their employees cannot use Microsoft Windows without providing a business justification.
AFAIK, the requirement is due to security concerns from the China hacks in 2010. The way Sergey Brin put it in 2011, it sounds like employees have the option. On the number of employees using Windows: "I’d probably guess 20 percent ... But I’d have to get back to you."
The HUD does not display/inject properly on our JS web app wunderlist. Wouldn't it make sense that the HUD controls existed outside the scope of the page's DOM? e.g. available in the [wtf] extension popover itself or as context menu items? Or as a dev tools tab?
Have you opened a bug and/or a feature request? I'm sure the team would love to hear that it isn't working for you (since that probably means it isn't working for someone else as well)
Also there is TraceGL which seems to be less about performance tuning and more about debugging and it's not free but looks like a great tool. https://trace.gl/
Very useful! Semi-related question: is there a way to profile the stack within a requestAnimationFrame callback? I seem to remember having access to it in earlier versions of chrome, but now I just see the callback and garbage collection events if present.
I'm so happy that I get to do mostly native apps. Building a good UI is hard enough without having to shoe-horn HTML into doing things it was never intended to do.
Yes, it sure is great that you never have to profile performance, trace call stacks, or find out where your heap is going in native app development.
Did people voting up this comment just not read the linked docs, or do you maybe not have the context to understand what this library does?
It instruments your code so you can get call stack traces with timing information associated. Unless your calls into the DOM are blocking, they aren't going to show up there (that's what the browser dev tools are for). There's a reason that the only HTML element explicitly mentioned in the docs is the canvas element. It even says, explicitly, "Though it's certainly useful to see the ways your application is interacting with the browser and vice versa, often there is much more work occurring within your call trees than not."
This has almost nothing to do with HTML. It's a profiling tool for a garbage-collected scripting language, and it looks more than a little useful.
For native front-ends most of that work has been done for me already though. I can't remember the last time I've had to worry about performance profiling or heap management in a native front-end - and we build iOS, Android and Windows apps that process huge amounts of (medical) data. Hell, I don't even have to make my own animations to have good looking apps because that's all built into the rich native components that I use.
On native platforms - if I stick to standard, well-known, stable components and if I follow good coding practices and recommended techniques - my apps are fast by default. And I'm just gluing things together most of the time. Easy, scrumptious pie! I can save the work of "squeezing every drop of performance out of my code" for back-end processes.
Things just work for the most part - unlike the web where half the sites that try to do something "fancy" like fixed elements just serve to make scrolling slow and clunky - hence the need for this tool.
