Just some quick background on my experience level and where this question is coming from. Earlier this year, I started working (as an intern) for a large tech company. Since starting to work I have started to learn that at a large company there is a lot of value in using “what the company” uses when building new products. This makes total sense as it helps new people join. In a startup situation I know that there is much more freedom.
So… onto my question. With all the JS web stacks out there, among non-JS frameworks, when is Meteor “the right choice”? I have heard a lot about choosing the right tech for the right problem. I love Meteor, where it’s going and it has a very bright future.
The next part of this is, when is Meteor “the wrong choice”? I.E. when should I use NodeJS/Express, Rails, Django, or otherwise.
I have some other follow up questions that I would be happy to pose if this post actually gains some traction.
1 Like
Meteor is a great choice for lots and lots of use cases. Most web apps would benefit from Meteor’s ease of development and reactivity and integrated platform.
Meteor can be a really bad choice if you’re doing something highly specialized, like with data that is not a good match at all for MongoDB.
But it’s really hard to answer your question in a meaningful way without getting any more specifics from you about what you’re thinking, what perspective you’re considering this from.
Also, there’s a lot of people talking a lot about “the right language/framework/stack” and a lot of that is just not very productive, from my perspective. Lots of discussion without much actual meat to it, without actually intending to find the best possible match for a very specific thing that is to be accomplished. And I’m not very interested in that.
I’d rather talk about real use cases and come up with potential solutions, finding the right tools and the right place for each tool, and how to connect all of them. I think that’s what our Open Source ecosystem allows us to do. Draw from the strenghts of each individual tool, and have them integrate and interoperate seamlessly and productively, solving problems we could not have (realistically) solved previously.
Look at the use case. Look at the biggest challenges it has, the biggest potential opportunities it has. Look at the tools and technologies that stand out in terms of their strenghts in those areas. Look at where and how Meteor fits in. What are its strenghts? That question is much easier to answer, and it’s a productive thing to do, too.
HTH, and post more specific thoughts if you like.
1 Like
The short answer: It changes all the time!
Meteor will always be a great solution for apps that want to capitalize on all the real-time, single page app goodness.
But as @seeekr mentioned, there’s a large, robust open source community around Meteor and Javascript, so you can discover more use cases every day!
Here’s an example where Python might be better: Big Data.
Python has many libraries built on top of scipy that work super well for crunching the numbers required in a machine learning application.
But the great news is you can create a python server application that communicates with a rest api to a mongodb database and a Meteor front end.
We have the technology. I am in favor of the “microservices” model for this very reason.
If you’re interested in using Meteor as a front-end framework, check out https://github.com/frozeman/MeteorFrontend.
Good luck and feel free to elaborate!
To answer this I think it also helps to view when Meteor is not the best solution as well.
Meteor is a great choice if you need:
- Latency compensation (this is really hard to do well from scratch)
- Real time data updates (also really hard to do from scratch)
- Clientside cache (especially a write-through cache)
- You want to write JS on the server
- You want to share code with the client/server
- Easy/quick build tools setup (as opposed to Grunt/Gulp)
Meteor is not a great choice if you need:
- Hundreds/thousands of ‘pages’, any request/response methodology works better than a SPA.
- Fairly static pages (not the most efficient use of resources)
- You need SQL support today
- You don’t want to write JavaScript on the client
- You’re integrating into a legacy system (Rails, Django have the same issue, roll in React, Angular, etc… into your current system instead)
Everything else is basically icing on the cake IMHO.
4 Likes