It’s definitely an awkward time to jump into a new app, no doubt.
However, if you look at the landscape in the next 6 months you can optimize for that. Here’s my recommendations:
Use React
React isn’t the ‘best’ framework but it has a huge mindshare and community to pool from. The next Blaze 2 will have a thin facade over React to put templates in separate files.
If you prefer Blaze 2, then you’re still going to have to learn React if you want to debug it. You might as well just dive in now. Remember, you can always move the JSX out later if you still dislike it. (I’ve found that once you use React you’ll break it down into so many small pieces that having 2 files for every piece is a major pain).
React makes you think different. Way different. It follows the functional paradigm and helps you organize your code for the better (IMHO).
Use testing tools for the future
Velocity is on it’s way out. At best it will stay and be made less buggy. However, I doubt that.
-
End to End testing can be handles with ChimpJS, Capybara, or your favorite tool as they don’t need to know about Meteor itself (though Chimp has some killer Meteor integration for setup/teardown!)
-
Unit tests can be setup to use Karma outside of Meteor with a simple config that mimics Meteors load order. I’ve used this with great success and it allows me to get millisecond test results with any JS testing tool (Jasmine, Mocha, Tape, etc…). Simple Jasmine stubs allow you to test a lot of client and server code without needing to mock out all of Meteor.
-
Integration tests are the most tricky as they need to know about Meteor. Gagarin is the best option out now and works well. Little magic and little to break. You’ll likely have only a few of these tests if you opt to cover most of the code with Unit and End-to-End tests.
Use a module pattern
ES6 modules are coming. You can use Webpack if you need the fast reloads or the power of configuration. However, many do not. You can mimick the modules so that when 1.3 comes out, a transition will only take a few mins or hours tops.
Think about your code as modules. Everything should be in a module namespace and the folder name should mimic this for ease of use. Doing it this way also mitigates load race conditions.
For example:
// client/helpers/form.js
const FormHelper = {
validateNumber(str) {
// ...
return true;
},
validateEmail(str) {
// ...
return true;
}
};
// expose globally pre-1.3
this.FormHelper = FormHelper;
// later in another file
const {validateNumber} = FormHelper;
validateNumber('1 555-222-0000');
// or
FormHelper.validateNumber('1 555-222-0000');
Soon you can find/replace the top of your files with 2 lines like this:
// client/helpers/calculator.js
const FormHelper = {
validateNumber(str) {
// ...
return true;
},
validateEmail(str) {
// ...
return true;
}
};
// export in a module
export default FormHelper;
// later in another file
import {validateNumber} from 'client/helpers/form';
import FormHelper from 'client/helpers/form';
validateNumber('1 555-222-0000');
// or
FormHelper.validateNumber('1 555-222-0000');
Well almost, at least with Babel. JavaScript itself also does OO very poorly compared to Java/C#/Ruby/etc… However, it does do the functional paradigm really well and is getting more ‘functional’ features in ES7/8