Same here, for 10 years I listen people telling MongoDB was the worst choice for Meteor.
It doesn’t scale, it crashes, it’s horrible…
I don’t know what those guys are doing with Meteor and mongo but I never had any issues to make a successful businesses and projects with those technos.
nosql db is perfect match for a full JS framework.
Agree 100%!
No need for opinionated UI or tying to specific framework.
Key points for me:
…next unpopular advices:
Great startup 101 advices ^^
I’m posting this, as having used Meteor for many years, and not having recent experience of other web frameworks to be able to comment about those other web frameworks. Anyway, creator of below video seems to have experience about frameworks I don’t yet know so well.
This video seems to have some points related to above discussion. For some of those good points, maybe they could be cherry picked to also use with Meteor, if those are helpful when growing Meteor community.
This video has some points, like for example:
Just stumbled over an actual use-case on React-Native and the React ecosystem that actually annoys me like crazy.
So react-test-renderer is apparently deprecaed by react: react-test-renderer Deprecation Warnings – React
Worse: React suggests “to move to testing library” - yeay another developer mass exodus from one package to another. Why React can’t simply update test renderer to use Tetsing library under the hood, while keeping the API?
This is the experience I (and I assume many other devs) don’t want to have and it’s an opportunity for Meteor Team and Community to learn from such experiences.
…I have similar experiences and mostly in JavaScript ecosystem (especially client side), sometimes is goying explode head, especially If I calculate some expected solution delivery time and then this kind of changes is comming! I remember 90’s, when things was simple and stable, and when we was solving himem.sys, emm386.exe and autoexec.bat problems 
Newest FreePascal TUI IDE fp has the same colors like that Turbo Pascal, so to get a retro feeling, maybe use it to edit Javascript code 
@xet7 haha, that times are gone …and I have enough shortcuts chaoss, when I’m switching between Webstorm, VSCode and c9 or between joe, vim or emacs and with another shorcuts wetween Windows/Ubuntu/Mac
@mikkelking that times are gone and fortunately we don’t have to write the code between BEGIN and END 
, but… for example Germany’s railways in some cases are still using MSDOS in some systems (not “dyno systems”, but they are really using it in some cases). They are telling, that its cheap, simple, reliable, clever and virus-free (in this times) 
.
I guess that explains why the German railways has so many problems. Hasn’t evolved much since that first trip in 1835 to Fürth
Just because this thread popped at the top again, here’s my two cents, as Postgres user and developer: you cannot replicate the Oplog/Change Streams functionality, which is unmatched (bar RethinkDB). Yeah, maybe you are thinking of LISTEN/NOTIFY*, but how do you effectively pool that in transaction mode,i.e. with something like pgBouncer?
Postgres, coupled with its amazing extensions, is an astounding database system, but when it comes to real time, it does not match Mongo. Meteor is a real real-time framework. Period.
*I’ve expanded on that in this post:
What trend site is that?
trends of current week in Github
Okay that is really good.
Hello, @edemaine and I are both on the Solid.js team. I’ll share some opinions on what I’d like to see for a framework like Meteor (or a Meteor-from-scratch-like project):
@lume/element, a library for defining Custom Elements with Solid.js reactivity and templating, which powers Lume’s 3D HTML elementsThese ideas are fairly high level, not too specific about Meteor, except that last three, in that I think having a high-level template with all the bells and whistles of a full app (that if you veer from this default makes things more difficult for yourself, which is fine) would be great and would help many people build apps more quickly.
React is not a good option because it is the last framework that does not have signals and effects, like all other major frameworks already do, inspired by the movement Solid.js created. React is “legacy” in my eyes because they do not even care to ship ES Modules in 2025, instead they ship CommonJS which does not even run in any browser without a build step or a CommonJS shim for the client-side. VDom diffing has already been proven less desirable compared to fine-grained updates (signals+effects these days). React’s state system is locked into the component system and cannot be used outside of it which leads to the requirement for 3rd-party state systems that introduce entirely different paradigms than the state that is inside components.
Solid.js Signals and Effects are very similar to Tracker and ReactiveVar, so they fit very well together. In fact, @edemaine’s edemaine:solid package makes it so that Meteor’s signals (ReactiveVars) work in Solid without any manual integration, making the experience feel very natural. Solid’s Signals and Effects, just like Tracker and ReactiveVar, are not limited to being usable only inside components, and can be used entirely on their own.
By extension, this means that Meteor’s signals also work in @lume/element which is built on Solid.js when using edemaine:solid.
We’ve also been developing a lot of high-level signals+effects primitives over at Solid that lead to very nice and concise clean code, that we could help bring over to Tracker+ReactiveVar. They are so similar that you can do this to get the same API as Solid.js equivalents:
const {
autorun: createEffect,
nonreactive: untrack,
onInvalidate: onCleanup
} = Tracker
function createSignal(initialValue) {
const var = new ReactiveVar(initialValue)
return [() => var.get(), val => var.set(val)]
}
// Now use it just like Solid.js:
const [count, setCount] = createSignal(123)
setInterval(() => setCount(count() + 1))
createEffect(() => {
console.log(count())
untrack(() => {...read other signals without tracking...})
onCleanup(() => {... runs when the effect is stopped or will re-run})
// effect nesting works the same (and this, is powerful, and we need it on backend too)
createEffect(() => {...})
})
If you find any articles on “signals and effects” they all apply to Meteor Tracker+ReactiveVar too, just differnt naming.
The TC39 Signals proposal aims to bring Signals to JavaScript natively. (If TC39 Signals comes out, with some minor changes Tracker+ReactiveVar will be in standards alignment here which is awesome!)
The reason I am biased to Custom Elements is because they are a standardized UI component system. You get devtools integration in all browsers out of the box (element inspector). This also means that if at any point in the future the Meteor team woud like to change the implementation of a hypothetical <accounts-ui> custom element, they could do so without everyone having to change their UI framework, without breaking changes. For example, a hypothetical <accounts-ui> element could be implemented with @lume/element, or with Svelte, or with Lit, or with anything else really, but it wouldn’t matter to the user of the element who would see the same DOM interface after the update and their app would continue to work.
The @lume/element package has type helpers for hooking up Custom Element type definitions into all major frameworks, enabling type checking and intellisense in the JSX of React, Preact, Solid.js, etc, and in other template systems of Vue, Svelte, etc, all which are powered by TypeScript. The docs for cross-framework type definitions are here:
By writing a hypothetical <accounts-ui> element with @lume/element, Meteor would be able to guarantee that all other framework users (React/Preact/Vue/Svelte/Solid) would have type checking, autocompletion, etc, no matter which framework they use. At worst, it will work in all other frameworks without type checking. This is much easier than, for example, trying to write 10 different components for 10 different frameworks.
If Meteor were to go with Solid, then an AccountsUI component would need to be made for all other frameworks. This is where Custom Elements can really help out, and Lume Element is the first with type checking across all major frameworks.
If I were starting from scratch, I’d consider looking at the following meta frameworks to see how they implement their foundations (or adopt one of them as a starting point):
What each of these three frameworks do is create a very clean abstracted layer between backend and frontend that includes the tough parts (SSR/SSG and connecting UI components across both sides), then leaving the user to implement backend and frontend logic specific to their app. A Meteor-from-scratch-like project could for example take one of these frameworks, then add authentication, standard set of components like <accounts-ui>, and other higher level features.
Vite is often used as a foundational piece below meta frameworks (including Astro, SolidStart, SvelteKit, etc) because it supports standard ESM and tries to remain standards aligned, while adding plugins for supporting non-standard features such as importing from a .jpg file, and hot-module-reload.
SolidStart is a great option only for Solid.js-based components. Similarly to those other three frameworks, a Meteor-from-scratch-like project could take SolidStart and add all the higher level things on both backend and frontend to make a more complete experience (accounts, roles, database, etc). But such a project would then disclude all the other React/Vue/Svelte/Angular/etc users, while Custom Elements can make it work for everyone.
React user:
function MyComp() {
// ... JS code ...
return <div>
<accounts-ui ... /> {/*This is a custom element.*/}
</div>
}
Vue user:
<template>
<div>
<accounts-ui ... /> <!-- This is a custom element. -->
</div>
</template>
<script>
// ... JS code ...
</script>
Etc.
How could a Meteor-from-scratch-like project start (or what would Meteor moving to) look like:
The key to making this work well is to start with a fresh fountaion built on standards (and making the decision to stay fully aligned with them as they progress). This means removing Meteor’s build system, no more ecmascript package which is now unmaintained and not aligned with standards, and when a build problem happens with it people get stuck. A downside of this is we may have to create a whole new system for packages that add integrations like Vue, or special modules types like import 'foo.mp4', etc. A big change, I know. I’m not sure how to keep the current build system (and the packages made on top of that) while having the new hypothetical design.
The good thing about being standards aligned is that the major hurdle, ES2015, we’re already past. From here on out it will be mostly just incremental language features, and nothing so major as the huge ES Modules update. So once we get over the hump of dumping the ecmascript packages and running natively, it will be smooth sailing.
( Digesting your mic-drop there @trusktr; curious if you have looked at Remult with the above in mind and formed an opinion with @edemaine especially with the “or a Meteor-from-scratch-like” caveat given there )
I am seriously considering Solid.js with this level of veracity going on behind it.
@digitalextremist I hadn’t seen Remult before, but after seeing the first line on the intro page:
Remult is a fullstack CRUD framework that uses your TypeScript model types
I know exactly what it is for. Similar to other things like tRPC, etc, with typed APIs across the boundary. Love it. I think it would be nice to have that, but as a typed reactive (signals/tracker) API connected to Mongo.
We can already write stuff like
createEffect(() => {
console.log(currentUser().name)
})
where currentUser could be a signal that is updated with a backend connection, and type safe. The next step would be auto-generating the signals API.
I’m thinking that to stay compatible with Meteor, we’d need to restore synchronous Meteor.methods on backend (async data behind signals/reactivevar), and then come up with a way to generate methods with type definitions.
An official Mongo schema core package could perhaps help with this. Right now its a bit of a manual process to write type definitions for all collections, but with a standardized core schema package we could map types to generated methods or etc.