Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ask HN: Is Meteor.js still a thing?

news.ycombinator.com

Post reply on HN
Print view View original

21–30 of 107 posts

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

#21

Post by maxsavin »

goloroden wrote: post #19

Spoiler: 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…

I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.

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

#22

Post by goloroden »

maxsavin wrote: post #21
goloroden wrote: post #19

Spoiler: 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…

I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.

I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

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

#23

Post by maxsavin »

goloroden wrote: post #22
maxsavin wrote: post #21

Earlier quoted context omitted.

I think you might need to give Meteor a second look, if only to learn a few things from it. It has nothing to do with (and does much more than) CRUD.

I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB, yes, but other than that I do not see the connection. Can you explain?

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

#24

Post by goloroden »

maxsavin wrote: post #23
goloroden wrote: post #22

Earlier quoted context omitted.

I know that Meteor is not only CRUD, but thinking in CRUD is at its center of how it deals with data.

Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB, yes, but other than that I do not see the connection. Can you explain?

E.g., if you have a look at Meteor's documenation, especially the part on collections (https://guide.meteor.com/collections.html), it is all about the classical MongoDB-like functions to access data which perfectly represent CRUD. It also describes hooks on INSERT/UPDATE/DELETE (https://guide.meteor.com/collections.html#hooks).

This pretty much shows how Meteor sees data: It's a "thing" that can be created, edited, deleted. That's it. It does not live on its own.

E.g., when you design a shopping cart, you can create a shopping cart, you can update it (which means adding items to it, or removing items from it, or changing the numbers of items in it, …), and you can finally delete it (when the user submits their order, or when they cancel their shopping tour).

What you can NOT do is to access your data using the verbs that are relevant for your domain:

- Put an item to the shopping cart - Increase the count of a specific item - Decrease the count of a specific item - Remove an item from the shopping cart - Discard the shopping card

For the domain "shopping", all these actions are relevant, and if you have to map them to CRUD actions, you lose semantics. What's even worse, update and delete are destructive actions, so you don't have any historical data. Of course you can implement all this, but you have to do it on your own.

wolkenkit, in contrast, uses event-sourcing, which works more like Git: Changes are collected, and you can replay them (either all to get the current state, or some of them for arbitrary analytics).

That's IMHO a major difference on whether you are using a CRUD-like foundation, or another approach.

We have also blogged about this: https://www.thenativeweb.io/blog/2017-10-25-09-46-ddd-and-co... and https://www.thenativeweb.io/blog/2017-11-01-11-13-ddd-and-co...

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

#26

Post by cies »

neoh wrote: post #11

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…

> I personally prefer more full stack solutions.

You might like Elm. If you also control the backend you may want to look into PostgREST (there's an Elm lib for it iirc). See also `elm-mtl`.

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

#27

Post by cies »

egeozcan wrote: post #6

I 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 l…

> If you want to like writing code [then names dynamically typed languages]

Huh? :)

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

#28

Post by petrbela »

anonytrary wrote: post #18
felipellrocha wrote: post #2

No. 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 sh…

> I think Meteor is building something called Apollo

Apollo is a library for GraphQL, primarily client side but there's also a server component (sort of like ExpressJS for GraphQL). While GraphQL also includes real-time web-socket based subscriptions, they are an extension rather than the core, and, in practice, most clients/servers (including Apollo) use polling to fetch updates because it requires a much simpler server architecture.

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

#29

Post by maxsavin »

goloroden wrote: post #24
maxsavin wrote: post #23

Earlier quoted context omitted.

Well - if you mean that MongoDB has a CRUD-like API, and Meteor uses MongoDB, yes, but other than that I do not see the connection. Can you explain?

E.g., if you have a look at Meteor's documenation, especially the part on collections ( https://guide.meteor.com/collections.html ), it is all about the classical MongoDB-like functions to access data which perfectly represent CRUD. It also describes hooks on INSERT/UPDATE/DELETE ( https://guide.meteor.com/collections.html#hooks ). This pretty much shows how Meteor sees data: It's a "thing" that can be created, edite…

I'm not super familiar with DDD but I do like the ideas behind it - in some cases I think I am doing something similar to it.

However - isn't that essentially creating another layer on top of MongoDB? It looks like this could be implemented as a library for Meteor.

I'm only saying that to clarify that I do not think it's Meteor CRUD versus this. I think of Meteor more as a boilerplate than an application framework.

Post reply on HN