Show HN: Meteor, a realtime JavaScript framework • Hacker News Board

Re: Show HN: Meteor, a realtime JavaScript framework

#341

Post by neilk » Thu, Apr 12, 2012, 6:50 PM UTC

maratd wrote: post #326

neilk wrote: post #320

Earlier quoted context omitted.

But they aren't accessing the database. They are accessing a data structure on the client, and changes are propagated to the server. There are opportunities to reject that change at the server. This trick is already in use in a lot of places. If you click an upvote on Reddit, it doesn't do a complete round-trip, it just increments the count in place, and then issues a command to the server to do a "real" increment. I…

All true, but then you're essentially lying to the client. You are saying something happened, when it didn't. I understand the argument that this type of lying is "ok" for the sake of responsiveness, since 99% of the time the data will be accepted. That argument isn't valid in my eyes. When I update the users screen to reflect the data they entered, to me, that's an indication that I accepted the data. If I were to f…

I agree with you for some things, but not others. If you are making a hotel reservation it would be retarded to indicate to the user that it was accepted, when you don't have confirmation.

But, you can still use this model of data synchronization with a bit of good manners. You create a "registration" data object locally, with a "confirmed" flag set to false. You wait for that data to propagate to the server, and for the confirmed flag to be set to true. You show the user a spinner until the confirmed (or processed or whatever) thing changes.

Re: Show HN: Meteor, a realtime JavaScript framework

#342

Post by spasquali » Thu, Apr 12, 2012, 10:02 PM UTC

This is just the client code necessary to run a todo app: https://github.com/meteor/meteor/tree/master/examples/todos/...

Seems rather fat. Fatter than what I've seen for Knockout, or Ember, or even Backbone.

As I suspected this idea of just dropping any package and bang it works depends on that package having been made available by the Meteor team, and the requisite wrapper/bindings made around the original package. Which means now using Meteor means you must use their package, which even with best intentions, means their team will have to keep up to date with every package you'd like to use, every new version, the bugs, etc.

What if my data comes from multiple sources ("the cloud" and "big data" and "3.0" means your apps don't all share the same persistence layer, and likely use several)

What if I push 1000 records of data to the client, in the html for efficiency and network reasons, to power my fancy D3 chloropleth, and the client interface allows manipulation of that (local) data. How do I take advantage of Meteor's data binding system? This is something almost every serious application does -- updating a local data structure and propagating that change to several views.

Overhead of having all these sockets open? If I want to change 20 items and then update my view, do I now have to write the boilerplate to store up 20 changes, then package, then send in one shot down the Meteor pipe? Do I make 20 calls via client DB bindings? Probably the former. Which means I end up doing a lot of work that I wouldn't have if I had a local model with CRUD methods (like Ember, Backbone, etc).

Latency compensation. Sounds great. So I say "pay my bill" and my interface updates with an optimistic confirmation. Great! Now I can drive my kid to the soccer game. Hope I notice that the number got switched back (server fail). How will I notice? Hope the developer implemented a noticeable notification system...

Security? Anyone with a browser can change my DB? How do you secure that? Log in? Now logged-in people can change my DB from their browser? Whitepaper is necessary, so this aspect can be tested.

Great team. Good ideas. But it is quite early yet.

Re: Show HN: Meteor, a realtime JavaScript framework

#343

Post by spasquali » Thu, Apr 12, 2012, 10:03 PM UTC

spasquali wrote: post #342

This is just the client code necessary to run a todo app: https://github.com/meteor/meteor/tree/master/examples/todos/... Seems rather fat. Fatter than what I've seen for Knockout, or Ember, or even Backbone. As I suspected this idea of just dropping any package and bang it works depends on that package having been made available by the Meteor team, and the requisite wrapper/bindings made around the original package.…

Meteor packages: https://github.com/meteor/meteor/tree/master/packages

The comments here are telling: https://github.com/meteor/meteor/blob/master/packages/handle...

Re: Show HN: Meteor, a realtime JavaScript framework

#344

Post by moe » Thu, Apr 12, 2012, 11:38 PM UTC

geoffschmidt wrote: post #335

moe wrote: post #87

Earlier quoted context omitted.

Portability, robustness, flexibility and security. There's little reason to spread out a package like meteor all over /usr/local. But many reasons against doing that. To illustrate, a few simple questions: What if I need multiple meteor versions on the same system (different versions for different users/projects)? How do I quickly switch between different meteor versions (often needed in fast-moving projects like thi…

I agree with all of this :) Meteor is self-contained and installing it in /usr/local is totally optional. The reason we install into /usr/local is that it is a way to get the 'meteor' command into the user's path without trying to edit their dotfiles for them, and without setting obscure system preferences that the user would have trouble unsetting. We went to a lot of trouble to make it easy to try Meteor, and we th…

Thanks for the exhaustive response.

I agree with almost everything you say; you seem to have it right then, I just didn't go through github so I never saw the README.

However, I would still argue that you should get rid of the packages, that's extra-work you could better spend elsewhere. For someone installing a dev-toolkit it's absolutely not too much asked to paste "echo >>~/.bash_profile 'source ~/.meteor/magic.sh'".

They have to do that anyway as soon as they need the latest git-HEAD because of some bug in the release version (we know how it goes, don't we? ;-)).

So by giving them the right instructions right away you save them this extra step. And you save yourself from making a bad (and false!) first impression on the older and grumpier devs like myself.

Re: Show HN: Meteor, a realtime JavaScript framework

#345

Post by malandrew » Fri, Apr 13, 2012, 3:47 AM UTC

binarymax wrote: post #212

geoffschmidt wrote: post #203

Earlier quoted context omitted.

Hey, one of the Meteor authors here. Meteor's architecture makes it super easy to make an API. It's one of the advantages of building your architecture around sending data around rather than HTML. We couldn't go into everything in the video (it was already too long!), but the piece you're missing is Meteor.methods(). This lets you define methods, which are functions that the client can invoke on the server by calling…

Thanks. What does DDP stand for? I found several possible definitions.

From talking to deberg (matt debergalis) on #meteor, ddp stands for distributed data protocol and in his words "is a combination of remote method invocation and attribute pub sub, tied together in a way that [allows] latency compensation on the client by simulating server methods"

Re: Show HN: Meteor, a realtime JavaScript framework

#346

Post by chrisherring » Fri, Apr 13, 2012, 4:49 AM UTC

chrisherring wrote: post #137

What's the roadmap for supporting windows? I tried to install meteor using cygwin and hit "Sorry, this OS is not supported yet.".

http://stackoverflow.com/questions/10108840/meteor-and-windo...

Re: Show HN: Meteor, a realtime JavaScript framework

#347

Post by raphinou » Fri, Apr 13, 2012, 11:05 AM UTC

micheljansen wrote: post #308

nosequel wrote: post #262

Earlier quoted context omitted.

"this is nothing short of revolutionary." Oh FFS, this is not revolutionary. It is an attempt to wrap things in a friendlier package, while at the same time making something horribly insecure as a default install. Ruby on Rails did that a long time ago. Better examples of revolutionary: Manned Flight: http://en.wikipedia.org/wiki/Wright_Flyer http://en.wikipedia.org/wiki/Apollo_11 In computers: http://en.wikipedia.or…

I get your point, but just because you can name examples of other technological advances that are more revolutionary, does not mean that this (in its own small world) cannot be described using that term. Revolutionary (according to the Oxford English Dictionary) simply means "involving or causing a complete or dramatic change". A technology that dissolves the boundaries between client-side and server side development…

http://www.webtoolkit.eu dissolves boundaries between client and server, and has been available for years. You shoult take a look.

Re: Show HN: Meteor, a realtime JavaScript framework

#348

Post by herdrick » Fri, Apr 13, 2012, 5:29 PM UTC

micheljansen wrote: post #208

My first impression of this: wow. If Meteor is all it appears to be, this is nothing short of revolutionary. My second reaction: what happens when the magic ends? When I was new to Rails, I really loved how easy it was to get started with scaffolding, a nice DSL for specifying relations, nifty form helpers. However, the first time I veered a little off the golden path and wanted to do something a little more complica…

API question answered here: http://news.ycombinator.com/item?id=3826814

Re: Show HN: Meteor, a realtime JavaScript framework

#349

Post by atleta » Sun, Apr 15, 2012, 8:27 PM UTC

The demo video looks nice, but to me it stinks. Maybe I wasn't listening carefully enough, but exposing the database to client code...? Almost a decade ago, back the time when we were writing Java apps, there were some debates around if you should write fat clients (business logic in clients) or not on a local java email list. I happened to throw in the counter argument that you shouldn't give direct access to your db to anyone, but your own code. (Which means you have to use an API, because you can't control what's happening on a client.) Then some DBA guy said that you have to set up the DB access rights anyway and that should be enough. But of course, if you don't use stored procedures, you can't do it fine grained enough. And these were SQL databases (!). We know how that story ended.

But what I see here, is retrying what already have failed, only know the DB is even less protected. Doesn't seem very wise to me.

Re: Show HN: Meteor, a realtime JavaScript framework

#350

Post by infinite8s » Mon, Apr 16, 2012, 7:15 PM UTC

jmarinez wrote: post #322

infinite8s wrote: post #300

Earlier quoted context omitted.

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

Coroutines and fibers in general, regardless of the language avoid the "pyramid callback" that can - depending on the developer - in spaghetti code. Lua on its own right, is a bit special. Fast, small, easy syntax - almost similar to Javascript when you think about it. However, "Coroutines in Lua are not operating system threads or processes. Coroutines are blocks of Lua code which are created within Lua, and have th…

You avoid the code spaghetti problem that you can see with multiple levels of callbacks, but you still have the problem that doing a blocking operation in a coroutine (even something cpu bound like a long calculation) will block the entire lua process.