Eric Greene is a full-stack developer and appendTo/DevelopIntelligence instructor. Over the past 5 years, Eric has taught JavaScript and front-end development to several thousand developers at dozens of Fortune 500 companies. In the last 2-3 years, Eric has taught several hundred Angular and React courses.

We interviewed Eric to find out what he has learned about teaching front-end development for a living.

Outline

Teaching JavaScript first

Thoughts on teaching Angular

Angular 1 vs. 2

Teaching React

Where JavaScript is going

Let the programmers program

appendTo/DI:

Hi Eric, what’s it been like to teach JavaScript, and especially Angular, for a living? What are the joys? What are the frustrations?

Eric:

Happy to talk! But before I can talk about teaching Angular… the first comment I’m going to have actually has to do with teaching any of the JavaScript libraries or frameworks. Be it Angular and React and Backbone and Marionette and any other JavaScript framework or library you want to cover. The single number one biggest problem with teaching any of those is that most of the students don’t really know JavaScript. So, when you go to teach those classes, you’re not just teaching a framework or a library. You’re also teaching the entire language, or almost the entire language, that those libraries and frameworks are coded in. And that is really the number one biggest, most frustrating challenge.

It would be like teaching a Java class, for example, on Spring MVC. But you show up to class and nobody knows Java. This happens over and over and over again. It doesn’t matter who the training customer is. This is universal across the board.

The reason why I believe it’s such a big problem is that most people don’t have a proper respect for JavaScript. The problem that you run into is that when you start writing Angular, React, Backbone type applications, you quickly start to realize that JavaScript is a real language that has a lot of principles, concepts, ideas that go into it. When you actually start building applications that are 90% JavaScript code, you really start to leverage those ideas and principles. Not only do people not understand what they are, they don’t even know that they exist.

What happens is developers come into a front-end web development class that’s JavaScript-heavy and they think they’re just going to jump right into the framework or the library and they can’t because they don’t even understand the language it’s actually written in. That problem is further compounded, especially with React and Angular 2, because those languages make heavy use of ES2015. They make heavy use of other domain-specific languages or other sub-languages, like a TypeScript or a JSX that are basically further additions and enhancements to ES2015.

You basically come into a class with a bunch of people who barely know ES5. No concept of ES2015. No concept of these other languages such as JSX. They expect to hit the ground running writing code with relative efficiency and ease right from the start. They quickly realize that there’s this entire ecosystem of programming they don’t even know exists. They really have no idea of the knowledge they don’t have. They don’t know what they don’t know.

appendTo/DevelopIntelligence:

That makes sense. Trying to learn the libraries/frameworks without really understanding the underlying language. What would you say are some other challenges?

Eric:

The next part that’s really challenging, and this is more so true of Angular than it is of React, is that the APIs for the frameworks are really large. And the tooling doesn’t always give the best code completion or intellisense. JavaScript, itself, has a lot of the syntax which is kind of hard for people. Combine that with something like an Angular that doesn’t always give the best error messages, and you have a real challenge on your hands. There’s something called the injector error, which is basically a syntax error in your JavaScript nine times out of ten. But the problem is it doesn’t tell you where. You have to hunt through all of your JavaScript source code that you modified since the last time it ran successfully. The whole debugging process of that can be very challenging for students. That’s probably the second biggest frustration when it comes to Angular 1. It’s the JavaScript typos, the large API, and the error messages that are really hard to debug.

appendTo/DevelopIntelligence:

What specifically about the large API catches people or is really hard for people to get at first?

Eric:

Really it’s the tying of all of the pieces together. What’s a directive? When is it used? What’s a service? What’s a controller? What’s a scope? How do scope objects get bound to a template? How do forms work? When I set up something on a scope in one controller, how does that impact other scope objects? Child scope objects? Parent scope objects? Of course, all of those things are built around the concepts of prototype inheritance. If they don’t understand prototype inheritance, then they’re not going to understand the scope object hierarchy. If they don’t understand the scope object hierarchy, then they have a really hard time trying to build an application of any real size. Depending upon the chosen development tooling, there’s no real intellisense or code completion. For many developers, they’re basically back to just using a simple text editor. Although, this is getting better with tools such as Visual Studio Code and Atom. Editing all of this code in a simple editor and working with a brand new language and a huge framework can make for a challenging learning experience.

appendTo/DevelopIntelligence:

Interesting. What have you found helps people understand? What kinds of tricks do you use? I’m sure through teaching so many people, you’ve probably found quite a few little shortcuts to hacking people’s understanding of these.

Eric:

The biggest thing I do to help developers is that I write actual code from scratch, live. And I get my students to write code as soon as possible in the course.

It really doesn’t work to sit people down and go through endless PowerPoint slides and then bore them with highly scripted labs where it’s basically go to line 33, type in a line of code, and watch it run. Labs where students modify one function in the middle of some file without really having proper appreciation of the larger context doesn’t work at all. Sure, they feel good about themselves when it runs, but they haven’t learned anything. I have been told by so many clients about training classes where students sit through endless slides, prepared code demos and scripted labs, then get to the end of the training and are unable to actually code an application.

For people to learn, they really have to code something from the ground up where they actually create every aspect of the application. Let’s say I only had one day to teach Angular. What would I do in that one day? I would have them build a simple CRUD application that incorporates all of the major components of Angular and demonstrates how they work individually, how they work together, why they do what they do, and at the end they actually produce something that’s actually functional.

appendTo/DevelopIntelligence:

Yeah. Makes sense.

Eric:

And they will code the whole thing from scratch. There’s no pre-filled out file. No just going in and writing this one function. Because what happens is that people, instead of really digesting and understanding all the pre-written code, they just focus in on how quickly can they get the lab done. How quickly can I write that one function? And if you said “Okay, well now that you wrote that one function, now go back and build me a larger application,” they’re incapable of doing it.

Whereas if you actually have them build the application…there’ll be parts of the application that require more help and assistance than other parts. Maybe they wouldn’t be able to really completely rebuild the whole thing from scratch from memory. But, their ability to actually take what they have coded and then go use it somewhere is greatly increased because they actually wrote an application. That’s been my approach.

The other things I do to help people understand is that I believe strongly in doing public presentation of student code. I use group debugging sessions. When a student really isn’t getting it or they don’t understand it or their code is broken and they can’t figure out how to fix it, we have them plug their computer up and the students, the class as a whole, help to debug the application with them. Usually I step back as an instructor and sit in the back of the class and watch them. Then, if they get collectively stuck, then I’ll jump in and give them a little bit of information to keep moving them forward. But the key to doing that is you have to have an instructor who really loves to write code, knows how to debug code, actually understands how the technologies work, and is willing to jump in there and risk having something not work or break.

appendTo/DevelopIntelligence:

How would you contrast both learning Angular 2 versus Angular 1 for yourself? And how would you contrast teaching the difference between the two?

Eric:

When I first learned Angular 2, I knew what to look for. I knew the problem it was trying to solve and I just had to memorize the APIs to use it. The way you memorize the APIs is to write lots of code with it as fast as possible. If you write lots of code, solving the problems over and over again, you remember the APIs.

What’s the difference? The first thing you have to realize is that Angular 1, Angular 2, React, Ember, Backbone, Marionette, Dojo, is that they all actually solve the same problem. They’re all different ways of solving it. But at the end of the day, they solve the problem how do I build a UI in a web browser without having to reload the page? How do I build single-page apps?

The key is once you understand the various problems that have to be solved by the libraries and frameworks, then when you encounter a new library or framework, you just go figure out how that library or framework solves that particular problem.

appendTo/DevelopIntelligence:

What’s your opinion on how different libraries/frameworks solve the problem?

Eric:

It depends. Take Angular 1. Angular 1 is a much more we’ll say free-form, open-ended framework. Basically, you have this concept of directives. A directive can have a controller. It can have a template. Or you skip the directive and just have a controller and then that controller’s applied on a template somewhere. You can configure the scope object how you want. Set up your template variables, whatever. You have a lot of control.

In Angular 2, what they did is they incorporated the new popular pattern of web component-driven development. They took the concept of a directive that has a template and a controller and put it into a special kind of directive called a component. Now when we do Angular 2 development, instead of having a general purpose API, they now give you more specific APIs to work with. Less flexibility, but better application design and organization.

appendTo/DevelopIntelligence:

Can you share any specifics of where you think it got easier or harder?

Eric:

It’s easier in the sense of working with a component. Identifying a special kind of directive that’s called a component that’s basically a controller combined with a template and then provided a very specialized component called a component. But a specialized thing makes it much easier to work with because people can identify that specialized thing. But, it makes it a little harder because the more specialized things that you have, the more unique little APIs you have to memorize. But if you think about it like this, JavaScript, the built-in DOM functionality in a web browser is probably the most free-form, easy way to go about building anything. You have the most freedom. But the result of that is that you have to come up with all the conceptual ideas yourself.

Whereas, when you move to a library, the library solves certain problems for you. But, you still have to do the overall conceptual idea of ‘how do I put all the different libraries together to actually then build a framework for my solution?’ When you go with a framework, it’s much more controlling and specific about how to do things. But, specific and controlling is relative. Angular 1 is much more free-form, less specific, less controlling. Angular 2 has more patterns that are baked into it, like component-driven development. You can do component-driven development in Angular 1, but you don’t have to. In Angular 2, you don’t have a choice. With all that said, Angular 1.5 now has a new component API built into it showing the importance of the web component pattern.

appendTo/DevelopIntelligence:

How is it teaching Angular 2 so far? How do students take to Angular 1 vs. Angular 2?

Eric:

I find that covering the same material in Angular 2 takes longer than Angular 1. I’m not really sure why. I think part of it has to do that in Angular 2, everything is in ES2015 (well, TypeScript actually). So, in addition to learning “normal” JavaScript, now they’re learning TypeScript. This requires more time to cover all the strong typing and everything else that goes along with it. Also, because of the component-driven pattern, you spend more time talking about component-driven design. I call it composing components. Taking multiple components and putting them together to build larger components. This composing process proves to be challenging for many students. But that’s something that I didn’t spend a whole lot of time on in Angular 1 classes because I didn’t force them to go down a specific pattern path. Instead, I taught them how the Angular 1 API works, all the ins and outs and details of it, but didn’t say ‘oh you have to do a component-driven pattern’.

appendTo/DevelopIntelligence:

Let’s talk about React a little bit. What’s your thoughts on it? What’s it like teaching on it? How are people learning it?

Eric:

I think React is great. It’s a great little library. It’s great for building components. It’s a little bit different way of looking at the world. So that can be a little challenging for students.

appendTo/DevelopIntelligence:

How so?

Eric:

In terms of understanding the flow of data and understanding that everything is uni-directional in nature. The DOM never directly updates the underlying model and user interactions never directly update the DOM. Instead, the DOM fires events and the events are handled by React to update the underlying model and then update the DOM again with the result of the changes. Consider the process of typing into an input field. Instead of taking the value typed in and updating the model or DOM, that value is passed through an event, which then gets passed back into the component. Then the component handles it. It’s the one way data flow that people are not used to (especially when they come from two way data-binding frameworks).

Because of this, it becomes a little bit more challenging for them to understand the flow of data in React. But on the whole, React itself is actually pretty easy to teach once people understand ES2015, which is the only way I teach React. The reason we only do ES2015 is that you have to use a transpiler for JSX anyway. So, if you’re going to use a transpiler for JSX, you might as well transpile the ES2015 code too. Why intentionally write your code in an old language?

We basically build a CRUD application, but it takes longer to teach then Angular 1. So, the same CRUD application that I can build in a half a day in an Angular 1 class, takes us all day in a React class. Because it is only a library and because of the way the data moves, it requires a little bit more work to accomplish the same thing.

appendTo/DevelopIntelligence:

Explain that process. What do you have to cover with React in a longer amount of time than what Angular allows you to do in half the time?

Eric:

It just takes longer. With Angular, because of the whole template two-way data binding and automatically hooking up of the data from the model to the view, it just all works right out of the box. In React, you have to wire up a lot more stuff. Wiring all that stuff up just takes longer to accomplish.

You’ve got to look at it from this perspective. Angular is a far larger topic. So with React, once you have your component working, you’re done. You’ve covered React. With Angular, once you have a component working, that’s great. But there’s so much more to it. There’s filters or what are known as pipes. You have services. You have a bunch of complex unit testing stuff and React has some of that too. But there’s more to an Angular application than there is to React in terms of the library versus the framework. But when strictly building the Hello World CRUD application, more work is required for React than it does in Angular.

appendTo/DevelopIntelligence:

What do you think are the advantages of React or advantages of Angular over React?

Eric:

React and Angular 2 have the advantage of following this whole component-based development paradigm. I would not choose Angular 1 to build any new applications whatsoever. Even though you can take a component-based approach with it, I think that having a framework or a library that has the component-based pattern already baked into it is far better.

I like Angular 2 a lot. I think it’s really cool and I think it’s going to be super successful. I think it’s going to be a learning curve for people because it’s not just a new framework. They have to learn new languages and new tooling and everything else.

appendTo/DevelopIntelligence:

If you were to teach a class where you had to build maybe more of a medium-sized app, something that’s a little bit more complex or interesting than Hello World, would React and Angular take more or less time? What does this look like beyond Hello World?

Eric:

Angular, to do that, takes about a week with Angular. Really it takes a little longer than that. I have yet to teach an Angular 2 class where we were actually able to complete the medium-sized app within the week. Because there’s so many moving parts and pieces to it all, as well as, many new ideas and concepts that students have to learn.

There’s a bunch of subtopics that are emerging out of the React and Angular 2 worlds. Things like immutable programming and reactive programming. These topics in and of themselves are huge. How you leverage them within these frameworks and libraries is actually a really important thing to consider, discuss and talk about in a class. To really build a full-blown, medium-sized application and really leverage the lot of these new ideas, you probably are looking at longer than a week to do that in Angular.

On the React side, it’s a little different because React only does the component part. So, you have to answer a bunch of additional questions about what pattern do you want to use for architecture in the overall application, be it Flux, Redux, or MVC. How do you want to utilize React as part of a larger application? That’s a little bit harder to answer.

appendTo/DevelopIntelligence:

What are your general thoughts on where the JavaScript ecosystem is going and what works and what doesn’t and how it’s evolving?

Eric:

Well, I think the component-based approach is the way to go in terms of building a bunch of UI stuff. Any framework or library you’re going to use from a pattern standpoint and from a technology standpoint should be embracing the whole concept of components and everything that entails. That’s number one. Number two, in terms of the JavaScript language and tooling itself, I see transpilers becoming very important and very big. Basically, JavaScript will continue to advance and improve but the browsers will take a while to catch up. So transpilers will become more important and commonly used.

I see languages like JSX and TypeScript and CoffeeScript becoming the norms, not the exception. You’ll still do JavaScript programming, but you’ll be doing it within the context of another language that transpiles the code ultimately out to regular JavaScript. Those transpilers can always transpile out with whatever the current version of JavaScript is, while making the latest features that are being discussed or the latest little sublanguages, whatever you’d call them, available to people now. Because you already have to have a transpiler anyways with the Typescript and the JSX, having another plugin for your transpiler isn’t a big deal.

Those are really the two big things I see happening in the JavaScript world. Component-driven development and transpiling.

appendTo/DevelopIntelligence:

Any other thoughts to share on JavaScript, Angular, and teaching programming for a living?

Eric:

My philosophy is to give students, lots of opportunity to write code. They’re programmers. We need to hold them to a higher level. They get paid to write code for a living. They should be able to write code, learn great new technologies, and quickly learn how to apply those technologies. I find that in almost all circumstances that when you have that expectation, the students are able to deliver. You’re able to really activate that creative, problem-solving part of their brain as opposed to the passive ‘how fast can I get through the lab’ aspect of their brain.

Many of the students went to college and spent all this money on degrees and everything else. It’s really amazing how many of them really haven’t written a whole lot of code. Not a whole lot of code on their own anyway. They might have copied and pasted a lot of other people’s code. But, if you said build me something from scratch, they really can’t do it. The sad part is that they’re really missing out on one of the greatest joys of being a software developer. The ability to be creative and express how you solve problems. What’s your view of the world? How should the world be organized? The real goal of my classes is not to learn APIs or master patterns, the real goal is for students to solve problems through writing code by exploring their creativity and curiosity.

Truly, software development, unlike most professions nowadays, is a reflection of the person writing the code.

Kind of like a carpenter or a blacksmith 200 years ago or a 100 years ago. Their work would reflect who they are, while today we have machines that do all that for us. Just like a painting reflects the view of the world of the painter, the program reflects the view of the problem from the programmer’s perspective. It’s their ability to contribute something back and really use their gifts and talents and abilities that God gave them and actually make something with it. By not letting them do that in class, you’re really robbing them of a great opportunity.