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.
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.
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.
You could easily add your own backend relatively easily (the API is easy to copy), though it's not really "optimized" for that yet. It's designed with offline storage for JS in mind though, so the library itself likely won't support remote calls.
I believe the aim is to have email providers be able to auth your persona email instead of Mozilla, but Mozilla exists as a sort of polyfill if the provider (eg. hotmail.com, gmail.com, your-custom-domain.net) doesn't do persona yet.
Also, yes: people can still choose crummy passwords. Personally, I don't think the appeal is in better security; it's convenience of single sign-on without it being tied to a. identity or b. Facebook (or twitter or google or whatever other service that harvests my data).
If you're looking to do remote work because you're sick of your current 9-5, you shouldn't look to remote work to fix anything.
I worked anywhere from 30%-50% a week remote at my last gig and it still requires maintaining somewhat regular hours (you still have colleagues) and a routine. I now work remotely save for trips to the Head Office every once in awhile. You still need a routine because you have other colleagues you need to interface with, at least sometimes in real-time.
If you want to set your own hours and do your own thing, start freelancing or start your own business. My ability to work remotely was an asset when I started at my new job, but if I phrased it like you did ("I don't wanna wear nice closes and drive") it would make me sound more like a sloth than a good remote worker.
And if you work remote, you best be getting out and dressed up at least a day a week anyway. Interaction is REALLY important and you'll go crazy if you don't get out and see people.
Jason is a designer by trade, and is routinely involved with the design of 37signals' products. In the same vein, DHH is a partner in the company, but still writes code (as I understand it).
Really? Most of the standard web dev stuff (Ruby, PHP, Apache, etc.) comes out of the box and works quite well, and if you need either specialized versions of things (rvm, virtualenv, custom Apache, etc.) or stuff that doesn't come with OS X (lighttpd, node.js, etc.) wouldn't it be installed in /usr/local?
I don't think this will break many web dev tools. Unless you mean stuff like Sequel Pro or TextMate; even then, I can't imagine most apps won't make the transition smoothly.
They're offering users who probably just want to use Twitter easy/quick access to an alternative client so they can get back to tweeting. Given that the app they used to use was banned for privacy violations, the fact that it's the official app is probably a good thing in terms of trust.
Fingerprints will grow back unless you get down to dermal layers of skin and that will hurt quite a bit. Permanently removing your prints is a more involved process than this, but it's certainly a cute idea.