Like many Meteor packages this one have maintenance problems. The solution is to keep core needs like this maintained directly by Meteor and add it to the core packages.
2 Likes
Great, to secure the continuation of this very special full stack.
Looking forward, my biggest wish would be: Make a careful analysis which features are fundamental to a solid fullstack framework. And then build well maintained core packages for these, instead of relying on the community to do so.
Some samples that immediately come to my mind:
- i18n
- styling
- support for REST and GraphQL
- mobile integration
- accounts (incl. reliable UIs and social networks)
You may have other priorities than me, but it’s important to know what the core stands for and which features you can rely on in the future.
6 Likes
A lot of folks care about Meteor and use it in a variety of ways so naturally the request list is diverse and large.
But I think a lot of us would be happy with the minimum assurance of the longevity and maintance of the core platform/packages. Many of us are happily using Meteor today but the lack of communication from the MDG leadership team and their unclear commitment to Meteor (and now we know why) has been a constant source of FUD in the community.
So little community engagement and leadership will do wonders I think.
11 Likes
@sacha Wrote an article in response to this: https://medium.com/@sachagreif/an-open-letter-to-the-new-owners-of-meteor-353d64780b20
7 Likes
Sacha could not be more wrong. He is publishing FUD at the worst possible time.
The Meteor classic stack has been the foundation of my business’s success. This means Blaze. This means DDP. This means Iron Router and even though we use MySQL instead of MongoDB, minimongo is a key enabling software component.
To me, it is Apollo and GraphQL that are solutions looking for a problem.
As I’ve posted previously, Meteor scalability issues are usually the result of someone not knowing how to use a feature properly or not having the engineering/computer science background to design a system to be able to manage computational complexity or scalability.
Many of my posts to this forum have been to debunk myths and share genuine tested scalability tips and best practices.
19 Likes
that is your opinion and a lot of people have a different experience with scaling and the usability of graphql and apollo.
I totally agree with @sasha and i don’t see that its FUD (this term is overused anyway). It’s a good analysis to the state and history of meteor and he is providing a clear strategy.
I don’t agree with your post that “Meteor scalability issues are usually the result of someone not knowing how to use a feature properly”. You also ditched meteor’s own data-layer for a custom solution, how should a beginner know that mongodb-oplog-tailing does not scale well without 3rd-party tools? There are solutions to most problems, but they scattered in a fragmented community and it needs a lot of evangelism to bring the community to embrace a solution. It’s also striking that the mysql-package you linked in your other post has been forked multiple times and none has an active community.
If you have solutions, i would try that meteor and the community understand and embrace them. Make Pull requests on meteor, advertise packages and get maintainers on your packages.
5 Likes
in terms of developing enterprise apps, dashboards, admin apps, there is nothing to replace the meteor
Next? It good for websites only
2 Likes
I also totally agree with you and with @sacha . I don’t think the “FUD” is unjustified in most cases and I don’t really think it’s FUD. He makes very valid points on most accounts.
3 Likes
I don’t think his premise is valid. He is saying Meteor has to move either direction (ddp or graphql) or it will decline and those are mutually exclusive. I think a third option is to focus on core and empower the community to manage the rest. Those are stacks that serve different needs. That hard earned flexibility (3 plus years of coding by Ben) has some drawbacks but it should be embraced as a major strength not a weakness. All the other frameworks will decline when their view layers lose their hype so stepping back and focusing on solid flexible foundation is a sensible long-term strategy.
6 Likes
IMHO, Meteor is the best prototyping solution and also the best “get-shit-done-quickly” framework for startups. This is also the reason why I chose it for my most recent startup, although I pretty well knew it’s in decline (somehow) - but after all: There was just nothing like it out there.
I personally think, Meteor could shine and grow again if it came back to this vision, instead of chasing the enterprise market. I have a strong enterprise background, and my gut-feeling is it won’t ever succeed in this world.
But why should it, if it’s so strong in other use-cases?!
You might argue the biggest challenge is to find a sustainable business model for this. But hey, as @sacha already pointed out in his blog post: WordPress managed to do this, too.
Meteor could become the go-to solution for any entrepreneur who needs “real” business logic that goes beyond a simple solution like WordPress. And then give them a quick and simple hosting solution, just like Heroku, for an affordable price (instead of pricing on enterprise levels, like Galaxy). The average deal size might be lower, but it’s a pretty interesting, scalable market.
4 Likes
Meteor is an incredible platform, and I’m excited for this announcement and what’s next. Thanks to the team at Tiny for believing in what this platform is capable of doing, especially for developers who work with startups and entrepreneurs!
4 Likes
Just to clarify a point I made in my post: the problem with that “Meteor 1.0” stack is not the technologies in themselves – I’ll be the first to say that many of the things I’ve done with Meteor would just not have been possible with another stack. Minimongo is a great experience, far simpler and easier to learn than Apollo/GraphQL.
The issue is that these technologies are not being used anywhere else, and even MDG themselves are not using them internally anymore.
So the goal should not be to hold on for dear life and keep these technologies on life support indefinitely; instead it should be to recreate the awesome developer experience of “classic” Meteor but this time with well-established technologies like React and Apollo.
I mean can anybody seriously argue that if MDG was starting the whole Meteor project today, they would still decide to develop their own view layer instead of simply picking React or Vue?
Not to stretch the political metaphor too far, but I feel like the “conservative” wing of the community is so afraid to lose what they have now that they don’t dare to dream of a better future where not only is Meteor just as easy to use as ever; but it’s also now a first-class citizen in the global JavaScript ecosystem instead of sitting behind a wall…
15 Likes
This is dead on. The value proposition should be about making these technologies as accessible as possible, which is what Meteor did initially.
9 Likes
Is this not a form of the logical fallacy appeal to popularity?
Popularity does not imply correctness or quality.
Popularity is more a function of marketing, PR and evangelism and I don’t think MDG will ever share a pedestal with Saatchi & Saatchi.
MDG have their own business goals and they chose to shift their focus to Apollo/GraphQL.
The only thing that matters is that the Meteor classic technologies are useful and value-adding to businesses, have the ability to be maintained and offer something superior to alternatives.
The bedrock technologies used to implement Meteor classic like Node.js, MongoDB and Websockets are all alive and well and are not deprecated in any way, so what is the maintenance obstacle? There isn’t one.
Why recreate when we already have an excellent existing solution that works well today?
I looked at React and Apollo when they came out and did not see how we would gain anything from switching to them. I doubt React would ever have become as popular as it has if it did not have a global corporate behemoth like Facebook pushing it. I now hear some people saying that a new framework called Svelte is going to kill React. I will keep watching from the spectator stand, eating popcorn.
Blaze was developed because it fulfilled a need that was not provided by the alternatives existing at the time. Today, people are free to use whatever view layer they want with Meteor.
We continue to use Blaze.
My businesses’ and a number of client’s solutions are built using Meteor, and we are making a living from these, so you bet we have an interest in preventing the erosion of support for frivolous reasons.
Meteor has continued to get better and better whilst preserving the functionality that made people choose to adopt it in the first place. A large chunk of the “wall” was demolished long ago in version 1.3 when full NPM ecosystem support was introduced.
I read Hacker News and other sites daily to keep me informed about new programming languages, frameworks and tools and their best use cases.
To date, the Meteor classic stack has been the most productive framework we have ever used and remains our first choice for new projects.
No other framework has allowed us to develop reliable SaaS solutions quickly, with the fewest bugs, without requiring us to seek out hotshot programmers.
I eagerly look forward to the imminent release of Meteor 1.9 which will allow us to enjoy the performance benefits of Node.js 12.
12 Likes
Congratulation! Hope Meteor became more and more powerful!
中国开发者发来贺电！
3 Likes
Popularity does not imply correctness or quality.
This was exactly the reason why I have chosen Vue over react when was afraid of Blaze not being maintained. And still have very warm feelings to Blaze.
I read Hacker News and other sites daily to keep me informed about new programming languages, frameworks and tools and their best use cases.
Exactly. Lots of fuss around, no substance on how to solve business tasks. Sometimes I feel most of people in broader JS community are just tech junkies and not entrepreneurs, which to my feeling contradicts to Meteor community. Man, MDG could have bet on small entrepreneurs and natural growth with all the participants interested in growing together, on the contrary to betting on enterprise (but that I believe is Silicon Valley and Investors relations things). Yet, not being able to make money with such a great product and such resourceful and deep thinking community is a shame of MDG (with great respect to technical wisdom).
11 Likes
Yes, I think this was the core issue. MDG wanted to use VC money to develop core web infrastructure. And this does not work. This is a problem of today’s investment methods available (non-profit, VC, research grants). They are bad for core infrastructure. VCs want return on investment and developing core infrastructure sadly cannot really provide that. So I think they were simply pressured to go into Galaxy first, enterprise focused, and then to reinvent themselves with Apollo.
4 Likes
I’ve the exact same sentiment about the NodeJS ecosystem, in theory nodejs should be the best choice for entrepreneurs since you’ve to use only one language but it seems to be dominated by cooperate tech/hype. It is different than php and RoR where you feel it has a strong and focused entrepreneurial community. Meteor has that entrepreneurial vibe within its community which I really like, but the community just need a bit more attention and nurturing. MDG managed to create the nodejs entrepreneurial nest which is a great achievement but then they pivoted to enterprise tech perhaps under VCs pressure as @mitar suggested.
4 Likes
Exactly. This makes a lot of sense. I would love to see an out-of-the-box Apollo integration supporting subscriptions, as simple to setup as Meteor.publish . 
5 Likes