Contemplating the future of Meteor.js
I have been a huge fan of Meteor.js and the thinking behind the framework for the past couple of years. From the first time I hacked up a small todo's application over a weekend to building a large scale web application like ClassMate.io, I have really appreciated the work and science put into the Meteor.js platform. Meteor has just made building applications easier.
Like most things, if it is too good to be true, it is. It just is. Since pre-1.0, Meteor has gone through large changes that have affected really the core of the people that have picked it up and built with it. And with the community working to fill the gaps some rather uninteresting changes in best practices have left some of us shrugging. In fact, the change has been so drastic that we are reconsidering the tools and style of how we develop with Meteor every few minor releases.
So what is coming? After attending Meteor Camp, most of the industry professionals are saying to consider avoiding the use of Meteor for major projects. Most of the speakers' presentations were geared towards arming you with different options to consider.
Critisim Meteor Faces
Real time all the time?
Now that real-time application development has been made so readily available to us we have had the opportunity to spin up some products with it. While real time has sparked the product imagination, the costs associated with powering those features just have not made enough sense. Developers and even some of their clients have said:
You know, it can update once a minute if it has to... I can even refresh the page it's no big deal.
Scale
A blog post on Arunoda really explained this best in Why meteor needs a new data layer in 2015. In a nutshell, it is the live query mechanism that is both costly and challenging to scale applications with.
But if you are having a hard time scaling your product congratulations on building a product people want to use.
Tightly coupled
The data layer is tightly coupled. If you want to use Meteor you are either using MongoDB or rolling your own driver. Additionally, the Galaxy hosting service may not accommodate your custom driver forcing you to adopt MongoDB.
Wishy washy libraries and best practices
This really only affects those that have been building with Meteor back before 1.0 dropped. During that time we went from a UI library Blaze and Spacebars to Blaze, React or Angular. A router library, Iron Router, was later routed ( ha ) by Flow-Router and now the author of flow router is saying to use React Router.
The truth is, if you are not using React for your UI Flow Router is still likely the best choice.
It is sometimes hard to swallow this type of change while we are trying to make the best decisions possible. But this is also a side effect of a platform that is working to accommodate the Javascript developer. It is fair to say that it has not only been Meteor that has been facing these challenges, even projects like Angular have undergone major changes. So many new ideas around how we build with Javascript have created new opportunities and practices that developers and product teams alike are drawn to.
This constant evolution puts projects like Meteor at risk. Since early release, the Meteor project has said to do so much, and while doing so much requires much more change to stay relevant. It also leaves little room to experiment with proposed solutions before committing to them.
In contrast, consider the Shasta project as an example of a modular stack solution that allows layers to be swapped out.
What is going on now
The MDG is hard at work focusing on developing their new data layer project Apollo. The team has to pull through this data layer development and fix the challenges they face with the live query architecture. This also means that those developing with Meteor will be optionally but encouraged to change how they build with Meteor once again. This time, it will be instrumenting a new data layer.
Should I consider Meteor for my next project?
As of 07/25/2016... maybe.
Ramblings of when Meteor.js might be appropriate
- If you have an idea that you can shrink down into a week or two of work. The Meteor platform is changing and creating extra work to get our applications right. At least while Apollo being developed and live query is in the state it is, keep your projects as small as possible.
- As a platform for you to experiment with some javascript tool or library. Personally, I dislike having to deal with the boilerplate required to get up and running with a modern JS stack. With Meteor I can quickly spin up a project, npm install some stuff and start hacking on it.
- Internal software. I sat in on a great talk on how a developer had been building internal tools and software using Meteor. Internal software really only needs to scale to a few thousand concurrent users.
- Embedded software or IoT. IoT is all about the real time stuff going on around you. Sending alerts when your plants need watering, lighting an LED when you have a new email. With the protocols and stack decisions baked into the platform, it leaves us with an interesting opportunity to simplify how we connect things.
The future
As for myself, I plan to continue to use and work with Meteor on ClassMate.io. I will also continue to use Meteor for small experiments, but I will consider other solutions for future projects.
If the MDG can solve for the known challenges with their current data science, which appears to be in the works, then pull that new work into the Meteor platform then I think we will really have something on our hands. Meteor seems "too big to fail", so the rest of this year may be very interesting for the platform.