My Journey with Meteor and Dynamic Imports
The new Meteor release had finally pushed me out of my comfort zone. For the longest time, I’ve lived in the world of “classic” Meteor — with absolutely no interest in what the world of ES6 and NPM could offer. However, the new dynamic import feature was seductive enough to lure me in.
For the longest time, I wanted to build an admin “toy” for Meteor, but I knew it wouldn’t get a strong response. Everyone’s app bundle was large enough as-is, and I noticed not many were comfortable throwing something else in there.
This is where dynamic imports changed the game. The package could be on the client without being on the client. When it hit development, I knew the time had come to make Meteor Candy. I kept the initial version as light as possible, as I knew the real magic would come once it’s working on demand.
Once the feature was production ready, I felt quite uncomfortable with this mysterious functionality, but in a couple of hours, I had it all working on demand. I’m not sure if that’s a testament to me or Meteor, but either way, I am very excited by what I saw.
After seeing this in action, I’m going to make three claims:
- dynamic imports can have a huge impact on the success of your app
- dynamic imports require us to re-think how we build apps
- running internal tools as importable packages makes more sense than as microservices
Benefit #1: You Can Hide the Weight
I usually try to avoid to junk food. But winters are cold and boring, and you can hide the weight, so sometimes, I indulge. Thanks to dynamic imports, though, one can hide the extra weight all year round.
At last, we can stop being embarrassed of including fat libraries just to to display a timestamp. We can say, let’s load the app first, then we’ll sneak this in there. You know, like one of the hidden ingredients they put into our food.
For internal features, we can enjoy the simplicity of having them available in-app, which let’s us leverage the current user session and permission system, and save us money on hosting, with no trade-offs.
I’m especially excited by the possibly of having protected imports, so that we can protect special features and functionality, and not have to think about someone else mis-using it.
Benefit #2: Multiple Clients, at last!
While researching the functionality, I noticed a “humbly documented” feature: you can dynamically import entire packages!
To me, this means that your client can now just be a splash screen. Once it loads up, it can detect the device/browser and import the appropriate packages.
Considering how long web apps take to load these days, especially on mobile, being able to quickly put up a loading bar could be huge for decreasing bounces and thus increasing revenues.
And best of all, module caching is built into Meteor, so even on something like Cordova, we get the fast local experience and automatic app updates.
Benefit #3: New Considerations for App Development
One of the things I hate about Slack is how much time it takes to load the every time I launch it. I’m convinced this is dragging down their engagement. With the right design, however, they would be able to load the chat stream first, and then the sidebar, and then all the other things.
And so, with imports not only do we have better control of how our app’s code runs, but also how we display it to end users.
This kind of thinking could be even bigger for mobile, as a huge amount of people can only connect to 2G/3G speeds or slow wi-if networks. So, for example, if someone visits your website for a blog post, it would be nice to show the content first, and then load all the bells and whistles.
This case becomes even stronger once SSR arrives to Meteor.
Dynamic imports are a great example of a feature that is small yet huge. Not only does it help you reduce the size of your client, but it also lets you make it bigger and faster. But perhaps most interestingly, it presents us with a new way to look at how we make apps.
It’s incredibly easy to use the feature, and it goes great with Meteor’s reactive style of programming. I thought about writing a quick tutorial, but I think this demo repo will explain it much better.