I have been doing Meteor development for a few years now, and I must say that the framework itself has really made my life a lot easier. It has significantly reduced idea to proof-of-concept turnaround times and has really been great for running apps in production such as Subcast. Over the years I am also happy to say that Meteor’s Cordova support has gotten much more stable and makes porting your web application over to mobile a breeze in many cases.
However, many times you need more and more control over which assets get loaded on which platform. For example, if you’re loading your application on a mobile device, you don’t want to cram your 6k lines of CSS into the tiny amount of memory space, and on your mobile experience, you want to be able to speed up the rendering pipeline by using CSS 3D transforms and by creating a native look and feel in the UI. How do we segment this out without wrapping everything in a bunch of isCordova() checks?
Enter: Meteor Mobile Desktop
I created a package called Meteor Mobile Desktop to solve this very issue. Using packages, you’re able to target specific platforms (web or mobile devices) for specific files. This also has the advantage of declaring which code you want shared between the two. Typically I organize things into a few different packages:
The MyApp-base package is for shared code and core business logic. This package targets both platforms. The MyApp-desktop package targets the desktop and contains only the specific UI elements and layouts for the desktop experience. These CSS files tend to be more heavy, so this saves us a bunch of time when loading assets on mobile. The mobile assets themselves are contained in the MyApp-mobile package. Each one of these packages has client/ server/ and both/ directories to control which assets are shared between the client, server or both (obviously?). This is helpful for having further control over where your assets go.
As you can see, Meteor is quite flexible in how you’re able to arrange things. This layout does have a drawback, however, since you have to explicitly define every asset you wish to share and where you wish to load it inside of the package.json file. However, it is a small price to pay for the level of control you get over how your assets are loaded.
Need help with a Meteor project?
I do Meteor work full time (among many other technologies), so feel free to drop me a line if you have any questions or need any help on your project or idea!