101–107 of 107 posts
I am using Meteor in my work on a daily basis, and still love it! On the frontend I use Vuejs instead of Blaze, though.
What do you use for forms and other items that have packages in the blaze ecosystem?
Contrary to many here, I feel over the last year they made themselves totally relevant again. And I think that the negative reactions here are from people that aren't fully aware of the current state of the project. Note that Meteor is much more than a data layer. Even though you won't find any easier system to deal with reactive data than their livequery system, I get that you don't want to be bound to Mongo or even…
I agree with this assessment. But meteor's main problem is being able to interface with providers that are not Galaxy, at least they dont have good documentation on it and you have to rely on blog posts. Plus galaxy is at least twice as expensive as aws for small projects.
Meteor developer for a long time here. Meteor, today, is still a good match for small to medium applications that provide real-time features in more than 50% components/pages. For most applications Meteor becomes a real pain in the ass. I wrote several applications for multiple clients, in 4 years I haven't wrote a single one that used the real-time features properly. A tradicional stack is simply much more flexible…
Earlier quoted context omitted.
I don't really understand RxJS that well, but here is where my understanding is at. RxJS helps with composition and dataloading. On a theorectical level, isn't it ideal to have Redux used with RxJS? How do you do global state management with RxJS?
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 whenev…
Reposting my comment because it's going to help you: Meteor projects are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug. Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've trie…
* It's a project with a strong community (364 contributors) that still has traction among developers (+ 8 stars by day on average over the last month, check the numbers here https://bestof.js.org/projects/meteor)
* They keep moving in the right direction: moving away from their own package manager (https://atmospherejs.com/) to NPM, accepting ES6 syntax everywhere, client and server-side without config, enabling AngularJS or React for the front-end layer... Since Meteor 1.6 version, they use under the hood one of the latest versions of node.js.
* Other contenders with such a combination "no config / real time / full-stack JS" features out of the box have less traction (check some contenders here https://bestof.js.org/tags/fullstack)
Some great projects on GitHub are built on top of Meteor:
- https://rocket.chat/ a clone of Slack chat app
- https://wekan.github.io/ a clone of Trello app
- http://vulcanjs.org/ "The full-stack React+GraphQL framework"
The drawback is that the Meteor is quite opinionated about a lot of things, it's a monster of its own, blurring the boundary between client and server-side code. It can be difficult to debug, test, deploy and scale.
So there is no definitive answer about the question "Should I use it in production?".
The team behind Meteor is really committed to keep on moving forward, GraphQL and Apollo support are coming soon, the post about the latest release gives interesting insight about their vision: https://blog.meteor.com/announcing-meteor-1-6-abf30f29e2c6 The author said that, at the end of the process, "Meteor may look less like a framework and more like a library of middleware that can be used in any existing application, JavaScript or otherwise".
One important thing is that they move forward steadily, without breaking things, which is important when you run applications in production.