At the end of this road, I foresee a full IDE baked into Firefox. I can't wait.
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.).
You're right! recroom works well with WebIDE. You build your app and can then use WebIDE (and even the Ember Inspector Firefox add-on) to debug your app, for instance in the Firefox OS Simulator.
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".
Well isn't that what Netscape had :) everything comes around. I actually think this part was really good part of Netscape Navigator and was in spirit of how html was intented to be used.
As an integrated environment to get going quickly on a large-scale single page app this looks nice. I'm wondering though who this is suited for. An experienced web developer who has a few frameworks under their belt will have a preferred toolbox, and likely won't be interested. Meanwhile, a beginner will have a really steep learning curve figuring all these tools out at the same time, instead of one by one, and I suspect will fall off the mountain before they reach the summit. I suppose this toolbox is best suited for the mid-level, experienced enough to know some of the tools, but not so experienced as to have decided which tools they want.
That's actually where a large group of developers fall as well. You have the total beginners, who realistically won't build an app that has tests, or use a framework to sort out their models and views etc. They just need a HTML, CSS, JS file and some comments and can throw together something simple.
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 :)
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 :-)
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
Because it takes an enormous amount of work, most of node.js source code (or at least a lot of it) is basically libuv bindings for V8. To make it work on top of SpiderMonkey is a lot of work (though multiple people tried). And the gains from having it run on SpiderMonkey are questionable, at least until more of the ES6 fanciness is implemented - and then the question is where V8 will be at that point.
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.
"SpiderNode" [1] and "luvmonkey" [2] were two Node experiments using SpiderMonkey (from 2012). The first implemented V8's embedding API on top of SpiderMonkey. The second implemented libuv bindings in SpiderMonkey. Neither project was an official Mozilla project. Mozilla's SpiderMonkey team has (casually) discussed rebooting SpiderNode for server-side ES6 and asm.js support, but nothing is planned.
Interesting. It wasn't immediately clear from the post: how is this going to be maintained? Some of the bundled tools on that list update fairly frequently. Is the plan to track the underlying versions (and risk breakage / having to create 'glue' patches), or maintain a separate (integrated, stable) fork/set of forks?
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.
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's kinda like Google's Web Starter Kit[1], isn't ?
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.
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.
Yes the whole space moves quickly. The current choice in tools in the recroom "tool belt" is not meant to be unchangeably set in stone. FWIW, Ember CLI is an interesting piece that would connect well to the core Ember framework as well.
I'm very curious as to why this is diverging from the "Ember Way" and not using http://www.ember-cli.com/
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.
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 ^_^
Yeah you're right. The grunt piece is definitely one that is not set in stone. Ember-CLI is exciting and we've started working closely with the Ember folks to monitor it and see if and when this should become another piece of the recroom puzzle.
I can see that yeoman is one of the included tools, but I don't see what Rec Room adds on top of the capabilities of Yeoman. Couldn't this entire toolchain be encapsulated as a Yeoman generator?
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.
Good initialive, although I'm surprised to see Stylus in that stack: I like stylus and nib very much, but now that there is libsass which doesn't rely on Ruby (and even compiles faster, although it doesn't support some 3.2 and 3.3 features as far as I know) and a matching npm module [1], and until there is source maps support in Stylus, SASS might be a better choice for newcomers.
Good idea :) I also just added a reply because turns out Stylus added source maps very recently (today even ?), so the lack of sourcemaps is not a problem anymore.
Maybe I'm in the minority here but this doesn't sound very appealing. I've said it before but do you really want to be a software engineer solving real problems or a glorified glue-stick gluing pieces of framework code together? All this seems to do is make it easier to glue framework code together.
There's a time and a place for both. The reasons frameworks (and so many of them) exist is because there are many problems you would otherwise have to solve over and over again, rather than focusing on the actual problems you app is supposed to solve.
However, that's not an excuse to avoid learning about the problems that frameworks and libraries solve, altogether.
Most "real" software engineering problems have actually already been solved many times by other engineers. Take a serious look at all of the work you have done over your career. Can you honestly say that you believe you were the only person who solved those problems?
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.
It could be that you need a web frontend for a project, and all the stuff that's interesting to you is done in the backend code. Engineers in other fields use prepackaged components all the time; Jeep engineers, for example, used to use Chrysler transmissions and Chevrolet motors even when they were more than capable of building their own.
Are X-tags and Polymer compatible? Really need that web components thing to work. Seems like maybe Google and Mozilla could cooperate a little bit more?
> The answer: “It’s the web; use existing web technologies.” was—and still is—a good answer.
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".
Yes, but developer experience is only one aspect for you to consider.
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.
> Have you considered the ease of deployment/availability/potential audience size of web apps versus your native platforms?
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 :)
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.).