I’m not sure if ‘immanence’, ‘homoiconicly’, or ‘the usual turtles inside’ was the best bit of that reply.
1 Like
The problem with so many of these arguments is people need to choose the right tool for the right job. There isn’t one monolithic framework which does absolutely everything perfectly.
Meteor is good for smaller applications that are more responsive out of the box, imo.
I had a friend who wanted to make a small repository of young basketball players and their statistics and hold a picture of them to show to recruiters, and a mobile app to go with it. For that, I said he should use Meteor, and he liked it a lot and was able to develop quickly and effectively.
For my own web application I used Flask and Angular because that fit my needs better.
1 Like
Not giving out an official mdg response in this post.
I have replied to these points on a Crater thread already. I do think a lot of the points raised here are valid concerns (although I would say they are fixable even with packages). Some of them are not something I would worry about, but if this is a deal breaker for you, I guess this is your choice.
I would like to ask people to keep the conversation civil and focus on discussing the particular points of the article and not the personal achievements.
Back to the article: I think this article is an indicator that Meteor is actually doing really well. For the last 2 years I have been working on Meteor, the usual criticisms went from “a toy”, “doesn’t scale beyond 1 box”, “can’t use ember/angular” and “no REST” to things like “no clear way to clean up” and “mongo is the only supported database”.
The reason is simple: Meteor is not a 100% perfect solution but every criticism and concern is solvable. Granted, SQL support is still a big project.
20 Likes
hacks? You don’t think that’s unfair? Are all atmosphere and NPM packages “hacks”? I don’t think so.
MDG feels that if the community is doing a good job (i.e Velocity) addressing a need, why duplicate efforts? Iron-router and flow-router suit the needs of most people. Who is to say an official package is always going to be better than a community created package anyway?
2 Likes
You must understand there isn’t anything inherently “hacky” about a package. Have you gone your whole developer life without using any third-party libraries?
We’ve created Meteor packages to integrate with third-party APIs like Stripe, HelpScout, Desk.com, Shopify and other system. We’ve created packages to integrate state-machines into our code. We’ve created packages to share code across multiple applications. And of course we consume a lot of packages to more rapidly implement features like routing, authentication, UI theming (bootstrap), accounting specific functions, exchangeRates, and all sorts of other tasks.
For me Meteor wouldn’t be any better if some officially ordained “core” developer created all these packages. The community makes the framework. MDG realized this early on and that’s why they’ve invested as much into developing the community as they put into the technology.
3 Likes
@maxhodges I think all the points I mentionned in my article are critical enough to be addressed officially in the Meteor API, if not I consider Meteor not production-ready.
Guys I told you why I’m no longer using Meteor, you are loosing your time trying to convince me I’m wrong, and I invite you to discuss how Meteor should improve itself if you don’t want other articles like mine popup tomorrow.
That’s just my point of view, life still goes on, take a rest, look at the stars, meditate, whatever…
1 Like
What’s the point of writing a blog post, opening it for discussion and say simply “that’s just my point of view”? This guy is funny, says is not discussing anymore but still come here and post to stop the ~hate~.
You raised good points and was worthy to discuss over them, unfortunately you seemed more into flames than to address them.
As you said, life goes on and Meteor is improving. Hopefully in the future less and less concerns will be raised.
5 Likes
That sort of attitude explains the abundance of defunct frameworks, plugins, UI libraries, components etc. that never had a chance to begin with. Even if you’re a genius running on Modafinil, the most you can hope to come up with nowadays by yourself in terms of a JavaScript library is something like d3. Pretty far in scope from a high-performance reliable stack, which are worked on by entire teams of experienced engineers.
@sashko put it very well in Optimistic UIs with Meteor:
It’s very hard to build an app that correctly implements client-side simulations as it takes a lot of work to make your UI consistent, avoid loading duplicate data over and over, and keep your client up to date with your server data.
2 Likes
To play the devils advocate for a second here, this altitude might be a result of a poor marketing decision:
Most cool libraries created for Meteor at the moment, fall under the namespace of meteorhacks. And of course I don’t speak for everyone, but having to add a package with the word ‘hack’ in it’s name makes me cringe a bit. I know all these cool tools are fine packages properly developed and maintained but even now I feel a subconscious fear when I have to install one of these things.
Food for thought
3 Likes
I have a client who is actually specifying that we use Meteor - he has been following it for a while, and is a big fan of the tech. As I was introducing myself and my company, I told him the top reasons I like Meteor:
- It’s easy to get started. Getting your first prototype on screen is dead simple. meteor create, and you’re there.
- It’s easy to keep moving. There’s a robust, homogenous community, adding packages. So once you’re underway, not only is it likely that someone else has run into the same problems you encounter, and not only is it likely “there’s a package for that”, but they have solved the problem on the same tech you’re using. Often SO solutions are “Well, if you use LibraryXYZ, then it will work, but …”. Meteor gives you a SINGLE, INTEGRATED stack, rather than a MEAN or other Frankenstack. Obviously, those stacks have been vetted by many thousands of hours of development time - but at the end of the day, they were not built from the ground up to work together. They need to be MADE to work together. This gives package authors a leg up - it’s like coding for iOS vs. Android - there’s fewer variation, fewer different configs you need to support.
- It doesn’t break on you. The team understands what it means to release production software. We have been writing Meteor code since 0.5, and shipped our first product on it at 0.8.2. At each point release - even before 1.0 - Matt and the MDG knew that they had real people, building real products, for real, paying customers. The change lists and migration docs were always crisp. Basically, they never let us down, unlike other library providers.
- It’s a very good tech. We did our technical due diligence before committing our first project to Meteor. The team is incredibly smart, well funded, and focused on the singular problem of providing a capable, integrated, usable stack.
When I dug into his requirements, I actually pushed back - he doesn’t need reactivity or many of the other Meteor ‘secret sauce’ pieces. I asked him why he is specifying Meteor as his desired solution, to make sure I wasn’t missing anything, and he said “That’s a good point, actually.” I told him it’s still a great tech, and it’s probably still the right answer - but not because of reactivity. That’s just the sexiest bit - the real payoff for him is that he has limited time and money, so, see bullet points 1, 2, and 3, above.
Basically, as has been said before, there are many solutions out there, and it’s a matter of using the right tool for the job. For us, Meteor is a good tool for many jobs, we always double-check that it’s the right solution, but to go so far as the original poster and say “It’s not even worth being in my toolbox, and I’ll never tell anyone else to use it,” is foolish. Why? It’s SO bad, SO much worse than what’s out there that you can’t take an objective look at it and say “Ok, in some cases, this WOULD be the right tool”? Your choice, and I’m not here to convince him otherwise. From a business standpoint, as someone who sells development services, I’m not sure I see the logic in stating publicly that you refuse to use a tool. It’s like a carpenter who says “Screwdrivers suck! I’ll never recommend them! It’s all hammers for me!” I don’t get it, but I don’t need to, and I don’t need to defend screwdrivers. I need to market to people who want to build things with screwdrivers, and knowing there’s one less person competing for that? Fine by me!
YMMV.
10 Likes
I did a little test run of RethinkDB lately by writing Meteor todos examples using React, RxJS & Socket.io, here’s the code https://github.com/bobiblazeski/rio and the article https://medium.com/@bobiblazeski/of-pipes-and-feeds-6b443b9713e0 .
In my humble opinion meteor still offers the best solution for rapid development of reactive applications, as there are many boring but necessary functionality provided by meteor that allow me to concentrate on my applications instead of reinventing the wheel or twiddle with integrating packages. On the other hand the advent of RethinkDB change feeds, working together with RxJS & Virtual DOM based view layer library such as React emerge as an option for a team that wants to create custom stack and has time and resources to deal with that challenge.
2 Likes
It will be a requirement once your competition does it; then your application will feel old-fashioned and out-dated. 
Most traditional web apps need a refresh button, and I think if you users ever need to click it, you’d be better off using Meteor. Most people think “realtime” is some edge case, but we’re just conditioned to think that (due to the 20 year collective legacy of working around HTTP). After building several apps with Meteor I have a new appreciation for why reactivity should be the default behavior.
And once you’ve seen nice things could be, it’s very irksome to be on a site like upwork.com (formerly odesk.com) and I need to refresh to see new applicants. Why can’t it just be reactive?
Or when I’m on my banking site and I have to click refresh to see the latest transactions. It could easily be reactive with Meteor. On when on a bitcoin site and I have to refresh to see the latest exchange rates. Reactivity is not a ‘requirement’ but it’s certainly better to have it!
Or when I have to click refresh on a forums or SNS site to load the latest comments. Even Pingdom requires a refresh on to get it’s pages load the most current data. If seems old-fashioned and out-dated.
It’s so easy to design a better experience–if they were just using Meteor. Without reactivity, your app is just a fax machine.
11 Likes
Came here for the clickbait title, it’s always interesting to read a “breakup” article to see where the pain points are.
Got a bit religious at times, some got a bit over zealous 
I, like one of the other posters lost in the middle somewhere, am interested in what is meant by the transactions... you're dead point and how that is worked around.
Apart from that, I’ve done projects on the MEAN stack, the angular+firebase stack, bought into grunt, bower + a million other tools to do all the things I don't really care about stack and have found love at first sight with Meteor. (It was actually over one weekend where life was just wonderful again… hehe 
)
3 Likes
DDP is painful in the close coupling with mongo/minimongo. Personally I’d like a clear abstraction layer over that…which I know borders on the oft debated efficacy of an ORM…but still. If used as general pub/sub then it’s only useful if socket style (persistent connectionnessess) is absolutely required for the use case…otherwise something like redis or rabbit or mqtt on the back seems like a path of least resistance and allows a well supported interop used in large scale prod apps today. In the end it comes down to how stateful you have to be for the ux. I think
1 Like
Recommending a hammer because it can be used as a tool to permantly solve marital problems wouldn’t be my idea either. Recommending a hammer because it is efficient to slam a bunch of nails quickly to create a fancy piece of furniture, now there is some value.
I really tried to read the article entirely. Somewhere I decided to do something more useful. Like writing this useless reply and mention a funny line as a starting point.
The title is the thing that probably misdirected me the most. Something like, “Would I use Meteor as a business ready solution to replace an existing stack of a bunch of things and compare it with the features of a suite like webSphere?”, would’ve triggered me to actually investigate those arguments. I think I never gracefully shutdown a server in development mode ( in fact, I just love that I don’t have to do horrible restarts as I did in Rails) and truthfully - any design that relies on atomic transactions and needs such behavior, should be able to handle ungraceful termination without any logic behind it (a great test moment for robustness) - so would it really matter or is it cosmetic?
It is like having the opportunity to cruise with a spaceship and someone is complaining there should be a 300lbs manual, stickers on every cockpit control and that going with Hyperdrive is wasting a serious amount of energy, while having a great time experiencing it.
1 Like
Personally I think that the limitation of DB to pretty much just MongoDB has one of the biggest factors in slowing down Meteor adoption; it’s had a lot of bad press recently, only some of which was unwarranted. I think that the sooner we get support for PostgresSQL, RethinkDB or MySQL, the better.
2 Likes
Personally I think that the limitation of DB to pretty much just MongoDB has one of the biggest factors in slowing down Meteor adoption; it’s had a lot of bad press recently, only some of which was unwarranted. I think that the sooner we get support for PostgresSQL, RethinkDB or MySQL, the better.
Rails (yes, I am using a popular framework to compare meteor with) doesn’t have MongoDB support that wouldn’t break it. Nor does it have Oracle support, MS SQL Server support - and if it does, it is crappy or with no batteries included. Besides, database migrations are the last known legends of utter horror for multi-nerd generations (DB2, Informix to MongoDB) that aren’t defeated yet (and every elite developer needs a veteran scar of a database migration to tell at mandatory enterprise training days). We should cherish them.
3 Likes
About a recent attempt to get react up and running with meteor, have a look on Sam’s stack he outlined here!
1 Like
I’m interested in knowing a little more about this: “If a company already has a Mongo installation, especially if it’s been sharded… no way.” Would you please give an update on whether this is still an issue? How about making a new Meteor app that needs MongoDB to be sharded, if one keeps the Meteor accounts system in an unsharded MongoDB, and have all the other collections kept with ObjectIds in a separate sharded Mongo?
Valid as the points of the article may be, they by no means represent unsolvable blockers for Meteor. The platform as a whole is, at the very least, the start of something really neat. I could not agree more with @arunoda:
I think Meteor is way beyond Meteor itself. DDP is the key. MDG should form a team to decide the future of DDP.
A few months ago we went full in with DDP when we (www.corto.io) started to web-enable our low-footprint, technology agnostic, data centric development framework. DDP allowed us to mimic a Meteor server, and instead of MongoDB data, serve up our own, which could come from anywhere.
We didn’t have to invest in an easy to use JS API, we didn’t have to write complex reconnect-logic and didn’t have to worry about fast, data driven UI updates. We only had to adhere to a very simple spec, and let the goodies come to us. This way we realized great UX in a very short amount of time. This is the power of a well defined interface.
However, we also encountered shortcomings. For example, we found that DDP (or rather the DDP/minimongo integration) is poorly suited for streaming time series data.
We also found that it’s hard with Meteor to build generic dashboards as I can’t dynamically unsubscribe/subscribe to collections without leaving garbage in my client cache. There also doesn’t seem to be a generic discovery mechanism for collections.
Over time these issues will hopefully be resolved. It’s a wonderful stack with lots of value, yet still a bit rough around the edges.
2 Likes