Ember has evolved from being the framework to a modern trusted Javascript framework used by major tech companies like Apple, LinkedIn and Vine, ever since it was born. It was developed by a Rails developer Yehuda Katz, so it believes in Convention over Configuration. Ember community not only is very supportive but also follows six week release cycle ensuring security and features which keep making it best framework to consider. It tries to stay as much backward compatible as it can so that with every new major release you don’t have to waste a lot of time learning new ground breaking things and syntax. I was working on my Ember project and it was taking a lot of time to boot which wasn’t a usual thing and before digging for its cause, this question hit me “How does Ember boot ?”. Though the reason for this extra time was a debugger on my API. It was enlightening to know how did ember boot. SproutCore 2.0 I did some research, mainly looking at Ember git repository to find my answers. Knowing the Ember boot process, not only made my roots strong but also changed the way I looked at it. It is beyond the scope of any article to cover the whole Ember boot process, to do that there needs to be a book but I can definitely brief things that made sense to me and were important mentioning. So let’s start … The first thing that happens when you start any Ember application is the creation of instance, which is done by Ember.Application window.App = Ember.Application.create(); The object that holds this instance is a global object and is created only once. Any method or variables in this class have global namespace as . While you can think of your as a container that holds the other classes in your application, there are several other responsibilities going on under-the-hood like Initialization, Event Delegation, and Routing. Ember.Application Ember.Application The first method that is called when the instance is created is . It is called when is fired which happens after all the resources required for Ember to execute is downloaded and parsed. _bootSync() domReady() Following code lists all the methods involved in boot process. Ember.Application Ember.Application{//other methods and variables...._bootSync(){this.runInitializers();this.advanceReadiness(){this.didBecomeReady();}}....//other methods and variables....didBecomeReady(){if(this.autoboot){//instantiate Ember.ApplicationInstancelet instance = this.buildInstance();instance._bootSync();intance.startRouting();//or instance.handleURL(url)}}....//other methods and variables} has following responsibilities : Ember.Application Initialization The goal of initializers is to register dependencies and injections. They provide access to the internal registry, which organizes the different components of an Ember application.Additionally they provide a chance to access the instantiated application. It runs only once. Because these initializers may load code, they are allowed to defer application readiness and advance it. When some asynchronous task needs to be performed before some initializer then can be used which is used to control which is called only if counter is set to zero. When we call ,the counter is set to decremented and becomes -1. Routing halts till counter becomes zero. Once the asynchronous task finishes execution it, makes counter increment by 1 and if counter =0 then is called. deferReadiness() advanceReadiness() deferReadiness() deferReadiness() deferReadiness() advanceReadiness() It is possible to add custom initializers on top of Ember , like so: Ember.Application.initializer({name: ‘api-adapter’,initialize: function(application) {application.register(‘api-adapter:main’, ApiAdapter);}}); 2. Event Delegation Ember uses a technique called . This allows the framework to set up a global, shared event listener instead of requiring each view to do it manually. _event delegation_ For example, instead of each view registering its own listener on its associated element, Ember sets up a listener on the . If a event occurs, Ember will look at the target of the event and start walking up the DOM node tree, finding corresponding views and invoking their method as it goes. mousedown mousedown <body> mousedown mouseDown has a number of default events that it listens for, as well as a mapping from lowercase events to camel-cased view method names. For example, the event causes the method on the view to be called, the event causes to be called, and so on. Ember.Application keypress keyPress dblclick doubleClick If there is a bubbling browser event that Ember does not listen for by default, you can specify custom events and their corresponding view method names by setting the application’s property: customEvents let App = Ember.Application.create({customEvents: {// add support for the paste eventpaste: 'paste'}}); To prevent Ember from setting up a listener for a default event, specify the event name with a `null` value in the `customEvents` property: let App = Ember.Application.create({customEvents: {// prevent listeners for mouseenter/mouseleave eventsmouseenter: null,mouseleave: null}}); By default, the application sets up these event listeners on the document body. However, in cases where you are embedding an Ember application inside an existing page, you may want it to set up the listeners on an element inside the body. For example, if only events inside a DOM element with the ID of should be delegated, set your application’s property: ember-app rootElement let App = Ember.Application.create({rootElement: '#ember-app'}); The can be either a DOM element or a jQuery-compatible selector string. The is responsible for delegating events to application’s views. The event dispatcher is created by the application at initialization time and sets up event listeners on the DOM element described by the application’s property. rootElement Ember.EventDispatcher rootElement Note that . If you specify a custom root element, make sure you only append views inside it! views appended to the DOM outside the root element will not receive events 3. Routing not only creates your application routers but it also controls routing. By default, the router will begin trying to translate the current URL into application state once the browser emits the event. If you need to defer routing, you can call the application’s method. Once routing can begin, call the method. If there is any setup required before routing begins, you can implement a method on your app that will be invoked immediately before routing begins. Ember.Application DOMContentReady deferReadiness() advanceReadiness() ready() These are the major tasks performed by initialization. Ember.Application Once this is done and our application is in state , the next method which is called is . This leads us to next important thing which is initialization. advanceReadiness() didBecomeReady() Ember.ApplicationInstance When we are talking about initialization, we are mostly dealing with registry of Ember , which happens before the container is created. Once that is done, is initialized. It encapsulates all of the stateful aspects of a running . Ember.Application Ember.ApplicationInstance Application At a high-level, we break application boot into two distinct phases: * Definition time, where all of the classes, templates, and other dependencies are loaded (typically in the browser). * Run time, where we begin executing the application once everything has loaded. are like class-level(static) members of the application which needs to be processed prior to instance creation. On the other hand, singletons reside in the . Registry is used to hold the stateless or static part while container is used to hold the stateful or dynamic part of the application. Registries containers Do note that each app instance maintains their own registry/container, so they will run in complete isolation by default. Now that we know how works its time deal with . _bootSync() this.didBecomeReady() Ember.Application{//other methods and variables....didBecomeReady(){if(this.autoboot){//instantiate Ember.ApplicationInstancelet instance = this.buildInstance();instance._bootSync();intance.startRouting();//or instance.handleURL(url)}}....//other methods and variables} In , we check . It is used to check whether the application should automatically start routing and render templates to the `rootElement` on DOM ready. While default by true, other environments such as FastBoot or a testing harness can set this property to `false` and control the precise timing and behavior of the boot process. didBecomeReady() this.autoboot is the special environment that is usually used for Server-Side Rendering. This setup allows you to run your Ember app in a server environment using Node.js and render its content into static HTML for SEO purposes. FastBoot 1. Autoboot is also handy when we want to wait for some resource to fetch before the rendering process starts. Just as is used to control the routing , in the same way is used to control rendering. this.autoboot advanceReadiness() this.autoboot 2. **Ember.ApplicationInstance** initialization Once is set to true the next thing that happens is . It is used to initialize . Unlike which run only once during the boot process, is created multiple times. Just as we have constructors which gets called every time we create an instance, in the same way gets called many times. It ensures that all the registries have been loaded and all the instance variables are initialized. They are created and destroyed on per request basis. So this is the place where we might want to keep the sensitive data associated with our application as it might get exposed if kept in registry and will be accessible to all the instances unnecessarily. this.autoboot this.buildInstance() Ember.ApplicationInstance Ember.Application Ember.AppplicationInstance Ember.ApplicationInstance 3. **instance._bootSync()** Just like it , we have method to setup the instance of It has following code: Ember.Application _bootSync() Ember.ApplicationInstance. Ember.ApplicationInstance{//other methods and variables...._bootSync(){this.setupRegistry();//define root element//define locationthis.runInstanceIntializers(){if(isInteractive){this.setupEventDispatcher();}}}....//other methods and variables....startRouting() {let initialURL = get(this, 'initialURL');if (this.setupRouter()) {if (initialURL === undefined) {initialURL = get(this, 'location').getURL();}let initialTransition = this.handleURL(initialURL);}}....//other methods and variables} ensures that all the factories required by the instance is properly registered. If any of the required factories aren’t registered then it gets registered in this process. this.setupRegistry() is used to define root element and where the instance will be rendered. We can also specify what type of events to listen to detect navigation. Once the location of render and root element is known, instance initializers are used to initialize the instance. this.runInstanceInitializers() is a phase where the application is ready to listen to events mentioned in If the application is still working on some fetching some resources its is set to false thus no event dispatcher is working. When our application is ready to listen to events its is set to true and event dispatcher is setup using . It sets up global event dispatcher which is capable of listening to all the events. isInteractive Event Delegation. isInteractive isInteractive setupEventDispatcher() With this is complete and the next thing that happens is routing. _bootSycn() 4. **startRouting()** Here, the routing of urls starts. The things that were set up for Routing during initialization is actually visible on the browser in this phase. Application is able to change the urls based on the application states (router.js). Ember.Application It initializes the current router instance and sets up the change handling event listeners used by the instances `location` implementation. A property named will be used to determine the initial URL. If no value is found `/` will be used. On any state change, fetches the new url to which the browser needs to point and updates the url. initialURL get(this, ‘location’).getURL() this.handleURL(initialURL) That’s all folks, hope this made understanding of Ember boot better. Thanks for reading. Source: and Ember github page Journey through Ember.js Glue: Booting Up by Mike North
