Introducing Rec Room | Hacker News Reader

Introducing Rec Room

hacks.mozilla.org

200 pointsrnyman62 comments

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.).

It's already there :-D

https://hacks.mozilla.org/2014/06/webide-lands-in-nightly/

(Well, in the nightlies anyway.)

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".

I just found out yesterday Chrome has one as well https://chrome.google.com/webstore/detail/chrome-dev-editor-...

If you are running Aurora, you can have almost all of this: go to about:config, search for "webide.enabled" and change the value to true

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.

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 :-)

I’ve been working on extracting something out of the way I’ve been creating web apps at Mozilla that you can use to write your next web app.

I didn't know Ember was already being used at Mozilla, that's pretty neat! It seems to be popping up everywhere these days

FWIW, most if not all of the web stuff is on GitHub: https://github.com/mozilla

mozilla.org: https://github.com/mozilla/bedrock

crash-stats: https://github.com/mozilla/socorro

marketplace: https://github.com/mozilla/zamboni

geolocation: https://github.com/mozilla/ichnaea

support: https://github.com/mozilla/kitsune

MDN: https://github.com/mozilla/kuma

I see no clock at this time: http://worldclock.tofumatt.com/

That URL redirects me to http://worldclock.tofumatt.com/#/clock, but if I hit the "Back" button, I get to the URL you listed and there is no clock.

I have seen some invalidstateerrors on this for some folks. I'm looking into it, sorry! :-/

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

    document.getElementsByTagName('section')[0].style.height = '100px';

I don't see anything either (chrome, osx)

It does seem to work with Firefox although I had a very hard time with the pull down widget for time zones.

Same on chrome. Puts my firefox in an infinite loop or something

Ditto

fails for me in private browsing mode because firefox can't remember history, works in normal mode

"Rec Room is a Node.js utility ..."

I am curious why there is no SpiderMonkey* based Node.js ?

* SpiderMonkey is Mozilla's JavaScript engine: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/Sp... , https://wiki.mozilla.org/JaegerMonkey . Node.js is using Chrome's V8 JavaScript engine. Both JS engines are fast and have their advantages and disadvantages.

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.

[1] https://github.com/zpao/spidernode [2] https://github.com/creationix/luvmonkey

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.

[1] https://github.com/google/web-starter-kit

That's really good to hear.

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.

Yeah, exactly this!

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.

wow, must have missed this release, thanks. At first glance i much prefer this stack over the mozilla one. For example gulp is far better than grunt.

That's the first time I've seen someone mention Grunt since Gulp became the new hotness. Wonder why they chose to go with that instead?

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.

Probably because next week Gulp will stop begin the new hotness and there will be something else.

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.

https://gist.github.com/substack/8313379

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.

Maybe it's the active development part of it? Things are changing fast and it's still not even at 0.1.0.

From the docs:

Although potentially exciting, this is still really a WIP, use at your own risk.

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.

[1] https://github.com/sass/node-sass

That's great feedback thank you. I've copied this into an Issue on recroom: https://github.com/mozilla/recroom/issues/35

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.

That depends on what your version of 'real' is. I enjoy creating things for other people, regardless of what they're made with.

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.

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.

You can't write an app for a platform like that without gluing some frameworks together :)

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?

That is such a beautiful table full of old tools!

> 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 :)

What a refreshing and well thought out viewpoint. I especially like the delivery of it, a perfect way to convince others!

I'm not evangelizing here and I don't have to because what I want is going to happen eventually anyway.

Then there is no point to you comment whatsoever is there?

Are you the Internet police or something? Why don't you take a look at your own comment history, asshole :)

Are you evangelizing every time you disagree with an article?

I'm inclined to say "meh."

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.

What's stopping you from debugging coffeescript? Firefox was the first browser with source maps support.

Reply on news.ycombinator.com