Skip to content

Instantly share code, notes, and snippets.

@michaelrkn
Last active May 4, 2018 17:03
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 michaelrkn/ffdd67906a724362bd8f5ccc3434db0f to your computer and use it in GitHub Desktop.
Save michaelrkn/ffdd67906a724362bd8f5ccc3434db0f to your computer and use it in GitHub Desktop.

Address the Hierarchy of Skepticism

Like most Ember developers, I want to see Ember's marketshare and mindshare grow in 2018. At EmberConf 2017, Tom presented the Ember Hierarchy of Skepticism:

  1. Metamorph Tags/ {{bindAttr}} (addressed!)
  2. No Documentation (addressed!)
  3. Custom Object Model
  4. Big File Size
  5. Monolothic

I'd suggest that the Core Team focus on working its way up the hierarchy. To this end, I'd suggest prioritizing, roughly in this order:

  • ES classes
  • Decorators
  • Optional jQuery
  • Tree shaking
  • Modularizing Ember

Ember's custom object model isn't hard to learn, but it's a big reason people are turned off before learning why Ember is such a great choce. I'd like to see ES classes support finished and adopted in the Guides ASAP, followed by decorators.

Finishing making jQuery an optional dependency will go a long ways towards addressing the file size concern. This is well underway, and I'd like to see this finished ASAP as well. Tree shaking will be an important win for file size as well.

Finally, breaking Ember into independent modules would help make it: easier to learn, by presenting it as a series of smaller pieces; adopt, by allowing developers to start with just Glimmer and gradually incorporate the rest of the framework; and address file size concerns, by letting developers opt out of the modules they aren't using.

Fortunately, most of these features are already well underway. I'd like to see these be the top priorities, so that we can see them shipped and make it easier for more developers to choose Ember without hesitation!

The last thing I'd advocate for is prioritizing routable components. Controllers are still the most inconsistent part of Ember and are an unneeded concept. From EmberConf 2017, it sounds like modularization needs to happen first so that experimentation can take place in the router to figure out routable components. Although there are a number of steps before we can get to routable components, I'd like to see that be a priority, so that we can finally be done with controllers, not have that be a concept new Ember devs need to learn, and allow devs to opt out of including that code (either through tree shaking or not including the controller module).

Thanks to the Ember community and Core Team for all of its hard work! I'm excited for the project to finish addressing the hierarchy of skepticism that Tom laid out, and be able to make an unqualified claim to be the best JS front-end solution for most web projects, without no apologies or explanations.

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