[alexandernst]

No, meteor is still missing quite some, basic I'd say, things.

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.

[benstr]

There are great packages available that handle these items for you. the Meteor Development Group is dedicated to maintaining the sub-projects that make up Meteor and equally dedicated to supporting community packages by not stepping on too many toes. Just take the the routing snap-fu with Angular as an example of how not to do things. Meteor is focused on making a framework with as little friction as possible with their community. It is a real joy to work with it.

* 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.

[brwn]

I'm a .NET guy, and I love Meteor. There's no call for this kind of ragging because he expressed his opinion that he felt it wasn't yet ready for large applications.

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?

[charif]

You missed that the MeteorJS ecosystem has a lot of packages that take care of i18n, routing support (iron router), SEO (spiderable), basic forms support (autoform).

I agree that there is room for improvement, but I am confident that the team behind MeteorJS will make MeteorJS a success.

[alexandernst]

No, I didn't. I'm aware of the existance of those. But those , as you say, external packages are lacking any type of official support. And that is just no acceptable for any serious/big project.

A project manager will be rofl-ing hearing those words, I'd say.

[towelguy]

Almost all the node.js ecosystem consist of external non-official packages. I don't get your point.

[kowdermeister]

I know these project managers. They ask for a 15 line JS helper "library" enterprise level support and they start to scratch their head "what if the developer abandons it".

[alexandernst]

Only that we're not talking about a 15 lines JS helpers, but about quite big parts that should be in the core and instead they are some 3rd party plugins.

[dandv]

If you're looking for a monolithic solution, Meteor may not be for you. Check out Wakanda and Servoy.

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.

[subpixel]

There has been some unofficial recent discussion on certain Slack channels about MDG introducing their own versions of key packages. I hope that happens - I think it would go a long way towards addressing concerns like yours, which I share.

[abhiaiyer]

Meteor is not necessarily a framework. But a hybrid system to build ontop of all in javascript. We get things out of the box and we build things we need to help further the community. Many of the packages weren't created by core dev but made by other smart people.

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

[sgdesign]

I think you're under the wrong impression. Meteor is somewhere between a platform like Node (which it runs on top off) and a full-fledged framework like Rails or Django.

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.

[nourharidy]

About joins in subscriptions, other than the community package Publish Composite, there is an officially supported alternative yet very poorly documented or mentioned, using the Spacebars layer: It is the template helper argument feature, which is in my opinion must more reliable and developer friendly, you can read about it here: https://www.discovermeteor.com/blog/spacebars-secrets-explor...

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}); } })

[roarkjs]

No i18n? https://github.com/TAPevents/tap-i18n

[softwarerero]

A little older but not dated is https://github.com/softwarerero/meteor-accounts-t9n that started as a translation of the meteor basic packages and it is easy to add translations for an application. Currently it comes with 24 translations of standard meteor packages. We have not implemente international date and calendar support so it is not a real i18n solution, just translation. But it works in many production projects, which answers the original question indirectly.

[joshowens]

Spoken like a true person who spent an hour investigating the platform and then moved on. All of the issues you've pointed out are solved using third-party packaging.

[alexandernst]

Please see the other replies I made. I'm aware of all those plugins, but I'm concerned about the official support they (don't) receive.

[rywalker]

Heh Alex — the Meteor posse has arrived to this thread (I'm a big Meteor fan too!) I'll echo some of the others, that any issues with Meteor being ready for primetime don't have to do with the issues you cited, but more around being unproven to scale at high traffic (also not disproven).

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.

[brown2rl]

Not sure what you mean by "official"? As of 0.9.0, MDG hosts all the 3rd party packages on the "official" Meteor Package Server. (https://www.meteor.com/blog/2014/08/26/meteor-090-new-packag...)

I guess you want every package to start with "mrt:"?

[roarkjs]

Why does it need to be official?

[collyw]

Plugins can and do work well some of the time. Other times they don't.

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.

[joshowens]

I guess money and a degree from MIT makes the code look/smell better?