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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
Thanks, that’s good to know. We’ve checked them out a few times but the thing that’s always put us off is the data centre they use isn’t part of one of the big-3, so we couldn’t launch our atlas DBs there, so it means we’d have to contract server & DB with them. I agree with you though about supporting the smaller guys, if only it was easier. BTW - I love that they have a public roadmap on trello
Reduce FUD by giving community clear commitment for long-term core support
Update the site/brand to explicitly endorse React, Vue and Svelte (and Blaze for backward compatibility)
Fix the pricing of Galaxy to appeal to entrepreneurs (at least match DO price), and decouple hosting from monitoring for extra revenue
Empower the open source contributors and package maintainers to handle the other features (I suggested adding feature voting page with sponsor influencer points)
Partner with companies that uses Meteor for contracting (e.g. Cult Of Coders) and support major open source Meteor projects (Vulcan,Wekan, RocketChat etc.) they’re your marketing front
That was actually a thread I made, not sure Evan ever really endorsed it considering he left MDG just a month or so after the post. However, yes, meteor should have official Vue.js support.
I actually looked in to the internals of Tracker to see if something could be adjusted there to make programming for React’s concurrent mode a bit easier (right now it’s super hard for a couple of reasons). I found an inversion of control that makes that difficult - each “Dep” maintains its own internal list of observers at the dep itself, not in the computation. I thought (without going deep enough to know if it’ll really solve the problems I’m trying to solve) that if the deps were either moved to the computation directly, or maybe if we replace the dep store with a weakSet or something like that, we might be able to rope the JS GC engine in to do cleanups for React’s discarded renders. The idea being that if the only references to those observers (or to the computation) is in the discarded react instances themselves, they should eventually get cleaned up by the GC. But that would all take a lot of testing - and either a fork of Tracker, or at least an extension.
The reverse was also possible. Evan endorsed it heavily internally, MDG made its position clear (similar to what he posted), and then he left because of conflict of interests
OpsCaptain already provides Meteor.js hosting via Git or CLI deployment and it is only $7 for a 1GB container and you also get a 1 GB MongoDB only $2 more expensive than DO. Infact, we are the cheapest Meteor.js hosting on the market. If Galaxy pricing is an issue, that shouldn’t be a problem for entrepreneurs as OpsCaptain is available. Just saying. Sure we do not have a fancy metrics graph and do not scale out but we are very reliable and get the job done for entrepreneurs just starting out. We are working on the scaling out and load balancing part. https://www.opscaptain.com/pricing
