If you were to stop using Meteor, what would you use instead?


#42

It seems to me that if you’ve a really large and complex client with a lot of things changing, many dependencies and multiple people collaborating on the code base, then I think it’s useful to be very explicit, transparent and develop a centralized and global source of truth on how each action changes the entire state of the client app.

For medium and smaller size apps, where one or two developers working on the front-end code and state changes are not that complex to grasp and maintain in the developers memory, then something like Redux might be an overkill. Furthermore Meteor does have mini-mongo and reactive data sources but it leaves it up to the developer to decide where and how this data will change. If the app grows in size and the developer continues modifying global reactive session variables all over the code, then you might end up with unexpected states, bugs that are hard to trace, and unmaintainable code.

But yeah I don’t like it when people blindly follow the latest trend and adopt the next shiny toy out there without careful evaluation of what does it really provide and whether it’s the right tool for the job in hand.


#43

At https://jssolutionsdev.com/ we started use Express and Reactjs, for mobile app development we use ReactNative. Cordova works really slow.

We also investigate option to work with GraphQL and Apollo as long term opportunity.

But we still use Meteor and React to build new web apps. It depends on circumstances.


#44

i totally love mobx. its brilliant. with redux i admit i don’t understand the use case or how to use it properly.

the point is, from my experience with redux was very negative. thats all i’m saying. its my exp with it, not suggesting that is the grand global truth, or the most complete analysis ever. my exp with it was lousy, hence i think its a piece of turd.

vast amount of boilerplate, for a set of circumstances it is highly unlikely i will ever face. i admit i don’t have experience with such large scale projects where redux would add value, and if/when that changes, i’ll rethink the opinion.

its just an opinion - no reason to take it any more seriously than that. i respect your opinion on it, just i have a different one given my experiences to date.


#45

I recently investigated the current state of few Meteor alternatives, so I wanted to share few thoughts.

SocketCluster + Mongo or Rethinkdb. This is what Meatier project was based on. More of a low level solution based on uWebSockets in comparison to bigger frameworks, but provides very nice scaling and close to no bloat. It’s got a commercial solution in the beta stage that takes care of the cluster management, but you can do it by yourself too. Pay attention that it’s a one man project, while all the others are backed by a company.

I consider using Mongo instead of Rethinkdb because of better server tooling, in this case the reactivity would be achieved by emiting websocket events from the function that tweaks the database state.

Sails + Mongo. Out of the box it has a pub/sub system based on events, too bad it only works with Blueprints (REST generator). There’s no option to use Rethinkdb. Sails has a new big version in alpha stage, but there are no docs for it.

Feathers + Mongo or Rethinkdb. Like Sails, it’s got a new big version in alpha stage. They’re working on it since april of 2016 though and STILL didn’t finish and that tells a lot about the framework in my opinion. At least it’s partially documented. Feathers by design don’t allow non-REST endpoints at all.

Horizon + Rethinkdb. Like Meteor, it makes you stuck to one database. Unlike Meteor, it doesn’t really work well. There’s not even an option to make a password authentication. Currently, Horizon development is pretty dead. They had a small meeting of people interested in further development few days ago though. It’s now under Linux Foundation like Rethinkdb but no idea what will happen to it.

Deepstream + Mongo or Rethinkdb. Deepstream is based on this weird idea that what we write as a server code in Meteor, should actually be just another client. Maybe it works for some people, but… man, come on.

Deepstream recently has a commercial platform DeepstreamHub which is a kind of Firebase alternative. You pay for the number of emitted messages, so be sure to divide the number at least 4 times if you want to provide any kind of data validation.

My personal gradation:
Recommended: Meteor and SocketCluster
A valid choice: Sails and Feathers
Not recommended: Horizon and Deepstream


Node.js framework shoot-out (Meteor alternative)
#46

Also useful for complex ui state mgmt like games. See Redux-saga.


#47

Other reasons you might want to use Redux

Persist state to a local storage and then boot up from it, out of the box.

Pre-fill state on the server, send it to the client in HTML, and boot up from it, out of the box.

Serialize user actions and attach them, together with a state snapshot, to automated bug reports, so that the product developers can replay them to reproduce the errors.

Pass action objects over the network to implement collaborative environments without dramatic changes to how the code is written.

Maintain an undo history or implement optimistic mutations without dramatic changes to how the code is written.

Travel between the state history in development, and re-evaluate the current state from the action history when the code changes, a la TDD.

Provide full inspection and control capabilities to the development tooling so that product developers can build custom tools for their apps.

Provide alternative UIs while reusing most of the business logic.


#49

Few more words about Rethinkdb as the alternative for Mongo. Yes, changefeeds are awesome. Yes, joins are awesome. Yes, ReQL is awesome. But it all fades away when there is close to no ecosystem around the database. Whenever you want to do something that is not in the core, you’re left alone to write it by yourself and even the only ODM is not maintained anymore. For Mongo, when you need something, you just google it and bang, there it is, available as an npm package.


#50

Thanks. It seems very simple and stable combination. Yes, basic ME stack does a lot.


#51

Now I’m using morphine just reading these stacks and combinations.


#52

I took a look at Google’s firebase about a year ago. Back then I would have already started using it but then there was one thing still missing – a NoSQL database. Now, with its Firestore database (and several other product additions since then) I’m going to try it with one new project…

https://www.youtube.com/watch?v=KeIx-mArUck


#53

If I had to stop using Meteor for some reason I would go for Hoodie and learn about offline-first approach: http://hood.ie/

I think Meteor has already made some steps in offline first, though it would be nice to see more support for it.


#54

Thanks for pointing me to Hoodie. Looks quite interesting. And I agree, better offline support would be cool in Meteor, especially for mobile apps (Cordova) and Electron. I can’t count the number of questions on this forum asking about how to upload and store simple stuff like images server-side.


#55

How do you know its Meteor which is the bottleneck ? What exactly in profiling shows up ?


#56

After a lot of research, trial and error, and load testing (https://forums.meteor.com/t/solved-poor-galaxy-meteor-performance-serving-small-bursts-of-users-load-test/38671?u=evolross, https://forums.meteor.com/t/mongo-scaling-issues/27905?u=evolross) it looks like the bottlenecks are mostly Mongo related and most definitely my app needing more optimization for how it works with Mongo and the amount of queries it performs per user action (I had lots of collection hooks firing.) You’ll hit Mongo bottlenecks when you have 25,000 users all trying to insert a document at the exact same time. And that document needs to do about five different validation queries before insertion. And then multiple other “resulting effects” queries after insertion.

But I’ve went through a lot of fire testing pubSub, Meteor Methods, oplog, and redis-oplog. I’ve pretty much went full-circle. redis-oplog is performing better than oplog-tailing and looks very promising but my app had a few bugs when I added it and I’m working with redis-oplogon getting them fixed.