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

Meteor hits 1.0

meteor.com

Post reply on HN
Print view View original

151–160 of 250 posts

Re: Meteor hits 1.0

#151

Post by imslavko »

kfinley wrote: post #147
liscovich wrote: post #139

I wonder if the criticism that the Flux team at Facebook has directed at two-way data binding is also applicable to Meteor. Jing Chen is her intro of Flux ( https://www.youtube.com/watch?v=nYkdrAPrdcw&list=PLb0IAmt7-G... ) says that two-way data binding creates a major challenge for scaling applications because views can trigger changes in data, and data changes can trigger cascading changes in views, which makes it…

I don't believe Meteor has two-way data binding. You have to update the model manually using events[0]. 0: https://docs.meteor.com/#/full/eventmaps

Two way data-bindings are not a Core feature and they are implemented in packages. My favorite one is this: http://viewmodel.meteor.com/

Re: Meteor hits 1.0

#152

Post by emgee3 »

chm wrote: post #68
dasmithii wrote: post #60

At this point, what percentage of web development can't/shouldn't be done with Meteor? It seems like everything else is obsolete in comparison. The only non-Meteor cases I can think of involve especially large scale.

Because Meteor hides much of what's really going on, it's sometimes hard to understand just how the app is working. At least that was my impression of it when I tried it about 9 months ago. Choosing a stack on your own means more time is spent making things work, but then you know how it works. That's why I went for a MEAN stack instead of Meteor. But I'm going to try Meteor again soon!

While Meteor does do a lot for you out of the box, it doesn't really prevent you from seeing what's going on. There are some good resources for seeing what Meteor is doing behind the scenes (meteorhacks.com and eventedmind.com) if one does want to dig in.

Re: Meteor hits 1.0

#153

Post by aliakhtar »

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic?

Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized javascript. That has the added advantage of letting you use a sane, strongly typed language, with all the productivity tools available for Java, and none of the quirks of javascript. http://www.gwtproject.org/overview.html

Re: Meteor hits 1.0

#154

Post by swartkrans »

aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

Re: Meteor hits 1.0

#155

Post by imslavko »

aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers.

Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the actions validation rules still apply on this executed logic and if clients disagree with the server (the privileged environment), clients cannot harm the server state.

Re: Meteor hits 1.0

#156

Post by [deleted] »

aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

[deleted]

Re: Meteor hits 1.0

#157

Post by jay-saint »

michaelq wrote: post #137
theckel wrote: post #123

Earlier quoted context omitted.

"We" are providing a large scale application in the education space, with more details to follow. I am not able to give much more now, but I can say that given the contractual nature of our application, we've been fortunate to start out with a HUGE user base that has taxed Meteor and exposed its scalability issues more than most typical Meteor apps at this time. It's still young, and there are some significant advanc…

I'm excited to hear about it. http://fourbeansoup.com/ has some cool-looking apps!

the site tweet hopper dot com link from this site appears to have been compromised and is pushing malicious scripts be careful.

Re: Meteor hits 1.0

#158

Post by [deleted] »

swartkrans wrote: post #154
aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

If you read the docs you will see it's not implemented in an insecure way. The core meteor devs are pretty brilliant people, creator of etherpad, svn core contributer, early asana employee, these people aren't dummies they wouldn't do something that silly. Such a dumb thing would have been called out way before 1.0 wouldn't you think? Maybe give it a moment of thought before you comment.

[deleted]

Re: Meteor hits 1.0

#159

Post by e12e »

aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

Trusting the client with all things is a bad idea. Running stuff like presentation/layout/gui on the client makes sense. For some things, it makes sense to run the same code first on the client, but the again on the server (so not really trusting the client). Example: form validation. You want to run it on the client, to give early feedback. You need to run it on the server, because you can't trust client-supplied data. Makes your life a lot simpler, if you only need to implement the validation code once, even though you use it both on the client and on the server.

Re: Meteor hits 1.0

#160

Post by aliakhtar »

imslavko wrote: post #155
aliakhtar wrote: post #153

I've read somewhere that a use-case of Meteor is to let you write your server-side logic in javascript, and then run the server-side logic on the client. Wouldn't that be clearly insecure, to trust the client with running server logic? Also, this was accomplished years ago with Google Web Toolkit, which lets you write both the server & client in Java, and compiles the client-side java to very efficient, optimized jav…

The logic runs on the client only for optimistic UI changes (getting to the right state and displaying the right data w/o waiting for a server to reply). In Meteor this is called "latency compensation" and you can read more about it here: https://www.meteor.com/full-stack-db-drivers . Meteor implements it in such a way, that app developer decides what logic is latency compensated and what is not. Furthermore all the…

Querying your database from client javascript seems like a bad idea. Even if they're not real queries, you are exposing the internals of your system, db column names / queries, etc.
Post reply on HN