There is a lot of abandon-ware in open source, ..
Too true. And, for JS tools, a development I've been watching with
increasing concern (development fragmentation coupled with
scarce developer resources leading to project starvation).
It is perhaps a necessary learning experience that new JS tools
developers start out writing their own ES parsers.
But when the time comes to building more interesting tools on top
of parsers, there should be some coordination of efforts. There are
valid reasons for writing new parsers, with different feature sets,
but many tools (linters, type systems, tag generators, .., transpilers)
could just as well be written as modules/passes on top of a shared
ES parser and AST traversal libraries. Which would increase the
chances of that frontend being maintained and staying up to date.
Instead, we have half a dozen or so JS-in-JS parsers, with varying
levels of support and spec-conformance, and with varying levels
of isolated tools on top of each. Some tools have mailing lists,
some do not. Those that do have mailing lists tend to go quiet
after a while. Coordination/reuse is a chancy thing here, as is
long-time support.
It isn't just traceur, there is also narcissus, or uglify's parser, or
the ever popular parser generators with partial ES grammar
examples, and the various home-brew parsers. Narcissus,
uglify, and some home-brews have analysis and AST traversal
libraries on top (uglify even has more than one set of each..).
None of these efforts share code, so if you want all the
features, you have to run half a dozen separate JS parsers
and analyzers over your code, which would be ridiculous
if it wasn't so sad.
<frustration>
My current pet peave is with DoctorJS, which I started building
on (instead of my own parser) in the hope of sharing efforts:
the project isn't abandoned at all, but the owners are so overloaded
with other projects that they can't even review/apply patches,
answer questions on the ticket tracker, or install a mailing list
so that tool users could coordinate among themselves.
DoctorJS is derived from jsctags, which was slated to be the
basis for code completion in some online JS editors. Last I
heard, Cloud9 developers are working on a new effort, based
on uglify's parser instead (the decision was based on efficiency,
not on DoctorJS somehow managing to lose the required
functionality without any news on when or if it will be restored).
Cloud9 will perhaps end up re-implementing type inference
functionality that existed in DoctorJS, as well as traversal
functionality that exists in a couple of different uglify libraries,
and linting functionality that exists in JSlint, JShint, Zeus,.. .
At least, by re-inventing everything, they won't fall into the
trap of building on shared infrastructure that falls out of favor
and support. And every hour spent on searching for existing
code to reuse is an hour not spent on writing code.
</frustration>
I've been mulling the idea of creating a js-tools mailing list,
in the hope of getting JS tool developers to talk to each other.
Do readers here think that would have a chance? Or do JS
tool developers prefer to work in isolation?
Claus
http://clausreinke.github.com/
PS. I am somewhat wary of using Google groups for such
a list, given their disastrous spam record for JS-related
lists. Any suggestions about a suitable free host that does
not make moderation a pain?
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
