Meteor is pretty great as we all know, and it’s had enough publicity by now (I vaguely remember Meteor being in Github top ten for a while). One would think it would have taken the world by a storm by now, with most startups adopting it by default. And yet, its market share is tiny, its job market is non-existent. What’s up with that? What could be the possible reasons? Am I missing something?
4 Likes
I’d also like to hear some thoughts on that.
As a Frontend-Dev I found that Meteor opens up a huge world of possibilities for me.
Suddenly I can do the stuff my Backend-Dev colleagues are doing.
Without needing to learn 3 new languages. That feels like magic!
In my oppinion every Frontend-Dev out there should give it a try.
Yet in my experience many of them have never even heard of Meteor?
Not sure about the reason for this.
But I’d love to have someone of the MDG on a Frontend-Podcast like ShopTalk.
I would say that one of the biggest reasons is the lack of support for SQL DBMSs.
I’m not trying to start another thread thrashing mongo, but until there is stable support for a normal RDBMS, Meteor adoption won’t go too far, it’s just a fact.
Other than that, I think people are still sceptical about Meteor scalability capabilities but this is changing (I think).
3 Likes
-
Node version changes and incompatibilities; each new release of node typically has issues that wreak havoc on deployments and prevent developers for feeling confident in upgrading meteor, as well as upgrading packages.
-
Poorly managed packages that wrap up well-managed javascript projects.
-
Over zealous meteor advocates who are ignorant of most technology outside of atmosphere and meteor; even if they have a heavy non javascript technology background.
-
The point when a well meaning novice developer hits when they realize they may need some computer science / logic fundamentals to fix far reach problems exacerbated by the above.
-
CoffeeScript.
7 Likes
Maybe it is because people are blinded by the fact that there are languages on the backend and front end. I mean, needless to say, it is verylikely that almost half the population who livedon PHP for the past decade, doesnt even know there is a thing called Node.js.
If you tell someone, Hey, I can use JAVASCRIPT on the backend.,
that person be like: What? I thought JS is used for animations. Have you heard of Jquery.?
I am not criticising Jquery, or anything, but People are just blatant arrogant about change.
They dont want to learn something new.
And if anybody ever sees this question in the future, Let us tell the world that, Meteor is AWESOME.
2 Likes
Could also have something to do with Meteor being a solution for both the client and the server. It’s not natural to take Meteor for only the server, or only the client.
If you’re used to running Rails/Django along with Angular and SQL database, to switch to Meteor, you basically have to switch out everything, and that’s probably scary for most people.
I realise you can use Angular instead of Blaze, and you can start using SQL, through packages, but these aren’t yet supported by by MDG.
The scariest part is probably switching backends. If you have a team of strong Ruby developers, it’d take a lot to switch your team to this new platform.
If you look at big apps built using each platform, for Rails I get:
For Django I get: http://codecondo.com/popular-websites-django/
Those apps inspire confidence. But what do I get for Meteor? Nothing of the magnitude of the sites posted above. I’m guessing this will change. Meteor is still very young.
One other area that seems to be subpar is testing. Velocity just doesn’t seem to be up to it (although I haven’t played with it in a while, so maybe things have improved a bit).
But despite all this I agree that Meteor is awesome and I hope it continues to grow.
3 Likes
The question asked in this thread is based on the false assumption that good technologies take off. The right question is: “is there any reason to believe that Meteor will get widely adopted?”
5 Likes
A big part is the misconception that it is insecure. A lot of people will say that it is terribly insecure without really reading about how it works, so that part is really on them.
Another major problem is that meteor does not allow for much variation in choosing technologies. Like choosing a database you prefer. With a more traditional framework like Flask, you can work with just about any database easily.
Other people don’t like how meteor melds the front end and back end.
I only heard about it recently and was about ignore it again in the face of the ever popular angularjs and mean.io approach to js full stack.
Only when a work colleague asked me to check Meteor out and I had to find some arguments for sticking with MEAN did I spend a weekend looking deeper into it and totally change my opinion. Having gone through the pains of asp.net/jquery and angular/firebase/node approach, meteor wins on so many initial levels it was a no brainer.
My friend played with it for a side work project and is doing a full app with it next. I’m doing a rewrite with it and will be using it for my next project too. It seems to me that meteor isn’t the popular kid on the block, but if you’ve heard of it, then you’re more likely to be hooked! These stories are pretty anecdotal… sorry that’s all I got 
I’d like to second elgusto’s point about SQL databases.
I’ve been absolutely wowed by Meteor and how easy it is to get something up and running. But having spent most of my time on backend development and SQL databases, I really struggle to understand how to create a good Mongo schema. The few projects I’ve used Meteor just don’t seem to fit well in a NOSQL database.
It kind of feels that Meteor is more of a prototyping framework used to prove an idea (which it does very well) but not currently something you would use in production.
IMHO despite all truly amazing features of Meteor, there still no really killing app. Lets face it. Even significant technical advantages attract initially relatively low number of people, typically young, enthusiastic devs, who have not invested years of their career in this or taht technology, so potential switch is relatively cheap
The game changer is usually a spectacular app, being adopted by millions, even for a short while. However great opportunities Meteor delivers, it is still pretty new, so critical mass of thousands of apps has not emerged yet, out of which a couple would really amaze mass publicity.
The good news is however that all other parts of that puzzle are mostly in place, so to me, its only a question of time when adoption explodes
4 Likes
I am very new to Meteor and honestly only gave it a chance because a friend of mine said it was worth another look. I think a lot of the early write ups that I read were not very favorable and I am also a pragmatist that searches the job boards and sees if a tech has any traction. That being said in this instance I need to write a large app by myself for the most part and meteor seems like a great way to do that after going through a tutorial. I will say that there is a lot of “magic” going on and that tends to make some people nervous. There usually is a price to pay for “magic”. So far my only issue was the order that javascript files were automatically being compiled. This is an instance where the “magic” wasn’t so great and I felt it a bit hokey to have to rename the file or put it in a sub directory just to get it to compile in the needed order. There is nothing wrong with default “magic” but give the developer some power with a config file (again i am a newb so maybe i am wrong). I will also second the opinion that Meteor will have a much better chance once they support mysql or postgre etc…
1 Like
I’ve just started to learn Meteor, and I absolutely love it until I get to the database arena. Most of my databases are stored in Postgresql, and that’s not going to change. I’ve been tinkering around with some third-party apps that help, but they’re still more like second or third class citizens.
I’d recommend Meteor to anyone that needs to build something from the ground up, because they can work around the Meteor framework. But for someone with an existing project they were looking to convert to another framework, I’d be hesitant to mention it at all right now.
Another issue that I came across when working on a project was that I wanted to pull a distinct query from a collection but found that Mongo 2+ has that, but the bundled Mongo 1 does not. Data is so important in almost every project that it should be one of the highest priorities for every release.
Can you connect Mongo 2+ to Meteor?
I would suggest that it’s partially due to Meteor being not opinionated.
I realize this is great for the platform, but it does lead to one issue that slows adoption.
This leads to a lack of consistency among tutorials, books and learning resources.
Take routing for example. Should you put subscriptions in your routing file or somewhere else?
Discover Meteor and Meteor in Action take different approaches to some very basic stuff.
This is great for designing and building apps, but as a beginner to Meteor, it makes it more harder to pick up.
6 Likes
rename the file or put it in a sub directory just to get it to compile
I’ve hit the same issue and found for me, there’s typically two scenarios of file loading conflict.
- A library function that needs to be loaded first - I ended up putting these in lib folders as per the meteor file structure
- Parts of the same ‘feature’ spread around in different aggregation files, e.g schema.js, collection.js, helpers, hooks, etc - Having these in separate files caused me to have to rename these 1schema.js, 2collection.js etc… but if instead you separate by feature (login.js, declare schema, then collection, then helpers, then hooks then rules etc), then it works.
Hope that helps.
Second all the comments about it handling both the front-end and back-end. I can’t think of any “isomorphic” framework that’s really dominated the market. Part of this might be that while isomorphic frameworks are great for a small team trying to get an MVP off the ground, they don’t really mesh well with the separation of concerns in larger organizations.
That is, building a unified framework isn’t super helpful if you have dedicated “front-end” people and dedicated “back-end” people. And in larger organizations, it sort of makes sense to focus. Even if you’re dealing with the same language and very similar pieces of code, the different contexts between the client and server force developers to think differently – e.g. Minimongo may use the same syntax as regular Mongo, but you don’t really have to worry about query performance on the client the same way you do on the server.
Also, Meteor forces developers to heavily rethink their assumptions on how to build an app. If you learned to build apps using PHP or Ruby on Rails, having to grok pub/sub, client-side data stores, latency compensation, reactivity, and more is a bit much
3 Likes
We have yet to see an end-to-end enterprise quality tutorial or video series which builds a full-scale enterprise application using all best practices.
6 Likes
very hard to port existing themes. You can build a great app, but be sure other people jquery will not work. This is my biggest limiting factor right now.
Please make porting easier, like a css/js sandbox to be able to drop other people code and make it work. Right now the loading logic mess everything up 
2 Likes
IMHO:
-
MONOLITHIC: the framework is very “full stack”, despite what has been advertised during preview era you can’t really switch technologies, you have to use proprietary packet system, exact version of Node, exact version of Mongo, without SQL, you have to struggle to adapt to the deploying technology, etc… You have to accept it as a whole or choose another framework. With the current “no framework manifesto” and ultra-specialized libraries, Meteor stay at the far opposite end of the spectrum, you can’t get more “frameworky” than that.
-
TOYISH : the framework is very beginners friendly : everything is global (has been partialy corrected), there is the infamous “Session” object, every files are bundled to the client, every data is accessible on the client by default. That’s a good thing when you begin, but i think it propably frighten more experienced and “enterprisey” developers/architects. These gave a bad rep to JS at the beginning and 20 years later it’s still struggling to get away from this “toy langage only for prototyping” impression.
-
MAGIC : Easy reactive/declarative coding is very cool. “Transparent” reactive programming is even cooler. Everything automaticaly work… until it doesn’t. When a computation depends on A which calls B which calls C when reactive variable D is defined, most of the times it works, but sometimes it doesn’t, and then you are in a world of pain. I have been developing a relatively big app in Meteor since the end of 2012, i think i have a pretty good understanding of how computation’s dependencies are registered and i still struggle with a bug i have been having with a reactive data source sometimes not registering, for a reason i don’t get, and it seems quite impossible to debug. As the adage goes “abstractions leaks” and sometimes when you have to look under the hood it can get pretty nasty. I guess experienced developers who have already been biten by “magic” technologies try to stay away for them at all cost. And there is not really a point in using Meteor without tracker.
-
HIGH OVERHEAD : i don’t have personnal experience with this matter, lacking the success that could cause high traffic to become a problem, but from what we ear, full real time could be very expensive for the hardware. We hear workarounds involving pagination (that make sense and i have implemented it sucessfully, althought it can lead to problems of its own) or doing most of the things on the server with methods (but then what is the point of Meteor ?). Like said by someone else, there is no “killer application” demonstrating high success application developed with it. Probably most of us remember all the “developed with Rails magic” apps that had to change their technology in panic when people really started to go to their site.
Points 1 & 2 will be probably adressed in the near future (with ES6 modules my best hope, Angular, React and at least one SQL DB for those interested), for points 3 & 4 i’m not that sure.
Perhaps the problem is that meteor is not the right tool for every application as some of us could believe (wish).
10 Likes