-
-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Analytics/Stats" Plugin #34
Comments
Here's a sample anonymized program: http://astexplorer.net/#/gist/30fd41385f5854c87df473ee4445c791/5343739e5fe69525bbc2d5ea39ffbbc1ae5b1574 Guess the program?It's underscore. |
Thanks for bringing this up @hzoo. Besides the learning for TC39, it'd also be highly interesting to know for the engine implementors for middle- to long-term planning of performance work. |
Totally, I couldn't put into to words what engines need it for but I guess it's more obvious now 😛, maybe I should learn more about that |
Ok something like tc39/proposal-optional-chaining#17 by @alangpierce sounds like what I was getting at |
On AST grep tools, I just started working on this: https://github.com/azz/ast-grep |
Ref https://twitter.com/left_pad/status/907357756713205761
Didn't give enough context into what "analytics" means so I'l write that here.
As Sebastian wrote, doing analytics similar to how other projects do/did it with things like homebrew, etc might not really work for a few reasons: pushback from the community, having to decide opt-in/opt-out, CI/development builds, per file/per build. So this idea would be opt-in (unless it's useful enough to be opt-out), run per build, and only run when the user turns on this option (or just plugin).
Maybe analytics is the wrong word to use since it reminds us of different things, so I'l say another word for it is just local stats for the syntax that you use.
Maybe it's weird, but I think it would be useful to setup some plugin/infra to be able to have stats of different kinds of patterns/syntax used in a codebase? Basic stuff could just simply be the number of functions in a file/codebase, over time, etc. But that could be changed to look for IIFEs, or other kinds of patterns (like an AST grep).
I'd like to see this kind of thing mostly for new syntax (new proposals) and see the kinds of usage the community has for syntax and how often things are used.
Example
An example to explain it better: we'll take optional chaining. Some possible questions I just randomly came up with (some may be specific to that proposal):
a?.b
(1) ora?.b?.c?.d
(3)a?.b.c?.d
a?.()
new a?.()
?I think some of these will help with feedback to TC39 on the kinds of use cases the community is using it for (maybe including the call/new expressions isn't that important, or could be added later), etc.
I think this would be useful for someone to explore (not sure what it looks like yet, this is just the general idea of doing an AST grep/analysis with new syntax), and also nice for us if someone wanted to share the data/results. We could also run a minifier plugin to rename
variable?.name?.here
toa?.b?.c
Potential Learnings
cc @addyosmani, @bmeurer
The text was updated successfully, but these errors were encountered: