Skip to content

Instantly share code, notes, and snippets.

@LongLiveCHIEF
Last active January 3, 2016 03:31
Show Gist options
  • Save LongLiveCHIEF/3645049f8102dfa75f97 to your computer and use it in GitHub Desktop.
Save LongLiveCHIEF/3645049f8102dfa75f97 to your computer and use it in GitHub Desktop.
For and Against Ember.js

Against Ember.js

"It's not developed by "

There's this weird notion that something developed by some big company is bad mojo. True... Microsoft, Oracle, and IBM burried us all in technical debt in the first decade of the new millenium, but we've come a long way since then, (or at least Microsoft and IBM have). Many proponents of Ember enthusiastically tout the fact that it's maintained by a community of folks who build with Ember by day, and build and maintain Ember by night.

Think about that for a moment though... I'm sure many of you have pulled consecutive 60+ hour weeks on a project, and have felt what it's like to try to solve a code design problem late into hour 50 or 60. Now imagine doing that for 2 or more consecutive years. I don't have to imagine it, because I did it, and I can attest, after the first 30 hours of the week, I might get a decent 20 minutes worth of code for every hour or so I spent at the keyboard. (Decent being the keyword here.)

This affect is hitting the maintainers of the Ember.js project, and it's not just speculation, there's supporting evidence. Many of the features that were planned for Ember 2.0, announced in the fall of 2014, have yet to make it into the framework. Back in December of 2014, I watched this video that talked about the imminent release of several features, as if they were merely a few short months away.

When you look at this subjectively, you'll find that we've come full circle. The thought is that a community driven project (vs a corporat-led project) will continue to thrive, and not be subject to abaondonment whenever Google or Facebook sets their sites on some shiny new codebase. This doesn't play out however. Just look at Bower. It's not backed by any corporation, and is one of the largest package management systems in the world today, yet it is being abandoned by the core team, primarily because it's now obvious there's a better way to do things.

Contrast that with Angular 2.0. When it was initially announced, there was an uproar from current Angular adopters. What did Google do? They pulled back, and retraced their steps, despite their own opinions on what was best for the product and the web, in order to meet their community of users at a place where they

In today's open soure industry, there's a new trend

Bottom line

Ember is billed as a "very opinionated framework" that leads to more maintainable code. If you chose Ember because "It's not Google" or "It's a community project so " then you need to ask yourself these questions, before investing too heavily:

  • are said opinions are getting the weight and attention they deserve from design and implementation, all the way through to maintenance?
  • Ember is notorious for it's steep learning curve and poor documentation. If these opinions are so great, and it's really the golden egg it's billed to be, then why would the learning curve be so jarring to even seasoned and experienced javascript devs?

Framework Fatigue

  • those who suffer from Framework fatigue are those who avoid (intentionally or not) truly learning functional programming and Javascript
  • many people think that "the next shiny thing" is a bad thing, but it goes to show the power of the language to adapt to constantly evolving technology

Rails, Rails, Rails

  • ember was built by Ruby and Rails guys, pure and simple. But JavaScript is nothing like Ruby, and forcing a similar experience on top creates technical debt via lock-in
  • Widens the gulf for developers when they are faced with truly learning Javascript

Next-web unfriendly

  • browser only
  • continues to bundle together a conglomeration of package managers and testing sweets that can't target server-side javascript

For Ember.js

Reform

  • ember is most definitely heading in the right direction
  • actively reducing surface area
  • moving away from OO/MVC to a more functional/compositional structure befitting javascript

Blueprints

  • a flexible dynamic way of sharing components native to the framework
  • not natively available in any of it's compeititors
  • allow registration of custom classifications that can be scaffolded correctly regardless of the resolution pattern implemented by the consuming application

Resolvers

  • custom resolvers allow you to break the rigid structure, without breaking the internals
  • resolve both classifications native to the framework, as well as those injected or registered dynamically
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment