Making Your App 'Update Proof'

1

I very well know that Meteor is in it’s early stages and I’m just wondering what I should keep in mind when I come to develop my own web app?

For example is there a chance I could create a web app with Meteor and then in the future when I upgrade the Meteor version it could break various parts?

I’d just like to know if anyone has had any problems building apps on older versions and then having a problem in the future?

Thanks, Nick

2

Hey so right now this is a real issue - it’s not clear which parts of Meteor are part of the “future”, and which are from the past. (for example, I’d say allow/deny is on its way out)

To that end, we’re working on a pretty big project, the Meteor Guide: https://github.com/meteor/guide

The idea is, if you build you app according to those recommendations, we’ll take extra care to make sure you’re happy with new versions of Meteor. You can see what we’re thinking about right now by browsing the outlines in the outlines/ directory of the repo and reading the issue threads.

I know that doesn’t help you at the moment, so as a core developer I can say that we have historically taken great care to maintain backwards compatibility and easy transitions as much as possible with new versions of Meteor. It’s bad for everyone if current users can’t easily transition to new stuff, since we don’t want to maintain old versions if we can help it.

2 Likes
3

In general be careful with using external packages, most issues are there. This topic has some good posts on it:

4

Overall, I’m happy with Meteor 1.2, I think there is enough there to build a great application! But I know there’s changes coming with 1.3 and 2.0…

From what I’ve been able to gather, the coming versions are focusing on NPM, webpack and es6 module integrations, and that can have big implications for the front-end and back-end.

Sashko, can you share any details on this? Some of the Slack channels have turned into rumor mills as we try to understand what will happen and when, and some kind of update would be much appreciated :smile:

Plus, maybe we can contribute something as we have the experience of being Meteor users and think about it quite often :slight_smile:

5

I think these new technologies bring really obvious improvements to the platform. While Meteor 1.2 is certainly enough to build a wide range of applications, there is some big low-hanging fruit:

  1. Real client/server NPM so that you don’t have to use sketchy re-published wrapper packages, potentially buggy webpack/browserify packages
  2. The above goes hand-in-hand with module support, which will save you from having to build any serious modular app as a giant folder of packages, and will make for easier code isolation for testing and reuse across different apps and even across other JS frameworks
  3. Once we have the above we can more easily integrate technologies like Webpack to do code splitting, faster hot reload, and more!

I don’t think the implications here will be as big as people are saying. If you’re writing your app according to what I understand to be the best practices, you’re doing the above already, but with hacky workarounds where Meteor doesn’t really help you. All of the developments are really just making it easier to do things most developers should already be doing!

(1) and (2) are encompassed by Ben’s PR: https://github.com/meteor/meteor/pull/5475

(3) is not currently in active development and probably won’t be in 1.3, but might come later as part of a bigger tool overhaul enabled by module support.

1 Like