I have been using meteor classic for a long time. I am starting new projects these days. Since I haven’t used neither Apollo nor React with Meteor yet. I am wondering if you have any recommendation on something that works and is considered a safe choice these days… What is the most common, most supported stack currently?
In short, I want to go with the flow where everyone is heading, I don’t have time to hit into silly obscure issues.
Any recommendations are appreciated.
PS: This is not a question for what is the best technology combination… I am not looking for useless war in the comments… I just want advice about the thing that you use frequently and works for you.
I have two related applications one is Meteor/Mongo/Blaze the other is Meteor/Apollo/Vue and Im digging it.
The first app has been development for a couple years running an older version of Meteor with the classic setup.
But when tasked with building a second application, it was time to pull the trigger and try some new technology, while still staying within talking distance of the old stuff.
I went with Apollo for a variety of reasons. First off Apollo is developed by Meteor Dev Group, so as a Meteor dev, it felt right to stick with the home team. I used the standard Meteor Integration. Apollo is quite flexible and I’ve found it very easy to learn as I go for the most part. It’s not as opinionated as other graphql clients like Relay. Once I discovered patterns I liked, the rest has become mostly trivial when setting up new graphql queries/types/etc. I’ve enjoyed being able to add SQL resolvers with ease. I find the apollo syntax/structure as a benefit to the overall organization of my app’s data layers. It’s really opened up some new pathways in my overall app design without causing issues for my legacy code. I’ve written all of my Apollo server code in a Meteor package and share apollo data with both of my apps without any trouble. I haven’t encountered a massive roadblock or anything obscure issues yet, and I’ve got Apollo working fine in production (both web/iOS). Apollo also integrates with a handy REPL called graphiql
I chose to go with Vue because I’m not really enhancing my skills by further mastering blaze at this point, Angular brings up bad memories from a previous job, and I personally don’t enjoy React. Vue has some quirks and what not, but it’s pretty darn simple to use, and I value that simplicity. I feel like most of the popular frontend frameworks will do, it’s much more up to you, but if you haven’t played around with Vue – I say give it a try. Vue has integrations with Meteor/Apollo which I’ve found to work great without issue.
Best luck to you. Feel free to message me if you have any specific questions.
I don’t know which stack is most common, I guess Apollo/React is quite trendy atm.
We use Meteor with good old DDP as a backend and Angular 5 on the frontend (wiring it up with Uri’s Meteor-Client-Bundler).
Angular indeed has a steep lerning curve and the Angular team’s focus on quick new versions instead of bringing in more robustness is an issue and I understand why many people have turned away from it recently. But is still like it’s patterns/structure for our use case (which is a “heavy” business application) and I really love the close integration with RxJs, which is a real pleasure to work with in combination with reactive data.
And if you want to make apps that run like native app then use nativescript-Vue then the knowledge you get with metoer,Vue you can use with nativescript-Vue (mayby soon some Vuetify reuse to the native apps)
With NativeScript Sidekick you can build Android,Ios and (Windows UWP) apps on all platforms (Windows, osx and Linux)
Jelly Beans using Peppermints on the client and Gumdrop for handling SSR on the server. Works well
Kidding. Been happy with React and Meteor pub/sub (and when appropriate GraphQL/Apollo). You may find our boilerplate over at Clever Beagle helpful: https://cleverbeagle.com/pup.
Curious to hear what quirks you’ve encountered with Vue. Are they issues with Vue or issues with integrating Meteor with Vue? We are using Vue and adore it, but since both Meteor and Vue are opinionated about data and reactivity different ways, I don’t imagine they’d play well together.
I work with Meteor + Angular 5, besides Meteor + React.
Yes, React has somewhat of an early steep learning curve, but a week or so with JSX will be enough.
I, however, recommend Meteor + Angular 2+ as it’s a more mature integration, they work wonderfully, but I’m not sure about Vue, I don’t think there’s a wrong choice here
This is the package I used to integrate Vue with Meteor vue-meteor. This will give you access to the Meteor context within your vue components. Here is a helpful guide on the integration with some code snippets that may help you out – vue-integration-for-meteor
The author of the package Akryum a core dev for Vuejs who has done some really great work imo.
He is also the author of vue-apollo which you can use to plug apollo/graphql data directly into your vue components.
They both have a very similar syntax that fits more or less seamlessly into the existing structure you’d expect to find in a vue component. So there’s very little new syntax you need to learn if you are already up to speed with vue.
You will never get an answer to your question here. This will only result in people saying what they are doing, and those are not statistically correct answers for “the most common stack these days”.
You could run a survey and ask a representative population (1000s of devs?) from which you can draw scientific conclusions in order to be absolute sure you are picking the stack that’s “the most common these days”. While you’re at it, swing some AI / big data analysis in the mix to be absolutely sure you are going with the flow. Once you’ve drawn your conclusions I’m sure you will get tons of positive and negative publicity.
Alternatively, you could have kept working with Meteor classic and get your project launched to 100K MRR within a year
Faster would be to analyze actual projects that have been developed (or continue to be maintained) withing the last year. That would be more accurate approach than to ask developers who might be biased or responsible for part of the stack or actually work with certain stack while they would like to play with something else.
