Ask HN: Is Meteor.js still a thing?

Well, RxJS helps with pushing data around in general. It doesn't care much if it's from a local state store, a backend api or something else. So in a way it makes a lot of sense to use it for state management as well. The way we do it is by having a single global state store (like redux) with one incoming RxJS stream for writing to that store, and one outgoing stream that emits the latest snapshot of the store whenever a change is made to it. A component can then subscribe to that stream and filter it so it only gets an emitted value when the data it cares about changes. And because there's only one incoming and one outgoing stream it's very easy to debug and see what's going on in the app, making it very predictable and transparent. Also, like I said before: almost no boilerplate code at all!

I would say yes. I used it for over 10 projects over the years and haven't found something more compelling in the JS ecosystem in terms of speed, database integration, easy of use. Reactivity should be off by default, that's right. Last thing I build has a React front (it's a text editor for medium-long form writing) and I'm super happy with the data layer on Meteor.

Your first 3 points are big deals but not unique anymore. The Vue webpack template comes with all that. Code splitting couldn't be easier, async/await out of the box and it stays backwards compatible up to IE9.

I'm sure React webpack templates have the same features but I don't have experience there.

I've had great success with Meteor. I started with v1.2, and it was quite painful to develop in. However, with improvements start within 1.3 and onward, every release has gotten better. Meteor 1.6 has the same concepts as Meteor 1.0, however it is extremely different and is up to date with standards of the Node/JS ecosystem.

I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box.

In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues.

I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer.

You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time.

My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.

You mentioned "gun" in the context of databases/realtime, so naturally I found it - although I was bummed it wasn't about gun (I'm the author of the popular https://github.com/amark/gun MIT licensed graph database) just the expression.

But since I now have you, you mention that "make reactive all the things" on the server caused newer developers pain? I've certainly had my fair share of developers initially being confused about reactive systems, but generally once they play with it, it "clicks" and they are mind-blown about the possibilities.

Would you mind sharing your experiences? So that way I can indirectly learn from your interactions and try to make things better, since I work on related systems.