Live data from Hacker News

Basil.js – Smart persistence layer

github.com

21–24 of 24 posts

Re: Basil.js – Smart persistence layer

#21
post #3

Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage solution (and in JavaScript any significantly complex task eventually becomes async) you are left with code that presumes sync behavior. This makes it difficult to refactor. Providing an API with callbacks or better yet promises forces you to write future-safe c…

I came here to say the exact same thing.

Even if you're using synchronous storage, wrap it in an asynchronous API and save yourself a world of hurt later.

Re: Basil.js – Smart persistence layer

#22

There's a project with the same name out there: http://basiljs.ch/ This made me wonder: how to deal with similar named open source projects? Although the goals of both projects aren't related in any sense it could cause for some confusion...

Do lots of searching before naming your projects, I suppose. Surely he could have used Rosemary.js, or Herb.js, or Bayleaf.js?

or something even remotely related to ... who knows... data storage?

Re: Basil.js – Smart persistence layer

#24
post #22

Earlier quoted context omitted.

Do lots of searching before naming your projects, I suppose. Surely he could have used Rosemary.js, or Herb.js, or Bayleaf.js?

or something even remotely related to ... who knows... data storage?

Bah, ridiculous! Clearly you haven't received the memo, all Javascript libraries are named exclusively by dart-board now.
Post reply on HN