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.
Making repeated prototypes (in est, experiments), quickly, is how you approach entrepreneurialism in any sort of scientific manner. Nothing needs to scale, or work at the edge-cases, until it has product-market fit; and you might need to write twelve or twenty or two-hundred different apps until you find one that works out that way.
That's what makes these frameworks popular with HN: startup founders are not in the business of executing on a known business model (which might be viably accomplished even through a waterfall process and code written in C); rather, we're in the business of searching for a business model by building MVP after MVP, as quickly as we can.
MVPs don't need to be able to be evolved into stable, well-engineered products. They just need to prove product-market fit. Once you've got your traction, your proof, your intent-to-buy, you can use that to get the loans or capital, to hire the talent, to build the Well-Engineered Version. Until then, "engineering" is not even a consideration.
That's all true, but I'm also beginning to wonder how much you actually need those frameworks to build MVPs quickly.
I used to do the bulk of my prototyping with Python + Django + JQuery + Postgres or AppEngine Datastore. Of late, I've switched a lot of it to just straight HTML + Javascript + a JSON feed from backends. If I need server-side computation, I'll build a quick Go or webapp2 app on AppEngine. I work just as fast if not faster, and there is far less that can go wrong. I'm not constrained by the idioms of the framework in development (this is a major problem with MVPs - all Rails/Django apps seem to end up looking like a bunch of forms over a database, even if that's not the best interface for users), and if one of the approaches works, I have an easier time productionizing.
For my most recent prototype, I started with JQuery (as usual) and then quickly end up removing it when I found that everything I used to use it for is now built into the browser. $ = querySelectorAll; .on = addEventListener; .addClass = .classList; .animate = CSS3; .ajax = iframes. And all of the browser native stuff runs significantly faster, and doesn't require that you download 90k of JS each time you want to refresh.
It's not 2006 any more. You can pretty much prototype in Webkit only, most of the things you need are built into the platform, there are easy minimalist libraries that will let you setup a JSON feed out of AppEngine with barely any code, and JS on the client can do pretty much everything. At least until you start caring about latency, but by then you're out of MVP range.
> and doesn't require that you download 90k of JS each time you want to refresh.
That's what caching headers are for. You can effectively cache your "big" JS libs indefinitely on the client, as you'll change the URL and therefore require a fresh download when the lib gets updated.
This isn't to say that cold cache performance isn't also important, but even a slow DSL connection should be fine with a once-off jQuery download.
I ran some experiments on this when I first joined Google. With JQuery loaded off ajax.googleapis.com, running my tests on google.com, cache hit rates were roughly 87%. This is with a CDN that caches everything indefinitely and the most visited site on the web at the time.
There's an extremely long tail of people who browse the web only occasionally, or have just one favorite site they go to, or who are running on devices with small caches, or who just cleared their cache because they wanted to look at porn. The hit rates are probably even worse now with the shift to mobile, because mobile devices have tiny caches. In recent prototyping experience using Chrome ADB to check on network traffic, files are gone from cache after only a half dozen or so other pageviews.
You can't assume "caching will take care of it" if the site downloads several hundred K of JS. Caching is effective at making an already-lean site even faster, and you get even more bang for your buck because more pages can fit in cache when the pages are small.
Anyway, I was thinking mostly about developer experience when I wrote that comment (this thread is about MVPs), and also mostly about mobile development, where the bulk of my time is spent lately. JQuery is a noticeable drag when loading a page over a cell network, even if you just want to try out some ideas. It's not just network latency, either; on mobile devices, you can burn significant time (and battery) just parsing and executing all that JS.
I was pretty much in the same boat as you regarding all the other choices, but when i saw this I thought: "Seriously?"
I remember when AJAX came out: I was finishing my iframe-based custom-rolled 'AJAX'. It was such a hack, I can't even believe someone would consider it in 2013.
1. You can do progressive rendering with an iframe. With an XHR you don't get the 'loaded' callback until the entire response has arrived, and so you can't start working with and manipulating the data until it's all there. With an iframe you can put successive chunks in <script> tags and they will start executing as soon as the closing tag for the script is found. Or if you want to transport the data as HTML, you can put a 0-length animation on each element that forms a response chunk, and listen for the animationend event to get notified as soon as it's ready in the DOM.
2. You can measure and manipulate elements while they're still in the iframe. For example, if you're animating the rest of your layout, you can measure the size of the elements that you just loaded inside a hidden iframe, adjust transitions on the main page to make space for them, and then pop the elements from the iframe into their proper places in the final layout. With an XHR, the only way to measure the element is to place it into the DOM and force a layout, which is much slower, particularly on mobile devices.
3. Iframes form a layout boundary, so when the browser lays out elements in them it stops the layout process at the iframe. This eliminates the need to do a CPU-intensive layout of the whole page when you pop in your XHR content.
Regarding the first objection, you could just send your responses as a series of websocket messages, rather than repeated AJAX request/response pairs.
The other two objections I'm not so clear on--maybe because I don't often dynamically construct views by retrieving "presentation" from the server. In what I've seen as "idiomatic HTML5 client-side development", all the views are shipped as templates with the initial code-blob that starts up the client; from then on, the client just speaks pure data-related JSON to the backend's plain HTML-unaware API. Does this practice not scale to Google levels? :)
Yeah, websockets are fairly useful if your data is JSON blobs or other byte data, but awkward if you just want to ship some more HTML for display. They're best used in long-running client applications.
As for sending JSON with rich clients vs. rendering HTML on the server; that depends a lot on the intended usage pattern of the app. For apps that you expect will be open for hours at a time, like e-mail or social networking, the former pattern is better - and indeed, GMail and G+ both speak JSON (well, a modified version that gives better latency) to rich client JS. For apps that you open quickly, perform your task, and then close (Search is the canonical example), it's far better to render all your HTML on the server and just ship that down to the browser. There is a large cost to downloading and executing all that JS, and you lose many, many customers if your app is slow.
There are strategic reasons why, if I were founding a startup today, I'd prefer to play in markets where the latter case held, unless I was writing enterprise software. Consumer markets where people spend hours with an app open are rare, and Google/Facebook generally want to own that space. I would rather not compete with them. On mobile, the open-for-hours apps are generally moving to native, where you can interact with the platform's notification API. The sweet spot for long-running webapps is enterprise and intranet applications, which has many fruitful markets, but many technologists shy away from it because there are frequently many arbitrary and difficult requirements.
> well, a modified version that gives better latency
Any more details on this (that you're allowed to talk about)? Low-latency JSON-alike communication is something I'd be highly interested in.
Personally, I've investigated BERT.js for this use-case, but it didn't work quite right (likely since the available client library was written to construct binary messages using String.charCodeAt, rather than just writing directly to an ArrayBuffer.) I kind of gave up when I realized I might be--especially on mobile--spending long enough on the pure-JS encoding/decoding processes (versus the browser's native JSON implementation) to lose any gains I'd get from the network. If you know otherwise, I'd like to hear about it.
that's all correct, but then you ruined it with the .ajax= iframes nonsense and the total waste of time removing jquery. optimizing for the right things is important, but doing the wrong ones is just wasting your time.
One of my big surprises moving to Google was how much iframes are still used, but even beyond that is the very pragmatic approach of looking for exactly what a technology gives you and what it costs you in return. There's basically a 1:1 correspondence between the API of an iframe and the API of an XHR:
xhr.open = iframe.src
xhr.onreadystatechange = iframe.onload
xhr.response = iframe.contentDocument
Many devs don't like working with iframes because it doesn't fit their mental model of how a request should work (possibly because iframes were initially introduced with a visual extent), but that's a problem with their mental models, not with iframes. You can always wrap the API if you don't like it, anyway - pretty much all the major frameworks do, since raw XHRs are a bit clumsy to use.
is there any small library ala "notjquery.js" that is a drop in replacement for jquery but that calls the browser native stuff directly ? serious question ?
You probably want something like Zepto.js. I'd also look into Lo-dash, which is a better, more functional-friendly version of Underscore.js that provides a ton of useful helper functions.
Be warned: Zepto doesn't claim to support any version of IE, so if you need IE support you'll want to fall back to jquery (yepnope works. Conditional HTML won't in IE10+).
jQuery does exactly that, with polyfills for browsers without the native implementation. jQuery 2.x does away with many of the polyfills since older IE versions aren't supported.
If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.
I am sitting at a Meteor unconf today and we are talking about scalability of Meteor... There are some very interesting pieces coming out in the next month to really push the envelope on handling a lot of users at once.
I would agree, we are in the business of building MVPs every day so it is much more interesting to us, I bet.
Let’s say you decide one day you want to build a table. This table is going to be made using wood, nails and a hammer. All things being equal, let’s say you build this table with hammer A that has a utility of 10. You build a second table with hammer B and it has a utility of 15. You, the carpenter, have now created two tables, table A and table B, respective to their hammers. The tables are identical, but the utility is different. Now let’s say your utility as a carpenter is 5 (we’ll call this carpenter ‘ME’). The value of the tables is now: Table A – 50 and Table B – 75. Now, my carpenter friend (we’ll call this carpenter ’FR’) has a utility of 4 and he builds the same tables using the same respective hammers. He now has two tables at the following values: Table A – 40 and Table B – 60. So we can build a simple comparative matrix now. Table B built by FR has a higher utility than Table A built by ME but it was built by a less skilled carpenter! We therefore logically assume the hammer is the key driver for the overall utility, not because it has a higher multiplier, but because we believe we have better ability over assessing what the utility of the hammer is. We then therefore place much more importance on it.
What is utility measure of? This analogy is way too simplified to be of real importance. There are more tools that go into building a scalable, maintainable table.
Can you point to some example that are a bit more complex in nature? My issue (that I identified with the backbone tutorials and re affirmed with the Angular tutorials) is that simple apps are easy to do with x, y or z. But if the new one or that one is going to replace the old one there should be 37 signals level complexity type apps out there. While I can't speak for Meteor, I don't see anything running on angular that's at that level.
Caveats: I glossed over the fact that angular is not a full stack, I have seen a few angular videos where teams have demoed and presented on complex angular apps.
podio.com is a pretty large enterprise app based on a Rails+Backbone stack. Their approach is to have multiple Backbone Apps (dashboard, contacts, tasks, calendar) for different modules. So if you switch modules you have page refresh and from there its a Backbone App...i like that approach and their app is pretty awesome.
We have that in America too caused by the varicella-zoster virus (aka chickenpox). That's not the first thing I thought of though - I thought it was going to be a site to help you find a roofing company. The "hang out your shingle" definition was the last thing I would've thought of.
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…
There is when the client doesn't want to pay for the extra work for the 0.1% of tinfoil hat-wearing people who turn off JavaScript.
"You need to spend an extra 30,000 to get this to work for the 3 crypto-anarchist wannabes who live in your state".
I don't think the client is going to want to pay for that kind of interop.
EDIT: I don't mean to be snarky but you absolutely HAVE to make these kinds of trade offs when working for people. And you have to absolutely discuss them with clients.
When a client asks for 'hey I want it fast like facebook and some of those cool animations I see wasitcalled haych-tee-em-ell five or something right? also it has to work on iphones because my wife has one', there is a hell of a lot of discussion there about tradeoffs. If the project you are building for them is speculative then even more so shit ain't gonna work for some people because they just aren't going to want to spend the money.
The last small job I did, I got a late requirement of "this actually has to work in IE7, 8 and 9", and stupid me, not hammering this down contractually the interop from the get go it ended up taking up nearly 20% of the budget in the end to get this working retroactively, and this was a small project.
It shouldn't be extra work. It's actually less work because it encourages you to play to the browser's strengths and to separate your concerns. It keeps rendering speed high, it makes it easy to debug issues because you can switch off JS to see if the problem is with the underlying HTML/CSS. If one JS component fails it doesn't take down the rest of the site, and so on.
Your website should work in IE7. It's a legitimate browser with real users. This doesn't mean it needs to behave exactly the same way as IE10, but a visitor to my site using lynx should get some level of use out of it.
Again, this helps you massively in the long run because the browser scene changes all the time. If you work hard to make your site work across the browsers you know about, it's more likely to work on the browsers you don't know about, or the ones that haven't been invented yet. (It took the iPhone to take Safari from a browser that nobody cared about to the browser everyone cared about pretty much over night.)
This depends entirely on what the customer is asking for, and how they're asking for it to be done, and whether or not they even care about fancy tricks or plain websites/web apps.
Non trivial example: client wants drag and drop uploads. What browsers support this functionality? Oh we can't do that in browser X Y and Z. Is that a problem? Oh, it turns out it is because manager A promised this to the CEO and she runs IE7 due to corporate IT policies. Crap. OK trade-off time, what should we do? Drag and drop for chrome that my boss runs or just stick to old school uploads? Use some plugin from jquery.com? OK let's do that. Now we have apparent 'automatic fallback' via the plugin but... boss wants it to display the image for confirmation in newer browsers, shit... Does the plugin support this? Yes? No? Let's say no now you're looking for another off the shelf or a roll your own.
Now you can say what you want about 'it should just work bler bler it's easy' but if you extract this attitude out to all areas of a software project you end up with the inmates running the asylum pretty much overnight. Like it or not, but the team or individual you are working with all have varied skill sets and you have to make work with what you have. The trick isn't 'just make it work with javascript off', it's 'deliverer something in the timeframe and on budget with the resources available' and those are different every time you embark on something.
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.
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.
Speaking as the author of Z Mongo Admin, it's mainly because we haven't implemented pagination yet. Can't be too hard to add {limit: 20} to the queries though.
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 .
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.
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.
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.
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.
Yep, if only the "forces of thruth" actually knew what they were talking about it would have worked great. :) Btw, I've asked for help in other places (which I won't link to as I like to keep my internet identities somewhat separated) but no one has an efficient way to deal with large collections.
> 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?
That's actually all possible. Just write a good publisher which takes the number of results as an argument. All the sorting can happen on the backend and then you push down the x results.
Sure, not as effortless as autopublish, but also no harder than in traditional apps.
This is very easy to do in Meteor. You just tell Meteor to only publish the information you need, just as you would in any other web application.
I am currently running an enterprise software project on meteor with thousands of pieces of data in the database. If I published all of the data at once, it would crash the browser. I know because I actually did it when developing. Once you write the correct publish functions, it runs extremely quickly and only has the information you need in memory. All of this data is reactive too. And yes, you can paginate the information.
The most hilarious thing about this is how uncannily your claims mirror those that Rails had to deal with when it was new - people saw the easy-to-get-rolling-with scaffolds and assumed Rails couldn't make your app look like anything else.
It took the better part of two years for people to stop saying so. The "smart, sensible people" condescendingly repeating "you need more than a _scaffold._" It was just as amazing then.
I was thinking the same thing. There were literally the same arguments against rails in 2006-2008:
- it won't scale
- too much magic
- it's is too opinionated. Only good to do things one way
- it's ok. but only for toy apps
- I can do that easily in X framework, language (php, java, and now rails)
- these are just toy example. can you do anything "complex"
The author says this is significantly cutting down on his dev time. He also mentions how meteor reduces context switching when developing. IMO those are signs of a very promising technology. I don't know if meteor will become practical or popular. All I know is if works and it's stupid, it's not stupid.
FWIW Rails did not scale well during that time period. (One word: Twitter.) I don't know what the situation is like now but performance was a serious issue with rails in the early days.
Admittedly very few, although I did run into performance issues on Rails sites handling orders of magnitude less traffic. It's an interesting use case though -- tough to imagine a simpler web app than circa-2006 Twitter. Tellingly, they ultimately threw up their hands and moved it all to Scala.
I would say that your argument is one that can be fixed by a number of means:
1. Removing the local copy of the DB.
2. Removing the need to use MongoDB.
#1 will let you have your responsive clients while #2 will let your application scale. We've got 2.5TB in MongoDB and I can't wait to get away from it for our use case.
(MDG-er here) A few meteorites actually did write an equivalent of phpMyAdmin for the Meteor Summer Hackathon, in case it's of interest to you: http://www.youtube.com/watch?v=ixJyB8Z-tU8 :-)
I hear ya... from what I can see it looks like it would be great for rapid prototyping, even big systems... however why anyone would go with a JS-backed framework for a serious application is beyond me - it's just not ready as a language (and a framework)
Most frameworks aim squarely at programming in the small/medium scope.
The Big Lie is that you should outsource your design to them completely, because the people who designed them are smart. Nobody ever calls out the implicit appeal to authority there.
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?
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 from a 10-day design?
If this guys is going off about how it shaves a week or so off a 5 week project, problems that appear on bigger apps might not be high on his priority list.
I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)
I still have the hope for a unified platform. But I'd much prefer it to be on a solid language that compiles down to JS. I'm not sure it's an unattainable goal. I think you nailed it with "seamless" and "invisible" - abstracting major things like client versus server, or local versus network, can really end up biting developers.
>I wonder if Meteor will end up introducing security holes like ASP.NET, as developers forget there's an abstraction and clients can't be trusted? (In ASP.NET, things like being able to screw with viewstate or fire events for disabled controls.)
This is a thing for Meteor already. For example, if you have the insecure package enabled, you can can make changes directly to the database from the browser console. However, this particular issue can easily be detected prior to deploying to production.
Insecure is there to help speed development when you are getting started.
All frameworks can do their best to compensate for security holes, but ultimately people need to pay attention to it. That being said, Meteor offers a call method and code runs on the server - if security is a concern then you should pay attention to what happens on the server.
I've not used Meteor. How exactly does "insecure" help speed development? Certainly any code you write with it is worthless, right? I mean, before production you need to remove it and rewrite it using another method, so what's the point? Or do you mean it's useful on the sysadmin side, as a REPL-like data access console?
>By default, a new Meteor app includes the autopublish and insecure packages, which together mimic the effect of each client having full read/write access to the server's database. These are useful prototyping tools, but typically not appropriate for production applications. When you're ready, just remove the packages.
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.
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.
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.
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 diligently. You'll likely have a product that's really good at rapidly prototyping applications inside a consultancy. What about people who aren't language-specific consultancy developers? Well if you have a similar use-case you'll surely be happy!
Meteor and Rails strike me as Apples and Oranges - Rails is a general purpose framework that assumes a separation of systems between client and server (And optionally separation between server and database if you forgo Active Record). Meteor assumes you want a tightly coupled, real-time, rich JavaScript web application.
The author assumes Sauce for the Goose is sauce for the gander... but judging by the lack of ASP.NET around here I'm not sure that's the case.
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.
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.
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.
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.
sorry that was a deploy to fix the "oops, this page can't be found" that was flashing before the page loads. When we deploy Meteor, it hot fixes the client (i.e. restarts the app in your browser)
My skepticism here is due to the use of an "app in my browser" to display a static blog post.
A blog post is fairly simple static content. My browser is an app that does fine at displaying it. By making the page an app that dynamically updates upon server changes, you actually substantially damaged my experience, as I was interrupted in the middle of reading the page.
I'm not opposed to apps which dynamically update data in real time from the server, when that's appropriate. A static blog post does not appear to be such a case.
The irony here is that this was on an article titled "Why Meteor will kill Ruby on Rails", an overstated claim describing how a framework build around updates from the ground up is so much stronger than one based on delivering static content. The actual behavior of the page seemed to speak more loudly than the content.
It takes maybe a day working with your Capistrano script to implement zero downtime deploys in Rails if you're running Unicorn, Puma, or Passenger Enterprise...
"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.
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 :)
We've got a pretty good google maps integration in our rails app & I've found sticking with plain old rails for CRUD and using fancy-pants javascript in high-value places to work out well.
The hyperbole of your blog post really annoys me. The urge to generate traffic lessens the quality of the overall discussion here on hn and within the larger programming community.
As an author with every post and submission you make a conscious decision about what is important to you. Do you want to enlighten your readers or do you want to gain notoriety at the expense of your audience?
Ask yourself, do you want to be the Daily Mail or Le Monde?
I'd love to see what your client actually wanted. Is the site launched/public yet?
Because there's a subset of map-based sites for which pure, out-of-the-box Google Maps is the best solution, but I'd estimate it at no more than 30%. (StreetView and consistent street-level addressing are the two main points in its favour.)
For the other 70%, you will build something better by working with the raw map data (which usually means PostGIS) and using custom cartography (which could mean a lot of things, but let's say TileMill+OpenStreetMap).
This greatly swings the balance back towards Ruby or Python. FWIW I don't generally use Rails, preferring a custom Rack+DataMapper stack, but the same point holds. The amount of smart geo stuff you can do in one line of code with a PostGIS-friendly ORM is astonishing.
More broadly, your article says "technology A is better than technology B because C". That's cool. And here I am, posting a comment that says technology D (custom geo) is better than technology E (GMaps) because F. No doubt there are also arguments G, H, and so on. Your C is essentially a productivity argument - do the same thing faster. That's important, yes, but deeply personal (I find it difficult to believe I'd ever be as productive in JS as Ruby, and I'm not entirely a JS n00b). But if F, G, and H enable you to do actual new stuff, they're the arguments I'll listen to.
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.
So, now you agree with what carsongross originally asked? The client does just want an app and you believe you know better and foist a broken javascript app on them?
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 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.
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 article's link, and then click my Back button, I'm directed to the top of http://differential.io/blog, not to the middle of the page where I left off. Very annoying.
I still think blogs shouldn't require javascript. I certainly can't read the article in w3m. And to read it in Firefox I'd have to enable javascript for the domain -- which I occasionally do -- but why should I have to do that to read a bit of text?
I can't read an offline version (reasonably) via wget/curl. I find it doubly ironic considering that the blog actually has a nice clean design -- seemingly focused on content. So why not publish it as content?
As a side note, the text of the article (copy pasted) takes up 7.2k. The main javascript file 591K.
Sorry if this comes off as a bit random anti-javsscript rant, but just because we now have a few apps that benefit from client side logic, doesn't mean that most content on the web does. Surely we can use meteor or whatever to implement (one of) the interfaces to our cms/blog -- and still publish regular content as html+css (maybe with an RSS feed that allows for easy syndication)?
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?
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.
Hah, I went to the website and it just sat there refreshing itself. After me manually refreshing it a few times it eventually loaded. Can't say I would bother touching Meteor.
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.
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.
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.
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.
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 Perl, PHP, ColdFusion, and WebObjects, I can this say with full confidence and can afford to put my name and credibility to stake - Nothing is going to replace Enterprise JavaBeans anytime soon.
I wish something would, but nothing at the moment, is even close to the scale at which EJB gets things done. I truly mean it. And something built out of Ruby replacing a Java-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 Rails 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 EJB and jBoss (or Orion if you know it better).
For performance sure, a java based solution is going to kick rail's ass. For speed of development though developing with EJBs is not even up to the standard of rails 1. The funny thing is, java is generally used to build enterprise apps which don't need anything like web scale performance. For this profile of app rails really shines, it's plenty fast enough and will hugely reduce development costs.
No one is taking Rails away from you. I don't think it's bullshit. There are use cases for each. I think Meteor offers up a good debate about "how we do development these days", and attempts to answer them, albeit early. Meteor is still new, and it's path is currently bumpy. But it tries, and innovation is a wonderful thing, that's what Rails gave us early on. The sad thing about Rails is it largely stagnated for some time while JS M.V.-whatevers sprouted. It couldn't solve realtime application building problems and provided no means for a client side implementation. And for the most part still does (although 4 supports SSEs). You just have to do so much glueing. One more: what about the inherently non-threadsafe nature of rubygems? How will Rails overcome being a threadsafe framework when it's dependancy mechanism has no safety check? I digress. These are solved problems on node, and it's something Rails still stagnates with. My point here is: Rails has issues too, big ones.
I can see Meteor either evolving nicely, or fading away. Keep in mind that it already has a growing community and development is backed with solid dollars & a passionate team.
I think the author is attempting to elude to the cargo-cult that hit Rails will migrate to Meteor. In time I believe many will. I think both communities will stay strong, and after enough time will begin to look like each other. Rails could learn a thing or two from Meteor. And conversely Meteor the same.
Thank you for your peaceful tone (unlike the author's). But I think there are a lot of opinions mixed up with your facts:
>The sad thing about Rails is it largely stagnated for some time
>You just have to do so much glueing
>These are solved problems on node
And to be clear, Node is not a 100% perfect platform either.
>I think the author is attempting to elude to the cargo-cult that hit Rails will migrate to Meteor.
Of all the options available, why Meteor? Like someone on this thread said, it has a lot more evolving to do, to even become on par with rails in the current situation.
We're talking about the basic reason why people choose rails:
Productivity (Getting stuff done) and getting your product out to the market. I think in this perspective nothing beats rails:
rails new blog
rails generate scaffold Post title:string text:text
rails s
How many lines of actual code I have written so far to actually get my basic blog idea up and running? None.
> And to be clear, Node is not a 100% perfect platform either.
Absolutely. But as a software piece, I think it can apply itself to the web more easily than Ruby currently can.
> Of all the options available, why Meteor?
Right, there are plenty of options, MEAN is getting nicely popularized. You also have Derby.
> Like someone on this thread said, it has a lot more evolving to do, to even become on par with rails in the current situation.
Yea, there's a problem with how much you get for free with Rails (rubygems), and how much utility a framework provides you (AR, generators, etc). Right now those are areas that need improvement, but the community & time will improve those.
Re the awesomeness of generators: Yea, meteor doesn't have any, and in all fairness we're talking about something that isn't 1.0, but from a practical point of view: this is an easy task in Meteor and would only take 5-10 lines of code.
On something that rails doesn't have is dependency reloading. So imagine a world without `bundle install`. Meteor wants to streamline, it just hasn't gotten all the corner cases yet. It's still early, but it's still got a lot of bang for it's buck.
Perhaps some are jumping ship early or just want to get acclimated with new software in it's infancy. I just like both.
In your previous post. Then you list out MEAN(Mongo, Express, Angular, Node), which is all glueing. I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet.
After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is a reason the Meteor team chose fibers. You can async.waterfall all you want but structuring your code in a synchronous manner, lets you get stuff done.
People tout Node and Meteor for real time stuff. I could do similar things with SSE and Rails/Ember or Angular. The users of your applications don't care if you use Websockets and really most of the time you don't even need Websockets, you just need SSE or long polling.
> In your previous post. Then you list out MEAN(Mongo, Express, Angular, Node), which is all glueing.
First of all, I only claimed you have plenty of glueing in Rails (although you glue when working with anything, it's the degree at which I think is important).
Secondly, I was agreeing with about there being options, I didn't really reply to the "why Meteor", I think I went over that enough.
> I have used this stack extensively, and I must say its not even close to Rails. In fact it's not even on the same planet.
They are both used to build web applications, I think they have many similarities. But yes, they do have a wide range of strength and weaknesses.
> After all you guys finish your piddly todo lists, start trying to write some real business logic in Node, and see how far it gets you. There is a reason the Meteor team chose fibers. You can async.waterfall all you want but structuring your code in a synchronous manner, lets you get stuff done.
I don't find it exceedingly difficult to be productive in Rails, Meteor, or MEAN. Again, each has their strength and weaknesses.
And in terms of structuring code: async or not, you have plenty of options to properly organize it (eg: Deps.autorun, promises, npm's async).
> People tout Node and Meteor for real time stuff.
I think because it tools itself well there.
> I could do similar things with SSE and Rails/Ember or Angular.
Right, no one is taking Rails away from you.
> The users of your applications don't care if you use Websockets
True, most users won't care about the specific technologies used to load a page. But it could play a role in the experience, which is something they will care about.
> and really most of the time you don't even need Websockets, you just need SSE or long polling.
See, here's the thing "most of the time", but not all of the time. So there are cases for each.
Long polling has plenty of cons, and SSEs don't provide you with a bidirectional channel. That's important for some applications.
Yes because no one has built real business logic in node.js. and clearly node.js is only good for piddly todo lists. I've worked with python/Django, rails, and node.js on real complex apps with huge amounts of business logic built in them. Each one had advantages and disadvantages. I will say that MEAN certainly compared very well to both type of apps once in production. I was more productive in the other two but performance and scaling were far easier on node. You like rails, that's great but if you dismiss node and other approaches that's your loss. You'll be a poorer developer for it.
I Never said no one has built business logic in Node.js.
I'm also not sure where you implied that I've dismissed Node, because I most certainly haven't. In fact I have several Node applications in production at my company. I'm just stating facts, and to be honest I'm extremely open minded when it comes to new frameworks.
But Meteor, I've been there done that. It's called JSF in the Java community.
I'm a back end developer and don't have much experience with web technologies, so may be some one can enlighten me.
Have we really come to a stage, where what Facebook has done after billions of worth investment and thousands of people working, can be cloned with a open source technology in hours?
>>I can make a clone of any complex app out there in the web in a matter of minutes/hours.
Again how is this possible. Or let me word it this way, if some thing can be copied in minutes how can it be called complex?
I meant that you can get out an MVP of a complex web application like Facebook in a matter of hours/days (depending on the complexity of course) instead of having to wait for weeks/months when you're on with another framework.
>if some thing can be copied in minutes how can it be called complex?
Just because your life is made easier by a tool, doesn't necessarily mean the original process is any less complex. And that's why the market for for such tools even exist :)
Translation: Just because a bottle of Coca Cola costs $0.99 and a bottle of water costs $2, doesn't mean that the process of creating Coca cola is by any means less complex.
I guess what the parent poster means is that you can create the basic functionality of Facebook easily, i.e. something that looks and feels like Facebook and works reasonably well for a few users.
Whether it can support a billion users is a different story. (It won't)
I'm a beginner web developer and I can clone facebook in a few hours.
In its core, the app is just users who can friend each other.
Add AJAX to that... and tada, something that resembles facebook.
Scaling the app to be very reactive, available to millions accessing it at the same time, and with near 100% up time is where the hundreds millions of dollars go. (and all that data mining)
>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.
You're wrong. Node.js has already overtaken what you think Ruby on rails "is". Node.js is the current darling of Silicon Beach. Add on some mongodb and more bells-and-whistles and you have Meteor.
That actually might be a neat one-day hackathon: strip a popular website down to its essence and implement it as fast as you can with your favorite framework of choice.
I'd be willing to go toe-to-toe with you guys on no framework at all - just HTML/CSS/JS and perhaps a little JSON feed to an AppEngine datastore if data needs to be persisted and shared among multiple users.
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.
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.
Yeah, and we saw how well that worked. Java projects sprung up to incorporate the good ideas from Rails, Rails itself picked up a load of developers and evolved into something decent, and the world moved on. Nothing was killed, but all the boats rose.
I'm thinking maybe the drama wasn't a requirement for this to happen. Perhaps Meteor devs could experiment with that idea.
Your feelings towards JavaScript essentially mirror mine, though I've found writing code in TypeScript for Meteor has been a much more pleasant experience and gives me more confidence in the code I write.
Does typescript do type checking at runtime or just compile time? I was really excited about typescript initially, especially for use with Obvious Architecture, but then it looked like it was just compile time, not runtime checking which seems problematic to me.
TypeScript only does enough run-time argument checking to support default argument values.
Full run-time type checking would have overhead. It would also be unnecessary in places where data flows from Typescript function to Typescript function — those places should already be foolproof after the compile-time checks.
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.
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.
I can go into large detail why calling it incredibly painful and unpleasant is nothing but hyperbole though. Have you tried building a to-do MVC app, at least?
GP is expressing a personal language preference. I also find JS horrific to work with (and I've worked with it a lot). But that doesn't mean you can't or shouldn't enjoy it.
Horrific is really stretching it too though. I know it's Halloween or whatever but let's just discuss it on technical merits before passing misinformation like that.
I would not want to build a large Ruby app. That sounds incredibly painful. What's with all these "=>"??? And I still haven't wrapped my head around how you get the star onto the monkey, and why one would even want to do such a thing.
Ruby is the worst language ever, because I do not know how to use it.
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.
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.
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.
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.
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.
Fads are good. Being able to run everywhere is also good, but frameworks eventually need to give way to new ideas. Not everyone wants to program in COBOL on .NET forever.
I missed out the first time around because the Rails community was full of fanboys and nothing turns me off a community more than zealot-like behaviour.
Then evaluate things on their merits and ignore the fanboys. There are plenty of people in this world looking for silver bullets, that someone excitedly claims to have found one is no reason to believe them.
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".
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.
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.
Having made some fairly substantial web-apps using Meteor such as 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...
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
"The problem is when you start with something like rails then javascript was an afterthought - something bolted on long after the technology was built."
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?)
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).
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".
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 :)
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.
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.
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?
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.
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:
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.
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. 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.
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
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.
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.
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?
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.
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.
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.
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?
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.
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/ that's having problems?
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.
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
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".
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?
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.
> 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.
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?
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'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.
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.
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).
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.
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.
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.
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?
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 invent the first or the last usable asynchronous web framework.)
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.
The performance is the same as if you wrote the javascript by hand. The only potential performance issue is when the compiler generates really poor javascript for some particular bit of code, where a person would have written less poor javascript if doing it by hand.
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.