* 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.
Delegating quasi-core parts of the platform to 3rd party libraries is quite common. For example, the preferred routing package for Angular, ui-router (https://github.com/angular-ui/ui-router) was born four years after the release of Angular, and for DOM state preservation, the ui-router-extras (https://github.com/christopherthielen/ui-router-extras) addon is required.
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}); } })
I've been using Meteor since early 2013 on all my web projects, and for me the core team goes to the correct feature depth — there's 4000+ packages on Atomosphere — it'd be really hard to determine how deep they should go pulling things into the core.
I guess you want every package to start with "mrt:"?
If something has been brought into the main package, its usually a sign of maturity, and stability and usefulness to a large number of people.
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.