47 ms·

Why Meteor will kill Ruby on Rails

• rywalker 13y ago
  It might take some time, but I have to agree after working in Meteor for a few months, the developer experience is much better than trying to do Rails/Backbone Rails/Ember or Rails/Angular.
  • joshowens 13y ago
    100% agree after a few months of hardcore work and then being forced back into rails.
  • angersock 13y ago
    Ah, but one wonders about that comparison for vanilla Rails?
  • brucehubbard 13y ago
    It's not quite there yet but it's getting better by the day. There are still some things like UI animations that are possible in Meteor but aren't quite as easy as they are in client side Javascript frameworks. It makes me feel a little better though that they are trying to be transparent about the flaws by publishing their roadmap: https://trello.com/b/hjBDflxp/meteor-roadmap https://trello.com/b/hjBDflxp/meteor-roadmap
• purephase 13y ago
  It's the framework I'm most excited about and watching closely. I still think Rails has a place in the back-end (e.g. API) but Meteor is showing a lot of promise.
• al2o3cr 13y ago
  "Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere." Similarly, anal sex is the best kind because it works on all genital configurations. /snark
  • petercooper 13y ago
    I suspect there's a significant number of people who would actually agree with that though.
    • dfischer 13y ago
      Touché Peter, touché.
  • aaronem 13y ago
    No it doesn't; you need at least one penis involved. /taking-snark-seriously
    • petercooper 13y ago
      A fake/simulated penis would work though in a lesbian pegging scenario.
• rimantas 13y ago
  > What if you could spend your time in one language > and one framework? What if you eat everything with a fork?
  • buckbova 13y ago
    What if you eat everything with a spork?
    • JackFr 13y ago
      What if you eat everything?
    • winslow 13y ago
      Sporks are for amateurs, why not Knife Wrench? http://youtu.be/x22yNaLdiGA http://youtu.be/x22yNaLdiGA
    • oftenwrong 13y ago
      Then you probably don't eat spaghetti.
      • buckbova 13y ago
        You must not be familiar with this utensil. It is a spoon with a fork like end. Many a plate of school lunch spaghettis has been eaten with a spork.
        • FooBarWidget 13y ago
          It's still much easier and more efficient to eat spaghetti with chopsticks.
        • oftenwrong 13y ago
          All of the sporks I have used have tines that are too short for proper spaghetti-twirling. Also, their bowls are always so shallow that it makes soup a chore to consume. What kind do you use?
• zyang 13y ago
  Bold claims - at least fix the glitches in your blog first.
• cjbprime 13y ago
  Is the inability to get HTML without being a javascript engine going to be a problem for major adoption? (I know there are hacks around using phantomjs to generate HTML for non-JS clients -- is that a viable solution for serious sites?)
  • rywalker 13y ago
    Meteor has a package 'spiderable' which allows Google to index the content — we're having no problems with it.
    • cjbprime 13y ago
      Yes, that's the PhantomJS hack.
• programminggeek 13y ago
  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 end to end might be an awesome developer experience, but I wish that language wasn't JavaScript. I won't go into great detail as to why, but I would not want to build a large JavaScript app. That sounds incredibly painful and unpleasant to me.
  • edwinnathaniel 13y ago
    Definitely not today when the tools, the best practices, the state of the libraries are still below average and the developers have varying skill sets. Who knows 5-10 years down the line...
    • orclev 13y ago
      I'm sure 10 years down the line someone will be raving about how the latest NinjaScript based framework is going to be the death of Foo#, and anyone who doesn't think so should go back to their crusty old enterprise Ruby legacy code.
      • gesman 13y ago
        ...and there aren't too many truly "enterprise" code written on ruby. Enterprises use Java or .Net.
  • orclev 13y ago
    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.
    • 13y ago
• AndrewBissell 13y ago
  > 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.
  • tieTYT 13y ago
    Care to elaborate? I'm a Java developer, but I'd guess you're referring to browser fragmentation, not the JS language.
    • AndrewBissell 13y ago
      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.
      • woah 13y ago
        I've never had any type coercion bugs, can you elaborate?
        • hrjet 13y ago
          https://www.destroyallsoftware.com/talks/wat https://www.destroyallsoftware.com/talks/wat
• vezzy-fnord 13y ago
  How exactly did the author come to this Meteor and Rails dichotomy? What do they have alike besides being web application frameworks, of which there are endless? This makes about as much sense to me as "Why Flask will kill Zend".
  • joshowens 13y ago
    I came from Rails after using it for 8 years, so it is my easiest comparison point.
    • dham 13y ago
      Give this whole Meteor thing some more time to sink in. Your still in the honeymoon phase. I know this because you list context switching. Anyone that moves to Node(or meteor) and lists context switching as a reason, is not long for this world... of switching to node. I'm not going to convince you here, but just proceed with caution. It would be like me convincing my friend after he's dated a girl for a year that she's a total ass. Not going to happen.
  • chc 13y ago
    They're both web frameworks with a heavy focus on RAD. It's hard to see how much more similar they could be before they started to become indistinguishable.
  • VeejayRampay 13y ago
    The author came to this Ruby on Rails dichotomy for the very same reason other frameworks/languages are doing so: 1) To cash in on Rails's good rep and outstanding efforts in the field in the past 10 years or so. 2) Because the author knows that people are fiddle and that new fashions are made and destroyed every other day, so why not scare people a little if that can help Meteor get off the ground, eh? 3) Because shitting on Rails is trendy these days and it's always very easy to precisely target the relative weaknesses of a framework whilst pretending to ignore its strengths. Anybody with half a brain can play that game. That being said, it doesn't diminish Meteor's merits in any way and I really hope its community thrives and grows in the next few years. The first few years are always the best ones :)
• xsighted 13y ago
  Technically, you can use meteor with rails https://github.com/tmeasday/ruby-ddp-client https://github.com/tmeasday/ruby-ddp-client, so I don't know if meteor is killing rails anytime soon.
• nemoniac 13y ago
  If you don't accept its cookies, it shows you a blank page. I hate to be negative but that's not how to win my confidence.
  • rwty 13y ago
    I'm thinking of setting up a wall of shame for sites that won't load w/ cookies off.
• carsongross 13y ago
  "When a client asks us to build an app, they are really asking for a fully interactive web app that utilizes javascript to get rich client interfaces." Or maybe they really are just asking you for an app, but you'd rather build a fully interactive web app that utilizes javascript to get rich client interfaces.
  • joshowens 13y ago
    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 :)
    • asdasf 13y ago
      And I haven't had a client ask for a javascript app ever. This is why anecdotes aren't very useful.
      • joshowens 13y ago
        Insert mis-attributed Henry Ford quote about customers wanting faster horses
        • mtkd 13y ago
          If you're going to make a bold prediction about Meteor killing Rails be prepared for some heat - your responses to that heat may progress or regress the argument.
          • joshowens 13y ago
            I'm cool with the heat. I am not perfect, don't pretend to be. I welcome the conversations and I am seeing interesting responses.
        • asdasf 13y ago
• acqq 13y ago
  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.
  • chestnut-tree 13y ago
    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?
    • squidsoup 13y ago
      Pardon the pun, but that old chestnut? Contemporary screen-readers implementing WAI-ARIA (http://www.w3.org/WAI/intro/aria http://www.w3.org/WAI/intro/aria) work with javascript web applications.
      • acqq 13y ago
        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.
      • chestnut-tree 13y ago
        "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.
  • ambiate 13y ago
    http://docs.meteor.com/#spiderable http://docs.meteor.com/#spiderable Could this could be used if the browser does not support JS?
• mmanfrin 13y ago
  I was halfway through reading the article, then the page refreshed and blanked out. Now it displays 'Oops, this page can not be found'. What?
• lambda 13y ago
  While I was reading this post, the page automatically reloaded to something that said "oops, this page can't be found", and then a few seconds later loaded back to the original. This is while I was simply reading the text, not interacting with the page at all. Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
  • orclev 13y ago
    I had to accept cookies from the site before it would even show me anything but a blank page.
  • acqq 13y ago
    It's not static and it's not readable HTML when accessed without JavaScript. If I understand, that's the feature of the framework that is being praised.
    • 1qaz2wsx3edc 13y ago
      I don't think that's completely fair. Meteor to me, is more cased for building realtime applications. Should a blog be a realtime application? Probably not, can it? Sure. Not only that but, but the page compensated. It's also kind of neat, that the author has indeed written a realtime blog. For fun: they could magically fix typos while you're reading.
      • joshowens 13y ago
        Perhaps I should write a quick event to highlight words as they get fixed in realtime :)
      • RockyMcNuts 13y ago
        Or users could legitmataly highlight typos and they could get fixed in real time.
        • joshowens 13y ago
• Kynlyn 13y ago
  The link is now a 404..I hope it wasn't powered by Meteor...
  • JPKab 13y ago
    The fact that its hosted at Modulus (the guys behind Demeteorizer, which allows you to host meteor apps on Node.js services) would indicate that its almost certainly a Meteor app to me. I DO think that Meteor is fucking awesome, due to the sheer speed you can crank out commonly requested features (you can add a Google/Facebook/Github Oauth login widget with one line of code), but it sure as hell doesn't seem to scale well these days.
• mindcrime 13y ago
  Did not read TFA, but my immediate thought on seeing this headline is "No, it won't". Why? Because software never really seems to die. Look at the billions of lines of COBOL or PL/I or FORTRAN still in use around the world. Look at the fact that (a few) people still use OS/2, which is about as dead as software ever really gets. Rails may well find it's popularity and prestige diminished, but I doubt it'll "die" anytime in any of our lifetimes.
  • j1z0 13y ago
    100% agree here. Way to many Rails developers around for it to die. Also as cool as Meteor is, and it's pretty cool. There is a huge continent of developers that will resist javascript for as long as possible, because even though it is ubiquitous, let's be honesty, it does suck in a number of ways. Ruby / Python / Go / etc.. are all so much nicer languages from a developer happiness perspective. Ultimately javascript will become more and more prevalent for sure, and Meteor along with it, but only because all the browsers decided to support it, NOT because of developer happiness.
    • pyGuru 13y ago
      if only all the browsers would run python... now that would be developer happiness. ;)
      • krapp 13y ago
        unless you happen to be one of those sickos who thinks significant whitespace is a terrible idea....
• gnufied 13y ago
  Why will a blog load anything over websocket? Link bait title and a blog that doesn't load.
  • scotth 13y ago
    I can think of one reason, although it's not necessarily a good one, or the only way to do it. Once the connection is established, the server could push down all required resources for the page, rather than wait for the browser to request them one by one.
    • joshowens 13y ago
      It is built in Meteor, we just switch our whole site to use it. We switch from rails because we have much more Meteor knowledge on our team.
      • rurounijones 13y ago
        "Right tools for the job" Meteor is not (and rails probably isn't either) the right tool for a simple blog like that. jekyll or something like that is. The fact that you used an inappropriate tool for a blog and then say on the blog how you use that tool for all your clients casts a shadow on your professionalism I feel.
  • mcrider 13y ago
    Liveblogs are one example.
• podman 13y ago
  Is this blog also running on Meteor? I can't get it to load so that's not instilling confidence. Maybe it's their host, https://modulus.io/ https://modulus.io/ that's having problems?
  • rywalker 13y ago
    it was us — HN blew up the single dyno the site was running on.
• davexunit 13y ago
  Let's all hop on the next hip web trend, guys! Rails has become so boring and mature. There are many languages better than Javascript for server-side programs, but monoculture is so much cooler. One size fits all and you'll like it.
  • JPKab 13y ago
    This is what Java guys said about Rails. "Hipness" is absolutely unrelated to whether something is actually good or not. I firmly believe that Meteor is a super fast way to build a certain kind of web app that just so happens to be very popular in businesses: CRUD apps where users can see other user's changes to data in real time. I will admit that older users are actually creeped out by other people seeing them type though. I guess its a generational thing.
    • asdasf 13y ago
      They were right when they said that about rails though. Rails was a fad. It was not good. It codifies industry worst practices into a framework that can most charitably be described as "writing PHP in ruby".
      • saraid216 13y ago
        Are we talking PHP before or after CakePHP?
    • davexunit 13y ago
      I'm not going to sing the praises of Rails. I think it is a pretty good framework, but it is one hell of a hype machine. As software gets older and more stable, people get bored and reinvent the wheel again, especially web developers that will stop at nothing until everything is written in Javascript. Rails was a fad. Meteor is a fad. Keep your nose out of hype.
      • camus2 13y ago
        Rails was such a fad it influenced every web framework after rails, and made Microsoft drop webforms.
• edwinnathaniel 13y ago
  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).
  • joshowens 13y ago
    There are plenty of easy to install unit-test packages. Laika, Chai, etc.
    • edwinnathaniel 13y ago
      Sure, there are plenty easy-to-install-but-not-necessary-to-use-properly tools out there as well. Not to knock off your argument but would love to see stronger emphasis on proper automation test (QUnit does not count as "proper") over the JavaScript community in overall.
• smathieu 13y ago
  Before meteor kills Rails, it should really fix the offline mode :) Blog try to refresh after HN traffic killed the backend.
• bowlofpetunias 13y ago
  Why do people put so much effort in comparing tool A to tool B when either of those tools only cover 5% of all the work that goes into any serious application, and the time saved by any advantage tool A has over tool B is pretty much negligible? I mean cool, so Meteor is maybe better for prototyping. Because that's all we're talking about here, prototypes and ultra-simple websites. It's always the same story, a shiny new tools that make the first weeks a little smoother, and after that it's business as usually for entire life cycle of the application. Except of course you now have to deal with a tool that still has years to go before it's really mature and stable, and any advantage you gained in the first few weeks is completely lost. This has nothing to do with software development, this is just about fashion.
  • joshowens 13y ago
    This isn't just fashion. We launch client apps in 6 weeks, time isn't negligible for us.
    • jarsbe 13y ago
      I'd love to see some examples of these apps, are you able to please share?
      • joshowens 13y ago
        Sure: http://www.shinglecentral.com/ http://www.shinglecentral.com/ http://assistant.io/ http://assistant.io/ http://lister.io/ http://lister.io/ Are just a few from the last 1.5 months.
        • pauletienney 13y ago
          how are doing those apps ?
        • camus2 13y ago
          http://assistant.io/ http://assistant.io/ : > Uncaught Error: Must set options.password > 62afa287c8fae43c43f745c9f43dbcd4b875e531.js:14 > Uncaught TypeError: #<Object> is not a function When trying to add attendees,nice UI though.
• jsnk 13y ago
  I watch some videos on Meteor website a while ago and I was really impressed. Stuff that's pain in the ass in Rails, you can do it quite easily on Meteor. One aspect that prohibits me from making the jump though is Ruby's third party gem ecosystem. Ruby has so many tried and proven gems for everything you can think of. Is there a website like rubygems.org in Meteor world?
  • akbar501 13y ago
    Community developed Meteor packages are on https://atmosphere.meteor.com/ https://atmosphere.meteor.com/.
• squidsoup 13y ago
  Derby (http://derbyjs.com/ 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.
  • morgante 13y ago
    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.
  • victorhooi 13y ago
    The documentation for DerbyJS is unfortunately somewhat thin on the ground at the moment, which is a shame. They do have this YouTube tutorial though, where they run through how they made the multiplayer story game: http://www.youtube.com/watch?v=V0DOGXmaT3g http://www.youtube.com/watch?v=V0DOGXmaT3g Code is on Github here: https://github.com/codeparty/multiplayernotepad https://github.com/codeparty/multiplayernotepad Demo (currently unavailable): https://stories.derbyjs.com https://stories.derbyjs.com
• subsection1h 13y ago
  Is your blog powered by Meteor? I ask because your blog has some major issues: First, when I load http://differential.io/blog 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 http://differential.io/blog, scroll down to an old article, click the article's link, and then click my Back button, I'm directed to the top of http://differential.io/blog http://differential.io/blog, not to the middle of the page where I left off. Very annoying.
  • subsection1h 13y ago
    I visited Meteor's blog just now at http://www.meteor.com/blog 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?
    • bhauer 13y ago
      I don't use Meteor, but If I recall correctly, when we added client-side composition to our blog [1], I had to capture the scroll position when I pushed a new entry into the history stack. When that entry is popped back off, I manually move the scroll position since the browser doesn't know to do that itself. I think it more or less works. If you scroll down and click one of the older entries and then press back, it should remember where you were in the bigger page. Kind of a pain in the rear, frankly. It was sort of fun doing the client-side composition, and I like the immediacy of it, but I'm left a little apprehensive. [1] http://www.techempower.com/blog/ http://www.techempower.com/blog/
  • rywalker 13y ago
    Thanks for identifying those issues — bugs we'll fix.
  • 13y ago
• curveship 13y ago
  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 time. But as we know, the warts emerged: - as apps grew larger and more complicated, the claim of "seamless" integration started to break down. The background traffic increased until the latency became untenable. Now you had to diagnose problems in a system that had been designed to be "invisible," meaning it was hostile to exploration. Why will Meteor be different? - The "one language" (VB.Net for ASP.Net, before C# became big) wasn't so hot a foundation. One word: Javascript. - It was an island. The background data-marshaling framework meant that it didn't play well with other software unless that software had been explicitly written/adapted to work with ASP.Net. ASP.Net wasn't bad at first, but the vaster ecosystem of the web quickly distanced it. What's the upgrade path for a Meteor app? What if I want to use Angular with it?
  • orclev 13y ago
    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.
    • joshowens 13y ago
      So it is ok to go build a node.js REST api and slap Angular.js on it and somehow that is better? You really should care what language/framework the server side is built in because someone has to work on it...
    • dham 13y ago
      I had the great privilege of working and maintaining a few JSF applications for a year or so when I first got into my job. -_-. I even had a greenfield project with it. It's probably the worse thing you can use, and after some asking, pleading, and convincing the boss we moved to Play 1.x. That turned to be a wank fest with the whole Scala and Play 2 thing coming in a year or so later. We ended up just going to the source of all good MVC frameworks and landed on Rails, with a move into Node for a few months before Rails. I tried Meteor a few times and the whole thing just reeks of JSF. I wont touch it with a ten foot pole. On the other hand Rails and Ember really flow good together. I was more of an Angular fan, but the whole Ember integration is great. Rails makes it really easy to do nice API's without a whole lot of boilerplate. Database handling is awesome. Migrations are nice. Lots of gems. I feel like someone is holding my hand, while with Node I felt like I was holding my breath the whole time. If that makes sense. It was like a sigh of relief when we moved to Rails. The whole context switching thing is overrated IMO.
• bashcoder 13y ago
  Nah. Because JavaScript.
• Eptis 13y ago
  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?
• l34ch 13y ago
  Damn meteor is cool beans...
• bjourne 13y ago
  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 and for highscore lists consisting of 10-20 items. Not so great when there are 500k items ordered by score and someone wants to paginate through all of them. It's trivial in a sql-database backed application, but more or less impossible with Meteor because you can't listen to arbitrary queries without having the whole collection in the clients memory. Btw, I'd love to be proven wrong though. I tried to write an equivalent of phpMyAdmin for the Meteor+MongoDB combination, but I couldn't figure out how to how to provide clients with an always updated view of mongo collections without running them out of memory.
  • prezjordan 13y ago
    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 settled - there are still people out there who feel any user can clear out the whole DB from the client .
    • bjourne 13y ago
      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 desc limit 10" (last I checked anyway) And even if it did, well what if you want to see result 11-20 or the 10 best scores among your friends? You or someone else is very welcome to prove me wrong here and I'll admit I'm an idiot. All that is needed is 1 grid, 500k items, allow me to sort up and down on the headers and let me paginate through it as I please and support 5 simultaneous users. Trivial to write using Rails or Django. I claim impossible to write in Meteor.
• avenger123 13y ago
  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.
  • joshowens 13y ago
    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.
• dasil003 13y ago
  Before we get carried away, let's remember that the web has tremendous utility outside of applications. Progressive enhancement is still the best way to do a great many types of websites. Rails succeeded because it tied together the fundamentals of the web in a nice package. Meteor is another step-change for a certain kind of real time application, but that is by definition a much narrower use-case.
  • joshowens 13y ago
    I see realtime as a great side effect coming with the framework, to be honest. Meteor itself makes it easier to write clean client side JS code where I care much less about the backend when I start.
• awj 13y ago
  That's a bold claim to make when your blog can't function without cookies. Also, after it loaded, the only point that seemed to be directly related to Rails had to do with teaching designers to use templates and the asset pipeline. If that's your only Rails-specific issue then you're really claiming that Meteor will kill all other kinds of web development.
• davidbanham 13y ago
  Does Meteor scale beyond a single server yet? Because until then I can't see much use for it.
• dnprock 13y ago
  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 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 Rails. Some of the serious problems I found developing with meteor: - Reactive template is nice but can lead to very hard to debug issues. Small portion of applications (in general) need real-time. I often spend time disabling reactive update. There's no really good way to debug reactive update trigger. - Organizing, switching views/templates can get confusing for site navigation. - Package system is still infancy, has a VERY long way to catch up with Rails ecosystem. - Pub/sub model introduces a lot of performance issues. We have to limit the amount of data we send back. - Security: this is related to pub/sub model in previous point. It's very easy to publish unauthorized data to client side. - No best practices with the exception of authentication. So everything else takes LONGER to do than Rails. Developing in Rails is still way faster in most scenarios. Despite of these problems, I think meteor is a promising framework. I like how it unifies client and server. And hopefully, meteor dev team will address the above problems.
  • rco8786 13y ago
    > I can say meteor will kill nodejs meteor runs on nodejs...
    • dnprock 13y ago
      True, corrected.
  • morgante 13y ago
    > I can say meteor will kill nodejs, but not Rails. It won't kill Node any more than Rails killed Ruby.
• deleted 13y ago
  [deleted]
• deleted 13y ago
  [deleted]
• xacaxulu 13y ago
  Meteor will automatically refresh your browser if you are reading a blog post about Meteor.
• vetrom 13y ago
  I think there is some degree of conflation here. You can have different views/communication for session state and separate that from database state. Websocket apps are almost invariably in the family of apps that act on some sort of session synchronization, and if you are depending on a synchronized full-view between server<->client, then yes, you will have a bad time if your working set grows without bounds. If you are more concerned with just prediction/event/streaming and have a decent invalidation/resync mechanism, then meteor becomes a natural choice for interactivity. Oh, wait, there's the first two problems in CS again — caching and naming things.
• mark_l_watson 13y ago
  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.
• thepicard 13y ago
  I'm tempted to say: "unless mongoDB gets a lot better, this is not going to be true." However, a minute fraction of the rails community is large sites, so it doesn't matter. I also think a lot of people like rails because they find ruby extraordinarily beautiful. As much as I like JS, beautiful syntax is not its strong suit.
• rglover 13y ago
  For those saying Meteor is for toy apps, I just launched a fairly complex app written 100% in Meteor (yes, with paying customers): https://properapp.com https://properapp.com. Runs like a charm, easy to develop with, and not even 1.0 yet. Don't dismiss the author, Meteor is going to change a lot.
  • dham 13y ago
    But why. Why does your app need realtime? That's the part I'm missing. I see a Rails/Angular app right there, and in the end you'll feel good because your data is in the capable hands of Postgres/Mysql
    • rglover 13y ago
      Simple: I'm a front-end developer by trade and Meteor gave me something I understood (JavaScript) on both the client and server. To build this in Rails would have meant learning both Rails and Ruby. My app doesn't need to be realtime, and that's a narrow way to look at Meteor. Real time is just a nice bonus that the framework enables.
      • dham 13y ago
        But why? Meteor is a paradigm shift from the front end. Front end Javascript is asynchronous and event based. Meteor is synchronous. You're going to take a hit learning any framework, no matter the language. I picked up Rails just as fast as I did Play framework, and I had never looked at Ruby before. The whole NodeJS appeals to front end programmers thing kind of reeks to me. I think it's an irrelevant argument. I maybe wrong, but an end to end JS stack(MEAN) didn't feel any more right then using Rails.
        • rglover 13y ago
          I think it's an irrelevant argument. I could say exactly the same thing. For example, say a new Ruby framework was released that you really enjoyed and you "got it" because it was similar to Rails or aligned well with Ruby. The same principle applies: if something is familiar, it stands to reason that you'll have an easier time comprehending it. Regardless, does what framework I use really matter? As long as I'm able to solve problems in a way that makes sense to me, I don't really see the point in wasting time debating what to use. If the pajamas are comfortable, they're comfortable. Who cares if they're blue or green?
• throwmeaway2525 13y ago
  What about the Mongo dependency? I like Meteor, but that's one concern.
• gaoshan 13y ago
  Grenade! Take cover!!
• neya 13y ago
  This is bullshit. In my whole experience as a full stack developer, after having tried various technologies and languages and frameworks - including ones built with PHP, Ruby, Scala, Javascript and Golang, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Ruby on rails anytime soon. I wish something would, but nothing at the moment, is even close to the scale at which rails gets things done. I truly mean it. And something built out of Javascript replacing a Ruby-based full-bleed framework? I think you must be fucking kidding me. What the author describes is a very specific use-case and maybe, just maybe Meteor JS might replace a portion of that use case. In fact, if I were to do something like what the author suggests, I would still choose rails and Knockout JS (or Angular JS if you know it better). Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day? And the frontend (all the Ajaxy stuff) should probably add a week or two (worse-case scenario). That's just it. That's the power of rails. If you were to build the backend in Javascript without the power that Rails provides I'm sure you will need more than just a day, let alone a week. The point is, nothing is close to what rails is right now. I badly wanted something to replace rails for my work, but I haven't found a single solution that fits my needs. I've tried everything - Play, Sails, Revel, Gorilla, etc etc. But nothing there is that can replace rails. And all the frameworks that claim to be more like Rails, they're simply not true. Have you tried using play (Scala) and PostgreSQL together? The experience is nothing like Rails. I can make a clone of any complex app out there in the web in a matter of minutes/hours. That's the power that rails gives me and no other framework/combination can't. I understand that Rails is slow. But this is not the right way to critique it - Claiming something is going to replace it when it actually isn't true. We develop all our v0.1s in Rails in house and port them to Go (only if necessary and if the project owner is particular about it.) and that seems to work well for us.
  • meowface 13y ago
    >Do you know how long it takes to build a Facebook backend clone in rails? Maybe a day? A basic social network clone? Sure, maybe a day. But to emulate all the features Facebook has would probably take well over a month if done alone, even if the dev was very experienced with Rails.
• deleted 13y ago
  [deleted]
• dschiptsov 13y ago
  There is rather an unpopular opinion, that we need less piles-upon-piles of J* crap do serve a web-page, not more.)
• laughfactory 13y ago
  As a relative newcomer to web dev, I find Meteor very challenging to work with. It's got too much magic going on. Part of that is the simple fact that the documentation, while sufficient for pros, simply doesn't hold your hand. At all. And beyond the documentation there's a dearth of other resources for finding out how to do things. The community is too small to be effective, and any books which have been written are out-of-date already. Answers to questions on StackOverflow normally don't even apply anymore because the platform has changed so much. This is all very typical pre-1.0 stuff, so the point is that I'm not sure Meteor is maturing fast enough. It might be too late to the party once it finally stabilizes. Either way, I strongly dispute the implied claim that Meteor is easy to learn. It certainly is not. Rails makes a lot of intuitive sense--at least to me--whereas Meteor doesn't. As the author mentions it has the whole kitchen sink approach going on, and that makes it very unapproachable to someone like me...because it's difficult to make sense of unless I understand all the components on which it's built. So is Meteor cool? Absolutely. And it could be great if it matures fast enough to still be relevant, and if it manages to be associated with some truly tremendous learning resources which not only display its potential, but assist in learning the intricacies of the platform. I worked my way through the Discover Meteor book and was impressed by all the magic Meteor slings, but I didn't really understand much of why and how it worked. So we'll see. But for now, Rails is untouchable.
  • imslavko 13y ago
    For more "how magic works" a lot of people watch eventedmind.com screencasts. But it's not the case that you can't use any magic without fully understanding it (otherwise we wouldn't be able to use anything in this world). In my opinion, problem with explaining all the magic - it takes a significant amount of time but the code and underlying system can actually change in several months. I think, it makes more sense once core parts stabilize.
• jcoder 13y ago
  What about long-term maintainability of a large application? Rails has its issues there, but a body of best practices has grown up around maintaining long-lived rails apps. I wonder what the author's opinion would look like were it building the single app that is core to their business, and maintaining it for 3 years, instead of spitting out a Meteor app for a client every 6 weeks?
• ben_mcmahen 13y ago
  Having made some fairly substantial web-apps using Meteor such as http://subtitles.fiddlware.com http://subtitles.fiddlware.com, I can say that Meteor does make it incredibly easy, at least at the outset, to create a certain kind of application. It's great for something that is fairly self-contained; i.e., the task of the app is fairly narrow, and only consists of 1 - 2 pages... which may still make up multiple views. It's incredibly easy to implement a login system. And if you're at all dealing with something that is real-time, Meteor basically gives you socket.io style functionality for free. It was a good fit for the subtitles application. But there are definitely some weaknesses. It doesn't scale particularly well -- and I don't mean, necessarily, in terms of performance, I mean in terms of creating a large application... or a page with many sub-applications. And while the reactivity is awesome... and the auto-real-time can be awesome... sometimes you can feel "locked in" to the Meteor-way, when another (declarative) approach may be more suitable. In a weird way, you end up "working around" the features of Meteor. I'm increasingly convinced that a more modular approach is ultimately the best route... which is what something that express, sockjs, and component.js provide. I like using reactivity when I want to. And I like being able to swap different parts of the stack when desirable. It's typically more work at the beginning, but the flexibility can ultimately be liberating...
• ryderm 13y ago
  > We spent over two days recently getting angular.js and rails wired up for a brand new project, that comes out to 12-16 hours spent on configuration instead of writing actual code to build an app that does something the customer wants Am I the only one who was confused by this? There is no "wiring up" rails and angular js. Just include the source js in your application, or use the google CDN. One line of code.
• NARKOZ 13y ago
  > Let's be real, Javascript is the #1 language on Github and for good reason - it runs everywhere. Cancer is #1 disease in the world, but that doesn't mean I want it.
  • CmonDev 13y ago
    Good analogy. And the funniest part is when people say it should spread from client ("body") to server ("brain").
  • Iuz 13y ago
    I choose to use javascript, nobody chooses to have cancer.
    • CmonDev 13y ago
      I don't like the analogy because it's not a laughing matter. Nevertheless there is no choice of script language in browser either.
• Tarang 13y ago
  I use Meteor alot. Some of the issues mentioned here were about a lack of scalability in terms of larger sized apps and to the number of simultaneous users it can handle. If you have a large app you can use subscriptions that change as you view them. You can indeed have large 100,000 item collections without any hiccups or slowness. The issues people display here are if you have this 100k database downloaded on your browser which is unrealistic. The second as to scalability user-wise. It is possible to scale meteor by altering some code. Meteor's still a baby but their 1.0 release will definitely sort this out: The issues relate to how publish functions are handled & how mongodb interacts with meteor. These will be heavily optimized by running publish functions less & using a mongodb replica set emulated via meteor or through mongodb's oplog. I have built before with .NET (I hate it the most), Java, Rails, PHP, Coldfusion, you name it! One thing Meteor helps me do is build fast and expect something that works without bugs at the end. Its nice to experiment around with what people like till we get it right. I'm going to go so bold as to say Meteor will let people experiment with many ideas just as VCs do with ideas but here you can get that one which works without much cost & time to develop it. RoR is nice but when it comes to a funky front-end user experience its not nice. The backend is loads of fun!
• hmart 13y ago
  Both frameworks use port 3000 in development, if you start Meteor first, sure it will kill Rails. Haha.
• pbreit 13y ago
  When someone writes a headline like that and it doesn't happen, should the writer lose a substantial amount of credibility? Or should we just chalk it up to provocativeness?
• wonnage 13y ago
  "The problem is when you start with something like rails then javascript was an afterthought - something bolted on long after the technology was built." TCP: 1974 HTTP: 1991 Your point?
• dodyg 13y ago
  I am just waiting for somebody to present "MongoDB+Meteor:Perform like a pr0n star" in a conference to have the Meteor "douchebaggery cycle" completed.
• bolder88 13y ago
  Silly linkbait. Tools barely matter to any competent programmer, it's just fashion.
• weixiyen 13y ago
  I still prefer a clear separation of server and client. The main issue I have with Meteor is that it assumes 1 client and for most businesses mobile & tablet is going to matter more than web sooner or later. It's sort of a technology solving problems in a space that is not really in hyper-growth.
• donw 13y ago
  When a client asks us to build an app, they are really asking for a fully interactive web app that utilizes javascript to get rich client interfaces. Just, no. When a client asks you to build an app, they are really asking you to solve a problem. How you solve that problem might be a rich Javascript client interface, but in general, your client probably doesn't give a shit as long as they can find other people to work on it when you're gone.
• deleted 13y ago
  [deleted]
• cubsink 13y ago
  What is the big difference between Meteor and let's say Sailsjs? I've never heard of Meteor before but it looks promising. I will try it when I get home :)
• izietto 13y ago
  I don't think so. Javascript frameworks are for real time applications, while RoR (and the other "classic" web frameworks) are simpler to set and to use for the classic dynamic HTML applications, and I don't think real time apps will overwhelm classic HTML apps.
• CmonDev 13y ago
  Differential looks like a small designer shop which does small UX-centric web apps. If they will be doing any serious server-side development in future they will have to hire guys who know serious non-script languages. But for now Meteor looks like a good fit for their needs. And of course they want some cheap PR, so it's good to over-generalize to make Rails developers pissed (for no good reason).
• Keats 13y ago
  Is seeing the bottom of the page flash before the page is loaded when clicking a page intended? It's not very good either way. Especially for a blog.
• Nodex 13y ago
  3-4 weeks for a simple app ? are you mad. 1 week tops and that's with rich client interfaces and without the need for a framework. I think you need to learn how to code better
• harel 13y ago
  Kill? Really? Is this a fight to the death and there can be only one survivor leaving the ring? Both Meteor and Rails will live on side by side, happy and unaware that somewhere there are groups of people fighting their fight for them. This is the same like the Spectrum Vs Commodore 64, or Amiga Vs Atari St fights... Pointless in any practical term, but I guess it gives some people a sense of some messianic gratification. "Hey, I blogged about X killing Y before X was cool".
• deleted 13y ago
  [deleted]
• leokun 13y ago
  Meteor is cool, and there's a lot that I love and is awesome about it, but it has quite a few problems, some of which are on the roadmap for 1.0: Server side routing: a nice thing for APIs and RSS feeds. Server side template rendering, because running phantom.js to get SEO is kinda crazy. Can't get access to any kind of request object/info on the server side because you know, maybe HTTP still matters. Have to do file/io to get reactivity (save to mongo). Try getting webrtc started that way, it's not fun. Can't get direct access to who is connected without hacks. See above about webrtc. It uses mongo, because mongo: http://aphyr.com/posts/284-call-me-maybe-mongodb http://aphyr.com/posts/284-call-me-maybe-mongodb It erases event listeners on the client side with reactivity, so the vast majority of JavaScript libraries on the internet are incompatible with it. The javascript globbing system at load time is incompatible with popular ways to manage dependencies like node'js require or require.js. Like having files load in alphabetical order? Meteor.js is for you! There actually is a package system, which is the new way to do this, but the old system still exists and the new system while easy to use is not yet documented, last I checked, and you have to create packages just to wrap node.js packages. Meteorite. Was created to easily hack meteor.js to fix some of the issues already listed, but now is the way to grab things from atmosphere. Meteor comes with packages, but those are all official. I never liked the idea of using Meteorite because you couldn't upgrade Meteor until packages you depended on upgraded too. Now though meteorite is this thing you have to use to import to from atmosphere which has turned into a bunch of wrappers for npm. The built in less can't import recursively. I love meteor and if I created a list of all the things awesome about it, it would be larger than those issues up there ^^^ and the team is working on it. They're also really smart people.
• chiurox 13y ago
  Sensationalist title but there are some parts with which I agree to some extent. I've heard about Meteor over a year ago but never thought about a use case where I felt the need to use it. Last week, we had a last minute project that required some sort of webapp that could allow X number of users viewing a certain page on the browser and editing things off simultaneously with good enough conflict resolution. Of course, I could have done it with Rails on the backend, rolling out my own reactive system with Server Sent Events updating the client. But as curious as I am, I decided to checkout Meteor and it was perfect for my case. In less than an hour (with Meteor) I had everything working as expected. The app was for a big social event and all it mattered in the end is that it worked and impressed everyone involved. No one really cares what you build it with, as long as you deliver. In my opinion, Meteor is worth a shot if you're building a small scale reactive system.
• andybak 13y ago
  Just to add to the chorus of disapproval. I got a white screen on my phone. Had to switch to my laptop. Here's the thing. You're building a mainly content-driven site (still the bulk of websites). If you go down the route of some javascript-based 'app' that squirts all the content in dynamically then you might get everything right and end up with a beautiful, fast website that works across a range of devices, is accessibly, doesn't break bookmarking or the back-button and doesn't kill your SEO. But you've got to get everything right so the odds are that you'll get a part of this wrong. Debugging and testing are also suddenly a much bigger part of the equation. So what have you gained over plain old HTML and CSS with progressive enhancement? If you want the possible speed advantages of not re-rendering whole pages then techniques such as Pjax can be used to get the best of both worlds. In short - with an app-based approach over a html-based approach - there are lots of ways to get it wrong and only a few ways to get it right. You're probably not clever enough to get everything right. Gawker weren't.
• dham 13y ago
  I'll make a bold claim. Meteor is not the future of web programming. Why? Because JSF, that's why. This has already been done in the Java world. I believe the future of web programming is REST apis(in whatever the hell language/framework you want) and a nice framework such as EmberJS/Angular on the front end. I may be wrong, but I have history on my side.
• UUMMUU 13y ago
  It's amazing for hackathons. I wrote http://battlehack.meteor.com http://battlehack.meteor.com in 24 hours by myself after having done meteor as a hobbyist for 2 months.
  • sumanyu 13y ago
    I've been meaning to learn more about meteor. I've read the official docs, tutorials here and there, but haven't really found any resource that clicked. Would you mind sharing resources you used to learn meteor? My email is sumanyu at hotmail Thanks a ton!
    • imslavko 13y ago
      http://www.discovermeteor.com/ http://www.discovermeteor.com/ is a great book but starts from 40$. There are some starting points those are up to date: http://www.discovermeteor.com/2013/09/17/meteor-for-front-end-engineers/ http://www.discovermeteor.com/2013/09/17/meteor-for-front-en..., http://yauh.de/articles/376/best-learning-resources-for-meteorjs http://yauh.de/articles/376/best-learning-resources-for-mete...
• TallboyOne 13y ago
  God I hate stupid titles like this. How about something like "This is why I think A will kill off B". Instead it's always some ridiculous, over-generalized all or none fucktard title.
• koffiezet 13y ago
  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.