Been using Meteor for 4 months, and I'm an junior ops guy turned developer. So if I say something that sounds like I don't know what I'm talking about, it's probably because I don't, so take it easy. Having said that, here's my two cents:
First and foremost, Meteor is a complete platform for building modern web applications. You get so much out-of-the box functionality that you'll be productive in no time. Also, you will find that your codebase is several times smaller than with other frameworks, because the isomorphic javascript saves you from needing to do a lot of boilerplate and configuration. You also have very convenient ways to organize code, whether through packages or in a /client or /server or /cordova folder, so you'll have an easier time managing your code. So a "big" application is smaller than it would be, and makes for more understandable code.
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.
Ha. Your writeup basically summarizes my extensive "Why Meteor" article. Curious if you've read it before, or if Meteor just makes developers become great minds ;)
I read it about a month ago, but these are thoughts that have been ruminating in my head for the past few weeks. I have struggled to explain the benefits of Meteor to others, they always try to compare it to React, Angular, Knockout, Node, Express. It's hard to get people to understand that it's a full-stack platform whose purpose is to make programming easier and faster. http://meteor.com/about
* 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 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.
* 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.
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?
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.
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.
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".
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.
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.
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.
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.
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:
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.
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.
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.
This is a poor question. You are asking a for a lot but providing little. The answer, at the same time, can be yes and no.
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.
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.
I don't understand this comparison. Meteor makes things simpler and removes a lot of low-level complexity. It makes software development simpler. By "some people want Windows", it sounds like you're suggesting that there's a better platform/framework for web development that's "plug-and-play" ready -- so easy that a non-developer could use it. I actually think that Meteor is the closest thing to this, and is the very best starting point for new developers. To this thread's question, it's also great for large applications. But at the end of the day, it's still web development -- you need to learn JavaScript, Mongo, html, CSS.
Do you ask because you are rewriting an existing large scale application (if so, why are you rewriting and why are you considering a different stack altogether?), or because you are starting a new application (there is a 95-99% chance it will never need to scale so the question is not terribly important unless it's between this and one similar technology for some reason)?
Exactly. And by the time you do need to scale, Meteor Development Group will have released Galaxy, the enterprise-grade Meteor hosting platform, which is their money maker.
I don't know about meteor in particular - but my advice would be to eschew frameworks in favour of libraries, I'm not the first person to suggest this and it's worth using some google-fu to read the differing opinions.
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.
While I agree in principle, I think it's fair to point out that glueing various libraries together takes a lot more work than using an all-in-one solution like Meteor.
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).
You can weigh the trade-off between needing to configure your environment with what Meteor gives you. I would say Meteor has a value proposition that's definitely worth looking at. The list of things it helps you with is more than most other frameworks, and at the same time it's modular so you can swap in components that are better for your use-case. You also have the benefit of still being in the JavaScript/NPM ecosystem, which is easy to take advantage of.
That post was from 2010. I think you vastly underestimate the difficulty of building from scratch rich, modern single-page apps that satisfy today's users' needs. Have a look at "7 Principles of Rich Web Applications" [1] by the creator of Socket.io, and at my comparison between Meteor and the MEAN stack [2].
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.
I think that depends on exactly what you are doing.
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.
Except that you underestimate the effort in incorporating the "framework" in your new project. Sure it isn't hard per se, but the steps involved in learning every bit of a process that surrounds the framework kills the excitement at some point or other. Like in rails, learning all the routing, code generators, forms, asset pipelines just makes you quit at some point.
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.
I think it goes both ways. Makes some things a lot easier and others a lot harder. Django's admin for example, can often give you 90% of what you are looking for with very little effort. It doesn't take a lot of effort to learn it. The again, if your application falls outside that model, no point in trying to shoehorn it in.
I would also say that frameworks keep things consistent(I know Django well, so based on that). I recently added Django-rest-framework to my application. It took very little to learn that as they have tried to keep the coding style the same as the class based views. Using them is almost the same, so after the initial half day or so in the docs, everything just clicked into place.
The answer to this question will always be "Not until X is available" where X is something needed by the company of the person answering your question.
By the time everyone agrees, it'll be 10 years down the road and we'll have a new framework.
No. Even pagination still requires 3rd-party plugins.
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.
I am actually quite a friend of the modular structure (Unix fan here).
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.
I personally don't see why pagination should be in core. That's not a necessary thing to have. I would rather have the core developers work on more important things like SQL support or performance optimizations rather than having to worry about a dynamic way to do pagination. There are 3rd party plugins for that reason, so you can still accomplish what you need to without needing everything in core.
Also... you may want to look at it again. A LOT has changed since last year.
Things have gotten a lot better over the past few months:
* 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.
What I like about Meteor is its community, which is very active and diverse. Most people who use Meteor tend to have a deep fondness and attachment to the framework as opposed to other Javascript frameworks in which IMO are used for the sake of their performant, simplicity, scalability, etc. all the functionalities.
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.
> that should be able to scale and with high performance on both client and server side
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.
It's not FUD, but I don't want to expose myself to criminal liability by PoCing the issue (it would require hacking the server and trojaning the shell script).
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.