I've had great success with Meteor. I started with v1.2, and it was quite painful to develop in. However, with improvements start within 1.3 and onward, every release has gotten better. Meteor 1.6 has the same concepts as Meteor 1.0, however it is extremely different and is up to date with standards of the Node/JS ecosystem.
I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box.
In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues.
I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer.
You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time.
My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.
Chanj FLOW is a mobile app designed to solve liquor inventory for bars and nightclubs. Frustrated with the existing liquor inventory systems for nightlife venues, we sought to create a new solution that was simpler, more efficient, and affordable. The app is available for download on the iTunes App Store. In this post, I'll talk about the technical decisions we made while developing the app, why we chose to build it with Meteor and React, and how Meteor's 1.4's recent updates have delivered even more value.
Just posted another blog about gettting started with Keen.io. I didn't really find any good basic writeups from anyone online, so just wanted to give a brief overview of the Keen service and event data. Hope it's useful!
https://www.airpair.com/keen-io/posts/getting-started-with-e...
Great guide Mark — it's important to get event data right, or else it really limits the analysis you can do. I'm always so sad when I discover bad data.
Just wrote a blog post about making Keen.io analytics real-time by integrating it with Firebase as a sort of proxy. Keen.io is awesome, but lacks the instant feedback that I was looking for -- this seemed to be a pretty good result.
Hope this helps out some others looking for something similar!
Mark
I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box.
In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues.
I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer.
You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time.
My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.