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.
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.
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.
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.
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.
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.
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.
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.
"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.
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.
Readit News
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.
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 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.
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.
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.
[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...
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.
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.
Don't make bold claims unless you try a little harder!
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?
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.
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 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.
You really should care what language/framework the server side is built in because someone has to work on it...
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.
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.
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?
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.
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.
It won't kill Node any more than Rails killed Ruby.
meteor runs on nodejs...
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 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)?
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.
[1] http://www.techempower.com/blog/
Could this could be used if the browser does not support JS?