| We spent a fair amount of time going back and forth over whether to use Meteor or not for our in-house development (in late 2017), before we bit the bullet and moved ahead with Meteor. Finding people is the hard part for us as a business, so finding a balance between technology and available skills was a priority. Since Meteor is a public framework, it has a ready ecosystem for onboarding (tutorials, etc), plus with being standardized it reduces complexity for onboarding. Any JS dev can pick it up in a few weeks. It has enough checks and balances to ensure some level of consistency in implementation, but beyond that, you need to setup your own process anyway. Again being standardized, it helps with BCP as well. Since Meteor is isomorphic, it gives us a very interesting advantage of tying code ownership to both front and backend code, which results in functional ownership not just code ownership. That emphasizes full-stack development, which is a priority for us. Our mantra is to do more with few people as we can, and Meteor lets us do that very well. Technologically, Meteor gives us access to a wide variety of capabilities as a technology team. NPM opens up the JS ecosystem, Apollo/MDG gives us the ability to move towards GraphQL if needed, build tools allows us to push code for web and mobile environments out-of-the-box, integrations allow us to handle scaling, and Meteor has gotten better at opening up options to allow for more granular tuning (queries, reactivity, etc.). It might not be the most performant, but honestly I'd rather throw an extra $50-100/m at hardware on DO/Linode, than justify having to hire more people. It helps that we're not planning at building apps targeted at millions of users, but when you hit that kind of scale, refactoring is anyway going to happen. This quote from DHH (https://twitter.com/dhh/status/885445986943868929) is the best way to explain this anyway :) As has been highlighted by others, MDG is still releasing updates to Meteor regularly, so there's not much reason to doubt they're stopping anytime soon. In addition, there's been a resurgence in the community to contribute modules to addressing gaps in the ecosystem, which have made Meteor more relevant again for a lot of us. This is highly opinionated, but for us and the fact that its about doing business, not just the best technology, Meteor ticks enough boxes to make it our choice moving forward. If you look at it through that lens, I think it makes it viable (valuable even) in 2018. IMO, I think Meteor is a victim of promising too much too soon. The real value only got unlocked IMO when they made NPM a first-class citizen. As a team, we aren't really missing out on anything being on Meteor. We think it makes us more effective as developers. |
This for us is also the main selling point, it allowed us to group client, server, routing, assets, static files all in one package thus enabling architects to split web apps and by extensions teams vertically instead of the typical horizontal split (client/server) thus full functional ownership instead of code ownership.
This architecture pattern is discussed here: https://micro-frontends.org/ and enabled (I believe uniquely by Meteor's build system).