I wrote this article based on a speech I did at a Berlin.js meeting. Recently, there are few Russian-language materials about this quite popular and stable framework, and I decided to correct this situation a little.

You learn Ember.js once, and then apply this knowledge on all Ember.js projects. I will try to open this thesis under the cut.

I and Ember.js

Briefly about my experience. I first tried Ember.js in 2014 at my first job as a front-end developer. The framework was then built in the MVC paradigm and did not use the CLI. Due to the lack of experience, it was difficult to judge the strengths and weaknesses. In general, my impressions are well conveyed by this live-battle of 2013 between Ember.js and Angular.js. Yes, the Google framework had a lot out of the box, but Ember is easy to integrate third-party libraries, like moment.js or jQuery-plugins like datatables.net, which made it much more flexible.

Then I moved to another company and worked for a year with Can.js and React.js, but in 2016 I had the opportunity to choose, and I gave my old comrade a chance. By that time, the paradigm had changed to Data Down Actions Up, services and components appeared. However, in general, everything remained familiar and understandable, so there were no special problems with adaptation.

Since Ember.js is my main tool. And in my opinion, this framework is worth considering as a basic choice if you are developing a SPA.

Why Ember?

The Npm 2018 survey recorded some tiredness of the js-community from the numerous tools needed in the development:

it would be a little bit more

This is understandable, given that React.js is the mainstream. When it comes to marketing, the library is positioned as a very “easy” tool, which means it is easy to learn and very flexible. But this is the deceptive flexibility of triviality. Imagine that you come to buy a car, and instead you are offered to buy only an engine with the words: “You can make an excellent car with this engine. Big, small, green, blue, hatchback or station wagon. For taxis, for city driving or countryside. Suitable for any car! " This is great, that will do. But I would like to sit down and go. Only for this you will need to still pick up the gearbox, find the body and also (!) Choose the color. And marketing is silent about it.

This arrangement led to a heterogeneous eco-system with a huge variety of supporting libraries. Libraries that are often incompatible with each other, so they need to be carefully selected. The choice is, of course, good, but it’s tiresome to choose from 24 kinds of jam . And the Npm survey confirms this.

So, dear readers, I have good news for you. The Ember community suffers much less from the agony of choice due to the framework’s “design features”. As one of the respondents of the last Ember-community survey wrote:

You can learn more about the ember project ... Ember is always a coherent experience. Spelling less brainstorming on tooling, setting up a testing environment, or writing a testable code.

which translates as

You learn Ember.js once, and then apply this knowledge on all Ember.js projects. ... With Ember, you get complete experience, since all addons can be created and integrated with the same set of tools. Saving mental energy on mastering tools, deploying a test environment or writing verifiable code is a good thing.

Next, I will explain why you get this solid experience with Ember, but first answer the right question.

Is he even alive?

Nowadays, you rarely see a live js framework, the development of which has not stopped for the past 5 years. But Ember is one of them.

Active development has never stopped, but adaptation has stagnated in 2016. If we turn to the same survey, Npm 2018, the following chart is mentioned there:

As we see, there was a reversal in 2017, and Ember began to grow again, ahead of average rates. This phenomenon has a simple explanation. In 2017, LinkedIn decided to redesign and chose Ember.js to implement both (desktop and mobile) versions of its main site. This event provided the energy for development and created the current trend.

It should be noted that in addition to LinkedIn, the framework is used by such well-known companies as Microsoft, Netflix, Travis CI (their entire front is laid out in open-source ), Intercom, Heroku and others.

In general, the framework is alive and well).

Ember in the landscape of other JS frameworks

Below you can see a non-aspiring, incomplete and subjective list of various aspects of the development frontend, the purpose of which is simply to show the approximate position of Ember.js among other libraries. The blue and green lines refer to React.js and Vue.js, gray and orange to Angular and Ember.js:

Ember.js for the "box" functionality closer to Angular, trying to provide default implementation and tools for all the tasks that arise when we want to create a new SPA. If something does not suit or something is missing, you are looking for the corresponding addon (well, or write it yourself). About Eddonah below.

What will be familiar?

React.js

If you come from the world of React.js, then you will be familiar with splitting the page into a hierarchy of components. In Ember, you'll also think about how best to break your page into components and encapsulate local states into them.
If you are familiar with React-router, then the Ember router will also seem familiar to you. Initially, the router in React was copied from the embankment, although now the project has long been living its own life.
Finally, if you feel comfortable working with Redux and / or GraphQL, you can also use them with Ember.js (see here and here )

Also at the last EmberConf was a presentation on the comparison of patterns for React and Ember.

Vue.js

Naturally, you, as well as people from React, will be familiar with the paradigm of breaking the interface into components. In addition, you will be familiar with the concept of patterns and computed properties.

Angular.js

To those who know this framework well, the services and the Dependency Injection mechanism will seem familiar. Also, you will surely like decorators, which will be officially released in release 3.10 , and the use of which is now possible with the help of a polyfile. Also, you probably want to use Typescript (see here ), which is becoming increasingly popular in the Ember community.

What will be unfamiliar?

Now let's move on to parts that probably seem unfamiliar and which are likely to raise questions.

Ember-cli, not Webpack

The standard tool for generating an application is Ember-cli . Practically everyone always uses it. With Ember-cli, you will generate new applications and files in an existing application. The tool is responsible for compiling resources and deploying a development environment with live-reload and tests. For this, many extensions have been created that cover all basic life situations (up to fingerprinting, CSP or SRI). It can also be used for calculations on combat environments.

For many, it may seem unusual that the tool does not use a webpack. Instead, broccoli.js is used. In general, from this, during the development of the application you will not be either hot or cold.

Ember-cli is a stable and convenient tool. And largely because of this, the community does not suffer from the agony of choice.

Hard file structure

This moment often plunges people unfamiliar with the framework into shock. Look at the file structure of a standard Ember application:

What do you say, knowing that it can not be changed? You can not transfer files to other folders and name them in their own way. One day because of this, I even heard the epithet "fascist" in relation to the framework).

However, this restriction was introduced specifically. Here is proof:

Of course, if you are a freelance artist and a vulnerable creative person, it will be difficult for you to accept such an order. But for the rest, "medium" programmers, new to development, and those who do not want to think about the organization of folders and the naming of files each new project, it is very convenient.

In my opinion, this is an elegant and effective architectural solution that has a huge impact. And every time I open any Ember application of any complexity, I don’t look at it like a ram at a new gate, but I know where the components are, where the templates, services, tests, etc., etc. are located. It saves a lot of time and mental strength.

Addons

Time has shown that the decision to have a rigid folder structure has one more advantage. I will try to reveal it on a simplified example.

Suppose you need to use the same component in several applications (well, all of a sudden). Then, if you know that the components always lie in the app/components/ folder, you can select this component into a separate npm package, add it depending, and the smart Ember-cli will pull this component into the application at the compilation stage. And you can reuse it in your applications.

But this is not the most amazing. The amazing thing is that ALL other Ember applications can also use it if you publish this package to open source. And all such npm-packages laid out by other developers, you can use in all your applications, without putting additional efforts on integration.

The community has long understood this idea, so you can find such packages for anything. UI-libraries (where without them), compilation tools, extensions for release, libraries for authentication, adapters for working with back-end and so on. For such packages, the site EmberObserver was created, where you can find the package you need.

Addons are how Ember developers share functionality with others. And due to the fact that the addons work in all applications, they all use more or less the same set. Therefore, when you come to an already established project, you most likely know 90% of the addons that it uses. The app is familiar to you, even if you see its code for the first time in your life.

Communication with BE

The last aspect, on which I, perhaps, will pass only in passing, is the work with the back-end.

Usually, if you work in the resource paradigm, in Ember you will use the Ember-data library to work with data . It is optional, but by default it is added to all new applications. It describes the DSL for working with models, which looks like this:

Further the library itself will determine what the URL should be, what parameters, what method and how to parse the response from the server. If you are lucky and your back-end developers will adhere to any standard for describing REST interfaces, there is a chance that you will be able to use addon on your side, and not describe the communication with pens.

If you are unlucky, then Ember-data provides you with the necessary abstractions, for example, Adapter and Serializer. These abstractions will help to write clean code so that it does not appear as in the picture:

By default, Ember-data adheres to the JSON: API specification ( here is about comparing with GraphQL and REST). From my own experience I can say that using JSON: API saves a lot of time and moral strength for you and your backend developers. You are NOT discussing what URLs should be, in the CamelCase or Kebab Case there should be attributes and parameters, use PATCH or PUT to change what the JSON structure should be in the request and response for the nested resources. You discuss only the models, their relationships and the business rules of the attributes. This is another case where the restriction of choice has a positive effect on productivity.

Where to begin?

Regardless of whether you are an experienced developer or not, I advise you to start exploring Ember by opening the official tutorial .

He will gradually introduce you to all the main points:

• How to create an application using ember-cli
• How to create components, paths, models, etc.
• How to use Ember-data
• How to write a complex component
• How to embed a third-party library
• How to loosen up

Where to ask?

The main communication channel of Ember-developers is twitter Discord server . There always hang out experienced programmers who will help you with incomprehensible moments. There is a Russian-language channel. And do not forget that the architecture of all Ember applications is the same and everyone uses the same tools. This greatly increases the likelihood of a quick response to your question.

Other channels of communication can be found on the off site .

Afterword

In the finale, I would like to emphasize once again the main thesis. You learn Ember.js once, and then apply this knowledge on all projects .

Thanks for attention!