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
Nobody writes an article with a clearly articulated plan for an open-source project if they aren’t invested in the success of that project in my opinion. So maybe some people thought the timing of the article was poor due to @sacha’s stature in the community, but that isn’t so bad really. I’m sure most of the people who read the article are already on Meteor’s side. I think the web development community at large is more concerned with Meteor running on Node 12, having modern features, support for Typescript, and up to date packages that solve problems that they need solved. And some signs of life regarding Meteor from its benefactor Tiny, like new blog posts discussing new releases, or new packages, etc.
11 Likes
Thanks for sharing,great write