Live data from Hacker News

Ask HN: Is Meteor.js still a thing?

news.ycombinator.com

91–100 of 107 posts

Re: Ask HN: Is Meteor.js still a thing?

#91
post #60

Lot's of people mentioning "reactivity as being expensive/non-scalable". is there a good read up on what reactivity in the context of meteor.js is and why it is expensive ?

TLDR is:

- Meteor uses MongoDB as a data store

- You write queries on the server called "publications", that make documents available to the client

- The client implements "MiniMongo", which basically lets you query the documents that have been published via your publications using Mongo queries as if you were writing them straight from the server

- The publications are (by default) reactive, so whenever any of the documents in your queries is added/removed/modified, the changes propagate instantly to your client.

- The original view library (Blaze) would seamlessly update with these changes in your UI.

From memory, the performance bottlenecks here are:

- It uses the Mongo OpLog to determine when changes have been made to the collections, which makes the queries themselves quite slow.

- For every dataset published to the client, Mongo keeps a cache of that dataset on the server so it knows when it needs to send deltas over the wire.

So for both of these reasons, once your queries get big, they get SLOW.

The other thing that is costly (but not fundamentally a fault of Meteor itself), is that most people building web apps model their data in relational terms. If you try and apply that to Mongo, (ie, treating collections as tables and "joining" across them instead of nesting data hierarchically inside your documents), you'll end up writing slow queries.

Re: Ask HN: Is Meteor.js still a thing?

#92
post #40

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.

Well, the output of meteor build is a normal node application, so in that regard it's just as easy or difficult to dockerize/deploy like any other node app.

Re: Ask HN: Is Meteor.js still a thing?

#93

Earlier quoted context omitted.

> Is Meteor the answer for everything? Of course not. It sure does claim to be.

And poptarts claim(ed) to be part of a "complete breakfast"... - https://www.youtube.com/watch?v=_nqhoP_ychc Promotion/marketing speak is promotion/marketing speak.

At least Pop Tarts throw in "part of a". Meteor wants to be your entire stack, to such an extent that I'm honestly a little surprised they don't ship their own editor.

Re: Ask HN: Is Meteor.js still a thing?

#94
post #68
post #65

Earlier quoted context omitted.

> React/RxJS front-end stack Tangent here, but I see this combo a lot and I don't understand what RxJS is adding to the equation on the front-end. What were/are your motivations for using RxJS?

We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJ…

We have been using VueJS. Loving its fully packaged ecosystem of vue-router, vuex. The EventBus + vuex layer takes care of all state management and data subscriptions.

Re: Ask HN: Is Meteor.js still a thing?

#95
post #68
post #65

Earlier quoted context omitted.

> React/RxJS front-end stack Tangent here, but I see this combo a lot and I don't understand what RxJS is adding to the equation on the front-end. What were/are your motivations for using RxJS?

We use RxJS for data loading and global state management. Started with redux first, but really disliked all the boilerplate code. RxJS enabled us to have a really smart data loading and caching mechanisme that automatically pushes changes to all streams that rely on a particular piece of data whenever that data changes. No need for reducers, selectors, actions, constants or sagas. Just components with one or many RxJ…

Sounds interesting, is there some code I can look at or a blog post or something?

Re: Ask HN: Is Meteor.js still a thing?

#96
post #40

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.

I've chosen meteor for a project recently and like where v1.6 is going. I agree the deployment docs for non-galaxy hosting being challenging and it took a bit to figure using PM2 from blog posts. Just starting to test Galaxy which integrates the kadira APM that I think is essential for scaling meteor, too bad the open source version hasn't been updated for 7 months so DIY meteor hosting. If

The meteor docs in general need more examples and best practices. The udemy course on meteor/react is extremely well done as a starting point.

Re: Ask HN: Is Meteor.js still a thing?

#97
post #27

Earlier quoted context omitted.

> If you want to like writing code [then names dynamically typed languages] Huh? :)

That's why I explicitly stated that it's my personal opinion, although "comment" already means "a verbal or written remark expressing an opinion" :) I actually like JavaScript more than many typed languages but I don't like writing a server that runs on an event loop. Again, preference. ps. You seem to be downvoted, I tried to compensate by upvoting. It is just a tease with a smiley at the end. Relax, people.

> I tried to compensate by upvoting.

Thanks..

> It is just a tease with a smiley at the end. Relax, people.

Indeed, what's wrong with these people! :-P

(I was a dynamic typer myself, but changed sides when learning about strong typing, especially in FP langugaes)

Re: Ask HN: Is Meteor.js still a thing?

#98
post #71
post #69

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…

That's a really clean sounding architecture. Any particular issues?

Re: Ask HN: Is Meteor.js still a thing?

#100

We 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

The author of Vuejs used to work for Meteor and he proposed them to officially integrate Vue as the front end layer. They didn't like the idea.
Post reply on HN