Should I use Meteor for production apps? If not, which Framework should I use for reactive realtime apps?
Ask HN: Is Meteor.js still a thing?
1–10 of 107 posts
Re: Ask HN: Is Meteor.js still a thing?
#2No. You should just build a regular app, and build reactivity wherever is necessary.
You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things.
Just build a react app, and add a websocket layer wherever possible.
Re: Ask HN: Is Meteor.js still a thing?
#3No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.
Re: Ask HN: Is Meteor.js still a thing?
#4The team behind it released version 1.6 just a few days ago, so it is definitely still alive. I haven't used it since a few versions ago but I don't see we it wouldn't still solve the same use case as it did before: making it trivial to build real time collaborative web apps (that don't require extreme scale). With rethinkdb being an unsure bet and graphql not offering the same ease of development I am also not aware of a competing framework. Arguably meteor is getting better and better by integrating more with the broad node/Javascript community.
This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.
Re: Ask HN: Is Meteor.js still a thing?
#5No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
Thank you!
Which backend framework should I use?
I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?
Re: Ask HN: Is Meteor.js still a thing?
#6I don't know a better tool for prototyping but I found it too slow even with ~1000 clients and that is on a beefy server. If, by some magic, they switch to a more modular design (maybe they already did, not following closely) and that in some way enables the use of postgres (as a 1st class citizen), I'd give it another go for something more than a prototype.
Here is my humble opinion: If you aren't writing business logic, and will do mostly network programming, try Go. If you are doing something enterprise-y, use Kotlin or (IMHO even better) .NET Core. If you want to like writing code, try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair with Python/Ruby).
Re: Ask HN: Is Meteor.js still a thing?
#7I speak from personal experience when I say companies are migrating away from Meteor. For me personally it's to a React/RxJS front-end stack in combination with a traditional Ruby/PostgreSQL/REST api back-end. This had the disadvantage of losing the back-end reactivity Meteor is known for, but at the same time it's a much more stable, decoupled and scalable stack. Meteor simply felt too much like a black box that caused a lot of scalability and maintainability problems in production. Its "make reactive all the things" model also gave (less experienced) developers a huge gun to shoot themselves in the foot with, causing a lot of performance issues.
If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.
Re: Ask HN: Is Meteor.js still a thing?
#8No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.
Re: Ask HN: Is Meteor.js still a thing?
#9No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
Thank you! Which backend framework should I use? I need to implement OAuth Gitlab auth -_- Do I have to implement Implicit OAuth2 Flow?
http://megaboilerplate.com will get you set up fastest, with auth already in there.
It sounds like you have no specific requirements for the backend, so don’t waste time thinking about it, just pick something and go.
Re: Ask HN: Is Meteor.js still a thing?
#10No. You should just build a regular app, and build reactivity wherever is necessary. You don't need reactivity everywhere, the way they do reactivity is really expensive, and you can't turn it off because they are so opinionated about how they do things. Just build a react app, and add a websocket layer wherever possible.
You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache way too much data. Wrap their caching functions to forget the data when you know you don't need it.
Still, I wouldn't use Meteor for anything requiring scale. Besides, it's way too easy to introduce state on the server, but there shouldn't be state on the server.
I think polling is ultimately a better model because it allows each component to throttle itself at whatever pace is necessary.
I can see meteor being useful for applications that required a shared state on the server (or in Redis or something) like in online games, chat, or any other online multiuser application.
But then Meteor became a tool for common websites that didn't actually need reactivity, and people started abusing server state, reactivity, etc. I think at some point, the community was begging for options to turn reactivity off in cert