TODO list.
Opened this issue · 8 comments
Yesterday I was developing using this library and I noticed some improvements that can be made.
There are a few things that need to be done:
- Adopt a style guide, I believe Google's style guide is the way to go. It's used in the majority of JS projects including AngularJS
https://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml - Write some test cases.
- Create a build script either using GruntJS or GulpJS to automate the minification and unit testing processes.
- Change the output file to lowercase: "Please.js" -> "please.js"
- Consider renaming the project since there is already another (older) please.js:
https://github.com/wingify/please.js
Feel free to suggest a new name. I'll go for chromatic.js
More popular please.js? By what standard? I had never heard of it until now. It's older, but older does not mean more popular.
Fooidge/PleaseJS: 1083 stars, 71 forks, 22 watchers
wingify/pleasejs: 193 stars, 13 forks, 20 watchers
By my standards PleaseJS is roughly x5 more popular than pleasejs. I'm not entirely against a renaming, just against your provided reasoning.
Well, I said it was more popular because there are more contributors. 2 vs 4 with tons more commits than this repo.
I just want to fix this because it's a good idea, it's like a sapling and at this stage is more flexible than other (older) repos.
That's in direction relation with age, not popularity. The older a project is, it may have a few more people working on it - and if it's had a year or so of development, there will be plenty of commits on the project compared to one that isn't nearly as old.
These are both my validation for a name change - as well as the counterarguments:
-
PleaseJS says nothing about what PleaseJS might do. Then again, names don't always have to be descriptibe. What about "Google" describes "Skynet"? Nothing.
-
pleasejs is an older project with the same name, and so changing it would be a sign of respect to age. Although sometimes that's how the world goes. There's a lot to a name when a developer makes it, and so sometimes change is not desired. A recent example being Swift by Apple and Swift, the other programming language. Either both parties will have to "live with it" or the one being harmed due to being the less popular will change their name.
If Fooidge likes PleaseJS as the name, I'm of the personal opinion that his project is more popular, even if newer, and can keep the name if he so wants to. Popularity determines speech. If someone talks to me about "PleaseJS" I would think of the most popular "PleaseJS" and not any others. Just like how I am not confused when people talk about "Swift". I know they are talking about Apple Swift because it's the more popular one.
If Fooidge is not too attached to the name PleaseJS, I would agree to a name change due to pleasejs's seniority out of respect for that project. But that's not a very high ranked reason in my mind, as I see popularity the determining factor of namesake - as do some judicial systems who will award a name to a given project/person/company if they are the more known for it.
Hey guys, I'm finally going to be able to wade through some of these issues tonight but I wanted to hit this one in transit to make sure you know it's heard.
First, I'll check out the google style guide, but I'm following my own style that I've cobbled together over the years. That being said, I've only been doing JS specifically for about 2 months, so there's appreciable wisdom to learning best practices.
Next up, the name. I'm disinclined to change the name at this point, and I don't see any overlap between this and the other library. It may be a different story if there was a conflict and the maintainer/author of the other please wanted to contact me about it.
Finally, thanks for your contributions. I really appreciate you taking the time. But try to stay away from language like "this hurts my eyes". I worked hard on this, and differences of opinion expressed in these ways have a habit of turning me off. I don't want that to happen.
I updated my issue to reflect your opinions.
Sorry for putting you off with my comment, I omitted it was because of JSLint giving up and saying "too many errors"
@Fooidge, could you publish your style guide or amend the README? maybe I can make a JS lint configuration to keep consistency.
Or if you approve, I can make a pull request that will put everything into spec.
So forth with the name change, @Fooidge has full veto rights, so I guess it will not happen.
At the moment, I'm trying to take a crack at the test cases with the Jasmine framework.
I'm not familiar with that, but then again full stack web work is sort of new to me. I'm just now integrating gulp and toying with grunt.
If you get it running I'll be happy to integrate!
Jordan Checkman
On Jul 21, 2014, at 11:07 PM, Jason Manuel notifications@github.com wrote:
At the moment, I'm trying to take a crack at the test cases with the Jasmine framework.
—
Reply to this email directly or view it on GitHub.
I've already integrated gulpjs in my fork. Though there were a few commits
merged before mine and now I need to resolve the conflicts.
ibarrajo/PleaseJS
On Jul 22, 2014 7:54 AM, "Jordan Checkman" notifications@github.com wrote:
I'm not familiar with that, but then again full stack web work is sort of
new to me. I'm just now integrating gulp and toying with grunt.If you get it running I'll be happy to integrate!
Jordan Checkman
On Jul 21, 2014, at 11:07 PM, Jason Manuel notifications@github.com
wrote:At the moment, I'm trying to take a crack at the test cases with the
Jasmine framework.—
Reply to this email directly or view it on GitHub.—
Reply to this email directly or view it on GitHub
#19 (comment).