It would so great if you could just open the App Manager, click "Create New App", check the boxes of the libraries you want to include by default (jQuery, Ember, etc.), and it would then generate a Hello World app folder with all those files included.
Heck, Firefox Developer Tools is practically already an IDE. All that really remains for it is a "Resources" tab with text editing ability.
EDIT: Additionally, being beginner-friendly would be a huge advantage to Firefox OS because its target market is the developing world. Only requiring an installation of Firefox to develop apps would significantly lower the barrier for who could learn to develop apps. Locals could quickly learn to make an app that caters specifically to their local community (what farms are hiring, where the cleanest water is, etc.).
(Well, in the nightlies anyway.)
Future plans of ours include having recroom (and really, any toolchain; this is not a privilege we only want Mozilla projects to have) integrate even more smoothly with the WebIDE, with more direct integration points like "pre-push hooks".
It won't download and install the js libraries for you, but it does let you click "Create New App" and sets a bunch of stuff up for you.
You can even install a Firefox OS simulator to test your app with.
On the other end of the spectrum, you have the experts, who have evaluated a dozen frameworks of their own, know why they like gulp more than broccoli, and really just need an API reference to know what's possible, and off they go.
And in the middle of all this you have the huge group of developers who would really like to have some more help, even if only to help them make decisions of their own and eventually get them over the hump to expert-level. That's the group this is targeted at.
If you make a client-side app with it and figure out you don't like certain pieces of the toolbelt, you can replace them on the spot (they're loosely coupled). If at some point you're so advanced you want to replace it all, fantastic! You don't need our help anymore :)
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 :-)
I didn't know Ember was already being used at Mozilla, that's pretty neat! It seems to be popping up everywhere these days
edit: for Chromium the clock wasn't visible, fixing the height helps
document.getElementsByTagName('section').style.height = '100px';
I am curious why there is no SpiderMonkey* based Node.js ?
P.S.: It could always make sense to make a "modern Node.js" that embraces es-next features for core APIs, but that's still ~1 year out.
The github page states that "this version includes the production version of some libraries", but doesn't indicate how it's going to be managed.
For me, it's really helpful when we can use some guidance from great players in the industry when choosing which framework to use. We recently forked Web Starter Kit, added some bower instructions, integrated Twitter BootStraped and now we've got some internal guidelines for new SPA.
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.
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.
Also, it enables the modular aspect of recroom, that you can add/replace pieces you want, so package management is definitely vital.
It's an officially supported approach that is under very active development and (at least ostensibly) covers what this tool does and more. The use of globals over ES6 modules is the most glaring omission.
From the docs:
Although potentially exciting, this is still really a WIP, use at your own risk.
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 ^_^
However, that's not an excuse to avoid learning about the problems that frameworks and libraries solve, altogether.
I don't tie my identity or my sense of worth to the tools I use or how I use them either, so it makes no real difference to me.
Good software engineers take full advantage of components, frameworks, and other ways to re-use code.
In fact, code reuse is one of the most important aspects of software engineering.
That's a terrible answer. Oh, I just need to cobble together a bunch of shitty libraries that pale in comparison to what's available on native platforms just to build a simple app that will equally pale in comparison to apps on actual native platforms? Yeah, I think I'll pass.
Web technology sucks and it's holding us all back. I'd rather see a new web that is built as a platform for actual applications instead of "documents".
Are you evangelizing every time you disagree with an article?
Have you considered the ease of deployment/availability/potential audience size of web apps versus your native platforms? We're all just trying to make successful products, after all. And any app of significant complexity will require at least some level of craft (which I suspect is part of your gripe - no craft required, ecosystem too large.)
Also, consider that any platform like HTML5 that includes Gamepad, Audio Data, Canvas/GL, Mouse Lock, and Socket API's has evolved far beyond simple document display.
The cruelest retort I can give on HN is none at all. It must be crushing to see one's story meet the front page of HN, only to receive few/no comments, right? If you're this passionate and worked up on the subject, please give the silent treatment a go.
Sure. Do you think that a new system that is better than HTML/CSS/JS couldn't be built with that in mind? Native systems all already have hooks for easy deployment and updates and the potential audience is everybody since you need a native system to run a browser and a browser is nothing special. What we need are standards for applications. Not documents that you can script.
> Also, consider that any platform like HTML5 that includes Gamepad, Audio Data, Canvas/GL, Mouse Lock, and Socket API's has evolved far beyond simple document display.
HTML is still very, very deeply rooted in document display and browsers. That's why native apps perform better and are more popular for anything but simple data entry. Even for simple data entry, as a user I prefer native.
> If you're this passionate and worked up on the subject, please give the silent treatment a go.
I guess three sentences including a curse-word and a bit of sarcasm counts as "passionately worked up" these days :)
I was hoping this was going to be general purpose rather than a nodejs (but only frontend) kit.
For my part, I still want to debug coffeescript in firefox.