Questions for thinking about "expertise" in the context of working with ember.js

#1

backstory

Some form of this question has been swirling through my mind recently. My team and I have also discussed this topic. I would appreciate anyone in the community to reflect and respond from their own experience.

disclaimer

Perhaps we cannot answer this question easily. What does expertise mean in any knowledge domain? Only authorities in that domain could answer satisfactorily. Despite the diffusion of knowledge in the JavaScript landscape, asking this question in one community seems helpful.

question(s)

  • how do you quantify expertise when working with ember.js?
  • what resources and learning strategies do you recommend for developing expertise?
1 Like
#2

To me personally expertise in Ember would mean several things:

concepts

A solid understanding of the various Ember features and ideas, and how to use them effectively:

  • core: routing, components, testing, app management (filesystem, build, deploy, updates, etc)
  • ember data: adapter/serializer customization, how the store works, JSON API conventions, etc.
  • popular addons: simple auth, mirage, concurrency, etc.
  • testing

I think the “how to use them effectively” is pretty important here. Theoretical knowledge is one thing, and very important, but there’s no substitute for some real-world experience using the Ember concepts and tools when things get messy or weird. Ember is a heavy framework with a really broad surface area and I think when it really comes down to it experience with it is going to result in better code and faster development.

component design

I don’t think this is quite as important in Ember as in something like React, since Ember provides other primitives like services, router, etc. out of the box but having a good understanding of component design patterns in general (contextual, higher order, provider, container, etc) can really help maintainability and readability especially in a huge app. I think this is where the biggest crossover value would be with other SPA frameworks, especially understanding the tools that Ember provides and their respective analogues in a more component-centric framework.

javascript

Sure Ember does a lot for you but one should have strong js fundamentals to really understand what’s going on, write clean code, and use a lot of the tools and concepts that the framework doesn’t provide. Especially as Ember continues to align itself more closely with modern javascript and the js ecosystem.

community

Some level of connection with the community: IMO one of Ember’s biggest strengths, I think it would be hard to really appreciate and understand Ember without at least a passive understanding of the community and ideas the framework has been built with. I think even from a totally passive standpoint this would involve understanding the framework goals and ideas (ambitious, batteries included, convention over configuration, etc), where to find help (docs, guides, the code itself, discord, this site, etc), the addon ecosystem (hugely important to ember), and probably the evolution of the framework and the ideas behind its development and maintenance (release cycle, editions, core team, history and modernization, versioning, etc). Ideally some one with “expertise” would also be an active part of the community, contributing anything from more of that= inclusive and welcoming feel to help to docs to addons to core code.

is this any different from expertise building Single Page Applications? If so, what makes it different?

I just had a conversation about this with my former manager, specifically from the perspective of hiring. I think it’s very different and to me it comes down to how well you can write good maintainable Ember code. In my experience the most maintainable code in Ember specifically is code that is well organized and sticks with Ember conventions as much as possible, and you can’t write that kind of code without some level of Ember expertise. This affects your development at a pretty fundamental level because it influences how you think about problems and design, how you structure your code, how you test it, etc.

My first Ember code was terrible because I didn’t have a good understanding of the fundamental tools and concepts so I’d jam code in the wrong places, or do things in roundabout ways, and I had teammates that quite literally just used Ember as a way to deliver jQuery into the browser. That’s not to say a great experienced JS SPA dev couldn’t rapidly gain the necessary Ember expertise, but I think it will take some amount of time for anyone. I’m sure this applies to any framework to some extent, and you could even argue that Ember’s conventions steer someone without expertise in the right directions a lot faster, but I still think you need some level of experience to REALLY be dangerous (the good kind of dangerous) with Ember.

what resources and learning strategies do you recommend for developing expertise?

  • I don’t think there’s any real substitute for just writing real-world code, whether that’s a side-project or an app you’re working on for an employer or client, or an addon you’re contributing to the community.
  • I’ve actually learned a whole lot from reading threads on this site and trying to answer questions here and there
  • contributing to ember core or addons: it can be intimidating to start, especially if you don’t have the expertise, but I think the core team is doing a great job of trying to make it easier and more accessible, and what better way could there be to learn the framework than actually writing code/docs for it?
  • 3rd party resources: @balint’s Rock and Roll with Ember book and EmberMap’s video series are both great resources that teach best practices along with basic concepts
  • Reading RFCs, keeping up with Ember development
  • Reading blog posts and other resources in the greater javascript ecosystem: I think this can help place Ember in the greater ecosystem, cement Ember concepts as you draw connections to other frameworks and also see where it’s different
4 Likes
#3
  • Quantify expertise is defined by how much hours you recently worked with Ember it seems. Not sure how this works but if you stop your expertise goes down every 6 weeks fast.

  • Upgrading an old app step by step will bring your expertise up fast. I also advise trying the Bloggr example.

#4

@dknutsen @broerse thank you both for your responses! I’ve added the ideas therein to my learning path bank.

Same here. Most architectural decisions I made in an application I develop fell into this category. This went on for 2 years or more. I’m now seeing some of the whys for concise, clearer ways to design functionality given Ember’s constraints.

I agree the immersive approach can lead to better understanding. Though I wonder about potential barriers in the process. I could misunderstand a key assumption built into to the framework and inefficiently spend a lot of time working at a problem. (the idea of “deliberate practice” from Dr. K. Anders Ericsson in his research).