Greqt article and quite complete I should add 
. It’s clear that you did put a lot of work in it. Though I agree with @peterfkruger and @dr.dimitru that the title is negative. Perhaps something along the lines of “Meteor is the platform your startup needs… Or maybe not”, to follow the advice by @pmogollon
3 Likes
“Could Meteor actually be the platform your startup needs?”
4 Likes
Okay, too many choices for me, I already feel the pressure
Please do a quick vote:
Proper article title
- Is Meteor really to win a popularity contest?
- Should you start using Meteor?
- Why to choose Meteor (or not) for our next project?
- Meteor is the platform your startup needs… Or maybe not
- Could Meteor actually be the platform your startup needs?
0 voters
6 Likes
GraphQL isn’t a one size fit solution for everyone. If you don’t need to combine data from multiple source systems (eg MySQL, MongoDb and Neo4j) then it’s absolutely not needed and just adds unnecessary complexity.
But this is going OT
2 Likes
I finalized the artcle and will publish i this evening, unless there are major concerns:
3 Likes
Just one last thing Jan. We can’t say ‘Why to’ (or maybe we can. I’m no english teacher but it sounds odd )
I’d drop the ‘to’ and leave 'Why choose… ’
Which reads a lot better.
4 Likes
Thank you @marklynch I changed it. Only found some stack exchange topic: https://english.stackexchange.com/questions/210762/why-to-choose-or-why-choose
3 Likes
And it’s released: https://dev.to/jankapunkt/why-choose-meteor-or-not-for-your-next-project-1gnh
Thanks to everyone for help, critics, reviews and discussion leading to this article.
8 Likes
I was reading through this thread and wanted to read your article but you re-posted it so many times every link above this one is broken.
Finally got through to it.
1 Like
that 47% “No Interested” crowd looks like a stubborn one to me
47% just happens to be the number of people who are existing State of JS participants/mailing list subscribers
I’m not saying they’re all hitting “Not interested”, but there’s possibly a strong correlation here, which then colours the whole result.
Also I question the definitions of “Expert” vs “Advanced” for a number of categories.
E.g. CSS:
“Able to style an entire front-end from scratch following a consistent methodology” - this doesn’t actually imply that you can do everything covered in “Advanced” or even “Intermediate”. It’s possible to style an entire front-end from scratch without ever adding an animation.
The same is true for the Javascript section.
Actually, the Back-end section has “from scratch” as “Advanced” and requires more skills for “Expert” - I suspect the replies here are more in keeping with the actual intention of the question.
…or maybe 50% of people who reply are genuinely JS and CSS 3-dan blackbelts. Seems unlikely though!
1 Like
Yeah, I get your point and I agree.
Anyway, I really hope both Meteor and the survey improve by next year. And that Meteor gets a more accurate description of its state and value proposition.
I enjoy Meteor, it keeps getting better, I like the community, it helped to bootstrap a business, and it is giving an edge and deliver results fast. I think that what matters at the end of the day, back to work :).
2 Likes
Agreed. Writing this while my latest build deploys 
1 Like
/offtopic
GraphQL is also great when your server needs to handle heterogeneous clients, when you don’t control when they are upgraded, since it makes backward compatibility so much easier than using REST calls.
But if you’re just building a web app, you don’t care about that.
2 Likes
I really do think Meteor 2.0 should be rebranded as Meteor NG for Next Generation or something similar.
Is this really a “Next Generation” thing? To me, it more looks like an evolutionary step.
2 Likes
Marketing versus engineering.
What/who is the marketing target?
Your question is the crux for this whole discussion. What most businesses get wrong is that not everyone is your customer. That means you have to learn to say to a customer: “sorry this product is not for you, perhaps you should try …”.
Firstly, recognize that all popular frameworks do work, meaning that they do they the job that they are intended to do. React and Angular were developed to solve the problems that Facebook and Google have. Not every company has these type of problems nor needs such heavy weight solutions. Proper architecture, componentization and disciplined code structure is more important than the technology that you choose. Too many developers focus on the shiny or are protecting their own choices.
Secondly, the “market” is saturated with frameworks, widgets and add-ons. Trying to roll your own framework / application is fraught with challenges: Open Source Challenges. The “marketing noise” is deafening sometimes. This makes it very hard to pick a way forward. And then comes the maintenance problem after your application is in production! This is something developers ignore because it’s more fun to do new things. Business managers, however, need to pay for customer support, after that fact and it’s boring and not fun.
Thirdly, beware of the “hammer” problem; meaning that if you only own a hammer then everything looks like a nail. In software, as in life, we know that one size does not fit all. Evolutionary forces always drives specialization. If you just need a marketing site, there are a number of solutions such as Next. Unfortunately, their market will be chewed up by “paint by numbers” type of website creators like Wordpress, Wix, etc. Every product needs to be positioned properly to meet the needs of the end customer. Focusing on silly things like GitHub stars, marginal performance differences, popular technology is not a great sales pitch. Showing how a customer is better off adopting your solution gets more sales. Real business oriented customers don’t care about what technology is under the covers as long as it produces the required business outcome and it gets supported.
If we shift out focus to the business side, we need to consider the real cost not only for development, but also the bigger cost of maintenance. New and shiny is simply not relevant here, but rather consistency, ease of use, good support, stability , etc, etc.
If we look at the state of Meteor today, I submit that Meteor meets the needs of business minded developers. It has had a decade of being in-market, being stress tested and improved to solve real worthwhile problems. The Meteor stack is actually very small, meaning that training a javascript back-end developer is almost trivial. The front-end will always need a developer that understands some other product such as Blaze, Vue, Svelte, React or whatever anyway! Just add a bit of Meteor front end spice to complete the project and that is also easy to learn. Hence the Meteor adoption barrier is really low for javascript folks and should not be an issue.
Meteor may not be the best solution for simple marketing sites, but then neither is any other framework: use Wordpress. On the other hand, if you are building an application (enterprise or SaaS) that has complex business logic, needs some real-time data transfer and client side reactivity, then Meteor shines.
Alternatively, you can cobble together an Express server, add database connectors, build your own websocket connectors, authentication, web pack configuration … and eventually you end with something almost as good as Meteor, but you have to maintain it yourself. But why bother re-inventing the wheel. Just get on with delivering a solution to your customers and get paid for a good outcome.
My two cents.
28 Likes
This post should be pinned on top of all these type of discussions
1 Like
Rather than removing it, you should consider revising the answer from a simple “Have already used” to a more insightful “have used <6 months ago” or “have used in the last year”.
Everything in Javascript evolves so rapidly that a feedback from anyone who have used Meteor for more than 2 or more years ago will not represent its actual state.
2 Likes