Have a look at https://trello.com/b/hjBDflxp/meteor-roadmap , but I can make a quick resume for you:
* There is no easy/official way for doing joins in subscriptions (you can't join "Posts" and "Comments" in a typical blog example). I'm aware of several plugins that try to implement that, but they all lack official support and quite of them just fail at doing it properly.
* No server-side rendering. Say goodbye to SEO, unless you're willing to follow the prerender.io way.
* No i18n. Should I say anything at all about this one?
* Not even basic forms support. This is the abc of any framework, and yet Meteor doesn't have it.
* Bad routing support
* Not-that-good documentation and examples
So, no, MeteorJS is just not there yet. But the idea is cool and I'm sure if those things get fixed/implemented, it will get quite a big user-base.
* There maybe no official support for reactive joins but they are very easy to make with packages like Publish-Composite: https://atmospherejs.com/reywood/publish-composite , plus you get the freedom to build your data and denormalization how you want. I think it just requires a dedicated dev to study Mongo data structures with Blaze&DDP. Some devs are just not dedicated enough to learn how to do it right.
* i18n, I cannot speak to that, never had a need yet.
* Forms are freakin' amazing in Meteor with the Autoform package: https://atmospherejs.com/aldeed/autoform
* Routing is freakin' amazing in Meteor with the Iron:Router package: https://atmospherejs.com/iron/router
* Courses, docs and resources are freakin' amazing for Meteor examples considering it's age. That said, all docs for all software could be better, it is more of a personal thing.
Just curious @alexandernst are you a .net dev because it sounds like you are not an Open Source dude? Instead of gluing awesome things together and being creative it sounds like you want a big company like Microsoft to come in and offer everything to you, tell you how to do everything, and box you into their ways. Packages do not have cooties, haha. And Meteor is built on Node. You have access to NPM as well.
He made valid points, you had a good rebuttal with respect to alternative methods while embracing the ecosystem. There was no need to take it to an unprofessional level.
In addition, his points are all valid - these things aren't baked-in, and once they are, he's sure the platform will get a large user base. Currently, you can make a large application securely with the commonly sought out factors of high availability, reliability, and scalability - but you have to work at it.
It's incredibly nice when a big company like Microsoft comes out and offers everything to you. If MDG had that kind of money and did that with Meteor, would you complain about it? No, you wouldn't. You'd talk about how incredible it is that they did that.
Using out-of-the-box functionality instead of "gluing" things together doesn't mean you're any less creative. If anything, it means you're more efficient and utilizing all of the functionality already available instead of re-inventing the wheel.
I don't know you, and I'm sure you're a great dev, as probably is @alexandernst - so why attack his opinion instead of just stating yours and sharing why yours may be more valid if people are willing to put in extra work?
I agree that there is room for improvement, but I am confident that the team behind MeteorJS will make MeteorJS a success.
A project manager will be rofl-ing hearing those words, I'd say.
1. Joins? I always hear this one. Youre playing in the world of mongo. You can use very different architecture outlined by mongodb in their docs 2.youre right, for now, but SEO has been handle via spiderable, sitemaps etc. 3.theres a great i18n package so idk what you should say 4. Everyone does forms different, at Workpop we built our own forms framework cause it made sense for our business 5. Id love Chris Mather, who is brilliant, tell you about the power of Iron Router 6. Thats an honest opinion
Meteor is there. It allows you to build fast, build packages, and support future developers. Its a reason why we were able to build and scale our job platform. And we built what ziprecruiter took years to build in several months. For these reasons we raised 7.9 million dollars from Notable investors tha are willing to see that things will get better. If you can make a huge app in an imperfect environment, just imagine bow powerful it gets when it comes closer to ideal.
Anyway my 2 cents
So I feel your criticisms are a bit unfair. Meteor doesn't provide a solution for forms and internationalisation out of the box because it's not supposed to. That's where packages come in.
Now whether or not it should become a framework is another matter.
A typical example would be to display a "post" with comments from two different collections:
Template: <template name="posts"> {{#each post}} {{title}} {{body}} {{#each comment _id}} {{username}} {{body}} {{/each}} {{/each}} </template>
Helpers definition: Template.posts.helpers({ post:function(){ return Posts.find(); }, comment:function(post_id){ return Comments.find({post_id: post_id}); } })
Essentially, Common JS + NPM lets people/teams create their own "frameworks" with very little effort whilst also freeing them from the bulk and cruft of a framework that has a limited future; if it has any future at all. The tools and technologies we use to create websites/apps are changing at break neck speeds. Frameworks are in it for the long haul and they hope the decisions they make today will be relevant in two+ years time - but devs have to cope with demands in real time. We don't have the luxury of hope.
Here's some good reading http://tom.lokhorst.eu/2010/09/why-libraries-are-better-than...
If you can do it, more power to you, but I'm pretty sure there's a large population of developers who just want something that works out of the box (I know I'm one of them).
By the time you've built a reliable data synch transport that watches the server database and pushes changes to clients over intermittent connections, then pushes changes from client back to servers when they reconnect, all this with access control, a Meteor developer will have built 10 proof-of-concept apps, determined the product-market fit, and have a working web app for users to use.
[1]: http://rauchg.com/2014/7-principles-of-rich-web-applications...
[2]: http://wiki.dandascalescu.com/essays/meteor_js_vs_the_mean_s...
If your application doesn't diverge much from a "standard application" in your framework, then you are probably better off using one. If its going to need a lot of customization then probably libraries are a better way to go.
I think things would be much easier if I had "grown" with rails as its features grew, but now, it being a behemoth, I would be pretty much disinterested in going in the effort of learning it just so I can make my shiny new project.
The learning would be much easier, if I get to work on existing codebase but then again, it is a chicken-and-egg problem.
Go look at places like ClassCraft, WorkPop, MixMax, FantasyHub, etc.
Plenty of teams are scaling both the code base and the app servers to handle thousands of concurrent connections.
What is stopping you from trying Meteor, really? Your questions are more focused on the culture of building an app, not about the framework itself.
There are many, many examples of functionality that you get for "free" without further set-up, and in my experience it empowers you, the developer, to build richer, better applications.
I think that the fact that the platform is stable and past 1.0, and the package ecosystem at atmospherejs.com is vibrant and high-quality, the answer is yes you can absolutely build an application with a large code-base. (And, I might add, you may wonder why you ever did it another way.) As for scaling, you're on a non-blocking node architecture, and so you're already doing pretty well. If you can't figure out how to scale it through the community, my understanding is that the folks at Meteor are working on a paid product that will make it dead-simple to scale to your heart's content. I am guessing that by the time you launch your Meteor-built product, there will be ample resources to hold your hand through it.
Last time I tried (granted about a year ago) none of the existing plugins were very good (the only reactive one added the new page's items to the table before removing the existing page's items maybe .5 sec later--horrible user experience).
Perhaps the plugins are better now, but still it seems like something so fundamental it should be in the core distro; the meteor team is punting if it isn't. I won't try it again until that is integrated into core, which at least as of a month or so ago, it's not.
The package manager is good and the packages itself are getting better and more usable all the time.
But one could definitely argue that things like routing should be part of the core. On the other hand Meteor could be getting pretty monolithic over time.
Also... you may want to look at it again. A LOT has changed since last year.
http://curlpipesh.tumblr.com/post/107681088292/https-www-met...
You leave out critical information, such as what the scaling is for. Is it to support lots of users or lots of computation? Lots of concurrent connections? Are you talking about meteor.js alone, or are you looking at other technologies? And what is high performance to you? What is a large code base? Why do you presume it will require a large code base?
You provide no requirements, and the question is purely subjective.
But pc86 makes a good point: it probably doesn't matter at this point. With the information you provided, that's the best answer anyone can give.
tl;dr: Yes and no.
Whether it's a good idea? Who knows. Depends on how the ecosystem will develop. Currently it's impossible to judge its health and growth reliably because of the massive hype surrounding it.
But the question isn't really whether it's mature enough. The question is whether you can / want to support a meteor application for the lifetime of the application you're planning to develop. And if you don't, how easy it will to replace you.
By the time everyone agrees, it'll be 10 years down the road and we'll have a new framework.
Then they are plenty of packages, some officials, some supported by the community, to answer most of the common issues you will face.
It's very modular, and could fit many different needs. From a small hack, to an MVP, to a bigger project that scales.
There is a growing number of dev shops who are working with Meteor.
Personally I am using it to maintain http://apis.io as well as http://speedhack.io.
* Meteor has added quite a bit of functionality
* The cluster package has simplified scaling a lot
* Template level subscriptions are making it easier to build reusable reactive components
* The quality of third party packages is improving as more developers are contributing and reaching a level of proficiency
As far as "high performance", it's a node app... so you have all the plusses and minuses of node. I think Meteor is way ahead of the curve compared to other platforms (think Zope, Rails, Django, Drupal) for it's age.
I'm building several apps with it now including a WebGL CAD app and a mobile job search app. Performance is actually surprisingly good for the CAD app and the job search app runs as fast as the apis it sources data from will let it.
One thing is for sure--Meteor makes Javascript less ugly by letting us write synchronous code. And the "place the code whereever you like" approach really simplifies the coding experience and make it very enjoyable.
No plateform "scales" magically. You are asking for something that doesn't exist. Or you don't know what the hell you are talking about and just throwing random words to make your question look sophisticated.
Sorry but I'm a bit sick these kind of questions.
