JS tools (was: Harmony transpilers)
From: "Claus Reinke" <claus.reinke at talk21.com> Subject: JS tools (was: Harmony transpilers) Date: October 11, 2011 21:53:58 GMT+02:00 To: "Brendan Eich" <brendan at mozilla.com> Cc: es-discuss at mozilla.org
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).
Amen to that! It’s worse in JS land than anywhere else! People are proud of their micro-libraries and inheritance APIs, but it’s not a good sign that they are there.
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?
Sounds like a good idea. It might make sense to coordinate with the CommonJS people.
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?
Google Groups is scary. I used it to communicate with my students for several projects. One day, some kind of automatic trigger went off at Google and decided that I was a spammer. I’ve been locked out of all of Google Groups (including my own content) for years now and my numerous attempts to get this fixed never led to anything (no human ever seems to be in the loop).
Possible alternative: Posterous Groups (haven't tried them, though). posterous.com/groups
On Tue, Oct 11, 2011 at 1:10 PM, Axel Rauschmayer <axel at rauschma.de> wrote:
*From: *"Claus Reinke" <claus.reinke at talk21.com> *Subject: *JS tools (was: Harmony transpilers) *Date: *October 11, 2011 21:53:58 GMT+02:00 *To: *"Brendan Eich" <brendan at mozilla.com> *Cc: *es-discuss at mozilla.org
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).
Amen to that! It’s worse in JS land than anywhere else! People are proud of their micro-libraries and inheritance APIs, but it’s not a good sign that they are there.
I think this issue is complex, with no simple solutions.
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?
Sounds like a good idea. It might make sense to coordinate with the CommonJS people.
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?
Moderation pain is what prevents a group from being spammed. I used Google Groups for Firebug for many years with success. First posts are moderated; about half of new posts are spam. Once in a while you let some in that have to block from posting adverts or what ever.
I wonder if js tools is really a subject however. I mean, 'firebug' is a subject one can discuss; 'web inspector', 'ES.next' etc are all topics but 'js-tools' is really a category. Everyone may have a different opinion and goal.
jjb
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 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?
> 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?