That's a good point and something I haven't thought too far into yet. For now I'd say "no updates that introduce API breakage without notice/semver chnage". But if it's more intricate than that we should discuss it as an issue :-)
It would limit its abilities to do things going forward, like integrate with Firefox's Web IDE. We'd like to, in the future, allow you to package your web app and push it directly to the simulator from a recroom command, so we wanted to make it more than just a set of yeoman templates.
I think you're right about it being like Google's Web Starter Kit. The WSK feels a bit more sparse and less idiomatic than recroom, but it's definitely in the same vein. I haven't checked it out since it was announced a few months back though, so maybe it's grown since then.
I'd love to see people do that to recroom -- add what they think is missing. Pull requests are definitely welcome. My aim is to take the headache out of decisions like "Which framework/tool do I use?" so you can get to writing code if, like me, you don't really care which tool you use as long as it works well.
On the front end part, it's a real pain to choose a tool over another, since there so many.
I'll be evaluating recroom this week, and will integrate it to my internal tools.
A question: something that I think is really broken, is how to integrate bower (or something like it) in the weapp. This is something that WSK left away, but you will always need.
WSK left it out on purpose because it doesn't want to dictate how you manage dependencies or module loading.
I don't use Bower. I build AngularJS applications and I prefer CommonJS over AMD, where I use Browserify for Node-like requires. Browserify allows me to use npm modules on the client-side as well, which eliminates my use of Bower completely.
recroom uses bower for package management at this point. Like many other parts of the picture, the "market" surrounding package management is in flux (there's also npm, for instance), so we'll monitor what's going on there. But for now, bower seems like a great choice for developers.
Also, it enables the modular aspect of recroom, that you can add/replace pieces you want, so package management is definitely vital.
I know Grunt a bit better, but as I explore Gulp I like it a lot. In the future we may switch, but I'd need the Gulpfile to do everything the Grunt one does.
Isn't that because indexedDB isn't accessible in private browsing? Not sure what's wrong with Chrome though. It seems not to be complaining about invalid state or about anything.
edit: for Chromium the clock wasn't visible, fixing the height helps
This is certainly the biggest reason. In the future maybe we can use ember-cli and integrate more with them.
Ember does a LOT of what I want recroom to be able to do, but I'm okay using something that works better right now over using bleeding edge Ember stuff that may be more idiomatic.
Of course, as more people contribute to and use recroom we'll evaluate changing out components. If I picked the wrong thing I hope people will correct it and make this thing better ^_^
You're right on the money. I think people who already know their tools well and have a system that works are covered and are NOT the target audience.
In the future I'd like to sort of ween new users into using recroom by abstracting away a lot of things (we are largely proxying to other commands in grunt/yeoman right now, but the user doesn't need to know these tools to use recroom at a very basic level).
But for me, I feel like an intermediate/experienced developer who has just always wanted an end-to-end idiomatic way to write apps without me knowing all the tools inside-out. I'm hoping recroom will be that most of all, so you're right :-)
When this was written, iOS 8 was unannounced and folks generally just used localStorage for cross-browser storage. IndexedDB isn't as high-level as some folks would like, and key-value is handy for many apps/sites.
Even with iOS 8's support for IndexedDB, there are edge cases in different browsers localForage handles, and it handles storage of Blob data and TypedArrays transparently too, which is handy.
It uses Promises and callbacks, though you're right it doesn't use node-style. It's not a node library and I frankly dislike needing to supply error as a first arg, as strictly speaking it's optional and just adds cruft.
I had a few folks mention this in the early stages of library development but it hasn't come up since.
