I'm looking at the example, specifically choosing only a date; You need to click off of the box entirely before the date gets updated, and it doesn't close when you click a date itself.
Note that if you're using the standalone version, the API is published under
the rome global. If you're using CJS, then you'll have to require('rome').
You can use Browserify[1] or WebPack[2] as a CommonJS module loader.
By that reasoning nothing is dependency-free, as it requires a browser, or a computer, or a universe...
Dependency-free almost always refers to runtime dependencies. A build tool is not a dependency. (Rome isn't dependency-free in that sense either[1], but hey...)
By that reasoning everything is dependency free, because I can just static link all the required libraries, or provide them in a vendor directory in the download.
I think maybe don't advertise it as dependency free. The modifications to get it to native js aren't massive, but it's not dependency free. For one thing if I make those modifications I then lose all future updates (or they become a massive pain in the ass).
Edit: I'm wrong, I misunderstood dependency free. It would be great to have a native js version of this anyway.
I don't understand how this can be considered dependency free in any sense - it has a dependency on Moment.js, which is a fairly large (and very popular and good) library for working with dates in JavaScript. Without Moment.js, this library would not work - therefore it is "dependent" on that. This is what the word "dependency" means.
Just because you can bundle up that library in the dist doesn't mean it's not a dependency.
This looks great. The two deal-breakers for me at the moment are the missing i18n, and support for older browsers (which I realize is increasingly rare these days, but unfortunately our webapp needs to support IE6+ for the time being. Yes, for real reasons).
Looks nice. One tinsey issue; It doesn't seem to allow me to clear the field. If I accidentally clicked on the text field, I have no way to empty the field again.
I cleared the contents of the field and clicked elsewhere, it fills the field with the last selected value.
I have been looking for a good datepicker to use at work, this one seems to miss a few things: No i18n (for days and months), doesn't close if you reclick the input, and no "today" button.
a time-saving feature of many date pickers is the ability to exclude certain dates (weekends, holidays, sold out, etc.). Pretty easy to implement - just a suggestion.
I've never used browserify, despite working in node, so I could be off base but I thought you didn't need to make it an npm package to support CommonJS and play nicely with the rest of your browserify js.
You don't need a package.json to use CommonJS or even to use Browserify, but as a developer I don't want to copy external dependencies into a vendor folder to use them, I want to declare my deps in my app's package.json -- so any lib that uses CommonJS but doesn't provide a package.json I will probably not bother to use.
People who use npm packages in browser code are pretty much all using Browserify or Webpack and leverage npm. (Many people use Bower, but I don't see the point of using two overlapping package managers.)
It's a new dawn of modular JS code; no more global namespace, no more stuffing CDN links in your <head>. I recommend giving it a go.
I didn't try to gain traction with it since no one will use a library without documentation. Your passive aggressiveness is completely unwarranted. I never once stated he had to change his library's name. I was simply pointing out that the name was already used, since I know I personally try to avoid conflicts.
Edit: seems the dependencies are bundled in the distributed files, making it 55kb minified!