How is that statement not true? It's how the web works, even if you have "real time apps" using websockets, by the time the data reaches you it could already be stale technically. So even if you have perfect caching you will still have this problem. As far as I know there isn't a 100% perfect solution to this, although good caching comes close.
Developer advocate, full-stack engineer, startup co-founder & CTO, bringing 15 years of experience in Silicon Valley, including at Google and Yahoo!. Public speaker.
Location
🌐
Education
UC Santa Cruz Extension
Work
Developer Advocate at Weaviate, the open-source semantic search engine
Sure, that's technically true, but for the vast majority of practical intents and purposes, Meteor solves that sync problem and you don't have to write any code. There's certainly value in not reinventing a wheel that's very hard to get round, and a wide perspective of the problem would include full-stack frameworks even if they only offer a 99% solution to this.
Meteor offers more than just caching, including optimistic updates and real-time sync between all connected clients.
I personally haven't used Meteor but if it handles caching well, then I think I'd be in favor of using it.
I realize the title of this article kind of entices a technology flame war but that's not what my point is. It's that managing backend state yourself on the frontend, in the majority of cases, is probably not the best approach. Any technology that handles frontend caching/fetching/invalidation/mutations well is a good way forward.
Developer advocate, full-stack engineer, startup co-founder & CTO, bringing 15 years of experience in Silicon Valley, including at Google and Yahoo!. Public speaker.
Location
🌐
Education
UC Santa Cruz Extension
Work
Developer Advocate at Weaviate, the open-source semantic search engine
Any technology that handles frontend caching/fetching/invalidation/mutations well is a good way forward.
Well put. One of those technologies is React Query, another is Apollo Client, and I bet that if you had read about Meteor, you would've included it too.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
How is that statement not true? It's how the web works, even if you have "real time apps" using websockets, by the time the data reaches you it could already be stale technically. So even if you have perfect caching you will still have this problem. As far as I know there isn't a 100% perfect solution to this, although good caching comes close.
Sure, that's technically true, but for the vast majority of practical intents and purposes, Meteor solves that sync problem and you don't have to write any code. There's certainly value in not reinventing a wheel that's very hard to get round, and a wide perspective of the problem would include full-stack frameworks even if they only offer a 99% solution to this.
Meteor offers more than just caching, including optimistic updates and real-time sync between all connected clients.
I personally haven't used Meteor but if it handles caching well, then I think I'd be in favor of using it.
I realize the title of this article kind of entices a technology flame war but that's not what my point is. It's that managing backend state yourself on the frontend, in the majority of cases, is probably not the best approach. Any technology that handles frontend caching/fetching/invalidation/mutations well is a good way forward.
Well put. One of those technologies is React Query, another is Apollo Client, and I bet that if you had read about Meteor, you would've included it too.