I would really like to see meteor get similar tools like ionic has with ionic studio and ionic flow, so more GUI tools for managing and building your apps.
Lots of features request, which is good, we all wish to have products where the users are engaged in it.
Perhaps a good start is to update the site with a page where the community can vote on what they deem most important? similar to what webpack has on their site.
This could be another source of revenue from Meteor, those who donate to the framework get influence points and their opinion weight heavier in the overall decision making process.
2 Likes
I’d also decouple the monitoring and hosting in Galaxy, so those who host elsewhere can still use Galaxy’s monitoring agent and portal which would increase Galaxy’s revenue and allow for cross sell later. I think Tiny first goal is make the framework financially self sustaining and allow the community to contribute both financially and technically so it can stand on its own feet long-term without VCs injection.
So many folks are using Meteor in major projects and it’s an organizational flaw that the framework is not getting the care/support it deserves. Again I think the most important thing is to inject stability and confidence in the community and improve the communication, this has been the biggest pain point for the last 3 years, everything else will follow, also investing in the marketing to reduce the broader misconceptions around the framework. No need to deprecate one thing on the expense of the other, there has been enough leadership churn by MDG already.
4 Likes
Regarding reactivity: often it is just not needed. You have to ask: can this data be modified by another user and do i always need the newest data?
Often you will have the situation, where the current user of the application is the only one modifying a set of data, so live updates are not needed in this case. Sometimes live updates can also be annoying. Imaging facebook always pushing new post on the top while you are reading!
There are ways to help be in sync with the backend:
- after mutation it makes sense to refetch queries that could be affected by this mutation. depending on the mutation result, you even don’t need to do anything
- you can simply poll the data (suprisingly often good enough).
- you can use graphql subscriptions (never done that) that give you real server push updates like meteor pub/sub
While I agree with a lot of what you have posted so far, I think you are too quick to dismiss the importance of real-time and reactivity. Granted, an application like Facebook or a website hardly needs any of that, beside pushing some notifications.
But if you switch to the realm of real-time sensors analytics and monitoring, fleet management, collaborative work of any kind (doc editing, mapping, engineering, and so much more), all of a sudden you’re talking about a different league. Pub/sub is a must in these cases and polling will never be good enough.
And that’s where everything is going. There’s even a big drive for machine learning from streams, then pushing results in real time to front-end users. The Meteor of 2012 has foreseen this shift. The problem started when everyone started building websites with it. Ever tried building a highly interactive, real-time app without using reactivity? If so, you must know what a nightmare it is to tie everything together in an imperative sort of way.
Real-time apps - that’s where Meteor belongs.
8 Likes
We’ve been using Meteor since version 0.49, and grew with it. Developed tens of minor projects with it, and a major one which is our main business today (illustreets.com). What I hope from Tiny is that they recognise the special and unique offering of Meteor, which small to medium business can’t afford to overlook:
-
Short time to market.
-
Minimal development costs (and with an improved Galaxy offering, minimal DevOps overhead).
-
The only serious player in an uderserved market segment: real-time applications. Think drones, think geospatial, think sensors, think logistics. In the last three years, one more billion people just got connected to electricity. And they have lease to own equipment. Which transmits events in real time and are aggregated in real time - visualised by a relatively low number of users.
Seriously, the amount of time I read people complaining about SSR… who needs that in admin dashboards with charts and maps? And there’s a growing market for that - the world just doesn’t belong to Twitter and Facebook clones.
-
Repackage / rebrand by industry, using the same underlying tech stack, but in different configuration. The brilliant success story of @awatson1978 just a few posts above is good evidence that this could succeed. There is also the financial industry.
-
Please keep the backwards compatibility, even if it requires effort. A paid support model can be used to mitigate that.
Good luck!
Edit:
Correction, Abigail’s post is under a different thread: Some Exciting Meteor News
6 Likes
You can use subscription-scope package to address this.
I think this is the main issue with Meteor: people are so used to great core features, that if something is not in core, it is generally hard to find it unless developer put some extra effort in PR. But for almost anything I have ever imagined or there was already a package fixing it (or even multiple of those), or it was possible to do it yourself. There are really very little fundamental issues with Meteor. It is just for three years or so it was not developed anymore feature-wise, so some common features which are in packages never made it into core, or at least guide.
12 Likes
Galaxy has the huge selling point of having fast and reliable deploys which are also super easy to manage, but the rest of the offering has remained stagnant for years.
We host at Scalingo (and Atlas). Scalingo has native support for Meteor, reasonable pricing, and exceptional technical support. for now the only disadvantage for international customers would be that their data centers are located only in Paris (though recently they have managed to open second data center in Paris, presuming tech wise they might be ready to go international).
And Atlas. Oh, this is what I would expect from Galaxy to be to Meteor, as Atlas is to Mongo.
3 Likes
What’s the performance of the Scalingo containers like ? ( I mean in relation to their Galaxy equivalents )
What makes meteor have a special place in my heart?
When I started vetting meteor, I realized it was the Apple of frameworks and it was not just marginally better than everything else, it was a revolution. I chose meteor for my business after a weeks of research wherein I deep dived into many competing web app frameworks, so when I say I was impressed, this was in the context of some serious research.
Meteor was very opinionated compared to other systems. Since the guys behind it were smarter than me, their opinions were right and that is much better that making hundreds of micro decisions and second guesses throughout the whole development process. Other frameworks focus too much on edge cases.
Meteor always has us asking “what’s the meteor way to do this?” If you fight that, meteor is not a good fit for you. You should not be using meteor if you are fighting meteor. Meteor works well for some things, like scheduling platforms, and those companies are really into it. If you embrace the meteor way, things start working beautifully. Code comes out nice and bug free
Like Apple, the guys at meteor had anticipated what the product will be used for, carved out a niche, and built features that supported that use case. That use case is squarely app development for apps with user accounts that interact. Pretty big market if you think about it. Other frameworks don’t attempt to anticipate what they’re used for and they suck to configure.
What did we need that meteor had solutions for?
- A good out of the box experience
- Database as a straight pipe to the UI, very strong coupling!
- Reactivity by default and not something that needs configuring
- Query language we can use on the client
- Subscriptions
- A flawless accounts system
What did we not use and didn’t ever even care about?
- Allow/Deny
- Blaze
- SQL support
- SSR
What did I need that meteor provided no solution for?
- Simple setup for react
- A router
- A way to deploy to DigitalOcean
- React native in the same codebase
To those in charge of the future…BE the innovation of the entire industry! We want more stuff that supports meteor’s established purpose. Don’t try to be everything to everyone, be something to someone.
5 Likes
And visionary, always ahead of the curve. Wonder what direction Arunoda would take Meteor in.
2 Likes
It’s not just Arunoda, Evan You the creator of Vue was working at MDG at some point and he proposed having vue officially supported back in 2015, here is a thread on that topic. 4 years later and vue still hasn’t gotten an official blessing, imagine if Meteor adopted vue back then.
And the other interesting thing about that 4 years old thread is that people were asking the same questions being asked today, graphql vs ddp etc…a good leadership will end the speculation about those points and align the community going forward.
7 Likes
I’m seeing more and more local project teams choose Vue over React, and I suspect hooks and other issues in the React space will only accelerate that trend.
To be honest though, the Vue Meteor integration seems tighter than the React integration, which always felt tacked on, even if it wasn’t a first party effort.
3 Likes
I use react but I’d be the first to admit that Vue is more natural fit for Meteor, if it was adopted back in 2015, it’d have made Meteor the Laravel php of nodejs. But anyway, we look forward in the near future for better decisions.
2 Likes
What’s the performance of the Scalingo containers like ? ( I mean in relation to their Galaxy equivalents )
After moving from Galaxy the app has been enhanced heavily, so I can not directly compare. When we performed realistic load tests as I remember it was around 300 simultaneous connections per single M-Sized container with 512Mb RAM, before it started to swap, whereas normally it takes around 256MB. There are things that can be optimized though, as almost everything is currently reactive. And after the optimization, we look forward to Redis oplog as well. More details on Scalingo’s containers is here: https://doc.scalingo.com/platform/internals/container-sizes
And don’t forget there is autoscaling by default - you just set up the limit and conditions and the thing ‘just works’. And so far for us, over at least half the year when the app is live, it has been working reliable.
Also, I can not say enough good words for their tech support guys. You literally talk to experienced devops in real time and solve rather complicated things right away. With honest and direct responses, with sharing of their ideas, suggestions, plans etc. After this I just don’t care that much about their prices, as I know I have such great people behind my back. And another thing is that I want also to support local/smaller guys, and try to limit support of monopolies that are forming in the tech world.
2 Likes
Reading the recent posts in this thread, I am thrilled to realize, there are so many exceptionally smart people around within Meteor community, that share weighted opinions (there were really scarcity of such over some time). So even if Tiny manages to break things up (
), I start to have more and more confidence now, that altogether we will find ways to keep things moving forward. Thank you all for being around! 
2 Likes
Yes, even internally they are very close so. Even so much that one can implement Tracker in terms of Vue.
1 Like
Most wanted features for Meteor:
Feature 0: Release Meteor 1.9 with Node.js 12 support ASAP
A much faster V8 JavaScript engine and support for worker_threads, Bigints and TLS 1.3 provides performance, scalability and security benefits to everyone.
Please allow @benjamn to keep working on this without interruption as he is very close to completion.
Feature 1: Improving MongoDB Oplog Tailing Mode Scalability with Minimum Result Fetch Interval Setting
This is critical for improving the scalability of Meteor apps that use MongoDB in Oplog tailing mode
The Meteor MongoDB code needs a throttling feature to set a minimum time interval between successive result set fetches for a given reactive query. This allows the developer to imposes a hard limit on the maximum update rate of a given reactive query.
This would greatly reduce CPU and memory usage for reactive queries and reduce network bandwidth when those reactive queries are published and subscribed to by clients.
In many cases, it is not necessary to fetch updates at top speed in response to every change. For example, if we are using a Mongo publication to update a user interface component like a table or map or chart on a web browser page, we gain nothing from updating it more than say once per second.
A new option minResultFetchIntervalMs would be added to Mongo.Collection.find(), which represents the minimum allowable time delay in milliseconds between successive result set fetches for a given reactive query.
For example, a publication that can send reactive updates at a maximum rate of once per second would have a minResultFetchIntervalMs of 1000. A maximum rate of twice per second would be a minResultFetchIntervalMs of 500 and a maximum rate of once every 5 seconds would be a minResultFetchIntervalMs of 5000 and so on.
Equivalent functionality has existed in the mysql-live-select package, the key component of the Meteor MySQL integration since the beginning. It has been crucial in allowing our reactive Meteor MySQL apps to scale. I feel compassion towards people using MongoDB and also want them to have a similarly good experience like we currently have with MySQL.
I have written this up on Github:
Feature 2: A Meteor accounts package that is decoupled from MongoDB.
Please introduce an abstraction layer in the code to decouple the database code from the Meteor account logic.
One simple starting option is to modify Meteor accounts to use a virtual/overridable Collection class instead of Mongo.Collection, so the developer can use their own database-specific code to implement collection methods like find(), insert(), upsert(), update(), remove() etc.
Feature 3: Minimongo secondary index support
At the moment, there is a third-party partial implementation of Minimongo secondary indexes provided by the experimental package helfer:minimongo-index. It only speeds up point queries but not sorting operations, but perhaps this code could be used as a starting point for a complete implementation.
This has been on the feature requests list for a long time:
Feature 4: Renew MDG commitment to Blaze
Back in August 2018, @hwillson brought a lot of comfort to the Meteor community with the following statement on behalf of MDG. I urge Tiny to renew this commitment.
Feature 5: HTTP/2 Websocket Support
Node.js V10.12 added RFC 8441 extended connect protocol support to allow use of WebSockets over HTTP/2.
The main performance benefit is that a single HTTP/2 connection can multiplex requests and WebSockets.
11 Likes
NativeScript integration. It would be nice to be able to connect to a Meteor server over DDP using NativeScript.
Support for the latest version of Mongo and aggregations without meteorhacks:aggregate.
I don’t think there’s a need for shiny new tutorials, but rather maintaining the ones that exist. I pulled the latest todos and npm audit shows 53 packages with vulnerabilities and tests are failing. It would be nice if there was an updated version of this classic tutorial for Blaze, React, Vue, iOS, and Android. I would also like to second an updated version of Discover Meteor.
Official Discord meteor community. I appreciate and have greatly benefited from Vue’s Discord communities. It’s easy to ask for help, assist others and stay up to date on changes. The Meteor Chef is in maintenance mode and had a popular Slack channel that is mostly inactive. Ownership of an unofficial Discord community was handed off last month and it’s pretty quiet in there too. If one was official, maybe it would be more active.
1 Like
Spot on! There are lots of conflicting opinions on how to proceed and which changes/features to prioritize. So, let the pros decide.
1 Like