If you are building a fairly complex web application, there is a high probability that you will have a lot of JavaScript code, and you would want to organize your code in some modular way that will be easier to maintain. Also at the same time you would also want to use some sort of a framework to simplify the process for you. But before getting there, let’s talk about how we got here at first place. In this video Robin Ward, co-founder of Discourse, talks about browser applications.
Building a fairly complex web application needs a very careful planning. Not just at the application level, but also at maintainability and efficiency level. Even if you are going to be the only person that’s going to work and maintain the code for a foreseeable future. Here are 9 things I thought you should know after creating your Hello World application and before creating your next application using Ember, especially if you are going to use Ember Data as your persistence library. Due to readers request, here is the code.
1. Is Ember the right MVC framework for your project?
I leave this decision for you to find out. But this is definitely a question to ask. Here is a quote by Tom Dale, one of the founders of Ember at interview at Intercom on his view on Angular vs Ember that I think is just right for this section.
I think there are a lot of people for whom they just want to be on whatever the most popular bandwagon is, right? I think that if you’re choosing a JavaScript library purely based on popularity, I think you deserve what you get. But I think there are applications that Angular is really great for and there are applications that Backbone is really great for and things where you would just use jQuery. So I certainly believe in choosing the right tool for the job. Tom Dale
2. Ember is Opinionated too
After learning your first MVC framework, JavaScript or non JavaScript, this should be kind of a norm for you by now, but I thought this fair warning is still necessary, especially if you are going to build an API mashup app.
Ember.js incorporates common idioms so you can focus on what makes your app special, not reinventing the wheel.
Similar to Angular, while Ember is opinionated, it also tries to make sure that its opinion is just a starting point you can easily change, and that’s the beauty of a well designed extensible framework. And this will be the challenging part of your learning curve as you will find less and less resources that talk about non idiomatic situations. 
Although there is a learning curve, it really becomes fun afterwards. Which leads us to the next thing you should know.
3. Active development = outdated help and tutorials
Active development of a framework is actually a good thing, as long as there are no hidden costs associated with it. There is a high probability that for a specific issue that you might search, you will end up on a website or a tutorial that offers a solution which does not fix your problem. You might even stumble up on a nice green checked mark on StackOverflow for an approved answer, and pull your hair on why the same answer that works for everyone does not work for you! My advice will be to just check the article or tutorial published date and referenced code. In most cases the syntax had a very little change, and a little modification will fix your code. 
Similar to any actively developed framework, Ember guides are not as extensive as they should be, so if you find a solution that does not work in your case, open the API docs and find out how that specific method was implemented. This was not much of an Ember.js case for me than Ember Data. I don’t want to blame anyone here, these are really though programming challenges, and as an open source contributor, I can attest that there will be some edge cases that you will intentionally leave some issues out for those edge case developers in favor of ________ (anything goes.)
4. Use the latest beta for Ember Data until version 1.0
Not all JSON responses conform to Ember’s JSON Convention and formatted like JSON API. And guess what! If you are using Ember Data, you will see variety of code out in the wild. For example without reading this blog post you would not know that there is no need for that revision number anymore.
App.Store = DS.Store.extend({
// Delete this!
revision: 13
});Not only that, in the newer version of Ember Data you don’t even have to initialize DS.Store anymore. I was using the “latest” keyword in Bower dependency manager settings for my Ember app hoping that I will get the latest stable release, but that was not the case. As much as I know version 0 is never stable, Bower fetched version 0.14 as latest stable release. And problems started from there. I started discovering known and unknown bugs. I started fixing them to realize that the methods that were causing the serialize section to throw errors, in my case, were completely rewritten and factored out in the latest beta releases. 
As much as Ember data is in it’s beta phase, as long as it works with your app and passes your tests, always use the latest beta till this article is outdated and new stable version of Ember Data is released. I will cover how to configure your Bower setting little further so you wont have any issues, but before that, let’s talk about the obvious thing you should know.
5. Version Control even before writing your first line of code
This is one of the obvious ones, and I don’t even have to mention this, but I have seen this happening a lot, especially with junior developers. It does not matter what version control you use, as long as you allow yourself to move back in history and revert your code if necessary. I am not talking about crazy branching and tagging or… Just keep history of your code, it comes in very handy, even if you are the only developer working on that code.
Git becomes more fun once you learn to leverage its hidden features. For example at Big Employee we use Springloops as our primary Git repository and Bit Bucket as our secondary repo. Since Git allows you to push to multiple remote repositories with one command, our code is backed up in both places.
git remote add Both ssh://sls@slsapp.com:1234/bigemployee/ember.git
git remote set-url Both --push --add git@bitbucket.org:bigemployee/ember.git
git remote set-url Both --push --add ssh://sls@slsapp.com:1234/bigemployee/ember.git
git remote -v show
git push Both master
6. You will probably rewrite your code, because you know more at the end. Reuse code.
Who cares about forward compatibility when you can move fast and break things, right?
At least to some extent, depending to your project, the odds are that you will learn things that you did not know when you started your application. Let’s call that stage a solid working prototype. Therefore, adapt other frameworks and libraries to your workflow to speed up your development. Bootstrap is the most important one here. You can learn it in one evening if not an hour. It is very well documented and it will allow you to work on more mission critical parts of your project. For example the contact section of this website uses a customized version of Bootstrap form and input field styling. #CodeReuse
7. Tools are very important, especially your automation tools… learn them, love them
Automation tools are not just exclusive to Ember. This section could apply to any web application development life cycle. You’ll be surprised on how productive you become.
I even use them to optimize images and all other things that should not be handled by a human. I don’t want to get into details of why you have to use automation, just consider that it saves time, but I want to talk about the essentials tasks of automation for your Ember app. 
What I want to talk about is what tools you need and what to be aware of.
Node and npm (Node Package Modules)
It’s true that we are not writing Node.js application but we need some modules that npm will handle for us when we run npm install command. This is what my package.json file looks like: 3 Grunt tasks.
{
"name": "my-app",
"description": "my awesome app",
"version": "0.0.1",
"private": true,
"devDependencies": {
"grunt": "*",
"grunt-contrib-watch": "*",
"grunt-ember-templates": "*",
"grunt-contrib-uglify": "*"
}
}Bower
Web apps are made of lots of things — frameworks, libraries, assets, utilities, and Bower will fetch them all for us. Bower requires Node and npm and Git. Here is my my bower.json file. Any time I run Bower, it will find the specified version of libraries I need for my application, like the latest version of jQuery, and keep them nice and organized.
{
"name": "my-app",
"version": "1.0.0",
"dependencies": {
"jquery": "latest",
"bootstrap": "latest",
"d3": "latest",
"ember": "~1.6",
"ember-data": "~1.0"
},
"authors": [
"Norik Davtian <norik@bigemployee.com>"
],
"description": "my awesome app",
"main": "index.html",
"license": "MIT",
"private": true,
"resolutions": {
"ember": "~1.6"
}
}One thing that you might come across when your app has a lot of dependencies is the dependency conflict. Bower will ask you which correct version of that dependency should we install and will allow you to save the resolution to make sure you won’t face the same question later on. For example if we have two jQuery plugins and one needs the latest 2.x version and one requires 1.x version, you will be asked to choose which version of jQuery should be fetched for your application. Make sure you specify the ember data version.
Grunt (The Javascript Task Runner)
Grunt is one of my favorite automation tools. Almost any automation tool that you might think of is written by the community of developers and available as a plugin on Grunt. For example if you want to remove all console logging from your code, which is a very good idea for production code, if you search on Grun plugin site, you will probably find few plugins that will help you do that.
@embersherpa @norikdavtian IMO you should reference ember-cli in part 7. btw, ember uses broccoli over grunt
— Ricardo Mendes (@locks) August 16, 2014
One of the readers mentioned that you might also be interested to check the alternatives to Grunt for your Ember app build and automation such as Ember CLI, Gulp, and Broccoli.
I do not run any pre processors or linting with Grunt as my IDE is configured to do those and highlight it right in the editor, but emberTemplates, uglify, and watch are the tasks I run in this case. Here is how my Gruntfile.js looks like. This should also give you a perspective why I am not using Yeoman. Feel free to fully contact all your files, uglify, and mangle your code. This is my light compression settings here.
module.exports = function(grunt) {
grunt.initConfig({
pkg: grunt.file.readJSON( 'package.json' ),
emberTemplates: {
compile: {
options: {
templateBasePath: /app\/templates\//
},
files: {
'app/templates.js': 'app/templates/*.hbs'
}
}
},
watch: {
emberTemplates: {
files: 'app/templates/*.hbs',
tasks: ['emberTemplates']
},
js:{
files: ['app/controllers/*.js',
'app/routes/*.js',
'app/models/*.js',
'app/fixtures.js',
'app/views/*.js',
'app/router.js',
'app/templates.js',
'app/main.js'],
tasks: ['uglify']
}
},
uglify: {
options: {
banner: '/*! <%= pkg.name %> <%= grunt.template.today("yyyy-mm-dd") %> */\n',
mangle: false,
beautify: true
},
build: {
src: [
// 'libs/jquery/dist/jquery.min.js',
// 'libs/bootstrap/dist/js/bootstrap.min.js',
// 'libs/handlebars/handlebars.runtime.min.js',
// 'libs/ember/ember.min.js',
// 'libs/ember-data/ember-data.min.js',
// 'libs/d3/d3.min.js',
'app/main.js',
'app/templates.js',
'app/models/*.js',
'app/controllers/*.js',
'app/router.js',
'app/fixtures.js',
'app/routes/*.js',
'app/views/*.js'],
dest: 'app/app.min.js'
}
}
});
grunt.loadNpmTasks('grunt-contrib-watch');
grunt.loadNpmTasks('grunt-ember-templates');
grunt.loadNpmTasks('grunt-contrib-uglify');
// Default task(s).
grunt.registerTask('default', ['emberTemplates','uglify','watch']);
};Well Configured IDE (Integrated development environment)
I use NetBeans IDE, just as a personal preference. It does not matter what IDE you use for your development, Eclipse, Sublime Text, or WebStorm, as long as it is configured to maximize your productivity. For example I have linting, CSS pre processors, and even some js minification plugins configured at IDE level.
Initially Netbeans was not highlighting handlebar templates properly, but I modified that from Tools > Options > Miscellaneous > Files and added HTML Files (text/html) for hbs file extension. And now my IDE supports highlighting and formatting for handlebars.
Browser Extensions
Ember Inspector: The most obvious browser extension in this case for our Ember app.
Postman REST Client: Just to test our REST API endpoints without having to write any code. Comes in very handy when we want to get some sample data just to test our code.
And all your other Web Development tools and extensions.
8. Handlebar runtime, emberTemplates
What is the difference between handlebar.js and handlebar.runtime.js?
Simple answer, performance. More detailed answer, according to handlebars website:
Using the Handlebars precompiler, you can precompile your Handlebars templates to save time on the client and reduce the required runtime size of the handlebars library.
This is where our Grunt task runner will constantly watch our templates, and if there is any change, it will compile our Ember templates into Handlebar compatible runtime JavaScript code.
9. Know JS debugging tools and techniques
This is an entire topic for itself. But I wanted to mention it here because it is in the list of things you should know before starting your next web app using Ember.js and Ember Data or any other library or JavaScript framework. I highly recommend pressing the F12 key on your keyboard more often and start experimenting with it. Especially the Console, that’s where professional JavaScript developers hide their secrets. Knowing how JavaScript objects work will save you a lot of time when working with Ember objects. And finally, I would like to recommend this upcoming book for developers interested to learn more about JavaScript.
I hope you enjoyed this lengthy article. Please let me know if I have missed anything, or would like to correct or add anything to this list.
