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

Show HN: Meteor, a realtime JavaScript framework

meteor.com

Post reply on HN
Print view View original

291–300 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#291

Post by shimonamit »

erikpukinskis wrote: post #289
upinsmoke wrote: post #288

Earlier quoted context omitted.

From the doc: "Currently the client is given full write access to the collection. They can execute arbitrary Mongo update commands. Once we build authentication, you will be able to limit the client's direct access to insert, update, and remove. We are also considering validators and other ORM-like functionality."

Yeah, I read that too. :) It doesn't really address my questions about how they'll pull that off.

I would assume their client DB stubs invoke server RPCs. A few server hooks for your webapp would solve that.

Re: Show HN: Meteor, a realtime JavaScript framework

#292

Post by XLcommerce »

eric-hu wrote: post #285
XLcommerce wrote: post #254

Earlier quoted context omitted.

Yeah, said much better than I could. I don't regret any of the time spent with these frameworks because it really broadens your horizons and makes you think in new ways. Lots of the techniques I've seen now make regular appearances in the versions I roll myself. Other ideas I've completely rejected. Eg. ORMs. A few years ago they seemed like a godsend. In reality they simply shielded me from the basics of SQL and wer…

I have to say that I feel like Rails' ORM does a magnificent job of saving me time. Migrations allow me to write database changes that can be undone more easily. An ORM also seems to lower the amount of configuration it takes to get development databases synced. It's not as much of an issue for an experienced dev, but a designer or new team member would need help. I have had to learn AREL, the relational algebra used…

I've not used the Rails ORM so I can't comment on how good it is or how easy it is to debug queries (peer behind the magic).

*The ORM automates things like tersely expressing the object associations I've built, leaving room for fewer syntax mistakes.'

Maybe it depends on the system you're working on however mitigating syntax errors seems like a small benefit. For me the SQL for most projects is fairly static i.e. once a given set of queries has been defined and tested they can lie there untouched, so once I nail a query and it performs the way I like I hardly ever need to go back and touch it again. However the performance penalty of sitting behind an ORM is ever present, for each query (at least for a cache miss). Personally I just don't like having 100s of lines of code sitting between:

model->get(('model.field' => 'value'));

and actually receiving the data.

It just seems so.... unnecessary.

of course YMMV, and perhaps the benefits kick in when you're working in a team (I'm not).

Re: Show HN: Meteor, a realtime JavaScript framework

#295

Post by grannyg00se »

jmarinez wrote: post #246
grannyg00se wrote: post #226

Earlier quoted context omitted.

I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.

Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something…

I actually don't mind the callback pyramid so much for what it gives you.

One of the answers to "why node" question might be because it's all about Javascript. It's on the client, on the server, in the api, talking to the database...everywhere javascript. So node is a great choice for that. And it's very fast. I see luvit.io claims a 2 to 4 times faster than node performance, but it breaks the convenience of one language everywhere.

Re: Show HN: Meteor, a realtime JavaScript framework

#297

Post by dgreensp »

erikpukinskis wrote: post #287

I'm surprised no one is talking about the glaring hole, which is security. It's apparently on the developers' short list of high priority features ( http://stackoverflow.com/questions/10100813/data-validation-... ) but it doesn't seem like a trivial addition. With client-side DB access, and eventual consistency baked into the platform as a core feature, you can't just throw "if current_user == object.owner" in your c…

Posted on SO:

Meteor has data validation already, though not user authentication.

The model is that the server chooses what data to expose for reading, and the server also performs the real writes against the database. The client only simulates the mutations. You can define your own mutations ("methods"), and have them simulated on the client or not. If access checks pass on the client, they still might fail on the server. The server can run additional or different code, and you can hide this code from the client by putting it in the "server" directory. If the method results in different side-effects on the server than on the client, the differences are synced down to the client -- exactly what you'd want.

However, in new projects, to make things easier for first-time Meteor developers, we auto-publish all server data. To turn this off, type "meteor remove autopublish". That is, auto-publishing is the default for new projects but not the default for meteor overall.

Re: Show HN: Meteor, a realtime JavaScript framework

#298

Post by cristiantincu »

micheljansen wrote: post #273
cristiantincu wrote: post #259

Earlier quoted context omitted.

“Any sufficiently advanced technology is indistinguishable from magic.” —Arthur C. Clarke. For an user of a product/service, this is bliss. For a hacker, it might get tricky. Now, considering the fact that this is all open source, the huge wall you’re talking about is just a matter of perception. You’re free to debug and go with it as low level as you need.

Easier said than done. The code of Rails was also publicly available, but getting from a hello world app to diving into a hard core codebase such as that of Rails is a huge step. Understanding framework code is quite different from understanding app code as well.

I agree. I didn’t say it would be easy, though. ☺ In fact, understanding “magic” is bloody difficult. It it weren’t so, then it wouldn’t be “magic”.

It’s also worth observing that Meteor is not presented as a “framework”. The comparison with Rails was introduced here, on HN. They say it’s “a set of new technologies”. I guess this implies loose coupling, which is a healthy paradigm when applied to components/modules/objects of a development ecosystem.

If only Meteor were nothing more than a proof of concept, it would still be mind-blowing.

Re: Show HN: Meteor, a realtime JavaScript framework

#299

Post by mcgwiz »

I wonder how much money they burned to get that domain name. Overall, this seems to be a production that feels much glossier and slicker than other technology "debuts". Is this the new way to launch a technology? Razzle and dazzle the programmer into the latest cargo cult... :/

Re: Show HN: Meteor, a realtime JavaScript framework

#300

Post by infinite8s »

jmarinez wrote: post #246
grannyg00se wrote: post #226

Earlier quoted context omitted.

I'd like to see some additional detail on this particular idea: "In Meteor, your server code runs in a single thread per request, not in the asynchronous callback style typical of Node. " Seems one of Node's primary style advantages (async non-blocking style) has been eschewed.

Fibers take care of the "callback pyramid of doom" and makes it easier to write thick logic layers. However, it still would have the fairness and starvation issues that Node has with callbacks. It's still single-threaded and non-preemptive like "stock" node. I wonder how dependent Meteor is on Node? In other words, why Node? Is it for Node module compatibility? If it isn't, I'd love to see Meteor running on something…

Lua's coroutines have the same issues that you mention for node's callback (single threaded and non-preemptive)
Post reply on HN