Learning Ember: Ember Skill Tree

What kind of skills does an ember developer have? In which order will a developer learn ember? What resources are available?

Those are some of the questions we currently have to get new joiners on board with ember and how to handle this with internal learning sessions. So we thought about a skill tree, which you can walk through go gain ember knowledge on the job. In order to get to a skill tree for ember (inspired by adam-golab/react-developer-roadmap), I did a flat acquisition of technologies or skills at first. See here:

  • File Layout: Classic, Pods, MU
  • Templating: Handlebars, Helpers and Modifiers
  • Structures: EmberObject, Native Classes
  • Decorators: Using and Writing!
  • Routing (includes Routes, Router, and Controllers)
  • Components: Ember, Sparkles, Glimmer
  • Component Patterns
  • State Management (tracked and computed)
  • Services
  • Testing Technologies: QUnit, Mirage, Sinon
  • Documentation: How to document (UML - ?) the workflow of a particular feature
  • Concepts of the Ember ecosystem: Apps + Addons + Engines + node packages
  • Creating addons and engines
  • Low-Level Ember: ember-cli, broccoli, babel, glimmer

This list for sure is incomplete. So, I was wondering whether we can create such a skill-tree together and align it with the guides?

This emerged from: https://github.com/ember-learn/guides-source/issues/727

6 Likes

The order, here, does not matter, do it?

It can worth to mention the Initializers and instance-initializers. In between the bootstrap and the DI of the application?

Great questions @gossi! A skill tree sounds like a great way to think about the progression of knowledge and provide more structure to how you learn building ember applications.

I think order matters for acquiring skills and moving from beginner to advanced in topic. I think there would be a lot of reordering of the above topics, or even alternative orderings depending on what most interests the learner. I think you could architect and develop stellar ember applications without ever knowing the internals of broccoli.js.

Initializers are good mention to mention as well @Thameus. As a barely related, shameless plug: the community favors removing implicit injections, so that could be emphasized less in any teaching approach. (See the pre RFC)

In my experience, I find grouping concepts together quite helpful. It can also relate to experience in other technologies. For example, 2 major concepts stand out to me:

  1. Thinking about state. To me this is the ā€œcache invalidationā€ of the 2 hard things folklore. I think it is spot on that the Octane version of the guides dedicate an entire section to the topic.

  2. building software with dependencies and managing those dependencies

The better Iā€™ve understood these concepts the easier it has been to think of an ember application as a coherent system and tease apart internals and advanced functionality. In any application, you need to deal with state. Youā€™ll also need to manage with dependencies.

As a naive way to navigate the order, you could ask ā€œwhy do I need to learn x and what does it matter for my roles when building my application?ā€

I think this relates to defining ā€œlearning goalsā€ through ā€œevidence based learningā€. While successfully applied in University settings, I think using the idea of learning objectives could really focus a skill tree.

My list is just a collection of topics, not ment to be sorted in any way (I followed the octane docs toc). However, the idea is perhaps to have it as a graph. ā€œLearning one unlocks the knowledge for moreā€ kinda thinking.

Also it is based on the octane docs toc, the idea in mind is, that you understand even the old/classic/legacy code (since many codebases still consists of many generations of ember). That said initializers is a good addition. While I discourage its usage today, itā€™s still a vital part of most addons in ember and a learner should understand them :+1: Good point @Thameus

When I share my knowledge, the first point I focus on is identifying to whom I am talking to, and their goal(s).

Organized by type of achievements, here are my ideal readers for leaning Ember.

  1. integrate HTML

Profile: students, young developers, even web designers

Scope: they mostly work around components

Ember provides to those people the most of value: all features out of the box. Hence, Ember avoids distractions. They focus attention on Handlebar and GlimmerJS. They donā€™t need much. Convince them is a key, they will use it later - if they are happy with the DX and the result of their efforts.

  1. create a JAMstack website

Profile: students, new++ to mid experienced developers

Scope: components, routes, and services for fetching data + intl

They have already worked on other frameworks. Maybe backend ones. The main difference with the first category is they need to ship their code to production. Also, they are more open to extending Emberā€™s features with contributed addā‚«ons.

  1. creating a simple application

Profile: students++, intermediate to senior developers

Scope: architect, create business logic, integrate services and many add-ons. They focus on lots of topics, from the DX to the deployment. They extend their applicationā€™s feature, installing, and creating add-ons.

They want to get at one glance the main architectural picture; most of them prefer reference APIs with explicit examples rather than long tutorials. They donā€™t focus on anything, but a bit everything. All Emberā€™s concepts are important: from the DX to the shipping.

  1. create/maintain large applications

Profile: intermedia to senior + expert

Scope: they want to extend/contribute/fix every part of Ember (GlimmerJS, Engines, ember-data, ember-cli, broccoli, etc.)

I guess most of those people contribute to Ember - at least, should contribute x)). They donā€™t read tutorials, they write them. They focus on the reference API. They want to understand how to each layer works to be able to define the best solution of there needs on both, the build and run time.

Sum up

There are for me to distinct readers: the spectator and the player ā€” one who implements the existing and the other one who creates it.

I firmly believe Ember is the best choice for beginners. Learning Ember and get something working (components, websites & simple application) should be done with ease and no fear. Itā€™s a great for any developer, though :wink:

The biggest challenge for Learning EmberJS is to get away from the idea of ā€œEmber = big learning curveā€. Many essential concepts are straightforward on Ember (nested route, basic to complex state management, easy DI, powerful pipeline, well-organized file structure, etc) and not on React nor Angular.

3 Likes

I think there are a few different places people come from.

There are CTOs choosing what to build their next large project with. Those people probably have used PHP, Rails, Backbone, Angular 1.5, and React and whatever - and they already get the patterns. They can probably see the pros and cons from a distance. They can just look at the docs and get moving. They donā€™t need a skill tree - they have a ā€˜needsā€™ tree / and they pick out the solutions for each of those needs from the toolkit. You can just put anyone whoā€™s been developing full-scale web-applications in this camp.

Then there is a large group of people who are not from that background (like me) - who got excited about Ember and struggled a lot. Instead of learning Ember I kinda had to go and learn all of that other stuff and then come back to Ember. I think there are a lot of people learning Vue - who want to step it up / or people using React who want to try something else / and I think there is a way you can incrementally learn the system - without so many assumptions. On one hand, you canā€™t be responsible to teach new adopters things like ā€˜JavaScriptā€™ - but I think you can build in some conversations about Node and module systems - so that people can differentiate the Node and the Ember.

Maybe Ember doesnā€™t want that person until they have more experience. Ember just might be for people who already spent years with another system. At that point, theyā€™ll understand how everything works and be able to clearly enjoy its benefits.

I see a lot of ā€˜how to use Emberā€™ and not a lot of ā€˜What situations this toolset addresses.ā€™ Instead of a ā€˜skill-treeā€™ maybe there some other way to think of it. How does the CTO think of it? Could we teach it through that lens? Or, if you were learning web development/design from scratch what order would you need the tools?

I started writing out what order I would prefer https://github.com/sheriffderek/ember-skill-tree/blob/master/README.md - but I lost steam. Iā€™ll wrap it into a tutorial or something when octane is stable.

I am worried that putting up an intimidating looking ā€œskill treeā€, while might be helpful for people who have learned to at least an intermediate level, will scare away anyone looking to get started with Ember. Unless a comparable ā€œskill treeā€ were made for other frameworks, just seeing ā€œall the things I have to learnā€ will reinforce the idea that Ember is hard to learn.

1 Like

I mean, to be totally fair, we should probably have it be incremental.

Here in everything you need to know to make your own website with vanilla JavaScript.

Next, here is how you use modules and a bundler to get fancy

Next, here is ember (post-embroider, so we can tie in webpack)

1 Like

So many good input here, thank you a lot. Some statements I think that are helpful, so we all can move forward:

  • The idea of the skill tree is to have a pure list of skills and to what they lead to once you master it.
  • That said, the way you teach it is completely decoupled from it. Thatā€™s where pedagogic methods jump in to provide that content to cut it and serve it in the smaller sized chunks. The important part is, that a skill tree greatly supports these learning paths.
  • Each topic should also have the requirements listed to (web) topics, like vanilla javascript or how to use modules and packages. Each topic (on ember docs) can have something like a preamble part, that lists the requirements + links to their resources (e.g. mdn or npm) and maybe can also state what kind of skill is teached in the given article.

@Gaurav0 My background is sports :wink: If you compare a skill trees of artistics gymnastics vs. unicycling (hehe) vs. soccer. Thatā€™s 500+ skills for gymnastics, 1000+ for unicycling and just a handful for soccer :smiley: Rhetorical question: For what sport you would go for?

Yoember.com is try to add new concepts slowly. It worked for a while, especially easy to process if you already have some backend experience and you know other backend/full-stack frameworks, but you donā€™t really played with JavaScript before.

  • Install tools
  • Create an app
  • Run the app
  • Add Bootstrap style (learn about addon)
  • Add navigation (learn about templates, handlebars)
  • Create a new page (learn about router)
  • Add input box to a page (learn about computed properties, controllers)
  • Submit a content (learn about actions)
  • Add model (learn about Ember Data, route hooks)
  • Save data async (learn about promises)
  • Add Firebase (learn about adapter)
  • Clean up your app using components (learn about components)
  • etcā€¦

The main point is, that this tutorial havenā€™t focused on components when it was released, because using components became mainstream later. However Ember is strong to manage pages, routes, data, so you can create a full app in a few minutes and you have to use only your html/css knowledge. I still think, that learning about templates and routes is more useful at the beginning in the learning curve and going deep in the components later speed up the understanding of the framework.

Yoember is still popular, 3000 beginners (according to Google Analytics) learned about Ember.js in the last month from the website. It will be updated to the latest concepts when Firebase gonna release a new compatible ember-fire, so the app can use the latest features.

3 Likes

As @gossi you mentioned, there are some inputs :slight_smile:

How that will look like; how to let readers find their path between the skills (how to do) and the pedagogy (what you can achieve)?

Does it belong to Ember Guides on the website, or somewhere else?

New Ember Developer Roadmap is work in progress, Please let me know your thoughts https://github.com/rajasegar/ember-skill-tree

2 Likes

Iā€™d suggest that you trim that down. There is no reason to think about bootstrap (CSS) - when youā€™re outlining how to use Ember. This kinda just looks like the React learning tree - which has become sorta a joke / and is not a selling point.

1 Like

There is also a scope definition issue with this, too. Likeā€¦ what assumptions are weā€¦ assuming? Do people know how to use a terminal? Are we starting someone from a totally different career path?

If so, I donā€™t think including stuff like CSS is bad, but the overall scope would be: how to go from knowing nothing to being able to make web applications

Good point. My assumptions is the following. People have knowledge of:

webdev stack:

  • HTML
  • JavaScript
  • CSS

To be fair, not further specified to what extend and I canā€™t even think of a good way to do it - but at least I think basic knowledge to create websites/-apps is there (Iā€™m happy to hear how to measure that). For JS to at least understand inheritance (with the class keyword, not necessarily that js is using prototypical inheritance).

Skillwise to know what a terminal is, to use it and basically to be able to use ember-cli.