Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Introducing Rec Room

hacks.mozilla.org

Post reply on HN
Print view View original

41–50 of 65 posts

Re: Introducing Rec Room

#41

Post by dwoot »

xfalcox wrote: post #34
tofumatt wrote: post #30

Earlier quoted context omitted.

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. M…

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.

Re: Introducing Rec Room

#42

Post by jkrems »

frik wrote: post #40

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

Re: Introducing Rec Room

#43

Post by 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.

Re: Introducing Rec Room

#44

Post by 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.

Re: Introducing Rec Room

#45

Post by theon144 »

Zelphyr wrote: post #44

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.

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

Re: Introducing Rec Room

#46

Post by sehr »

Zelphyr wrote: post #44

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.

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.

Re: Introducing Rec Room

#47

Post by fwenzel »

Zelphyr wrote: post #44

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.

Re: Introducing Rec Room

#48

Post by tofumatt »

digisth wrote: post #43

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 do…

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

Re: Introducing Rec Room

#49

Post by cpeterso »

jkrems wrote: post #42
frik wrote: post #40

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

"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

Re: Introducing Rec Room

#50

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

Post reply on HN