Understatement of the year. It was just completely neglected
2 Likes
I will be carefully optimistic. On one hand I think it can’t get any worse with Meteor, so having Tiny on board sounds like we’re finally going up again.
Then on the other hand I don’t know what they are going to do with and I’m well aware of the art of Marketing (that’s why you have PR people that make even worse things sound like the new Hallelujah).
So now they have Galaxy, which finances itself and is a good platform that can be developed further to grow and become a cash cow.
Now what to do with Meteor? I’m not sure what Tiny’s intention is and only time will tell.
Our app is build on Meteor and yes, we’re one of those traditional ones with Blaze (no Vue/React), heavy MongoDb operations at the backend and ready to scale up (thanks to Lambda, AWS Fargate, Atlas and lot’s of time spend on thinking it through). But because MDG neglected Meteor so much, we had to go ahead and write our own extension of it to be able to use MongoDb 4.2 with the newest driver and more importantly for us, use Transactions.
That was painful and a lot of work for a small company. So my sentiment is that it would be great to have that for everyone (as Enterprise apps will have a lot of database interactions) but the benefit for us will be small. It’s rather another PITA to again rewrite much of our code 
So in summary, we have one foot out of the door for a long time, not because of frameworks looked more promising or better but because Meteor went nowhere in the last years. Just some small cosmetic changes.
Just my two cents,
Andreas
Author of https://yourDNA.family
5 Likes
Reading all these posts I wonder if Tiny imagined the amount of frustrations, missed opportunities, disappointed hopes caused by the decision of the founders to focus on Apollo to the detriment of Meteor.
10 Likes
The react integration isn’t exactly amazing. I replaced the withTracker HOC with my own solution pretty quickly.
Have you looked at this? https://github.com/meteor-vue/vue-meteor
my reaction to @sacha’s article was more focused on the first two of his next steps, talk to the community and get a couple big wins to start things off of the right foot (getting a new feature like HMR added to Meteor and hiring Ben would be the big wins). Those two steps would show everyone that Tiny is going to have an impact on things and encourages community involvement. And that will buy them time to then take the transition more slowly and form a plan.
I think they are off to a good start though and hope for more exciting news in the future.
6 Likes
Does anyone know what will happen to Meteor Developer support, their support program? https://www.meteor.com/solutions
Is it going to stay with MDG, or go to Tiny? And who will be providing the support there?
1 Like
From my communication with Tiny, it looks to me, that it will go with them. But I might be stretching from the little exchange we had.
Sharing thoughts as a Meteor user & developer. For me, at a very basic level, the most important elements of the Meteor stack are:
- unified framework for both front and back-end, with a single programming language, and a common codebase for both the web app and the iOS / Android apps through cordova.
- ability to pick whatever front-end technology is best suited for my project (Blaze, React, Angular, Vue, … you name it).
- Reactivity. It may be a small thing, but the way Meteor is natively inducing data reactivity by observing collections is amazing. It kind of forces you to think about your entire app in a reactive way.
- Minimongo. Life would not be the same without it. The benefits of data manipulation on the client side using the same exact methods as on the server side are huge. Using the mongodb grammar and syntax is really powerful.
What I would love to have at this stage is an easier way to handle data persistence and offline operations for the mobile apps. This is something we have still not entirely solved in our project.
7 Likes
The integration being developed at https://github.com/meteor/react-packages/pull/273 is excellent (I’m using it currently).
5 Likes
yes and I replied him back in that post, because I strongly disagree:
Sorry but I think that would be a major mistake. Meteor beauty is derived from its original vision of simplicity. It’s different—and valuable—because of Monimongo. Blaze is just a template engine, but it is simple and perfect for many use cases in mid-range application development. React is fine too, but a lot more complex. It would be ok let the user choose the template/framework for the View, but Minimongo—nad reactivity made easy—is what makes Meteor different. Getting “rid of the old Meteor” is equivalent to kill the project to make “just another Javascript framework”—that we don’t need sincerely. In a Javascript world where new frameworks get released every other day, I think we need something that keeps users focused on the business side instead of configuring and re-configuring their development environment. Not everyone is making big products that need to scale a lot. Most of the programmers create projects for customers or tiny niche products. I think that Meteor should fill the gap in the mid-range applications market to make things even easier and hide the complexity of the Javascript world—which is pretty messed up in my opinion. The enterprise needs this because there are plenty of options to build complex and core business systems. There are just a bunch of options to deploy a project in weeks and none of them is as good as Meteor in the Javascript space.
8 Likes
I strongly agree with this. The fact that there is no Meteor experience equivalent within the webpack/graphql/react ecosystem almost 4 years later is not due the lack of trying by the JS community but due to the inherent complexity of those standards/APIs and tools, a complexity required by large enterprises (thousands of components, multiple endpoints, multiple teams etc.) but unnecessary in many other contexts.
Flexibility in view layer is great but the Meteor experience need to be preserved and even enhanced. Tiny to Meteor can be the Steve Jobs return to Apple, double down on what works, fix what does not but preserve the identity/experience of what we all loved about Meteor when we first joined.
7 Likes
I agree with you regarding Apollo vs. MiniMongo/DDP. But I am not sure if I still agree regarding Blaze vs. React.
One thing is clear: Blaze was what got me into Meteor, since I loved its simplicity, and it was very easy to get into it if you came from a pure frontend web developer background, like me.
However, if I would encounter Meteor today, I would wonder if I should really use a technology that nobody else is using. I guess I would rather go for React, because it’s way more wide-spread in the overall JS community. Or maybe even Vue, because it’s more similar to HTML and Blaze. Plus, there’s so many more ready-to-use React components out there, which is also a big plus.
2 Likes
I built my fair share of apps in Node, some as services to support our main Meteor app, and, damn, I couldn’t find anything to even come close to the simplicity of DDP and Meteor methods.
While in the front-end, Minimongo and Tracker are just a joy to work with. Blaze was and is perfect for any medium size project, though I understand why one would want something that is guaranteed to be maintained.
2 Likes
The preference for a view layer tend to be very subjective and dominated by hype, yesterday it was handlebards (and blaze), today it’s vue and react, tomorrow it svelte and web components. By keeping the core/backend flexible (yes at the expense of some end-to-end full-stack magic) you shield the framework and whatever is built on it from that churn and ensure the longevity of the platform. Furthermore, companies do re-write their view layers to update the user experience every now and then and pick the view technology of that time (hence the churn) but their DBs and backend are way more stable since those are battle tested.
7 Likes
But of course Tiny could always decide to maintain it again. Also, I think given similarities between Vue and Blaze, it would be relatively possible to build compatibility later on top of Vue exposing Blaze. Moreover, I have already done work which allows combining Blaze and Vue together, with great simplicity (using Vue inside Blaze and Blaze inside Vue), with reactivity working across them.
So, putting more people on this and all this could be pretty neat.
6 Likes
I very much agree that Meteor should stay view layer agnostic and just be open to integrations with whatever view layer necessary. There are hordes of developers pouring massive efforts into React/Vue/Svelte/whatnot and no reason for Tiny to duplicate any of that in any capacity (i.e. repeat the mistakes made with Blaze).
A good example here is the semi-official Vue integration created by the Vue core dev @akryum. The only two components of such integration that are actually needed in most apps is the vue-meteor-tracker (links Vue to Meteor’s reactivity) and vue-component (links Vue to Meteor’s build system). The first one is around 400 lines of code and the second around 1500 lines of code. If Meteor is able to maintain a codebase where a nicely working integration can be achieved with only 2k LOC, then I don’t see any good reason why not to keep Meteor separate from view layers and allow such integrations to do the work.
13 Likes
Oh, I’m familiar with your work 
. I hope there’s going to be some investment put into it. Personally, I have nothing against Blaze. On the contrary, I found it very productive. We have 1000+ templates in our application, many of them as reusable components - using best practices as per Meteor Docs, the app is fast and nimble as a wasp.
To me, the tribalism and “politicking” surrounding the multitude of JavaScript frontend frameworks makes no sense, but, well, such is life.
1 Like
I can only agree and say: Great News guys!! I am so happy to here of these news and frankly I am very optimistic for the future of Meteor now! 
#makeMeteorGreatAgain
4 Likes
Spot on! (enough text for 20 chars)
I think the backlash caused by @sacha’s article is getting a bit too far. I’d say the FUD is unintended, and mostly caused by his desire for Meteor to have a future.
Sacha is one of the staunchest defenders of Meteor, and one of its most dedicated fans. Being pessimistic is not difficult to imagine, given the lack of communication we have all complained about for a while.
8 Likes