Why I'm not choosing Meteor for the foreseeable future for my projects

community
1

It’s with heavy heart that I’m deciding tonight to leave Meteor in my dev toybox - and it’s funny but it’s not even about how it uses MongoDB (I know a lot of detractors say MongoDB sucks).

My brother and I have been trying for the past two weeks to get a project off the ground and every time we want to expand a feature we run into issues with outdated packages, hunting around for blog tutorials, and just plain old working against the code rather than working on our core idea.

I’m going to keep tabs on Meteor because I think it’s core idea is fantastic and a breath of fresh air in the web development world. But for projects that pay the bills and personal projects I’m just going to use Rails and Ember.

Instead of just whining and leaving, here’s what drove me away:

  1. Packages slowly became outdated and worked only with other old packages that the community had moved on from. Example: A pretty neat login package only worked with IronRouter, and IronRouter is no longer maintained properly. Too many choices none that were properly backed by MDG.

  2. No baked in Router. Again, the entire Meteor ecosystem split into two groups: IronRouter or FlowRouter. Too many choices none that were properly backed by MDG.

  3. Blaze discontinued, React is the way forward (for now lol). Again, the entire ecosystem is split, and just when I was getting the hang of Blaze, React is declared the way forward. I have very little time to dedicate to my side projects, I want to flesh out ideas, not play around with code.

  4. No model validations, no models? A lot of options to choose from (notice a pattern?) but none officially supported. I know MongoDB is a non-relational database, but still - no validations of any kind?

  5. Look what’s currently trending: Why Meteor needs a new Data Layer? - #12 by jeffm - A new data layer? People barely grasp the one in place at the moment.

Basically it boils down to this: Meteor’s tutorial is fantastic, show it’s strengths immediately, but falls short when you want to build anything of significance. If you want to keep going and build something that’s worth something good luck sifting through sketchy README files on Github and outdated tutorials. Then when you finally have a feature working, look: Meteor has moved on to $flashythingX.

I will most definitely come back in a year and see where Meteor is, it has an awesome idea, but it’s slowly losing it’s focus pandering to the hipster programmer and not the actual “9-to-5”.

5 Likes
2

I’m curious, what are you switching to? Is there a stack or framework out there that is more stable or opinionated on these issues?

I think really there are only two choices: be constantly changing, or fall behind and stick with using some things that aren’t being actively developed. I wonder if there is a framework out there that would let you sidestep that situation, which I would consider the reality of web development in the last 5-10 years.

4 Likes
3

Hi @sashko I’m going to switch to Rails (backend API) and EmberJS (client side app).

Rails: You have one almost crystal clear way of doing things that the community has agreed upon.
Ember: You have one clear way of doing things that the benevolent dictator of Ember has decided on.

Structure is awesome, you concentrate so many smarter minds into a single funnel.

I get what you’re saying, stagnate or innovate - but Meteor is just so new, is it really time to innovate? Edit: Actually or maybe now is the best time to innovate, maybe I just hopped onto Meteor too early on.

4

I know that feel, and I’m also leaving too. But for me the problem is the mobile support.

Accounts system for example, it’s not Cordova ready, does not use native facebook / plus apps (uses webview redirect instead).

Community packages works for iOS or Android, never both.

Maybe if Atmosphere start to rank packages by its isomorphic / cross platform capabilities, developers could make better effort on this matter.

But while core packages doesn’t embrace Cordova, I’ll not expect it from community.

I’ll take my chances on react native. It’s very immature by now, but they’re delivering everything they promise.

3 Likes
5

Well, you’re leaving at just the wrong time if Mobile is your core issue–the moves toward deeper integration with React will just mean that for the first time we (and the entire javascript web development community) have access to a real Native Solution: React Native.

…i see you just updated your post to mention React:

except, the Meteor community will end up having Reactive mongo support, and you’ll be de wiring plain jane Reactive Native up to your server yourself.

2 Likes
6

You’re right, I’m following discussions about that.
But I’m not expecting less than a year for the first draft.

7

Well most of the technologies in Meteor are evolutions of ideas designed in 2012 in the Meteor 0.x days. I think Meteor 1.x is a very good development environment for a wide class of applications, but in the meanwhile a lot of things have cropped up in the wider JavaScript community that have, by themselves, gained just as much recognition and usage as all of Meteor.

I’d guess that it’s significantly easier to find articles, tutorials, books, and more about how to use React to build complex UI than for Blaze. In the long term, everyone benefits from Meteor supporting the more “standard” solution, but there’s a difficult switching cost now. In the future, MDG itself will face these switching costs as we need to transition the Galaxy app and our own internal services.

I don’t think this will be the last of the changes. In my mind the main premise of Meteor is bringing the world-class developer environment to people who just don’t have time to sit around and browse through 1000 blog posts about the best way to wire up Redux to Express. However, that doesn’t mean that Redux and Express aren’t great pieces of technology - all of the new libraries out there keep moving the goal posts on what people expect from their developer experience.

My opinion on this would be a two-pronged approach:

  1. Significantly increased flexibility in Meteor core - right now it’s so hard to build a Meteor app with React Native since the Meteor build tool is extremely custom and it’s almost impossible to write code that works both in Meteor and another environment. It’s hard to use a database that isn’t Mongo because everything is so wired together. If it were easier to replace the parts of Meteor that aren’t working for you anymore, then using Meteor is a head start that doesn’t lock you down.
  2. Significantly more opinionated Meteor guide - right now, the Meteor core API is the only official messaging about how to use the platform. This makes it feel incomplete, and results in fragmentation of the package ecosystem - what if Arunoda stops supporting Flow Router tomorrow? Which is the foremost schema library for Meteor? We need to have a document that takes a stand on every single issue. The interesting thing is, we’re the only platform equipped to produce such a document, since nobody else covers the same surface area.

I’d say both points come with a fair bit of controversy, but I think it can be our way of having your cake and eating it too; you can stay on the cutting edge if you want by leveraging the technology in Meteor core, or have a paved road to success by following the guide word-for-word even if it’s a bit outdated at times. And when we need to make big transitions as we undoubtedly will, the guide will be the place we look to see where we need to build compatibility layers and refactor paths.

I don’t know if any of these things help you with your personal projects at the moment, but this felt like a good thread to lay this stuff out.

18 Likes
8

I’ve found packages such as AutoForm, SimpleSchema etc to be extremely solid.

Iron Router isn’t maintained properly, really? Stills works solid across all my projects. So the login package in reference doesn’t work with FlowRouter I assume–nobody says you have to use FlowRouter. I find this statement inaccurate–at least if you’ve been in the Meteor community for a while, tracking which packages to make best on. One example is far from enough. If you have a lot more, you must be picking some obscure packages.

It doesn’t need to be. They are both solid as all hell. That’s how us “histpers” have pioneered NPM to be, and Atmosphere/Meteor too tries to make things more of a “library” rather than a Framework, giving us access to 3rd party packages as if they are first class core modules. That’s the whole point. You’re leaving the open future and current for the walled garden past.

It’s the only possible decision. Everything is congregating around React. It’s either get on the boat or be left behind.

Who doesn’t grasp it? Blaze was easier to grasp than jQuery.

Github + NPM is how everything works these days. Just cuz we dont have shiney Active Record guides on the exterior doesn’t mean what’s inside isn’t solid.

On this one, I agree–they need some sorta class-based containers/structure to build your app in an object oriented way like Rails. Been a huge problem for people how to scale all the procedural/imperative code Meteor has you writing.

I dont think it was ever for the “9-to-5” programmer.

Then I hope you don’t have that much reactivity to manage. Several orders of magnitude more boilerplate work to do there, even if Rails has stepped up as much as possible to address it. Ember similarly has you doing lots of setup for what’s inherently reactive in Blaze and React. …Why not React at least? I havent checked Ember in a long time, but last I checked the fire was put out.

It’s a trade off–do things the old way and put tons of work into what’s easier in the new systems (or perhaps just avoid it). Or, do things in the new systems, knowing it’s somewhat of a moving target. The upside of the moving target is you’re growing and learning a lot more. Anyway, I just think the boilerplate you now have on your plate to achieve the same level of Reactivity is a vast waste of time. But if you have very little Reactivity–likely because you’re not pushing the envelope of what web apps are capable of–then your decision is a sound one. However, if you want to push the limits of user experience, Reactive-first frameworks/tools are the way to go. Cheers

Ps. You, look like a relatively young guy, not sure why you don’t want to be part of the big tectonic plate movement into the future. You’re leaving at just the wrong time. The whole Javascript industry is finally reaching where it’s been heading, given things like React Native, RethinkDB, GraphQL, Meteor’s proven effectiveness for so many developers, browser advancements, Babel, Node, NPM, etc. I predict a slowdown in a year after React Native officially kills the “Native Problem.” That’s the big one we’ve all been waiting for (along with browser inconsistencies), and now that’s finally all gone. A lot of things have stabilized. A lot of innovative things that you just couldn’t do in pre-web platforms, but made a lot of sense for web. So while previous platforms might have been more stable, they weren’t accessing as big and frictionless of an audience: people web browsing that can click from site to site. So it’s been a given the “platform of the web” would be less stable, a “moving target” as you say. But you get a whole lot more. So just using anything other than the web’s official tooling, NPM is not gonna align you with this future. Meteor branched out (at the perfect time when NPM wasn’t ready), but is merging back at the perfect time.

No, there isn’t if you want to produce stuff able to capture the attention of users/influencers who will think your Rails site is “so yesterday.”

3 Likes
9

Yes, key key key. You guys need to say “do it this way, if you don’t you’re on your own.” When I first discovered Meteor the thing I enjoyed about it the most was the tutorial and packages doing most of the heavy lifting with opinions being thrown heavily.

Now it’s like half-baked support for everything under the sun, and I see guys saying “What about the larger JS community out there?” - I say, what about us Meteor devs?

6 Likes
10

Have you been following the Meteor guide project at all?

We’re actually not far from being done.

You can check out all of the opinions by reading the outlines, and browsing the issues labeled “article”.

11

700×840 637 KB

I’m sorry but did you really just prove my point with the so yesterday comment? :laughing:

1 Like
12

No I haven’t, where do I find this link?

13

It’s in my post. I’ve been promoting it basically everywhere I know how, but apparently it’s not easy to reach the whole Meteor community.

2 Likes
14

funny. i knew that one wasn’t gonna do my point justice. …but at the same time, you’re only retort is to focus on wording/presentation (along with a meme pic)–to me that means you likely don’t have the substance to back it up. DONT LEAVE MAN! Bad decision, stay with us! It’s about to get very interesting right now. And more stable for you.

ps. 14 your old girls wouldn’t even say “so yesterday”–i’ve been at this computer too long today.

1 Like
15

Well you’re agreeing with my basic premise: “There are choices.”

That’s fine for you.

It’s not for me.

No real true or false here, just different goals.

1 Like
16

Well, I thank you for this post. There is a lot of things going on in the Meteor community (and more so in the greater NPM community causing it), which are reason for our/your concern. Seeing first hand the effect of all the changes we’re facing is crucial if we ever plan to navigate the waters to success. So again thank you.

My personal opinion, as I said before, is that things will likely slow down in a year or so. So I think it’s imperative Meteor jumps on the bandwagon for all the latest advancements that basically just blew up this year (React, GraphQL, Redux + immutable architectures, etc). In short, this is the big wave, and we need to make sure we’re on it. After that, I see a brand new host of problems being tackled, but these tiers stabilized (much like HTTP, HTML, javascript, the browser itself has stabled as our main mediums in the past).

If Meteor plays its cards right, it could be the defacto platform to utilize “The Facebook Stack,” i.e. GraphQL, Relay, Redux and React (and NPM/Node of course). I don’t think Facebook has any interest in making a unified easy-to-use stack. They just wanna release these core pieces and let the rest of the web development community figure out how to put them together. That’s Meteor’s opportunity for the taking. If someone could put them all together in top quality fashion, that will be a big win for them. Meteor’s done just that for years–just using older tools. It should be even easier to put together the newer more optimized tools (even if now, Meteor has the added obstacle of being backwards compatible with the old tools).

2 Likes
17

Yep; if before we had to build the tools and put them together, now we have 3x more people and money to do just the putting together part.

8 Likes
18

Super excited! Hope Galaxy is showing signs of being the big pay off you guys need!!

19

The guide is getting awesome! In short time it got some shape…

I think it’s going to make a big difference in the learning curve, i wish it was here when i started.

I would like to see some pretty advanced stuff in the guide along the path Meteor gets more modular, for projects with too specific customization needs. Sometimes it is even better to know some internals than use packages.

Great work sashko.

3 Likes
20

Hola Sergio,

I’m totally noob on meteor and some of your estatements puzzled me. May you, please, explain a bit more this two points:

Is iron router getting deprecated?

Is not worth getting used with blaze? I mean… Is react definitely ‘parking’ blaze?

Thank you