I probably should say why I keep coming back to the good ol’ Meteor. The meteor platform as a whole has been a really useful bag of tools for me. Tools which are simple and complete. Despite this, some time ago I decided that I needed to find something else because Meteor wasn’t as flexible as I wanted it to be. Then I realized that in small or medium apps, in most cases, I need a standard and simple configuration. I realized that I still keep coming back to Meteor because it is simple and it gives me what I need in most of apps I work on. Of course I’m aware of all the potential problems in big apps, but I realized that this isn’t my problem generally.
In this post, I want to list all of my insights learned from experience with the Meteor platform up to this day. Of course this is just my opinion, you might have different ones, and I encourage you to tell me about them in comments. Ok, let’s dive in!
What will we be talking about here?
- What do we need in most small and medium apps?
- Blaze templating language — little bastard!
- What if we don’t know whether the app which we’re writing will be big in the future?
- Should we use Meteor in big apps?
First of all, let’s see what we need in most small and medium apps.
Let’s set aside the coding part for a moment. I want to start to talk about Meteor as a whole platform and workflow path, not only a coding framework.
Every app needs a boilerplate or some starting point. We don’t want to start everything from scratch each time. The next thing is that we need some kind of build system. We want to manage our assets and styles. We want to use preprocessors and so on. If you want to do that by yourself, you need to find couple of tools and bind them together or you need to find a ready to use boilerplate. Of course you can do that, but then, which one is the best? Which one will be maintained in the future? What if 50% of the boilerplate is not what we need? Also remember about all the backend stuff. Database, security stuff, and of course accounts. You need to configure it all.
What I want to show in this paragraph is that even when you have many options, the final result is usually that you use something like Gulp, Webpack and a preprocessor for css + backend framework, which you need to configure properly. Of course keep in mind that I write only about standard, small and medium apps, which we all code in most cases. In most cases, but not always!
The workflow, build system, database, etc. is what you need to manage at the beginning, but the production hosting simplicity and possibilities is also something very important. Let’s think about PHP language. Why it is so popular? I bet not only because it’s good. I guess it’s also because there are many hosting options. Despite this, even with PHP it isn’t that simple to manage deployment of your app. That’s always something which is a pain in the ass for me. I don’t like to manage that part of the apps life cycle.
So, all Meteor developers will probably know where I’m going here. What I want to say here is that the Meteor platform gives it all to you at the beginning without any configuration. You can generate a simple app or one with full folders structure. You can do it with one command. You get a preprocessors compilation without configuration, just add the package. You can use a very simple templates engine or you can use Angular or React and even Vue. You get MongoDB database and the whole API to secure your app. You also get awesome accounts packages. Then you can host your app on Galaxy, which is as simple as generating a Meteor app. Even if you don’t want to use Galaxy, you can host your Meteor app using DigitalOcean or other solutions like meteor-now.
Of course that build system is basic, and you can’t do much with it (Actually I don’t like it and I’ve written about it in many places). Of course Galaxy is quite expensive for small apps, but you can find other options. And of course React integration isn’t as natural as using React with Webpack. Oh, and you need to use only MongoDB (in basic Meteor). But hey! It all works well for small and medium apps, and it saves you a ton of time.
To sum it up. When I want to build a small or medium app I go with Meteor and maybe React on the front-end. I’ll start very fast. I’ll be able to host my app on DigitalOcean using Mup or I could host it on Galaxy, which is even simpler. I can deploy it with one command in all cases. I’ll get the whole backend for free without additional work, so I think it’s really good.
Blaze templating — you can love it or hate it, no option in between!
Yes, I know there is an option in between, but I wrote this because there were so many fights about the topic lately. In fact, I don’t know why. Blaze is for something else and other view layers are for something else. In my opinion, Blaze is awesome when you need to write a useful app really fast and don’t care about performance, but at the same time it could be a really painful option when you need to build a performant and very big app.
There are times when you don’t need a performance boost in your app. You just want to write really cool, useful tool where performance isn’t that important. Or maybe you need to mock something fast or prepare your private website with some cool features like accounts and simple server side logic. I can’t imagine a faster and simpler way than to use Meteor and Blaze in that case.
Why do I need React if this is just a simple app anyway?
Many times I’ve had the feeling that I need to start with React because later I could have problems and as you probably guessed already I never had any because my apps are still small. Some of my small apps are written in React and I still wonder why.
So, why do I still like to get back to the Blaze templating language? Because it’s really readable and simple. Of course it is also really tricky. You need to be careful with it. I’m happy that it is excluded from the Meteor core nowadays and it now has its own repository and community behind it. I’m sure that it will be still used in many apps.
Ok, but let’s assume that you can predict that your app will be big in the future and you know that Blaze isn’t an option for you. You could use some custom Node framework and configure Webpack with React, but you could also still use Meteor with React. Let’s see what options we have.
My app is big and I need it to be blazing fast without Blaze!
If you are Meteor developer you probably know what has changed in the last couple of months. You probably know that you can use React with Meteor and integration is really simple. React in big apps is a very good choice because it is optimized and designed to be used in big projects when data flow is really extensive. You can still use real time updates with it. That kind of stack could be used in big apps without problems. Of course you need to optimize other parts of the framework, which shouldn’t be so complicated. There is a great guide. Of course keep in mind that the view layer isn’t the only thing which you can switch to optimize your app.
If your app is really big and complicated, it’s time to think about architecture which is really strong in that context. For that, the Apollo stack is here to help, which is a set of tools integrating GraphQL in your app. What it gives you is separation and control over your data flow. Your real time updates etc. But it also allows you to use other databases and many different data sources with simplicity, readability and single language queries, keeping it performant.
I don’t want to write about Apollo and GraphQL here because that’s a topic for another blog post and there are plenty articles about it. I just want to talk about my experiences and my hopes regarding the Meteor platform. I really like where it’s going. This clearly shows that the Meteor Development Group knows what they need to do. They see that the environment is changing rapidly and they need to adjust. That’s why we get a platform for very simple apps which you can use without knowing much about programming and also at the same time we get a really powerful platform for very big enterprise apps with the whole backend and development support. That’s really promising.
Should we use Meteor in big apps?
I think the answer to this question is now quite obvious. We can use Meteor for big apps.
For me, just a couple of months ago, it wasn’t that obvious. I had very hard times with Meteor. But now when I see apps which uses Apollo, GraphQL, many databases and how it is all connected with Meteor as a simple build system and glue which unites it all, I have good feelings about it.
There is ongoing work in separated teams in MDG. Apollo is better and better, Meteor core is getting more decoupled. There are some rumors (Transmission podcast) that build system in Meteor will be much better soon and maybe there will be some solutions which aren’t available in other stacks. Meteor 1.5 should bring code splitting and build system performance improvements!
What I would like to see is Meteor as a very flexible and still simple backend with very good documentation about how to integrate Apollo, other data sources and how to extend build system to be able to integrate all front-end tools and view layers available nowadays. The same tools which we can use with Webpack through loaders.
Let me know what you think. Let me know how much experience you have with old and new Meteor. Let me know what you think about the future of the Meteor platform. Thanks!
Have a cool project in mind? -> psd2Meteor — Meteor apps development!
Originally published at julian.io on February 13, 2017.
