Why Meteor will kill Ruby on Rails
differential.io
differential.io
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.
http://www.shinglecentral.com/ http://assistant.io/ http://lister.io/
Are just a few from the last 1.5 months.
> Uncaught Error: Must set options.password > 62afa287c8fae43c43f745c9f43dbcd4b875e531.js:14
> Uncaught TypeError: #<Object> is not a function
When trying to add attendees,nice UI though.
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.
https://dl.dropboxusercontent.com/u/7633426/shinglecentral.p... https://dl.dropboxusercontent.com/u/7633426/assistantio.png https://dl.dropboxusercontent.com/u/7633426/listerio.png
If you want to use a javascript tool you´ll have to add an exception for this tool.
"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.
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.)
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.
Screw you buddy.
Compare the above screenshots with this one:
https://dl.dropboxusercontent.com/u/7633426/BundleHunt.png
it's "broken" in similar ways, showing markup like ${{product_price}}, but clearly includes enough static-content and context to allow be to choose whether I want to click my "allow scripts" button.
If somebody sent me a link to Shingle Central with no explanation, I'm highly likely to go "whatever" and move on t the next work-distraction-link…
your domain is literally "shingle" central
what? I don't even
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.
I would agree, we are in the business of building MVPs every day so it is much more interesting to us, I bet.
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.
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+).
If you want an even smaller jQuery, you can build your own[0] without the modules you don't need.
[0] https://github.com/jquery/jquery#how-to-build-your-own-jquer...
wait...what?
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.
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.
> .ajax = iframes
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.
Why not XMLHttpRequest?
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.
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? :)
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.
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.
https://news.ycombinator.com/item?id=6649195
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.
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.
http://www.techdisruptive.com/2012/06/29/the-cyclical-nature...
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.
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 .
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.
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.
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.
Far more effective to announce something incorrect and let the forces of truth and justice solve your problem for you. Well played.
Don't make bold claims unless you try a little harder!
[1] http://www.meteor.com/blog/2013/07/09/congratulations-to-the...
[2] http://www.meteor.com/blog/2013/10/11/meteor-at-hackmit-onet...
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.
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.
- 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.
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.
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.
- 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?
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.
You really should care what language/framework the server side is built in because someone has to work on it...
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.
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.
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.
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.
>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.
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.
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.
There may be a few more ASP.net developers out there than you assumed.
http://w3techs.com/technologies/overview/programming_languag...
But I have to admit that it is pretty funny that comparing a framework to ASP.NET is apparently the nerd equivalent of insulting someone's mother.
Somehow, through the magic of JavaScript and Websockets, they managed break passively reading static content.
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.
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's difficult to implement the same functionality with Rails, where the default is to be down while deploying.
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.
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.
Your milage, and billing rates, may vary.
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.
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?
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.
meteor runs on nodejs...
It won't kill Node any more than Rails killed Ruby.
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.
Is this a problem that the Meteor developers are working to resolve?
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.
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)?
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.
Could this could be used if the browser does not support JS?
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.
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.
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.
>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
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.
[1] http://blog.mongodb.org/post/49262866911/the-mean-stack-mong...
> . You just have to do so much glueing
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.
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.
Thanks.
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.
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?
Whether it can support a billion users is a different story. (It won't)
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.
Cheers.
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)
If you mean "mimicking on or two of the features" I'm with you :)
This is probably a more important metric than language popularity on github: http://www.statisticbrain.com/computer-programming-language-... And I'm sure javascript has grown quite a bit in popularity in 2013.
Javascript is getting things done, and with node and mongo and now meteor, it's only getting easier.
It's a fact that many don't want to face, but you may need to practice your JavaScript skills to find your next job.
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.
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).
etc, etc.
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.
Who knows 5-10 years down the line...
Enterprises use Java or .Net.
I'm thinking maybe the drama wasn't a requirement for this to happen. Perhaps Meteor devs could experiment with that idea.
I'd love to hear how you're better acquainted with 'nikatwork's feelings on JavaScript than he is.
Ruby is the worst language ever, because I do not know how to use it.
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.
LOL @ Java being described as "hard to work with" in comparison to JavaScript. Major indicator of JS developer Stockholm Syndrome right there.
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.
Server side routing: a nice thing for APIs and RSS feeds.
Server side template rendering, because running phantom.js to get SEO is kinda crazy.
Can't get access to any kind of request object/info on the server side because you know, maybe HTTP still matters.
Have to do file/io to get reactivity (save to mongo). Try getting webrtc started that way, it's not fun.
Can't get direct access to who is connected without hacks. See above about webrtc.
It uses mongo, because mongo: http://aphyr.com/posts/284-call-me-maybe-mongodb
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.
Similarly, anal sex is the best kind because it works on all genital configurations. /snark
Rails was a fad. Meteor is a fad. Keep your nose out of hype.
I don't want to miss out again.
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.
They do have this YouTube tutorial though, where they run through how they made the multiplayer story game:
http://www.youtube.com/watch?v=V0DOGXmaT3g
Code is on Github here:
https://github.com/codeparty/multiplayernotepad
Demo (currently unavailable):
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.
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!
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 hate to be negative but that's not how to win my confidence.
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.
Rails may well find it's popularity and prestige diminished, but I doubt it'll "die" anytime in any of our lifetimes.
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.
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.
Cancer is #1 disease in the world, but that doesn't mean I want it.
Either way, I strongly dispute the implied claim that Meteor is easy to learn. It certainly is not. Rails makes a lot of intuitive sense--at least to me--whereas Meteor doesn't. As the author mentions it has the whole kitchen sink approach going on, and that makes it very unapproachable to someone like me...because it's difficult to make sense of unless I understand all the components on which it's built.
So is Meteor cool? Absolutely. And it could be great if it matures fast enough to still be relevant, and if it manages to be associated with some truly tremendous learning resources which not only display its potential, but assist in learning the intricacies of the platform. I worked my way through the Discover Meteor book and was impressed by all the magic Meteor slings, but I didn't really understand much of why and how it worked.
So we'll see. But for now, Rails is untouchable.
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 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.
TCP: 1974 HTTP: 1991
Your point?
This makes about as much sense to me as "Why Flask will kill Zend".
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.
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 :)
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 makes me feel a little better though that they are trying to be transparent about the flaws by publishing their roadmap:
Don't dismiss the author, Meteor is going to change a lot.
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.
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?
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.
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.
Blog try to refresh after HN traffic killed the backend.
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.
Thanks a ton!
Meteor itself makes it easier to write clean client side JS code where I care much less about the backend when I start.
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.
I believe the future of web programming is REST apis(in whatever the hell language/framework you want) and a nice framework such as EmberJS/Angular on the front end.
I may be wrong, but I have history on my side.
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.
Maybe it's common not to have good unit-tests? (integration/functional-test does not count as unit-test).
> What if you could spend your time in one language
> and one framework?
Many a plate of school lunch spaghettis has been eaten with a spork.
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.)
I also believe there are some current projects that compile Python and Ruby into JS, but I'm not sure how mature they are.
Decaf: http://trydecaf.org/ Opal: http://opalrb.org/
A quick google search gave me Pyjs. http://pyjs.org/