
Introducing Rec Room - rnyman
https://hacks.mozilla.org/2014/08/time-to-get-hacking-introducing-rec-room/
======
diafygi
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.).

~~~
smacktoward
It's already there :-D

[https://hacks.mozilla.org/2014/06/webide-lands-in-
nightly/](https://hacks.mozilla.org/2014/06/webide-lands-in-nightly/)

(Well, in the nightlies anyway.)

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

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

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

------
compedit
_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

~~~
reubenmorais
FWIW, most if not all of the web stuff is on GitHub:
[https://github.com/mozilla](https://github.com/mozilla)

mozilla.org:
[https://github.com/mozilla/bedrock](https://github.com/mozilla/bedrock)

crash-stats:
[https://github.com/mozilla/socorro](https://github.com/mozilla/socorro)

marketplace:
[https://github.com/mozilla/zamboni](https://github.com/mozilla/zamboni)

geolocation:
[https://github.com/mozilla/ichnaea](https://github.com/mozilla/ichnaea)

support:
[https://github.com/mozilla/kitsune](https://github.com/mozilla/kitsune)

MDN: [https://github.com/mozilla/kuma](https://github.com/mozilla/kuma)

------
Raphael
I see no clock at this time:
[http://worldclock.tofumatt.com/](http://worldclock.tofumatt.com/)

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

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

------
frik
"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://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey) , [https://wiki.mozilla.org/JaegerMonkey](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.

~~~
jkrems
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.

~~~
cpeterso
"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](https://github.com/zpao/spidernode)
[2]
[https://github.com/creationix/luvmonkey](https://github.com/creationix/luvmonkey)

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

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

------
xfalcox
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](https://github.com/google/web-
starter-kit)

~~~
tofumatt
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.

~~~
xfalcox
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.

~~~
dwoot
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.

------
snarkyturtle
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?

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

~~~
fwenzel
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.

------
wdmeldon
I'm very curious as to why this is diverging from the "Ember Way" and not
using [http://www.ember-cli.com/](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.

~~~
compedit
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._

~~~
tofumatt
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 ^_^

------
xb
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?

~~~
tofumatt
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.

------
wildpeaks
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](https://github.com/sass/node-sass)

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

~~~
wildpeaks
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.

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

~~~
fwenzel
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.

------
ilaksh
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?

------
blt
That is such a beautiful table full of old tools!

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

~~~
EdSharkey
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.

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

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

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

