Why Meteor will kill Ruby on Rails • Hacker News Board

Re: Why Meteor will kill Ruby on Rails

#71

Post by acqq » Wed, Oct 30, 2013, 9:10 PM UTC

squidsoup wrote: post #70

chestnut-tree wrote: post #29

Earlier quoted context omitted.

I'm against this too. Why do we want Javascript engines serving simple text pages instead of HTML? What about accessibility? Look at the source code of the linked article. What would a screenreader user encounter if they visited this page?

Pardon the pun, but that old chestnut? Contemporary screen-readers implementing WAI-ARIA ( http://www.w3.org/WAI/intro/aria ) work with javascript web applications.

Ever tried the above site with the screen readers? The sites produced with Meteor? I claim it would be easier for most of the programmers to generate HTML representation than to implement support for that. HTML is basics. Everybody can test it: just turn off JavaScript.

Re: Why Meteor will kill Ruby on Rails

#72

Post by programminggeek » Wed, Oct 30, 2013, 9:15 PM UTC

orclev wrote: post #49

programminggeek wrote: post #12

It depends on your definition of kill. If you mean for new project starts, it might severely diminish it, but I don't think it will flat out end its popularity any more than Rails killed Java. Also, it depends on what type of project you are talking about. For something at large scale, my guess is meteor won't be any more successful than Rails has been at huge scale (like Twitter). I do agree that using one language…

Ruby and Java don't really compete in the same space, it would probably be better to compare Ruby and PHP as those two are the primary competitor with each other. If you wanted to point to a competitor to Java, .Net would probably be the closest match.

I agree, but when Rails came out, there was a whole lot of Ruby on Rails is going to kill Java type posts. I guess this means Meteor is reaching some mindshare.

Re: Why Meteor will kill Ruby on Rails

#73

Post by subsection1h » Wed, Oct 30, 2013, 9:20 PM UTC

subsection1h wrote: post #66

Is your blog powered by Meteor? I ask because your blog has some major issues: First, when I load http://differential.io/blog and click a link for an old article, the content of the "Why Meteor will kill Ruby on Rails" article is displayed instead of the content of the article I wanted to read. This happens for every article. Second, when I load http://differential.io/blog , scroll down to an old article, click the a…

I visited Meteor's blog just now at http://www.meteor.com/blog to see if it would break my Back button the way that your blog did. Indeed, it did. Clicking my Back button at a Meteor-powered site seems to always direct me to the top of the previous page, not to the location on the previous page where I left off. As I wrote in the parent comment, this issue is very annoying.

Is this a problem that the Meteor developers are working to resolve?

Re: Why Meteor will kill Ruby on Rails

#74

Post by orclev » Wed, Oct 30, 2013, 9:26 PM UTC

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…

Similarly on the Java side you've got JSF which is basically ASP.Net ported to Java. It was a dumb idea when ASP.Net did it, and it was still a dumb idea when it was ported to Java. Now we have the same dumb idea ported to Javascript. Also as you point out, Javascript.

Thanks but no thanks, give me a proper REST API on my server, and a good JS framework on my client, and I could really care less what language the server code is done in so long as it's easy to build the REST services I need in it.

Re: Why Meteor will kill Ruby on Rails

#75

Post by ambiate » Wed, Oct 30, 2013, 9:31 PM UTC

acqq wrote: post #20

I can't read the site (there's nothing in HTML) but is this a framework that doesn't produce pages viewable without JavaScript? If it is against HTML, my vote is against it.

http://docs.meteor.com/#spiderable

Could this could be used if the browser does not support JS?

Re: Why Meteor will kill Ruby on Rails

#76

Post by bashcoder » Wed, Oct 30, 2013, 9:33 PM UTC

Nah. Because JavaScript.

Re: Why Meteor will kill Ruby on Rails

#77

Post by joshowens » Wed, Oct 30, 2013, 9:33 PM UTC

edwinnathaniel wrote: post #36

When Meteor was released couple months ago on "Show: HN" or something, I recalled unit-testing is not part of the release. Wonder if that's still the case? Maybe it's common not to have good unit-tests? (integration/functional-test does not count as unit-test).

There are plenty of easy to install unit-test packages. Laika, Chai, etc.

Re: Why Meteor will kill Ruby on Rails

#78

Post by Eptis » Wed, Oct 30, 2013, 9:44 PM UTC

I don't really see you making good points as to why Meteor would kill Rails. So Meteor lets you deploy apps quickly, but how is the rest of the development cycle after that? You can find more JS developers than Rails developers, but since when is more always better? You write JS on the front and backend and don't have to switch all the time because Meteor does a lot, but why is easier better?

Re: Why Meteor will kill Ruby on Rails

#79

Post by chestnut-tree » Wed, Oct 30, 2013, 9:55 PM UTC

squidsoup wrote: post #70

chestnut-tree wrote: post #29

Earlier quoted context omitted.

I'm against this too. Why do we want Javascript engines serving simple text pages instead of HTML? What about accessibility? Look at the source code of the linked article. What would a screenreader user encounter if they visited this page?

Pardon the pun, but that old chestnut? Contemporary screen-readers implementing WAI-ARIA ( http://www.w3.org/WAI/intro/aria ) work with javascript web applications.

"Contemporary screen-readers implementing WAI-ARIA...work with javascript web applications."

This isn't a web application though (in terms of interactivity), it's a plain text page. Why do we want Javascript to serve plain text pages like this?

Also, on the WAI-ARIA site, the expectation seems to be that Javascript is used for dynamic content or widgets (for which there are Aria-roles), but that HTML is used for text content (correct me if I'm wrong about this).

Again, if you look at the source code of this page, I can't see how it would be accessible.

Re: Why Meteor will kill Ruby on Rails

#80

Post by AndrewBissell » Wed, Oct 30, 2013, 10:18 PM UTC

tieTYT wrote: post #69

AndrewBissell wrote: post #13

> Java promised this too us back in the 90's, but it was too big and bloated and hard to work with LOL @ Java being described as "hard to work with" in comparison to JavaScript. Major indicator of JS developer Stockholm Syndrome right there.

Care to elaborate? I'm a Java developer, but I'd guess you're referring to browser fragmentation, not the JS language.

No, I'm referring to the languages themselves. JS does a very few things better than Java, but it is simply chock full of bizarre type coercion rules, strange semantics, and other "hall of mirrors" gotchas which make it much harder to learn and work with than other dynamic languages. And yes, Java has some of these too, but they occupy a much smaller share of the language base, and are often a side-effect of useful features (such as signed integer types) which JS doesn't provide.

We're stuck with JS because it's "the language that runs in every browser," but that's no reason to grant it praise that it hasn't earned such as "easy to use."

Fragmentation will create headaches regardless of which language is running in the browser.