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

101–110 of 350 posts

Re: Show HN: Meteor, a realtime JavaScript framework

#101

Post by silverlight »

This is very neat. I've been using Backbone + ShareJS[1] to do a lot of similar things for a current app I'm building. This is certainly nicer, though, with concepts like latency correction and support for keeping the user's changes in place whenever a template updates by only updating the specific elements that change (very cool).

A couple of questions for you:

1) What's the current and projected goal in terms of concurrency for the server? Is this going to be able to handle thousands of simultaneous connections? Is the Node server built on anything else like Socket.IO, or is it fully new and unique code?

2) How does this handle conflicts? ShareJS implements Operational Transformation[2] to attempt to smartly handle conflicting writes from multiple clients (used in Google Wave, for example). Does this just do a simple timestamp-based overwrite? If so, how far down the tree? I'm not familiar with MongoDB (sorry), but would it be at the object level? Or the property level?

[1] http://sharejs.org [2] http://en.wikipedia.org/wiki/Operational_transformation

Re: Show HN: Meteor, a realtime JavaScript framework

#102

Post by benrahn »

For a not-full-time developer like me (I've picked up bits and pieces here and there) Meteor might just blow the doors open on what's within reach of my prototyping abilities.

(Full disclosure: I'm friends with most of the Meteor crew, very excited to see the wrapping come off!)

Re: Show HN: Meteor, a realtime JavaScript framework

#103

Post by pennyblack »

luigi wrote: post #28

This feels to me a lot like how Rails felt back in 2005. A fundamental leap forward and an understanding of where web technology is going. I haven't felt that way about Node.js or even its higher-level frameworks like Express or Batman. This feels like "The One", even though I've been absorbing the docs and screencasts only for the last 20 minutes.

..and this is how people create hype.

now downvote me.

Re: Show HN: Meteor, a realtime JavaScript framework

#104

Post by iamgopal »

geoffschmidt wrote: post #2

Hey everyone! The four of us have been working very hard on this for the last six months, and we're excited to finally take the wraps off. Can't wait to hear what you think! We've got a lot more stuff coming over the next few months, and if there are particular things you'd like us to do/prioritize, I'd love to hear about them!

Can you relax server side requirement a little bit ? Lots of people, including me, want to run such app on google app enigne which do not support node.js yet.

Re: Show HN: Meteor, a realtime JavaScript framework

#105

Post by davej »

Geee wrote: post #78

Would it be possible to set it up so that the initial page load is completely static html served from cache? The page would then be updated when it changes, i.e pushed to client and new cache. There's lots of overhead on both server and client side generating everything dynamically, especially on slow mobile clients. Testing it on fast machine on localhost creates visible delay in initial DOM update. On typical conte…

I agree, I want to call the Meteor framework revolutionary, but this is the one thing that's stopping me. Unfortunately, it's only suitable for web applications (i.e. not content sites) because Google can't index it and permalinks wont work in browsers that don't support push state (IE 9 and below don't support push state).

In my opinion, this is the missing feature to make Meteor revolutionary in the process of web development.

Re: Show HN: Meteor, a realtime JavaScript framework

#106

Post by fruchtose »

geoffschmidt wrote: post #17
davidcann wrote: post #15

Is there a built-in way to execute different code on the server, such as proprietary business logic, custom authentication, non-cross-domain APIs, etc?

Certainly! Take a look at Meteor.methods. That lets you define a method that the client can call without necessarily having the source. (If you give the client the source it will be able to do predictive latency compensation. But you don't have to. Or you can give the client a "stub" implementation that just inserts some placeholder records, while the server goes off and moves the forklifts around your warehouse over…

Just to hear it explicitly, does this library allow the client to call a server-side function without the end user ever seeing the source of the server-side function? That's my biggest concern, especially with the emphasis in the video on, "The client can access the DB!"

Re: Show HN: Meteor, a realtime JavaScript framework

#109

Post by guscost »

silverlight wrote: post #101

This is very neat. I've been using Backbone + ShareJS[1] to do a lot of similar things for a current app I'm building. This is certainly nicer, though, with concepts like latency correction and support for keeping the user's changes in place whenever a template updates by only updating the specific elements that change (very cool). A couple of questions for you: 1) What's the current and projected goal in terms of co…

It looks like David Greenspan (the guy who created EtherPad and then got hired by Google to work on Wave) is on the team so it's probably safe to assume that OT is a feature.

Re: Show HN: Meteor, a realtime JavaScript framework

#110

Post by underwater »

stelford wrote: post #10
rabidsnail wrote: post #4

"You can use the database api on the client!" Does that freak anyone else out? Where are they doing permissions checking? Who can run what database commands under what circumstances?

Urm. Yeah. It scares the ba-jesus out of me. The first thought when I heard this "killer feature" was, 'well, there goes security out the window'. Stupid hypnic jerk question perhaps, but, how's it deal with injection attacks ? is this left upto the javascript programmer to make sure strings are "safe" ? I almost dread the answers.

The screencast showed they were using Mustache for templating. That should prevent XSS.
Post reply on HN