I think what @Spyridon was really saying is that he wishes Meteor was as user-friendly as it used to be. Part of the problem is that you guys didn’t invent React 
so despite all it’s advantages, the syntax can be rather obtuse.
8 Likes
A lot of that is ES6 as well, not just React.
3 Likes
So you only just don’t like the new Javascript. Meh.
The only react-thingy there is in your screenshot is the embed html tags. Every thing else is standard.
2 Likes
The lambda operator was not invented by Ruby. Also - in Ruby it’s actually ->
Are people that decide to build apps without Meteor better off, or do they suffer from other forms of fatigue?
2 Likes
I think the ecosystem will always be changing and Meteor is far from dying. They’re adapting like any sane company would.
Think about this: Galaxy, MDG’s main B2C source of recurring revenue, is built on Meteor. That says a lot about where they think Meteor is going.
1 Like
I’m definitely curious about this as well.
It is true that what I’m saying is it’s not as user friendly, but not necessarily because of React. My primary project does not use React.
My main problem is it does take more time to work in Meteor than it used to, and I’m worried if this trend continues in to the future.
I am already very comfortable with Meteor (this last project of mine has been worked on for over a year), but I do recognize that being friendly for new users is an important priority for Meteor to grow. And Meteor has been lacking in this department since 1.3 as well.
So it seems Meteor has became less user friendly as a whole - both for new users and experienced ones. It’s still manageable right now, but if the transition to Apollo and NPM require the same kind of trade offs of development speed & user friendliness for functionality, there’s going to be trouble.
Personnally, I do believe that Meteor is dying, because some of the major packages out there are not maintained anymore. You can clearly see it in the Graph Activity in Github and the number of issues piling on.
Just to mention a few: Simple Schema, Collection2, CFS, Iron Router and more recently Flow-router, meteor-roles, meteor-spin, etc. Basically most of the major packages. They were actively being worked on last year but not anymore.
4 Likes
- Some of these packages you list are very mature.
- We are moving towards NPM so use packages from there.
- Many packages had limited usefulness including many that were NPM wrappers.
Also, people in meteor-related businesses are re-aligning.
3 Likes
- True but mature has nothing to do with activity, otherwise companies like Microsoft would have stopped working on .NET and Oracle on Java.
If you look at Flow Router for instance, this is the announcement made last year:
https://kadira.io/blog/meteor/flow-router-4-0-and-future-of-routing-in-meteor
Now look at the comments in that blog post and the GitHub activity:
Clearly there won’t be a Flow Router 4.0, I highly doubt it.
- and 3. I’m not talking about NPM package wrappers. The packages I mentioned are meteor-specific, MDG-recommended, packages. Packages that you need to develop real-world applications.
The people that have developed these packages (arunoda, aldeed, etc.) seem to have basically left within a few months. Meteor does not have a strong community of developers actively participating in the development of third-party packages able to take over.
I have invested months of work in developing a meteor-based app and honestly this is extremely worrisome to me.
3 Likes
Correct me if I’m wrong, as I’m still a relative intermediate to coding, but I find Meteor to be much too “wild west” for me, as in there aren’t good patterns or best practices to follow, and the framework doesn’t enforce any best practices and such.
It’s really easy to get spaghetti code and the “data everywhere” ideal means that data does indeed come from multiple different places at times and it gets really hard to make things orderly without side effects.
Try the guide, that’s quite opinionated and actually a very good document. So knowing how to do things now is certainly not impossible or undocumented. The hard issue is predicting how much to invest in certain parts which might disappear or are already scheduled to disappear.
But if you want to work now on building a good piece of software the situation actually got better.
@fuzzybabybunny a good stack overall for me was Meteor + React (front end) + Flow Router (routing) + Simple Schema / Collection2 (data validation). 6 months ago that used to be, I think, the recommended solution (used to be Iron Router + Blaze before that).
But like @lucfranken said, it’s hard to predict what to choose from. It’s changing again with Apollo and whatever is coming next. The real issue for Meteor is that the whole React stack is getting extremely interesting and backed by FB with a vibrant community (React / React Native / GraphQL / Relay etc.). I feel people who used to work with Meteor (for instance Kadira) are moving towards that direction.
What place does that leave for Meteor? I don’t know. When Meteor came out I thought that was absolutely revolutionary.But if you look at their showcase apps (https://www.meteor.com/showcase) you’ll see there’s no one major on there. The best they have is Mazda Netherlands for a small portion of their website. It’s harsh to say but that does not give a lot of confidence either.
1 Like
I kinda like Meteor.
4 Likes
Here is what we do now. If we find a particular package has something missing for us, we clone it and make minor changes as needed. These changes are rarely major enough to warrant a public fork. The inner workings of Meteor have not changed that much. This happened twice, with Cluster (which we dropped as we are doing things right with proper load balancing), and the yogiben admin package.
That being said, we are lucky to have already started with meteor, so we are slowly updating things as Meteor progresses. Eventually our code will look so much different from the original package.
In fact, we are dropping packages and slowly doing things ourselves (we use Semantic UI, so so much of the UI is easily handled there). For instance, we have moved away from @aldeed autoform.
I’m trying to do the same, what did you guys do in terms of reactive-client-side-form-validation? All my show/hide controls and validation (“require”) is in SimpleSchema that’s tied into Autoform.
lol these were my exact thoughts. had to put so much time in to researching each of these pieces.
Meteor can’t win! You got one group of people arguing that Meteor is changing too fast, and other people are here arguing that things aren’t changing fast enough!
@taken don’t you think that maybe these packages are good enough to be productive with? I produced a large, complex Meteor app, which has been in production for a year, and it was built with Iron-router. As you know that package has been abandoned 9 months ago, but we have a mission-critical production app, used by thousands, which generates hundreds of thousands in revenue, an dit run on uses iron-router. If you can get something working maybe that’s all that really matters, right?
We put our first app in production at Meteor v0.6. Back then many packages were in their infancy–or weren’t invented yet. You just worked with what you had, made your own packages when needed, and did whatever it took to get things working. We put about 6-7 weeks of work into an app which served us very well in production for over a year. I consider that a great successful.
Also maybe some of those packages you mention aren’t being maintained because they are no longer as important as you think. We’d do a new Blaze app with Flow Router, but we’re actually building our latest app in React and react-router–not iron-router or Flow router.
As for “meteor-spin”? Seriously? That’s like a dozen lines of code. If you’re expecting the community to solve every problem you have with a package, I don’t think you’re doing your job as a programmer.
Why? Can you give us a few examples of packages you used to implement features in your app which you feel need to be continually updated for your features to continue working?
6 Likes
Apollo seems to duplicate other frameworks that already are production-ready (e.g., FeathersJS). Feathers’ server-side framework allows you to rapidly build REST or Websocket interfaces via a’service’ abstraction that sits on top of support for many ORM’s (and therefore, many more actual database implementations). Also, you don’t have to use GraphQL, which doesn’t appeal to everyone.
Here’s what querying with their client-side package looks like:
const app = feathers()
.configure(rest(__API__) // could be websockets too
.superagent(superagent));
// a service is an interface for essentially
// accessing a table in a database, with
// CRUD (create, read, update, delete) operations
const messages = app.service('messages');
// find all of my messages
messages
.find({query: {userId: 'myUserId'}})
.then(function (data) {
// persist data to your store (redux, etc).
})
.catch(function (error) {
// not authenticated, no internet connection, etc.
});
If you’re already investing in webpack and react and redux, meteor’s value proposition (for the developer) has to come in the form of simplifying the server-side piece (easily building REST and websocket interfaces) and having accompanying client-side libraries that make it easy to consume those interfaces. I could be wrong, but it looks like feathers and apollo are an apples-to-apples comparison in that regard.
I guess it’s a little less clear to see what Meteor’s role is in hosting, it’s primary revenue stream. Meteor can’t be a walled garden, since that’d appeal to too few developers. People want to build vanilla nodeJS apps, so the recent direction with projects like Apollo makes total sense. But frameworks that essentially do what Apollo does already exist. At that point, Meteor is just scaling vanilla node processes (and there are many PaaS providers out there doing that). However, they would be notably differentiated from other PaaS providers in that they’re also building frameworks that facilitate the development process. But does that have any relevance to the revenue model when compared to other hosting providers? I don’t know.
2 Likes