I 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 caused a lot of scalability and maintainability problems in production. Its "make reactive all the things" model also gave (less experienced) developers a huge gun to shoot themselves in the foot with, causing a lot of performance issues.
If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.
I'm a fan of RxDB. It makes a lot of sense to combine something like PouchDB with RxJS to create a reactive datastore. The only thing that bothers me a bit about it is the dependency on CouchDB (at least in case you want to have online sync). Not that I have anything against CouchDB (it's a great piece of technology IMO), but it's definitely not suited for all use cases and is in general a lot more restrictive/less powerful than a more general-purpose database like PostgreSQL.
yo this looks interesting. Thanks for posting it. Do you use it? Any thoughts on it and maybe how it compares to Firebase? We currently use firebase but are looking at a few other options.
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 RxJS subscriptions, and services to alter that data. It's been working really well for us so far.
Totally agreed, after I jumped through the hoops of learning RxJS I realized it can replace all the libraries you mentioned just because of the way RxJS worked. If you are interested, I created a small little Redux-clone based on Observables/RxJS as a fun project, but am using it in my side projects in production now: https://github.com/Dynalon/reactive-state
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 whenever a change is made to it. A component can then subscribe to that stream and filter it so it only gets an emitted value when the data it cares about changes. And because there's only one incoming and one outgoing stream it's very easy to debug and see what's going on in the app, making it very predictable and transparent. Also, like I said before: almost no boilerplate code at all!
Hi, do you know of any docs / blogs that describe how to build what you have built? it sounds amazing but I don't know where to begin. do you write to the data store with some key / value pair, and subscribe to data by the key so you get back what you want when it changes?
The official Redux documentation [0] mentions using RxJS with Redux. According to the docs they work great together but you might not need Redux with RxJS.
I haven't come across a project using only React and RxJS though. There is redux-observable [1] if you haven't seen yet that combines Redux and RxJS.
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.
You mentioned "gun" in the context of databases/realtime, so naturally I found it - although I was bummed it wasn't about gun (I'm the author of the popular https://github.com/amark/gun MIT licensed graph database) just the expression.
But since I now have you, you mention that "make reactive all the things" on the server caused newer developers pain? I've certainly had my fair share of developers initially being confused about reactive systems, but generally once they play with it, it "clicks" and they are mind-blown about the possibilities.
Would you mind sharing your experiences? So that way I can indirectly learn from your interactions and try to make things better, since I work on related systems.
Perhaps I misread, but I got the impression they were going from Meteor front and back to React + Python. All I'm saying is that if you'd done that you wouldn't have to throw out everything to get React.
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 need reactivity.
But it's also a server and build tool that has given our application:
- A stable upgrade path for almost 4 years where we could keep up with new ES features incrementally, with full backwards compatibility. In Javascript-framework land this is really unique. We've been able to keep adding features, expanding our product and building for our customers. While at the same time continuously update our codebase to the latest and greatest.
- By far the best easiest way to do code splitting (since 1.5) without any configuration or overlap in bundles. I don't know about any other tool that offers something similar. Webpack doesn't even come close in this area.
- Because they had node-fibers to get synchronous code from the start, now it's really easy to adopt to async/await.
- They have good integrations for React, Angular 1 & 2, Blaze and there are third-party integrations for Vue (haven't used that one myself)
- They're also the same people behind Apollo which people do seem to like for their data layer. And they announced Meteor will focus on full Apollo integration.
But yeah, their current data layer requires you to buy in to Mongo. And yes, there's no good separation of concerns in their data layer. And yes, the oplog tailing can't handle "facebook-scale" and I know you believe you need this. But picking this allowed our application (that needs a reactive data layer) to be delivered fast, gain customers and grow. Without Meteor, I'm pretty sure I would have ended up 2 years later with a nicer codebase and no customers.
TL;DR Have a look at their latest release (1.6), build a small application and chances are you might really like it.
We've been building an large, complex application on Meteor for the past year and most definitely agree with this assessment. We've also found Galaxy to be incredibly easy.
Your first 3 points are big deals but not unique anymore. The Vue webpack template comes with all that. Code splitting couldn't be easier, async/await out of the box and it stays backwards compatible up to IE9.
I'm sure React webpack templates have the same features but I don't have experience there.
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.
In my experience, I've found Galaxy not only to be expensive, but also lacking in support and stability. One way around this is to host your own Meteor applications on a VPS using a program like mup[0]
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.
We used Meteor for a long time as our primary stack at my current company. We just finalized the switch to React/Webpack + AWS Lambda/DynamoDB this week.
The main motivator was that Meteor's big sell — the "zero-latency" data sync — wasn't enough to outweigh the overhead of having to keep up with the constantly shifting landscape of which libraries were now deprecated, which were suddenly "anti-patterns", which were suddenly insecure...
That being said, I still prototype all new projects with Meteor. It's by far the fastest to go from 0 to 60, and it's extremely pleasant to ignore data transit and focus on the Big Ideas.
tldr; Prototype things in Meteor because it's a great platform. Your production stack may or may not need the same things your prototype stack needs.
So much hate for Meteor here, but I use it at work and it's been great for what we wanted.
I inherited a vendor-built website that was Craft CMS (a Yii framework) sitting atop a Laravel application that was integrated with Google Maps and indexed by Solr -- debugging even a minor issue could take days.
Meteor is fast and full-stack, no more knitting together 13 different frameworks. It's integrated with Apache Cordova, so you can easily port your website to mobile apps. It supports importing of node packages. Is Meteor the answer for everything? Of course not. But for a fast, data-driven app it's still great, IMHO.
The alternatives recommended in this thread so far are:
1. Firebase + React/Angular
2. Elixir/Phoenix + PostgreSQL's LISTEN/NOTIFY
3. Deepstream.io
4. Kotlin
5. .NET Core
6. Vue and Rails
If those things work for you, great, but I'm not sure they're 10x better than Meteor or that MDG is in some kind of death spiral -- it's still a viable solution for fast NodeJS apps.
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.
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.
I didn't use Mattermost, but probably the biggest advantage of Rocket.Chat is that it is totally free to use. On the other hand the UI is sometimes not as polished as other commercial solutions.
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 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.
> 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.
You can definitely do non real time stuff in meteor. The server can return data to the client just like a normal express server. Only when you create publications for a query do they auto update. That being said it is still obviously not meant for mostly static websites that are public facing.
You can turn it off with about 10-15 lines of code. It has been a while, but IIRC they just cache way too much data. Wrap their caching functions to forget the data when you know you don't need it.
Still, I wouldn't use Meteor for anything requiring scale. Besides, it's way too easy to introduce state on the server, but there shouldn't be state on the server.
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 required a shared state on the server (or in Redis or something) like in online games, chat, or any other online multiuser 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 in cert
Websockets is also probably overkill for most applications unless it really needs to update in near real-time (such as for a multiplayer game) and requires specialized server architecture. HTTP/2 with server-sent events is an interesting modern solution for applications that would have previously used long-polling.
I had steered clear of websockets a lot until recently. Turns out it's not a big deal. The API is easy in node. It's easy on the browser side too, and now widely supported. You only have to give up IE9 and Opera Mini.
Lol - 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
The team behind it released version 1.6 just a few days ago, so it is definitely still alive. I haven't used it since a few versions ago but I don't see we it wouldn't still solve the same use case as it did before: making it trivial to build real time collaborative web apps (that don't require extreme scale). With rethinkdb being an unsure bet and graphql not offering the same ease of development I am also not aware of a competing framework. Arguably meteor is getting better and better by integrating more with the broad node/Javascript community.
This sounds like a huge advertisment but I simply thoroughly enjoyed using meteor. If it fits your use case I'd say go for it. You can build the frontend in react and re-use it should you decide to move away from meteor. The amount of backend code you need to write to make all the realtime stuff work is significantly less than with other frameworks, so not much in terms of sunk cost there.
From my experience (a.k.a tried and failed..), I'd rather take a bit more time to glue a few amazing open-source tools together than to use an "all-in-one" framework that will screw me down the road.
Over the years, I've built the equivalent of those real-time systems using postgres, redis, rabbitmq and node that can scale horizontally. It's obviously longer than using firebase, but at least I know what's going on under the hood, I can easily optimize and debug it, I can add any missing features or switch any tools (I.e. can easily switch off postgres to something else if I needed it).
It's for the same reasons that I use React on the front-end. It's great for the view layer, but I still get to pick and use great libraries for the rest of the app (in-memory database, state management, routing, etc etc.) I can easily switch off React to something else because the surface API that I'm using is extremely small.
I would still use meteor or any of the competitors for a hackathon or prototype, but never for a long-term project. YMMV
I've used Meteor a lot over the last 4 years. Recently I had to start a new project and I wanted to move away from Meteor because clearly it has less traction lately.
I've considered a lot of things, but I couldn't find a setup as simple as Meteor with database integration. I ended up going back to Meteor and I'm very happy with it.
The tooling keeps getting better (recent 1.6 release), server-side rendering is almost there (already possible but no clear best practices yet), and scaling seems like it will be getting better soon (MongoDB upade + a path toward GraphQL with Apollo).
I had my doubts but I'm back on board. I recommend every JS developer give Meteor a good look.
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 when compared to Meteor.
The problem today is that Meteor is not a component that you can't easily plug and play like Angular, React, Express, etc. Example: You would like provided a real-time widget on another website? Open an iframe and load the entire application and waste more than 300 megabytes on the browser. Or use a non-official package and hack the shit out of it.
MDG (Company who developed and maintains Meteor) went too greedy. In order to use Meteor you have to be fully committed to the stack. Although the project is open source, you will waste several hours trying to modify Meteor to be make it more modular. Event today if you want to use the DDP protocol outside of Meteor, you've to use 3rd party non official packages. Meteor was great in the beginning but failed to play nicely with the rest of the JS ecosystem even although some work was done in that direction. Arunoda played a HUGE role by building and writing a lot.
As a prototype tool Meteor is excellent, it's very hard to find a framework/tool that provides what Meteor provides. Building a real-time application with modular components isn't trivial, Meteor just offers a lot for free: LiveQuery, Authentication, Server-Client shared code, Consistent API, client side implementation of MongoDB (minimongo), painless build system, easy deployment, etc. You can build a prototype in record time.
Play with Meteor, you won't regret it. Scaling applications is always hard, requires in depth knowledge and time. Meteor is websocket based, there is not need to compare with an HTTP based API since it is unfair. Scaling a real-time application is hard on any language/framework. For most projects FireBase will do the trick if you've a small number of real-time components.
My advice: Pick the right tool for the right job. Most of the complains typically come from project that are not a decent match for real-time applications. I worked on many project because someone decided to use Meteor regardless of their technical knowledge to decide so.
With Meteor, I wanted legos but they provided an assembled fortress. It just didn't work out for me. I'm not saying that my situation is everyone else's, but the lack of flexibility led to me to turn away from it.
I have, at a high level, looked at the Apollo project and I think they are beginning to become more modular. So the direction is good, but it no longer has the selling points that it once had: it's no a longer a one-size-fits-all solution.
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 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.
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.
I’ve read through your pdf docs explaining wolkenkits approach to CQRS.
I think most of the value you’re describing through correctly modeling behavior to language is only important at the level with which most teams deal with data—and this isn’t necessarily the DB level. Just like our brain may use (relatively crude) bio mechanical processes to encode & recall information, yet at a higher level of abstraction relies on the flexibility of natural language, to codify and transmit meaning between idea storage systems (people), I think a similar process is at place with programming. Let the low level stuff stay low level and optimize for performance/throughout and not meaning, then in the higher order aspects of code make sure the abstractions that are most used by teams map data to constructs which humans use to communicate meaning.
I think this approach can be found in any framework, including meteor through effective abstractions, as nearly all frameworks give you the necessary mechanisms to map data. I think the issue with ineffective language systems is mostly the same reason people hate poetry. Most people have a difficult time adequately mapping ideas to language, because it is extremely difficult to do it correctly to the satisfaction of others.
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.
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.
I've been working on Meteor apps for a few years now, and my TLDR answer for you is, no, don't use it.
The releases since 1.3 have definitely pushed it in the right direction:
* NPM instead of atmosphere
* React/Vue/whatever instead of Blaze
* ES Modules (import/export syntax) in place of global variables everywhere and a dependency loading system that i-shit-you-not came down to loading things in alphabetical order
* ESNext support
* Getting Node and NPM up to current LTS versions
Next stop on their roadmap is integrating Apollo, at which point it'll basically be a turnkey system for building React/Vue apps on top of GraphQL. Most of what originally made Meteor what it was will have been removed in place of sensible best practices that everybody else in the JS world has since moved on to.
But for me the sticking point is that Meteor is built on a couple of assumptions that, in my humble opinion, are fundamentally incorrect.
1. Focusing on writing code that runs on both the server and the client is a useful idea.
2. MiniMongo is a sensible way to handle the data layer and reactivity everywhere is helpful.
I personally reckon these are both crappy ideas, and combined with the "magic" parts of the framework, they encourage people who are new to full stack JS to develop bad habits and skip learning some of the real fundamentals that every developer should know in relation to security, performance and scalability.
Yes! The company I work for uses it for most of its user facing apps.
No matter what poeple say about Meteor, the fact remains that having the ability to live push data to the frontend, and share code between client and server, with absolutely no extra work is supper appealing.
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 tried to follow it over the course of a year, I could never get it to work properly.
On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure.
I say this as someone who has used Meteor for multiple projects and used to love it!
"Testing is still a third-class citizen" The exact reason meteor is disqualified for me. Even the basic manual is broken and wrong in some ways. Internet searches point to frameworks which are broken or obselete and to the meteor testing site (If I recall correctly even docs point to it) which has a notification for a long time about being "rewritten" and no actual content (and would be a paid book .. :( )
If testing is a third class citizen then No real professional software development can take place with it. A real deal breaker
If 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.
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 logic, and will do mostly network programming, try Go. If you are doing something enterprise-y, use Kotlin or (IMHO even better) .NET Core. If you want to like writing code, try Elixir with (on?) Phoenix (or Django/Rails depending on your love affair with Python/Ruby).
I would say yes. I used it for over 10 projects over the years and haven't found something more compelling in the JS ecosystem in terms of speed, database integration, easy of use. Reactivity should be off by default, that's right. Last thing I build has a React front (it's a text editor for medium-long form writing) and I'm super happy with the data layer on Meteor.
As a product designer and entrepreneur, Meteor is still absolutely a thing. The products I've built simply wouldn't exist without the massive (development) speed boost it gave me. I'm well aware of its problems and faults, but I love it for the amount of work I don't have to do.
Do not touch this platform. it caused us so much problems and didnt seem to solve any real issue. each new project we start without it is a bliss.
you dont need it and the voodoo bugs it will create.
you can just use react+node js.
works great together and will be lot easier to solve platform issues when they come
I missed the opportunity to use meteor, but these days the big appeal of meteor (minus one opininated framework) is that I can get the same experience with VueJS/React and Feathersjs
For some time, I was amazed by Meteor.js developer-friendy approach and it's "magic" stuff. But after some time I've found that I had to do many hacks to achieve something and gave Express.js a shot - it was a purification experience for me - You have more control what framework do out of the box and You can avoid using hacks easily.
Late to the party here, but could you comment on your experience with Meteor-Vue? I just ported an app from Viewmodel back to traditional blaze, but really want to rebuild the frontend in Vue for performance.
What do you use for forms and other items that have packages in the blaze ecosystem?
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 ?
- 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.
It 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.
About the first part of the question, Meteor is still a thing for several reasons:
* 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:
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.
I've had great success with Meteor. I started with v1.2, and it was quite painful to develop in. However, with improvements start within 1.3 and onward, every release has gotten better. Meteor 1.6 has the same concepts as Meteor 1.0, however it is extremely different and is up to date with standards of the Node/JS ecosystem.
I think it's important to know it's application and use-case. I use it for a hybrid iOS/Android app, and Meteor + Cordova has been fantastic in terms of developer productivity for a small/medium-sized app. As a startup, I wouldn't consider anything else right now for new projects. React Native has a higher learning overhead, and with other architectures you always have to deal with user registration & authentication, something Meteor supplies out of the box.
In terms of performance, it is important to understand the core concepts of Meteor. This is not easy. The reactivity layer and publish concepts make it extremely easy to overpublish data, reckoning your Meteor app completely useless. Afaik, something like Kadira is required for Meteor apps, as it will quickly tell you when something is wrong. If a Meteor app is correctly designed, it should rarely have performance issues.
I've wanted to integrate Redux into my Meteor app, however there are a lot of moving parts getting both working together, so I'm opting for smaller container components. React performance is tricky in any case, and Meteor + React is no exception. This combo makes it a bit difficult to diagnose performance issues on the rendering layer. I would love to migrate to VueJS, however the it would require a complete re-write, just as I'm getting comfy with React. I would highly recommend VueJS + Meteor + Vuex over Meteor + React for new projects, so you don't deal with diagnosing rendering performance problems with Meteor's reactivity layer.
You can definitely run your own React stack that is decoupled. For a larger app, I would recommend going this route, due to the big build system of Meteor. Once your app gets a bit too large, the builds still take forever. You can offset it by using something like React Storybook with hot module reloads, but if you have a high number of users or a requirement to not use Mongo, you are better moving the other way. Meteor Development Group is moving out of the built-in reactivity layer that it is known for, and into GraphQL. I'm not planning to move to this new architecture anytime soon, and will run with Meteor's reactivity layer for the foreseeable future. I'm concerned once the reactivity layer loses focus and development, that Meteor may start to fade away. GraphQL has a high learning overhead IMO and presents it's own sets of issues. Perhaps those will be worked out over time.
My 2c. Without Meteor I wouldn't have a real-time web app as nice as I do now with both iOS and Android builds, up and running as quickly and easily as I have. It's been a godsend.
I've switched to https://deepstream.io for my projects. It's just the realtime aspect of meteor, but in an entirely different league when it comes to performance
Looking at troika's submissions, there's one "Show HN" about Deepstream so yeah, definitely involved in the project. Don't understand why one would say "I've switched to" for an application they've created or contributed to, especially if there's proof in your history that you have marbles in the game.
If you want to keep all the reactivity goodness from Meteor I'd suggest taking a look at Firebase. Their new Cloud Firestore is very impressive and basically gives you all the features Meteor offers when you combined with a front-end framework like react or angular. Or you could take a more low-level approach and use something like Elixir/Phoenix and PostgreSQL's LISTEN/NOTIFY to create your own reactive push streams, and subscribe to them in the front-end using a reactive library like RxJS.