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

331–336 of 336 posts

Re: Why Meteor will kill Ruby on Rails

#331

Post by computerslol »

spamizbad wrote: post #170
rywalker wrote: post #133

Earlier quoted context omitted.

I have more faith in open-source community to fix warts vs. closed-source Microsoft. I did ASP.NET back when it launched, and Microsoft wasn't setup to really listen to developers like the Meteor team is.

Actually, Microsoft did listen to their ASP.NET developer userbase. And ASP.NET developers loved them for it. And yet, despite Microsoft listening to their users, we're still not enchanted with ASP.NET... what gives? Lets say a framework's user base consists primarily of language-specific consultancy shops that really desire tools for rapidly prototyping applications. And the framework authors listen to these users d…

As someone that's been building high traffic applications on ASP.net for 11 years I generally stay out of threads like this. There is a ton of ill-informed (and more often than not blatantly false) asp.net bashing that goes on on this site. I see so much of it I generally just roll my eyes instead of hitting the reply button.

You can't use the silence of developers like me to prove a point when any pro asp.net content posted here is met with hostility.

ASP.net has an "easy mode". Easy mode is for small sites made quickly. If you're dragging and dropping, you're using easy mode. If you're only using the server controls provided, you're using easy mode. If you haven't extended or replaced any of the provided subsystems, you're using easy mode. I'd prefer developers from other platforms stop making comparisons between their platform and easy mode asp.net as if they knew what they were talking about.

ASP.net is a tuner's platform. It is completely modular, and anything you don't like can be replaced with something custom suited for your business/performance needs. This goes much deeper than custom server controls. You can look at the development of ASP.net MVC as an example.

If you want an easy framework to master, ASP.net is not the place for you. If you want something fast, scalable, strongly typed, customizable and built for large applications; you should have a look under the hood.

Those who haven't spent time getting intimately familiar with ASP.net's innards really have no place to comment.

Re: Why Meteor will kill Ruby on Rails

#332

Post by benaiah »

bjourne wrote: post #320
benaiah wrote: post #121

Earlier quoted context omitted.

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 so…

In addition to that to make robust pagination you need aggregation. Printing the message "you are looking at page X of Y pages" requires you to know the count of the collection or else you can't say how many pages there are. I.e You need to reactively monitor MongoDB's equivalent of "select count(*) from blaha". Doing that (without cheating and caching the count) is very expensive in Meteor.

How is caching the count "cheating"? Grabbing the count for every request would be ridiculously expensive in any framework, not just Meteor.

Re: Why Meteor will kill Ruby on Rails

#333

Post by computerslol »

computerslol wrote: post #331
spamizbad wrote: post #170

Earlier quoted context omitted.

Actually, Microsoft did listen to their ASP.NET developer userbase. And ASP.NET developers loved them for it. And yet, despite Microsoft listening to their users, we're still not enchanted with ASP.NET... what gives? Lets say a framework's user base consists primarily of language-specific consultancy shops that really desire tools for rapidly prototyping applications. And the framework authors listen to these users d…

As someone that's been building high traffic applications on ASP.net for 11 years I generally stay out of threads like this. There is a ton of ill-informed (and more often than not blatantly false) asp.net bashing that goes on on this site. I see so much of it I generally just roll my eyes instead of hitting the reply button. You can't use the silence of developers like me to prove a point when any pro asp.net conten…

In November W3techs.com's survey of the top 1 million web servers based on alexa.com traffic numbers found 18.6% to be running on ASP.net.

There may be a few more ASP.net developers out there than you assumed.

http://w3techs.com/technologies/overview/programming_languag...

Re: Why Meteor will kill Ruby on Rails

#334

Post by bjourne »

benaiah wrote: post #332
bjourne wrote: post #320

Earlier quoted context omitted.

In addition to that to make robust pagination you need aggregation. Printing the message "you are looking at page X of Y pages" requires you to know the count of the collection or else you can't say how many pages there are. I.e You need to reactively monitor MongoDB's equivalent of "select count(*) from blaha". Doing that (without cheating and caching the count) is very expensive in Meteor.

How is caching the count "cheating"? Grabbing the count for every request would be ridiculously expensive in any framework, not just Meteor.

One count(*) query per request is not expensive at all. Suppose you cache the count and someone else adds rows to the collection. Your cached count is not getting updated and the whole reactivity concept breaks down since your app now thinks the row count is different from what it really is.

Re: Why Meteor will kill Ruby on Rails

#335

Post by bigiain »

noptic wrote: post #253
bigiain wrote: post #215

Earlier quoted context omitted.

I'm sure you aren't going to worry too much, but you know some of us only see this: https://dl.dropboxusercontent.com/u/7633426/shinglecentral.p... https://dl.dropboxusercontent.com/u/7633426/assistantio.png https://dl.dropboxusercontent.com/u/7633426/listerio.png

This is a discussion about a javascript framework. Meteor relys on javascript on the client and the server so how should it work with noscript? If you want to use a javascript tool you´ll have to add an exception for this tool.

(A somewhat late response, since something I saw this morning reminded me of this discussion)

Compare the above screenshots with this one:

https://dl.dropboxusercontent.com/u/7633426/BundleHunt.png

it's "broken" in similar ways, showing markup like ${{product_price}}, but clearly includes enough static-content and context to allow be to choose whether I want to click my "allow scripts" button.

If somebody sent me a link to Shingle Central with no explanation, I'm highly likely to go "whatever" and move on t the next work-distraction-link…

Re: Why Meteor will kill Ruby on Rails

#336

Post by koffiezet »

The biggest issue I see with this is: MongoDB. Anyone who worked with serious SQL databases who looks at MongoDB shivers. It has not even solved problems 'classic' databases have solved for over 20 years. The entire "it is fast" thing is based on very smart Linux disk-caching strategies. It's reliability is questionable. It might work very well for you, but when it would go wrong, good luck!

Also I hate being tied down to 1 database back-end. At least make it a plugin or smth. That you use a NoSQL db for rapid prototyping, I do understand (although I don't like it), but you can do exactly the the same with Postgres 9.3 with the JSON extensions, and more. That way you build on a reliable, proven database which has solved the problems MongoDB is facing now a LONG time ago.

Oh, and the 'big data' argument for using NoSQL is plain bullshit, only a very small percentage of developers actually have worked with 'big data' that requires clusters to process.

Don't get me wrong, better frameworks are good, and I would be interested in Meteor if it wasn't for MongoDB being tightly integrated.

Post reply on HN