4 strategies to survive Meteor in 2016
From reading the Meteor forums, things are not looking very good in the land of Meteor.
Some people wonder, if you take out Blaze and the Meteor data layer, what’s left of Meteor?
Here are a few strategies to help you navigate Meteor in 2016.
1. Understand the technologies and issues
Nobody likes uncertainty, people prefer to know exactly what they are dealing with.
If you tell me to jump off one side of a cliff before I can see the other side, I will be reluctant.
More Modular Meteor and NPM
The first issue is that Meteor is moving from a closed ecosystem, towards an open ecosystem. They are embracing NPM ecosystem and soon there may be no reason to write a ‘meteor package’.
Meteor is moving from becoming a framework, to a somewhat-curated collection of libraries that you can use in your apps… or not. But we all know that frameworks are evil and libraries are good, right?
Blaze to React
Then there’s confusion about React, because React was somehow chosen to be the successor to Blaze 1. It’s unclear how MDG will suggest to manage this tricky transition when the time comes (maybe some kind of similar-looking templates and a compatibility layer that makes the transition as palatable as possible). But in reality you should be able to use Blaze alongside React (if you choose to) for the foreseeable future.
Remember, Meteor now is just NPM, so you can import any module, you could import Vue.js if you wanted.
Flux, Redux, Relay, Help!
But a big part of the frustration with React is that the React world is just as chaotic as the Meteor world. So people wonder, how am I supposed to write a complete app with React, should I use Flux, should I use Redux, or Alt, or something else? Should I use class syntax and higher order components, or object syntax and mixins? And should I use flow-router or react-router?
Fortunately none of these decisions are life-or-death. If you choose to use React now, start with the technology that looks and feels best, that makes the most sense to you, and don’t worry about picking “the right one”, because there is no “right one”.
Another point of confusion is that React promotes “one-way data flow” while Meteor had it’s own philosophy that I would call “magical reactivity”. The Tracker library basically intercepts methods that have reactive data inside and automatically re-runs them when new data is available. This pattern results in a pattern known as “sideways data loading” in the React world. Neither approach is better or worse, right or wrong, but it’s good to understand the differences.
What about GraphQL and Pub/Sub?
Then there’s the other side of the Meteor equation, the data layer. Many people love pub/sub (aka Livequery/Livedata), while others have found it doesn’t scale very well when you have a lot of users. Maybe GraphQL comes to the rescue, but that means another part of your app you have to replace. And this one is even trickier to replace than the view layer.
Kadira has developed some libraries that allows you to use GraphQL today, with your Meteor server, with MongoDB. This is a big win for the Meteor community, but the question remains, should I start using this? Should I stick with “Meteor-approved” data layer? Can I use them both side-by-side (I think the answer is probably yes).
2. Gradual refactoring
So if everything is still changing so fast, the best advice is:
Don’t jump on any bandwagon too fast. None of the technology choices mentioned above are life and death choices
The reality of being a developer is that it’s kind of like working on a spaceship while you’re traveling through space. You never want to break anything too badly in a way that leaves you stranded out in space! I wish it wasn’t that way, but that’s the harsh truth.
Thankfully, Meteor is making efforts to maintain backward compatibility. Hopefully they will provide better guidance in the future on how to evolve your app. (At least they didn’t try to shove a 2.0 version down your throat without asking, like other frameworks)
So what is a good way to develop your app? Gradual refactoring! This is why we all love unit tests (and why we keep them up to date, always, right?). Unit tests aren’t a silver bullet either. The truth is I don’t find writing tests very valuable, so I gave up on it. The alternative I use is to write my code so it fails fast. Then I know if my page loads, it’s working pretty ok.
The biggest problem about refactoring is the fear of refactoring.
Get in the habit of refactoring your code, get some automated testing solution and CI server so that you know if anything breaks too badly you will find out soon.
3. Work out a strategy* for developing your app
Having a plan and strategy never hurts. *I realize this section is recursive, hope your brain can handle it!
Maybe you need to think about how your app will evolve in the future. Are you seeing any potential bottlenecks in performance?
Keep in mind premature optimization is the root of all evil.
Also don’t worry about getting everything (like your API) completely right. I wasted a lot of time doing this, and in the end, I need to refactor things anyway.
There are some changes that will be easier to make, while some changes are very difficult to make. Changing your database on a production app is a big hassle, or even changing your data schema. So pick that wisely. Other changes like swapping out one router library for another can be made without much pain.
Make your life easier by keeping similar code together and DRY, so you only have to make a change in one place instead of 100 different places.
Remember that the whole idea of components and libraries is to keep things as modular and isolated as possible, so it is hopefully easy to modify and upgrade.
If you’re still not relaxed, I have another joke for you.
But seriously, the best way to ensure you are not making too many stupid mistakes, is to take a deep breath and maintain your cool.
Happy coding in 2016!