jpillora / xdomain

A pure JavaScript CORS alternative
https://jpillora.com/xdomain/
3.12k stars 270 forks source link

Refactor: Convert From Coffeescript to Javascript #59

Open dcrockwell opened 10 years ago

dcrockwell commented 10 years ago

I understand how this is a terribly unpopular suggestion for Coffeescript aficionados, however I am at least one developer that would like to contribute to this project (specifically to help along browserify compatibility), but am unwilling to endure Coffeescript in order to do so.

Libraries that are intended to be used by the javascript community as a whole, in my opinion, ought to be standardized in vanilla Javascript, so as to reduce friction to contribution. With far more Javascript developers than Coffeescript users, and with all Coffeescript users being familiar with vanilla Javascript, I see this as a logical choice to make.

I leave the decision making in your hands.

jpillora commented 10 years ago

Yep, I agree, I have seen this various of my other projects since moving to CoffeeScript and have since moved back to JavaScript for the sole purpose of accessibility. I don't have time to convert the source and clean it up at the moment, though I would accept a PR that converts all of the .coffee files into .js (which should still build using grunt-source). Which brings me to the second piece of the accessibility puzzle is Grunt Source. Since I have a number of libraries that all require the same Grunt build, I wrote Grunt Source and moved the JS Library build into grunt-source-jslib to remove this code duplication. In regards to the CONTRIBUTING guide, what are your thoughts on the accessibility of Grunt Source?

dcrockwell commented 10 years ago

In my opinion, when a library gains public acceptance to the degree that this one has, you want to de-couple the library from your own personal ecosystem. This is to give the community an opportunity to say; replace grunt with gulp.

So, while I don't believe that the extra step of grunt-source is tedious enough to be an issue, I do think that it's own dedicated Gruntfile at this point would be appropriate at this juncture to allow others the ability to change the project's build sequence, without affecting your other libraries.

In this way, it would be trivial to remove the coffeescript dependency when converting to vanilla JS.

dcrockwell commented 10 years ago

If I can find time this week, I will do a conversion of the existing .coffee files. From there, I would like to refactor to provide universal compatibility with AMD, CommonJS, as well as without a mod loader.

jpillora commented 10 years ago

replace grunt with gulp

Sure, it's a possibility, though I can't see a strong enough case for gulp in this project just yet?

allow others the ability to change the project's build sequence

Definitely agree, one modification I've made was add testing via saucelabs, where I've had to create a test/Gruntfile.coffee, which could now become a Gruntfile.js, by pulling the necessary parts out of grunt-source-jslib/Gruntfile.coffee.

A PR would be great :) definitely could use some help on this project! And here's a nifty UMD definition if you want to use it: (this.define || Object)((this.exports || this).myLib = myLib);. Supports AMD, CommonJS and no loader, though is quite cryptic...

dcrockwell commented 10 years ago

(this.define || Object)((this.exports || this).myLib = myLib);

Aye, that's a nice pattern. Thank you very much.

replace grunt with gulp

This was only an example of a scenario in which coupling this project to a remote Gruntfile can prove problematic. I am not suggesting to switch this project to gulp, yet.

A PR would be great

We'll see how this week goes, and whether I can dedicate a day to doing the job correctly. If I do get to it, I will begin by establishing a .jshintrc file to keep all of the script homogenous, which I will integrate into the grunt test phase, so that it is also a part of your continuous integration strategy.

These are the rules I propose a public library to use:

{
  "bitwise": "true",
  "camelcase": true,
  "curly": true,
  "eqeqeq": true,
  "eqnull": true,
  "forin": true,
  "freeze": true,
  "indent": 2,
  "latedef": false,
  "newcap": true,
  "noarg": true,
  "noempty": true,
  "nonew": true,
  "plusplus": true,
  "quotmark": true,
  "undef": true,
  "unused": false,
  "strict": true,
  "trailing": true,
  "maxparams": 4,
  "maxdepth": 3,
  "maxstatements": 20,
  "browser": true,
  "esnext": true,
  "globals": {"describe": true, "_": true, "it": true, "beforeEach": true, "before": true, "after": true, "afterEach": true, "sinon": true, "xhr": true},
  "globalstrict": false,
  "white": true,
  "smarttabs": true,
  "node": true,
  "expr": true
}

I can explain the rationale behind any option you would like me to.

jpillora commented 10 years ago

Yep looks good, "indent": 2 is the only setting I'd be nazi about lol

peterjosling commented 9 years ago

Might be worth following this project and giving it a go once it hits production ready: https://github.com/eventualbuddha/decaffeinate

jpillora commented 9 years ago

Agreed