It depends entirely on the budget really. Meteor is great for turning over applications quickly, but that's it. Ember is a better frontend full stack framework and if the server is to be built by someone else, go with Ember.
If the budget is large, there's a good dev team and the project needs a performance kick then React is the better choice, if built right.
We've been handed over React codebases though that needed saving and while the previous devs might have been fairly competent, React has a lot more work involved which can make people get lazy after a while and have the opposite effect of what it was intended for, and that's speed.
For personal projects I will never go for React. I love the concept of React and how it works, but there's too much boilerplate and I personally prefer more full stack solutions.
Ask HN: Is Meteor.js still a thing?
11–20 of 107 posts
Re: Ask HN: Is Meteor.js still a thing?
#12If you want to look at it from popularity angle, we continue to see many meteor deployments on https://nodechef.com/meteorhosting suggesting it's still a popular choice out there.
Re: Ask HN: Is Meteor.js still a thing?
#13We migrated on of our customer app from Meteor to Vue and Rails. By doing this, the app is much more easier to scale. They are happy with the result.
It's is easier to find developer for Rails and Vue.js
Re: Ask HN: Is Meteor.js still a thing?
#14It used to be, now I find it quite bloated and slow. There was a time a save diff would be instant and startup was also just as quick. Now even to run 'meteor shell' and meteor mongo in an admin environment spits out instructions which are unnecessary and bloated. I could really go on..
Also, they used to have focus in 'blaze' which served a good purpose and then they reverted to a generic model where you use React (which needs all sorts of plugins to be reactive). It used to have direction and was very well thought out.
Re: Ask HN: Is Meteor.js still a thing?
#15I 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 cau…
You can use React as a front end for Meteor
Re: Ask HN: Is Meteor.js still a thing?
#16Lol - a thread like this seems to pop up every couple of months.
They are updating it like all the time with new features.
The biggest problem with it is that the data layer does not scale well for large apps, and that has tainted the reputation of Meteor as a whole.
However, there are community packages on the way to fix it, and hopefully Meteor will implement MongoDB's new Change Streams feature, which essentially puts the reactivity on to the database.
I'm still holding my bet on Meteor, having recently launched an admin panel tool for it: http://meteorcandy.com
Re: Ask HN: Is Meteor.js still a thing?
#17If you want to look at it from popularity angle, we continue to see many meteor deployments on https://nodechef.com/meteorhosting suggesting it's still a popular choice out there.
More details please :)
Re: Ask HN: Is Meteor.js still a thing?
#18No. 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 and diff way too much data for the reason that it saves bandwidth. Wrap their caching functions to forget the data when you know you don't need it, and Meteor can become much more performant.
Still, I wouldn't use Meteor for any kind of traditional website. It's way too easy to introduce state on the server, but there shouldn't be state on the server, and it's way too easy to abuse reactivity and end up with a toy that tanks with trivial traffic.
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 require a shared state on the server (or in Redis or something) like in online games, chat, or any other online multi-user real-time 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 by default or in certain cases.
Meteor apps consume less data but take up a ton of server resources. Overall, the problems introduced by polling were just traded for DDP's own problems. The problem of "sending data to the client in real time" might not even be an important problem. If the client looks at a page every 20 seconds, then there's no reason for the page to be updating for an empty audience.
I think Meteor is building something called Apollo now which uses some sort of intermediary caching server to keep track of data versions, which the client then polls for updates to the data it depends on. At a first glance, it looks like they just took the problem with DDP and moved it into an independent system. I could be wrong, maybe their polling solution would end up fixing the issues.
Re: Ask HN: Is Meteor.js still a thing?
#19Spoiler: I am one of the authors of a competitor product (wolkenkit), so my answer won't be perfectly objective.
IMHO Meteor is not a thing, as it builds on a wrong assumption: At the heart of Meteor is modeling your data, and it basically builds upon a CRUD approach. This is perfectly fine for very simple use cases, but it doesn't work well for more complex things, because limiting yourself to create, read, update and delete limits your expressive power dramatically.
In contrast, when we designed and developed wolkenkit, we put the verbs into the center of the development process. With wolkenkit, you model processes that describe what your application does. This way, wolkenkit is a pretty good fit if you do domain-driven design (DDD), but you do not need to do DDD to use wolkenkit.
wolkenkit gives you the option to focus on your domain expertise, and provides all the technical stuff below, such as persistence, authentication, real-time updates, and so on…
We built it based upon CQRS and event-sourcing, so you have a pretty good foundation for scaling and reporting / analyzing data. As it's only for the backend, you are free to use any UI framework you want to use, but we have a client-side SDK for JavaScript to assist you.
You can find more information at https://www.wolkenkit.io/ and in its documentation https://docs.wolkenkit.io/1.1.0/
If you just want to get started with the concepts, have a look at our 68-pages brochure on DDD, CQRS, event-sourcing and wolkenkit: https://docs.wolkenkit.io/1.1.0/downloads/brochure/
wolkenkit is available as open-source and under a commercial license. If you have any questions, feel free to contact us.
PS: At first, wolkenkit feels somewhat strange, if you are not used to CQRS, event-sourcing & co., but once you get it, I think it is a pretty good approach to developing software.
Re: Ask HN: Is Meteor.js still a thing?
#20I 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 cau…
You can use React as a front end for Meteor
That wasn't at all their point.