Skip to content

Instantly share code, notes, and snippets.

@sukima
Last active March 30, 2019 21:21
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save sukima/309af8b802dd25fb640c8ef9b950d553 to your computer and use it in GitHub Desktop.
Save sukima/309af8b802dd25fb640c8ef9b950d553 to your computer and use it in GitHub Desktop.
My personal thoughts on the perseption of Ember.JS and the wider JS community

I was very sad today to read some negative comments concerning ember. I can't help but feel that outside the Ember community there is a lot of hate towards Ember. Here is my observations from a big Ember proponent perspective.

Community

Back in 2016 I attended EmberConf and was blown away by the inclusiveness of the community. I felt welcomed the moment I walked in. This is drastically different from any other technology conference I've attended (including WWDC in 2014). First off they offered a mentoring program so that new attendees had a meet and great with seasoned attendees and did not feel alone and isolated in a strange town for a week. Then the first keynote ended with Yehuda addressing a very sensitive topic about alienation and bullying. He set the tone that all attendees are responsible for looking out for others and to help when you see someone shut down.

Often times I find I shutdown when met with more dominant language. My ideas go underground and I loose all interest and motivation to participate all because someone retorts back that my idea is no good. We see this generally in our society concerning race, religion, gender, and sexual orientation. And it was a real eye opener to have that situation directly addressed at the very front of the conference. It set the tone and also empowered everyone to be their best.

This is what sold me on Ember. Then as I continued my journey it was the Discord (then Slack) that never had a lack of good people willing to take the time out of their day to help me with the same silly questions countless others have asked in the past. They even deal with me ranting and raving when I fail to fully understand what they are trying to tell me. No other online community I've been with has done that. This is why I pay the same forward to others daily.

Solution space (addons)

Having experience with Ruby and Ruby on Rails which has a very active Gem space. And also dealing with the cowboy antics of Node.js modules world I like to say that the Ember addon space is fantastic. There is rarely a lack of solutions to common problems. Most of the community promoted addons have good maintenance and responsive maintainers. No other community have I been able to have hours of conversation with the authors of open source then I have with the Ember community.

Ember core also works very hard to make the upgrade process transparent and doable. It also allows addons to control what versions they are willing to support. The technology underlying addons offers amazing conventions allowing things to work faster and with less hacking while remaining flexible enough to do such hacks if needed. I haven't seen that in many other systems out there. To me it is a well thought out solution.

Activity

The community seems very active to me. Offering future plans annually along with attack plans to move people through breaking changes. There has not been a period where I was not able to engage with people on either the Discord or the Forums. Each step from Ember 1.o to now Ember 3.4 has been clear and a good majority of addons have kept up-to-date.

Often when an addon breaks it is more a reflection of a bad design on the addon author's part then a reflection of the Ember ecosystem or framework design itself. For example assuming addons that wrap jQuery and then realizing that the same problems you had with jQuery you also have with using the addon. I have found that if you stick with Ember things work. I see this as no different then a Gem for RoR. You break out of the RoR framework you are asking for a fight.

RFCs

I think it is interesting that Ember took on the idea that all changes follow a request for comment process. The RFC itself seems transparent and helps a lot to get everyone (even the underlings) a chance to participate in the future of Ember.

However, there are some places where the transparency breaks down. Much like the typical RFC we see come out of the IEEE or other organizations it is difficult to see a direct cause and effect. Often the time between the RFC and the actual implementation can be years in the making. I think one of the problems is that of perception in that RFC are managed with GitHub which has a long standing perception that activity on GitHub equates to quick implementations.

I know I had this perception the first RFC I wrote. In fact my first RFC came accompanied with an implementation. It took a long time for me to understand why it was rejected and I carried for about a year dismay that the RFC process was a joke. This area I agree could use a lot of improvement.

The Software Development field has shifted from long planning waterfall like processes to fast and quick processes like Pull Requests were a merge means instant adoption. I think this difference in perception is the core reason Ember has difficulties to other communities out there.

Teaching

This is a big crux of the issues with the perception of Ember in my opinion. I've had many long conversations with React and Vue fans about the difference. And I've yet to ever have a satisfactory answer other then they feel more comfortable with their frameworks. As a side note, I don't fully understand why Presentation Libraries are so often compared to full Application Frameworks but apparently comparing apples to oranges is an accepted standard these days.

I've been able to articulate my own feeling about the difference and often it comes down to design choices. Ember took a very Object Oriented approach to its design while other frameworks focused on a more Functional approach in their design. With this difference I see many struggle when learning Ember. It seems that the OOP way is still a difficult mental model despite 20+ years of teaching otherwise.

Functional Programming is the new hotness and it is fascinating to see how powerful that thinking is. I feel like this is the modern equivalent of the craze to make everything out of XML a decade ago (anyone remember this?). I think partly the drive is that in libraries like React you have to do most of the work yourself (find your own implementations for application concerns) and this isn't all that different from Ember's addon philosophy. However, it does add to a developers sense of self worth in that they feel like they have more control then when using a framework that tells you what to do.

I also think it would help to compare this to the RoR framework in that it is an opinionated framework with conventions. Ember is too. This means that those who like convention over configuration will like Ember while those who do not will dislike Ember.

Perhaps these discrepancies can be helped by making new learners aware of the OOP and convention oriented nature of the framework. Explain what it is and what it is not. And include how Ember departs from things like React and Vue so that new learners know that this is no longer a one-to-one comparison anymore.

The Real Issue

Finally, the real issue and the crux of the entire problem with Ember. Jobs when a company needs to hire they are met with too many candidates who have some degree of competency in using tools like React and Vue.There just is not enough Ember folks willing to be out in the market (or they are all just have the best jobs already).

This failing is not Ember's fault and to think that it is is a disservice to all the hard work everyone puts into their livelihood. What I'm talking about is the chicken and egg problem.

Perspective employees want to be marketable, Employees want a good set of choices in their pool. Asking for an Ember dev returns little results, Asking for a React dev return many results. This is mostly because the evaluation of a piece of technology is not down to design principles or fitness for purpose but in what others have done.

I think this could equate to my first job where they saw me writing PERL and asked me to make another Amazon.com because they used PERL at the time. FaceBook promotes React to an unhealthy degree. By saying they use it on their site others will blindly assume that React is the epitome of technology and should therefore be the one to use. Abandoning decades of sound practices to take a piece of the FB frenzy pie.

This isn't to say FB is bad ort that React is wrong just that it is different and solves a different problem then Ember does. But because the end result is the same (A single page application serving millions) the two are compared together. And since FaceBook is the gold standard of all technology these days it is obvious that their nice technology solves all the problems one will face when designing the same thing.

In truth this comes down to a popularity contest and sadly Ember is loosing out. I'd like to close by saying that if you feel that there is discord in the communities it is based on this popularity and not on merits. I ask that everyone be honest and just state that one solution is better not because it has a better design or is technically superior then another but that said solution is popular.

Companies that wish to align with the popular pool of developers will have to reconcile this truth. A business choice in tech is more about how many devs they can get to use the technology then it is about the technology itself. Although a framework like Ember is capable of offering many benefits to a business it still lacks the overwhelming pool of Software Developers willing to take it on and places the burden of learning on the company itself.

GistID: 309af8b802dd25fb640c8ef9b950d553

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment