Hi everyone,
In the wake of server issue I experienced recently, I had an opportunity to rewrite my Meteor application using Express + React + Redux. I would like to share the experience with the community. I wrote and article focusing particularly on why and how I rewrote the app.
Here is the article:
http://stories.remotebase.io/post/rewriting-without-meteor/
For what itās worth: Apollo is going to bring all the advantages you mention in the article to Meteor, and it lets you keep most of the things that are great about Meteor. Might be worth giving it a try!
What is the status of reactivity with Apollo by the way? Afaik that part is opt in, but when will we be able to get it? My team is planning to move over to GraphQL in the next few weeks. Weāre looking for the right time to build a Polymer implementation of GraphQL.
Apollo Will have auth built in?
I completely understood the reason for your shift and itās completely legit.
Hope Mantra helped you to do the switch and minimize the UI re-write.
Personally, I believe we will start seeing more of this. Meteor is great to launch quickly, and if built right (@sungwoncho mentioned a few mistakes he fixed) it can (probably) scale well.
But as the advantages of using a fullstack are getting eroded (express.js and its many frameworks are really solid now + Angular still around = very easy to build AJAX apps, many UI frameworks including React and Handlebars), and as NPM packages start to replace Meteor-only, the only reasons left to use Meteor are (1) reactivity, (2) speed of deployment, (3) mobile
Big companies donāt care about #2 (speed) as they can throw resources in ā smaller companies liked Blaze for that purpose but thatās being dropped. Reactivity (#1) is being replaced by unidirectional binding in many frameworks (React, Ember) even though itās really cool (probably relates to #2). Mobile (#3) is now super easy with Cordova / React Native.
Nothing left.
I also donāt see how Apollo is going to save the day. If you are using MySQL (or any other DB type), you will find a way to push data down from your DB (GraphQL isnāt that cool if you have a single data source). Startups anecdotally like MongoDB which is already supported.
Not sure what the path forward holds. Then comes monetization, can you really make money on hosting?
PS: As I checkin to this forum every once in a while, I notice that there arenāt as many posts as before. Am I the only one noticing this? Or maybe I should say, there arenāt as many INTERESTING posts as before.
Nah, Iāll just stay with Meteor! Thanks for sharing though!
@fcaldas I should mention I am not leaving Meteor; I will use it for my other projects.
There is no āleavingā or āstayingā when it comes to technologies because they are just tools. We simply use them as we see fit.
Iām curious though, given your problems with remotebase, would you build something similar with meteor again, now trying to not make those mistakes or would you rather only use meteor for very specific apps?
For your pubs still being reactive, could you not have just changed it to a Meteor.call(...) to get the data instead? A Meteor method is pretty similar to a REST API isnāt it? As in, you only get data when you ask for it. I just wanted to understand your reasoning more. Thanks for the insightful write up!
Agreed, Iām also curious. Weāve written our MVP with Meteor but we are considering to use something else for the backend/database. I am also afraid we might run into performance issues, especially because we donāt have a really good backend person on our team so Iām sure our backend will have flaws 
.
All the issues that you had with Meteor could have easily been solved in a day.
For example, if you know Meteor you know you need Oplog tailing, Mup(x) has tons and tons of issues (ever heard of Galaxy??), and Meteor needs CPU power, not ram and it canāt make use of multiple cores without squeezing yourself in (impossible) angles. Itās also very easy to query mongo without reactive overhead.
Donāt take it personal, but it sounds like you made beginners mistakes that you blame on the framework, and then you decided to ditch the framework (and even blame Meteorās performance for not setting up database indexes!!) and do a rewrite. Instead you should have spend a day on learning Meteor and optimising your app.
So I donāt think the āwhyā argument in your post is very valid. But itās positive to see that you are at least aware of your own mistakes.
Meteor scales fine. But scaling is always an art. And it definitely helps if you understand the framework better.
Those are very significant reasons. Indeed the reason why A16Z sunk millions into Meteor was because they were impressed with how quickly Geoff used it to create the travel app he was pitching (A16Z didnāt want to fund the travel app, but they were interested in the framework, which became Meteor).
I think you discount the importance of these things too much. The idea that you can just āthrow resourcesā at projects to make them go faster was debunked in the 1970s.
Meteor+Polymer+GraphQL?
Wow, sounds cool!
I canāt wait to see it workingā¦
Thanks for your comment. I am not discounting these reasons, they are the same reasons we jumped on board. However, they are not as differentiating anymore as when Meteor started.
For instance, Sails does a superb job too and we donāt have to worry about Meteor-specific issues (like UI issues, profitability of MDG, shift of focus to Apollo etc.). Sails is an open source platform supported by a services company, so the flow of investment is less risky then trying to build a hosting business sponsored by VCs.
Another advantage of using Sails (just an example) is that they already solved the DB problem that Apollo is trying to solve AND they use mature packages (express, socket.io) ā so if they go bust, you are dependent on mature packages that are deep in the NodeJS ecosystem.
Also, I agree that you canāt throw resources to make a project go (a lot) faster. If you are using the React ecosystem, itās partly because you need to work in teams (i.e. resources). With Meteor (using Blaze as was originally designed) you need a much smaller team. This was touted as an advantage, but is not so when you have budget dollars.
I feel like the ability to move quickly was eroded around 1.3ā¦
Blaze + meteor 1.2 imo is the greatest mix everā¦ now it feels like meteor is so much like the vanilla JS ecosystem that I may as well just use the vanilla ecosystemā¦ reactivity isnāt needed most of the time (there can only be so many live chat apps, and if you need live chat, you may as leverage a slack API).
I tried to start a react+meteor app, and found it was easier to just use vanilla react+alt+webpack. You donāt have to make bets on using an atmosphere package vs npm package, and you donāt have to spend time trying to figure out the meteor way to use react, or how to integrate react router or how to do redux/flux the meteor way.
Webpack really wasnāt as hard to grasp as I thought it would be (from all the negative press on it)ā¦ and once you know it, you essentially just take other peopleās boilerplates (or use your own) and the ā2 hours of setupā is actually 10 minutes.
The only thing I miss is the account system and being able to do stuff like Meteor.userId() etc.
If Apollo can do (a) reactivity (b) accounts and Ā© connect to any database in a way that is simple to understand like meteor1.2/accounts/mongo/simpleschema/mini-mongo was-- then I would use apollo + webpack + react ALL DAY.
My other gripe is that unless youāre self employed and can use any tech you want, then you really need to learn vanilla node/js/react to get employment. There are just so few meteor jobs around that competition is beyond stiff.
I think you said it well, once Blaze was out of the picture, the real value of Meteor as a cool and quick platform to develop in got eroded. We donāt need Meteor for React, seems more like a bolt on. React and Angular are pretty complete ecosystems in themselves.
Have you checked out Sails? It has (I believe) what you are looking for when it comes to data (played with it a bit and looked at the intros). In fact, the intros are focused on real-time data.
Iām reminded of what happened with Visual Basic years ago. It was a really easy way for a lot of people to get started in programming. But once VB became VB.NET and fully an OOP language, it became a lot more sophisticated and professional but also a lot harder for amateurs and hobbyists.
It may seem like a loss, but itās also a gain. Meteor is evolving for compelling reasons. There will always be easy alternatives for amateurs. Not every movie needs to be suitable for children.
We donāt need Meteor for React, seems more like a bolt on. React and Angular are pretty complete ecosystems in themselves.
Angular developers were attracted to Meteor because of itās data flow (Pub/Sub, Tracker, ReactiveDict, etc.) Ask anyone doing Meteor dev with Angular why they donāt just use Angular without Meteor.
As someone who has produced several Meteor apps with Blaze, weāve moved to Meteor + React and are finding we can move more productively with better code quality than ever before.
Youāre talking about Meteor not being able to monetize. AHAHAHAHAHA!!!
Hereās what Meteor gets, that you donāt:
And all of these are, again, just marketing stunts for their real cash cows:
And Iām not even talking about their community efforts, MeetUps, forums, StackOverflow, and Github presence as marketing efforts.
Theyāre absolutely fucking genius.
So is monetization possible? You bet your ass it is.
Just a heads up: MongoDB is on the same business model; Iām pretty sure it works.