ScottHamper
commented
8 years ago Hey Tung,
While I absolutely appreciate the sentiment for collaboration in the open-source community, I think that having libraries with differing APIs is precisely what makes them valuable!
Ultimately, the existing native browser API for handling Cookies in JavaScript is a unified interface that's supported by any browser you choose. However, the interface is really awful to use, and so third-party libraries have stepped in to provide a better experience. The fact that these libraries are providing a non-standard interface is what makes them useful for some people to use.
Another consideration is that different libraries can focus on different goals. For example, js-cookie appears to focus on being sort of a "Swiss army knife" of cookie libraries. It attempts to provide utilities to cater to every possible use-case, making it versatile but complicating its API. Cookies.js, on the other hand, is more focused on providing a pleasant "core" experience without many frills - the API is compact, but advanced use-cases will require the user to do additional work on their end. Depending on user preference, and the project being worked on, either library could be a great a fit.
I can definitely understand the frustration of spending a lot of time comparing differences between many options, instead of accomplishing productive work. One option for dealing with this might be to only research options until you find one that seems to meet all your use-cases, while otherwise seeming "OK" (API, documentation, and/or source code look reasonable, etc). At that point, instead of spending more time comparing and contrasting it with all the other options, go ahead and try it out. If you run into problems as you start using it, then you can move onto another option to see if it works out better. This is just one idea - I'm not sure what the best way to handle the vast sea of JavaScript libraries is, and it's probably different at different times.
Lastly, if you'd like to set multiple values to a cookie key, you can use JSON to do so effectively. In Cookies.js, you'd have to manually serialize a JS object to a JSON string before storing it in a cookie, like this:
var prefs = { hl: 'en', abc: 'xyz' };
Cookies.set('Youtube.PREF', JSON.stringify(prefs));And then deserialize the cookie value after retrieving it:
var prefs = JSON.parse(Cookies.get('Youtube.PREF'));You could use the same approach with js-cookie, though it looks like they provide some API methods for doing the JSON (de)serializing while also getting/setting a cookie, which can save you a few keystrokes.
In any case, thanks for checking out the library and taking the time to discuss all of this with me!
redstrike
Coming from PHP world and conceived the usefulness of PSR (PHP Standards Recommendations). I think that we should have a unified interface for a stable and lightweight component like Cookie.
Last night, it cost me a lot of time to compare the different of Cookie libraries like js-cookie vs ScottHamper/Cookies vs florian/cookie.js. I wonder why libraries' authors don't spend time together to design a unified interface for Cookie. We also don't have the feature that big company like Google used to set "multiple values to a key" (Youtube.PREF: {hl=en&abc=xyz&...}).
An interoperable unified interface helps library user much when choosing a good one and swapping to the right one in the forest of libraries of JS community.