Hi! First blog entry. I’m going to talk about why I like Ember.js. With that said, I’m going to cover a few things:
- What is Ember.js;
- Reasons to pick Ember.js;
- The structure of the framework.
What is Ember.js
Reasons to use Ember.js
I’m biased. I love this framework. I will try to be brief in this list and cover the points I like the best. Let me know if I forgot something. Later I will explain what it did help me to solve.
- Convention Over Configuration: When you get an ember project, you know what to expect. You know where to find specific parts of the code. You don’t have to think what is the best structure for your project. Smart people designed this structure, so you can take advantage of that. With that said, it does not mean you cannot change the configuration. The Ember core team knows that sometimes you will have to use some third party API’s which you have little to no control.
- Write Less Code: who wants to have less work and have a better product? Everyone who loves themselves. With Ember you can take advantage of many tools that will help you to achieve this goal. The built-in tools are pretty solid. Here are few examples of the standard packages:
- ember-data, an incredible package that helps you with to handle your model objects;
- ember-cli, responsible to give structure to the folders and help to generate blueprints;
- handlebar, a the template engine used to render the components
- Great ecosystem: I know it’s related to the item above, but this is a very important subject. There are many addons in the community that have good support (check it out on Ember Observer). Here are some of the most popular addons and tools that are maintaned on the regular basis:
- Ember-inspector – browser plugin that helps you to debug data in your app
- Liquid-fire – responsible for animations\transitions;
- Ember Twiddle – online tool that helps you to reproduce and share snippets of your code with others;
- FastBoot – Server side rendering tool. Ember is a single page render app. FastBoot helps to generate an html skeleton with static text that will be populated later with your dynamic text. Rather than having to wait for your app to load everything at once with JS and some async calls.
- Built in security snippets: Handlebar tries to mitigate security flaws such as XSS attacks;
- Built in test system: It’s easy to write and run tests with ember. You can also install powerful addons to help you boost your tests, such as ember-cli-mirage;
- Component designed: Here you can take advantage of higher order functions with your components. The template structure promotes the usage of component blocks. This makes the app easier to read by avoiding code duplication, and less lines of code;
- Easy to hook with REST interfaces: you can easily hook up API’s that use REST interface. On top of that, you can use many different formats such as JSON (which is the default adapter)
TL; DR; Ember helped me to deploy my apps faster, because it comes with many tools available and it also forced me to write better code (more modular and better organized); It improved my productivity.
Many people could argue that Ember.js is not the simplest framework to learn and start developing web applications. I feel like even though the guides are helpful, they are not enough. Especially with a framework that evolves so fast! Luckily, the community is very active and helpful. Things move fast in the JS world and Ember likes to take the lead on it. This causes the framework to change rapidly. This can be good and bad at the same time. I like this kind of mindset, but I can see how overwhelming this could be for some people. At the end the code always change for better, it usually gets easier to work with and the developers handle code deprecations better than other frameworks from what I’ve seen (like Angular). Also, the .js bundle is larger compared to other frameworks which can cost a few miliseconds. The ember core team is aware of this problem and they’ve been working hard on the Glimmer VM and the results are shocking. This topic deserves a whole new post for it…
Ember.js uses a common design of MVC (Model-View-Controller) and on top of that it also include the Router. It’s common to see people saying that this is a MVC+R framework.
- Model is where you describe the structure of the objects your app will handle. Ember ships with a very powerful tool called Ember-data. Over there you can specify the type of one attribute and define relationship between models. It is so good that besides all that, it comes with a cache system that can save you from querying the same data over and over again.
- View is what will be render by the template engine (Handlebars). Here is where you can create your different components and re-use them over and over again. Besides that it comes with built-in helpers such as conditionals and loop blocks. You can also create helpers to help you with your template, such as a date formatter, currency formatter, and so on.
- Controller is where you will deal with user events. Here is where you will define variable states that should change the template (components).
- Router is where you will handle URL access (transitions) and will load the initial data for that view (famous model-hook). In fact, the ‘router’ is separated in ‘router’ and routes. Routes in Ember act like a controller to many other frameworks.
Below there is a graphic that can be found in the ember guide that illustrates the workflow of the framework.
I want to mention briefly, that there are some conventions while using Ember, such as Data Down, Actions Up. That’s also a nice topic that I’d like to cover at another time.
Well, to wrap things up: I use ember, because it helps me to achieve my goals faster and more reliably. It helps me to be a better software developer as well. With ember it’s quite simple. If you are doing complicated things, you are probably doing it the wrong way. This is a quote from my coworkers. They said that when I was starting with Ember and they are so right 🙂
Hope it was a good read. Let me know your thoughts!