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

Why Meteor will kill Ruby on Rails

differential.io

Post reply on HN
Print view View original

121–130 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#121

Post by benaiah »

bjourne wrote: post #114
prezjordan wrote: post #96

Earlier quoted context omitted.

Your claim that the client has a full copy of the server's data is incorrect. By default that is the case, but removing such functionality takes only a few lines of javascript and removing the "autopublish" package (one command). Seriously, Meteor has grown up a lot recently. This stuff moves quick. I encourage you to take a look at it again, because I imagine many of your initial problems with the platform have been…

No stopping autopublish doesn't solve anything in this case. In my leaderboard example, the clients view of the highscore is dependent on all data in the collection which has to be published and the client has to subscribe to it. Even if you only want to show the best 10 scores of your 500k population, Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score d…

It's quite easy, and you still get reactivity. You publish the collection as before, but you write a server-side filter (a well-documented core feature) that only sends a small piece of that to the client. Even though the client only sends a small piece, the changes to those items are still reflected back to the server and other clients live.

It's supported this from the day it was released - I remember hooking up something quite similar at the time. It was never purely autopublish.

Re: Why Meteor will kill Ruby on Rails

#122

Post by joshowens »

avenger123 wrote: post #95

Josh, it's an increasing article. I don't know what types of apps your company builds but it would be nice to state that. I certainly don't think you believe that Meteor is a good fit for all kinds of web apps. It does seem like its a really good fit for the apps that your company builds. I would get more out of your article if you provide some context around the types of apps your company is focused on.

We generally build MVP apps for clients, we are a venture shop. I do think Meteor could be used for most web app cases and the ones it doesn't fit for now will be taken care of in the near term.

Re: Why Meteor will kill Ruby on Rails

#123

Post by jcutrell »

asdasf wrote: post #55
meowface wrote: post #38

Earlier quoted context omitted.

I already hate writing Javascript for the frontend. If I had to write it on the backend, too, I'd probably go insane. Coffeescript makes things a bit better, but only to an extent (plus it has a few odd quirks of its own). I'd much prefer if some day the reverse was possible: writing Python or Ruby on the backend AND the frontend. I imagine something like that would render Node rather useless. (And no, they did not i…

It is already happening. Not specifically with python or ruby (although possibly, I don't follow them), but several languages have "compile to javascript" options now. Just like we treat CSS as purely for the machine generated from the SASS which is for people, we treat javascript as purely for the machine generated from the haskell which is for people.

Opal and Decaf are two projects that run ruby in the browser. Opal compiles to JS. Decaf is a "modification of Webkit".

Decaf: http://trydecaf.org/ Opal: http://opalrb.org/

A quick google search gave me Pyjs. http://pyjs.org/

Re: Why Meteor will kill Ruby on Rails

#124

Post by neilkelty »

asdasf wrote: post #32
joshowens wrote: post #23

Earlier quoted context omitted.

No, the client that spawned this blog post was specifically asked for heavy google maps integration. We haven't had one client asking for just a server side app in years. I've been doing this for 8-9 years, I have a good idea on how to talk with my clients :)

And I haven't had a client ask for a javascript app ever. This is why anecdotes aren't very useful.

Are you serving the same market segment as OP?

Re: Why Meteor will kill Ruby on Rails

#125

Post by maerF0x0 »

bjourne wrote: post #114
prezjordan wrote: post #96

Earlier quoted context omitted.

Your claim that the client has a full copy of the server's data is incorrect. By default that is the case, but removing such functionality takes only a few lines of javascript and removing the "autopublish" package (one command). Seriously, Meteor has grown up a lot recently. This stuff moves quick. I encourage you to take a look at it again, because I imagine many of your initial problems with the platform have been…

No stopping autopublish doesn't solve anything in this case. In my leaderboard example, the clients view of the highscore is dependent on all data in the collection which has to be published and the client has to subscribe to it. Even if you only want to show the best 10 scores of your 500k population, Meteor doesn't allow you to subscribe to the Mongo equivalent of "select player, score from results order by score d…

5 minutes of my time, code to do what you're saying: https://gist.github.com/MaerF0x0/7242600

Re: Why Meteor will kill Ruby on Rails

#126

Post by morgante »

squidsoup wrote: post #65

Derby ( http://derbyjs.com/ ) ostensibly does everything that Meteor does, but seems to be flying a bit under the radar. I'd be interested to hear comments from anyone that has had experience building apps in both Derby and Meteor.

I've used both and actually prefer Derby. They don't toss out Node (which the Meteor team did), thus making it easy to leverage the growing Node ecosystem. Also, I'm constantly left scratching my head as to why the Meteor team chose to make backend code synchronous.

That being said, Meteor simply has a lot more developer talent (and money) behind it. Hence it's improving at a much faster rate than Derby.

Re: Why Meteor will kill Ruby on Rails

#127

Post by benaiah »

MichaelGG wrote: post #85
curveship wrote: post #68

It concerns me that the selling points of Meteor are the same as the old selling points of ASP.Net. - Both seek to make the divide between server and client "seamless", marshaling data back and forth so that you can "call" server code from the client and vice-versa. - Both tout the ability to do all your development in a single language - Both claim impressive gains for RAD ASP.Net had some impressive demos for its t…

ASP.NET enabled a lot of certain types of developers to quickly drag-n-drop web apps just like they did with VB Windows GUIs. The amount of code needed was pretty cool. Sure, it resulted in a less-than-ideal webpage, but it worked. VB.NET wasn't really a foundation; it had major changes from VB6 and had feature parity with C# (and more in some cases). Javascript is by far a much worse language. What should we expect…

While you are right, my view is simply that any developer incapable of understanding the difference between client and server has a snowball's chance in hell of actually creating something secure. Meteor may abstract some of the drudgery of client-server communication, but you still have to know the difference - both for security and implementation.

Re: Why Meteor will kill Ruby on Rails

#128

Post by _7fvc »

rco8786 wrote: post #117
_7fvc wrote: post #107

Catchy title but misleading. I can't access the blog. Josh, do you run your blog on meteor.com? You should migrate to a production-like environment. We ran into this issue before :) My team builds http://vida.io with meteor. We've got 100-200 visits a day, few thousands at our peak. I'm an experienced Rails developer and dabbled a little with nodejs. I can say meteor will change nodejs framework dev, but not kill Rai…

> I can say meteor will kill nodejs meteor runs on nodejs...

True, corrected.

Re: Why Meteor will kill Ruby on Rails

#129

Post by mark_l_watson »

I am very impressed by Meteor! Earlier this year I did an experiment: I coded a complete application in Clojurescript + Clojure back end, and then afterwards in Meteor.

I have tons of Clojure experience (with little bit of Clojurescript), and not too much use of Javascript. I spent much less time on the Meteor version and it had lots more features. Really no comparison. Unless you really dislike Javascript I suggest you try Meteor.

Re: Why Meteor will kill Ruby on Rails

#130

Post by qiqing »

bjourne wrote: post #92

I'll make an even bolder claim: Meteor doesn't work at all for anything except small toy apps. Meteor is built on the idea of reactiveness between server and clients. That is if the servers view of the data changes, then the clients views' must also change at the same time. It accomplishes that using websockets and letting each client have a full copy of all the servers data in memory. Works great for simple chats an…

Z-mongo-admin, the Meteor equivalent of phpMyAdmin, was a project that won a prize at the Meteor hackathon earlier this year. [1] Here's one of its authors, Geoffrey Vedernikoff, speaking at HackMIT. [2] Perhaps you could compare notes with the team to see what's going wrong in your version.

[1] http://www.meteor.com/blog/2013/07/09/congratulations-to-the...

[2] http://www.meteor.com/blog/2013/10/11/meteor-at-hackmit-onet...

Post reply on HN