ctataryn · March 15, 2017 15:31
diff --git a/ember-blog.txt b/ember-blog.txt
 It has been 5 years now, since I got myself involved into JavaScript. Be it developing projects, guiding people or publishing articles; I feel like, JavaScript gave me an identity, scope and most importantly satisfaction. Thanks JavaScript!

 In the last 5 years years I worked heavily in many JavaScript frameworks, be it back or front-end. But Ember was disappeared from my life since 2015 mid. I involved my life in other tools and frameworks of JavaScript. Fortunately one month ago I got a chance to work with a client who wanted me to develop his project in Ember. I was not much excited as ember was a known guy to me, but started developing the project as it’s a day to day life for me. But after delivering the project I started thinking of my experiences with these three front-end frameworks and probably today publishing this article out of my emotions.

 Disclaimer

 This article is NOT about blaming or lashing out at Angular or React.
 This article is NOT about going very deep in technical aspects of these three frameworks but about the real life experience of a developer with all these.
 I used the word “prefer” and not “recommend” in the post title. Cause recommending is always dependent on your situation and use case. But preference is an in general term.
 Where Ember gets 100%

 The native feeling

 Being honest, I’ve become very possessive about JavaScript in last few years. And I do not like them who tries to do over engineering with it. I love JavaScript as JavaScript. This is the reason I couldn’t like TypeScript; thus Angular 2. I don’t see any usefulness to learn another scripting who tries to introduce types (I know it’s optional) and some ugly syntaxes. 
 React is better than angular 2 atleast in this sector; but still you need to deal with jsx. 
 In the other hand, ember is pure JavaScript. You will write code in JavaScript. It provides many apis though, but no extra syntax. This gives me the pleasure of being a JavaScript developer.

 Convention over configuration

 Trust me, reducing the configuration code of your project is a huge advantage. Firstly, the code size is going to be smaller and very cleaner. Secondly, the conventions are universal. Any new developer can easily understand what’s going on. For the people who haven’t worked with ember yet; ember is smart enough to detect the purpose of your files and variable names if you name them in a certain way.

 Best documents ever

 Ember guides and Ember apis are probably the best technical documentation I’ve ever came across in my life. Even the beginners can understand it very easily. The official discussion form of ember is also very helpful to address your issues.

 Built in best practices

 Ember-CLI is a power to Ember. Even angular is trying to develop a cli inspired by ember. When you scaffold a project using ember-cli it will scaffold with a predefined architecture which is approved by the big guns of the community. 
 When a startup tries to start building something using a certain tool, no matter how experienced the team is, but if the framework is new to them, they will never be sure of the best practices. In case of react the risk is even higher as it’s a library and not a framework.

 Forcing the best practices

 Even if you have good developers in your team; sometimes, out of delivery pressure they write bad codes. Not logically, but conceptually bad. In some parts atleast ember forces you the best practices. For an example, you can’t write business logic in your template. Only iteration and if helper that too with boolean parameter only is available. So you simply CAN’T write logics in your template.

 Productivity improvement

 I understand the learning curve is very steep and ember is probably the toughest to learn among these three frameworks. But once you are a master, you can develop projects way faster than people with angular or react. Convention over configuration and ember-cli are the main cause of that.

 Inter team work

 If all the teams of your organization (or even someone outside your organization) are developing ember applications using ember-cli; they will be very familiar to the projects architecture and in no time can start contributing at any project. This also improves your productivity as an organization by the way.

 No organization; only community

 Angular belongs to Google and React belongs to Facebook; two giant organizations. But ember is by the community; for the community. The developers of Ember’s core team are also developers in their own projects and this is the biggest plus of Ember. Because they are just not the framework developer, but the framework user. Thus always attached to the ground reality.

 Handsome releases

 Fortunately when Angular 2 was released I was out of my angular projects. But I’ve seen my friends crying with the headache of upgrading their applications to angular 2. 
 In the other hand when Ember 2 was released, it simply didn’t have any changes. Yes you heard me right. It did not have any changes; ember 1.13.0 and 2.0.0 are exactly the same (only the deprecations were there). Because the developers started releasing the new things slowly and gradually in the 1.X versions. Absolutely zero pain for application developers to upgrade the application. This is the benefit when the core team members are the framework consumers.

 No cons for Ember?

 Everything has a second side. Ember also has cons like steep learning curve, little slow rendering, heavy weight etc. There are more technical articles who compares the framework almost apis to apis. But this one is more a behavior article which I’ve composed out of my experiences. I believe no matter what the framework is, technically you can always complete your project with it. But there are other factors which affects the journey and the path. After considering everything along with your situation, use case and business you can make the best decision for your project and startup.
	It has been 5 years now, since I got myself involved into JavaScript. Be it developing projects, guiding people or publishing articles; I feel like, JavaScript gave me an identity, scope and most importantly satisfaction. Thanks JavaScript!

	In the last 5 years years I worked heavily in many JavaScript frameworks, be it back or front-end. But Ember was disappeared from my life since 2015 mid. I involved my life in other tools and frameworks of JavaScript. Fortunately one month ago I got a chance to work with a client who wanted me to develop his project in Ember. I was not much excited as ember was a known guy to me, but started developing the project as it’s a day to day life for me. But after delivering the project I started thinking of my experiences with these three front-end frameworks and probably today publishing this article out of my emotions.

	Disclaimer

	This article is NOT about blaming or lashing out at Angular or React.
	This article is NOT about going very deep in technical aspects of these three frameworks but about the real life experience of a developer with all these.
	I used the word “prefer” and not “recommend” in the post title. Cause recommending is always dependent on your situation and use case. But preference is an in general term.
	Where Ember gets 100%

	The native feeling

	Being honest, I’ve become very possessive about JavaScript in last few years. And I do not like them who tries to do over engineering with it. I love JavaScript as JavaScript. This is the reason I couldn’t like TypeScript; thus Angular 2. I don’t see any usefulness to learn another scripting who tries to introduce types (I know it’s optional) and some ugly syntaxes.
	React is better than angular 2 atleast in this sector; but still you need to deal with jsx.
	In the other hand, ember is pure JavaScript. You will write code in JavaScript. It provides many apis though, but no extra syntax. This gives me the pleasure of being a JavaScript developer.

	Convention over configuration

	Trust me, reducing the configuration code of your project is a huge advantage. Firstly, the code size is going to be smaller and very cleaner. Secondly, the conventions are universal. Any new developer can easily understand what’s going on. For the people who haven’t worked with ember yet; ember is smart enough to detect the purpose of your files and variable names if you name them in a certain way.

	Best documents ever

	Ember guides and Ember apis are probably the best technical documentation I’ve ever came across in my life. Even the beginners can understand it very easily. The official discussion form of ember is also very helpful to address your issues.

	Built in best practices

	Ember-CLI is a power to Ember. Even angular is trying to develop a cli inspired by ember. When you scaffold a project using ember-cli it will scaffold with a predefined architecture which is approved by the big guns of the community.
	When a startup tries to start building something using a certain tool, no matter how experienced the team is, but if the framework is new to them, they will never be sure of the best practices. In case of react the risk is even higher as it’s a library and not a framework.

	Forcing the best practices

	Even if you have good developers in your team; sometimes, out of delivery pressure they write bad codes. Not logically, but conceptually bad. In some parts atleast ember forces you the best practices. For an example, you can’t write business logic in your template. Only iteration and if helper that too with boolean parameter only is available. So you simply CAN’T write logics in your template.

	Productivity improvement

	I understand the learning curve is very steep and ember is probably the toughest to learn among these three frameworks. But once you are a master, you can develop projects way faster than people with angular or react. Convention over configuration and ember-cli are the main cause of that.

	Inter team work

	If all the teams of your organization (or even someone outside your organization) are developing ember applications using ember-cli; they will be very familiar to the projects architecture and in no time can start contributing at any project. This also improves your productivity as an organization by the way.

	No organization; only community

	Angular belongs to Google and React belongs to Facebook; two giant organizations. But ember is by the community; for the community. The developers of Ember’s core team are also developers in their own projects and this is the biggest plus of Ember. Because they are just not the framework developer, but the framework user. Thus always attached to the ground reality.

	Handsome releases

	Fortunately when Angular 2 was released I was out of my angular projects. But I’ve seen my friends crying with the headache of upgrading their applications to angular 2.
	In the other hand when Ember 2 was released, it simply didn’t have any changes. Yes you heard me right. It did not have any changes; ember 1.13.0 and 2.0.0 are exactly the same (only the deprecations were there). Because the developers started releasing the new things slowly and gradually in the 1.X versions. Absolutely zero pain for application developers to upgrade the application. This is the benefit when the core team members are the framework consumers.

	No cons for Ember?

	Everything has a second side. Ember also has cons like steep learning curve, little slow rendering, heavy weight etc. There are more technical articles who compares the framework almost apis to apis. But this one is more a behavior article which I’ve composed out of my experiences. I believe no matter what the framework is, technically you can always complete your project with it. But there are other factors which affects the journey and the path. After considering everything along with your situation, use case and business you can make the best decision for your project and startup.