I talked with my friend Tero Parviainen about his outstanding Angular book, Build Your Own AngularJS, as well as what it was like to transition from Java to Rails to front-end, as well as CoffeeScript vs. ES6, Angular 2, and a few other topics. Enjoy.
Jason Swett:
Hello everyone, I’m Jason Swett, author of angularonrails.com. I’m here with my friend Tero, author of “Build Your Own AngularJS.” Tero why don’t you introduce yourself tell us who you are, what you do and that kind of thing.
Tero Parviainen:
I’m Tero Parviainen. I’m a programmer from Helsinki, Finland. And I’ve been doing web development for about 13 years professionally. I started from doing Java stuff in the early 2000s and then moved on to doing Ruby on Rails for several years and did a little bit of Clojure.
Still doing a little bit of [inaudible 0:00:50] . For the past couple of years I’ve really been doing front end development. JavaScript essentially.
Jason:
I would like to talk about those couple of transitions that you’ve done, because that’s a pretty common transition to write Java to Ruby.
Tero:
Yeah. It’s definitely seems to be.
Jason:
What prompted that transition for you?
Tero:
It was mostly that doing web applications in Java was really painful. It’s almost ten years ago now it goes only 2006 and 2007 time frame when Rails really started hitting their fees all over the place.
Back then it seemed like a lot more productive than Java which it was. I convinced my boss to try to use it with something. We failed miserably but we did not blame the framework luckily. We did second thing with Rails and that was a success.
I haven’t really looked back since to Java the language that much. I have been working with the JVA model Java virtual machine the whole time. I did a lot of JRuby at some point and turn, of course Clojure’s based on that. The language itself I really haven’t done any since Ruby.
Jason:
As far as Ruby and Rails to the front end and stuff, what prompted that transition and obviously, unlike Java and Ruby, JavaScript and Ruby can co-exist in the same application and so may be use them together. What prompted that transition and you still do the real stuff?
Tero:
At some point it became apparent that we have to do to some heavy front-end applications, because it wasn’t enough to have a little bit of jQuery sprinkled into your Rails application. I went into the rich Internet application thing quite early on when they were still called that.
Did it all off Google Web toolkit at some point which was Java. Then flex was one of those things that I did. The Flash action script thing. From there it…
I followed the industry. Backbone came out, then Angular, and now React. Pretty much following what everyone else is doing at this point. Seems like that at least.
Jason:
What did you think of Backbone?
Tero:
Backbone was really refreshing after the things I was doing before that, which was mostly Google Web toolkit, because it was so lightweight and so small. It seemed to encourage the application architecture that was also small and simple. I liked it.
Back then I didn’t really miss the things we have now with data binding and things like that that we get with newer frameworks, because I hadn’t tried that yet. Backbone seemed to be like everything you need. It doesn’t feel like that anymore, but it did then.
Jason:
How did you get into Angular from Backbone?
Tero:
It was most Angular, originally mostly because it was used in some project that I went into. I didn’t choose it. It was there. That’s how it started, but obviously since then I’ve heavily gotten into Angular.
Jason:
For me, it was as much of a career and business decision as a technical decision. I really wanted to bet on the winning horse. If you think back to when was it, mid 2000’s, the whole prototype versus jQuery thing.
Obviously, if you’ve invested your whole career in being the prototype guy, then that would be a lot of time, I don’t know if I want to say down the drain, but probably invested in jQuery, because that’s the framework out of those two that won.
I definitely didn’t want to back the loosing horse as far as the JavaScript application frameworks or whatever you want to call them goes. That was part of why I picked Angular as opposed to Ember or something like that.
I don’t really see Angular and Backbone as being really for the same thing. They do some of the same stuff, but they’re not really apples to apples I would say. What do you think about that?
Tero:
Yeah. They are not directly comparable mostly because Backbone is such a minimalist framework and it’s meant for different things essentially. Definitely it’s always a gamble what you choose especially if you want to make sure that it has longevity, which customers are very interested in.
They ask if this is something that we can maintain five years from now and looking at our track record as a front end community I don’t think we’ve done that well with that but its mostly because things are really new, still, at this point.
Jason:
And its almost like are things going to converge and get easier? Or are things going to accelerate even more? It’s not clear to me.
Tero:
Yeah. Both of those things are probably going to happen at the same time. The best bet is to really learn the standards. Like what’s underneath. What JavaScript is, the language itself and the standards around that and HTML and CSS and things like that.
Because their rate of change is also increasing, but its much slower than the frameworks on top. And the web is really pretty much the only platform that’s remained stable for about 20 years now.
Like if you open one of the first web applications that came out in the 90’s they still work when you open them in the current browsers. Can’t say the same of anything else.
Jason:
Yeah. That’s a really interesting point. I haven’t really thought about that too much. I haven’t had occasion to do that, but that would be really interesting, to open up some page from so incredibly long ago and see how it performs now.
I’ve also done the opposite a little bit where you open something in IE5 or something like that and see how bad it looks on that.
Tero:
Yeah. It may look terrible but it still usually works.
Jason:
Right. So speaking of all the different divergences and different options and accelerating rates of change and stuff like that. The JavaScript language itself is getting more splintered in that if I’m writing an Angular app today.
Let’s say, I can choose to write it in ES5, ES6, Typescript which I understand is going to be what Google wants to be the standard for Angular 2.
Or if you come from the Rails world, you’re probably familiar with CoffeeScript, you’re probably used to using that. And so its like, “What. Now do I switch from CoffeeScript to ES6 because that is where the puck is moving to?”
“Do I stick with CoffeeScript and if so what’s going to happen with that?” “Am I leaving anything on the table by not using ES6?” Its a decision that’s totally unclear to me. So what are your thoughts on all that stuff?
Tero:
Yeah. Its unclear to me too. I’m currently using ES5 in my customer project, but I definitely see myself going to ES6 for the next one.
Pretty much regardless of what framework or anything might be used there because it’s the next version of JavaScript that is going to be the most common denominator from now on and the Transclusion also get to know that. That it’s not really that painful to use either.
I did use CoffeeScript a lot at some point. It seems to me that half the good things about CoffeeScript are in ES6. Many of them are there. Not all of them like the expressions by default and the significant white space on the indentation and things like that are not there.
But those were always like the controversial features anyway. So its good that they are not in ES6 because that would have been a big fight but I don’t see myself using CoffeeScript much in the future. Probably ES6.
TypeScript I haven’t tried yet so I don’t really know what I think about that yet. Except that I’m comfortable doing untyped languages because of my history of Ruby and Clojure but now that I’ve been getting into the Angular 2 source code and reading that.
Comparing that to the Angular 1 source code, it’s a riftic difference. It’s largely because of the type of information that they have in those.
Jason:
You find Angular 2 source code easier to read than one?
Tero:
Definitely, yeah. It’s partly due to the fact that it’s new and it’s clean and it’s organized much better than Angular 1 that has this history of seven years or something like that — six years.
Behind it but also when you look at a function declaration in TypeScript you see the arguments are supposed to be of this type and it’s supposed to return this thing which you can’t see in ES5. It helps a lot when you’re trying to get into a code base and I don’t know what it’s supposed to do.
Jason:
Yeah, that’s a good point and I myself fear my background is in Ruby and before that PHP and so I don’t really know what I’m missing out on by not having that stuff but I can see how coming into a new project that I’m not familiar with…
Seeing what types of parameters certain functions expect and stuff like that, that can go a long way as in picking up that unfamiliar code base more quickly.
Tero:
Definitely, I get into trouble with my own applications as well. In ES5 because I can’t remember whether this was an array of objects or arrays of objects or whatever. Those are the things that you get over by debugging or adding console statements or whatever, to help in these situations.
The types are optional in TypeScript, I might be wrong about that. But that also helps that you don’t have to do it all the time if you don’t want to.
Jason:
Yeah, that’s my understanding too. At the very least you don’t have to, if you want to use ES6 with Angular. You don’t have to use TypeScript if you don’t want to.
Tero:
Yeah, they’re saying that very strongly that you don’t have to as an application developer use TypeScript. I don’t think you even have to use ES6, you can still do ES5 even it won’t be as pleasant but those are not requirements for us.
Jason:
How much have you gotten into Angular 2 so far. You mentioned reading the source code and there’s more and more becoming available that they’re putting out there. What are your thoughts on what’s emerged so far?
Tero:
I haven’t built anything with Angular 2 yet, I’ve gone into the source code mostly because it’s what I’ve been doing with Angular 1 for such a long time with my book project that I want to compare and contrast what they’re doing.
Jason:
Yeah and by the way that in totally been switched up, it’s in the middle of that but tell us about your book. Talk about that a little bit. What made you want to write that? How did that go? All that stuff.
Tero:
The book started from an article I wrote and that started from the fact that I wanted to learn how Angular works.
Angular seems to be one of those technologies that are a little bit difficult to learn because everyone was saying that like no one understands Transclusion or whatever it is, myths that are going around. I’ve had this experience with some technologies in the past like when I was doing Java.
There was a couple of frameworks and libraries that I never really understood. There are parts of Rails that I never really understood how they work, you have to do these things.
Then it works but you don’t really understand what it’s doing and it’s not pleasant to have to rely on, superstition when you’re using something that because you don’t know what it does. The best way to fix that is to look at the source code and see what’s in there.
I started doing that and then it wasn’t really enough to even do that, but really to understand and I started thinking maybe I should reverse engineer this and try to replicate…I started from the scopes and that changed detection system.
I wanted to understand how it works, how does it detect changes? When does it detect changes and how all that builds up to the framework. That’s what I did for the article. That was in the fall of 2013 and then I published that and it got a very good response.
People really seemed to like that approach because it seems that many others as well had the same problem as I did. I started writing that book then and it was a six month project. I started 18 months ago and I’m still doing [laughs] . It’s been very large project.
The book is 800 pages now and I’m not done yet.
Jason:
Yeah, I noticed. I bought the PDF and all these eBooks are on the short side. I looked at the number of pages and I’m like, “Is that right? It’s gigantic.”
Tero:
It is mostly because there’s a lot of code in there. I have this approach where every feature in Angular that I introduced, I write a failing test first, not the units test. Jasmine test case for it and then augment the production code base to make that test pass.
A test driven development the whole book. Those tests add up to a lot of lines and a lot of pages. In that sense the text in that book isn’t that long as it sounds when you say 800 pages. It’s a lot of code. It’s certainly longer than I had planned for it to be.
Jason:
It sounds like it. Both in terms of how many pages and how much time and effort it has taken you to put into it but you’re probably learning a lot as you do it, right?
Tero:
Yeah. The next topic I’m going into is now Transclusion and I hope to finally understand it now when I get into it because I still don’t, even though I’ve been using Angular for a couple of years. I know what it is but I don’t really understand how it works.
Jason:
There is stuff that you think you understand but you never really have to articulate it to anybody and I’ve heard things like that in the not too distant past where somebody asked me, “What is active record?” I was, “What do you mean what is active record?
It’s a thing we use every single day.” Then you try to articulate it, what it is and it’s like way, “I can’t put this into words and if I can’t put it into words maybe I don’t understand it as well as I can stand to.”
That’s definitely a valuable exercise to take those things that…you might have been using them for a while and you understand them well enough to use them, to understand it well enough to be able to teach it is sometimes a whole different thing.
Tero:
Oh definitely yeah. I totally agree with that.
[chuckling]
Jason:
Let’s talk about testing a little bit because it sounds like you’ve done quite a bit of that with Angular and that’s and that’s an area that I definitely struggle with in Angular and I think a lot of people do. A lot of people in my limited experience talk with other people about it.
They totally skip that part because they don’t understand it. If people could understand better how to get into that, maybe it wouldn’t be so intimidating and confusing and people will get into it more. For me, there seems to be a certain stress hold below which the test don’t have all that value.
Like when I’m testing for example a controller that’s a couple of lines a code maybe there’s an HTTP request happening and my test is like everything is marked out and all I’m testing is that a certain function got called.
It’s not testing for a mistake I usually make and so a test is seems to be worthless. It’s like, “Why did I even do this?” But then on the other hand, it feels totally irresponsible not to have any test at all. What are your thoughts on that?
Tero:
Yeah, I feel that same thing. Let’s see… I do skip those kinds of test these days, pretty much all the time. There was a time when I felt like I have to test everything because someone has read it from somewhere. But these days I usually don’t test drive everything at least.
I usually only write test when I feel like I’m unsure of something, which happens relatively quickly whenever there’s anything none trivial in the code. I test a lot but I don’t test everything.
Essentially things like the case that you mentioned where a controller pretty much calls a service or something and puts the results on some attribute.
That’s not something that I usually bother to test because as you said, everything the test does is expressing the same thing that’s in the code in a slightly different way and it doesn’t had much to testing.
But, as soon as there’s some logic in there’s some new statement or there’s anything none trivial than it usually becomes more impossible to do that. Also as to the challenges of testing in Angular, it always been difficult to test UIs as long as I can remember at least as long as I’ve been doing it then.
The way I usually deal with that is those parts of it that is interesting that I described. I pull out from UI code, to ordinary functions in some services or factories. Then I test them as pure logic.
Give them some input to see what the outputs are, try to pull out all the stuff that’s worth testing out from anything that’s really UI specific or even Angular specific, but you plain java script objects.
Jason:
That makes sense and it sounds like an angular too. They are making efforts to make things even more separated. You can get out that stuff even more conveniently to test it.
Tero:
Yeah, it does sound like that and I’m looking forward to working with that.
Jason:
I want to talk a little bit about directives because that’s something that took me a long time to even get to the level of understanding I’m at now. I still have a feeling that there’s something I’m not quite getting yet. Maybe you could talk a little bit about that.
What triggers you to say, “Hey, this looks like something that would be appropriate to write a directive for” that thing. When do you find yourself writing directives?
Tero:
It used to be the case when I find myself writing directives when I felt like I wish this tag or this element exist in HTML or the type bar or whatever.
Jason:
Yeah. You said that thing in your book about list. Like Paul Grimm had that thing about building a program from the bottom up with list as well as the top down and directives apply to that idea. I thought that made a lot of sense.
Tero:
Yeah, it made a lot of sense and that’s definitely one used case for directives but what I did not understand at first is that directives are really everything in Angular. You can use them for everything and you probably should because they…you can use them in so many different ways.
People often think of them as something that’s the alternative to controllers which was also what I looked at them at first because of I understood what a controller is from backbone.
And even things like Rails and thought that was an important concept in Angular and separate concept from directive but that’s not the case. The controllers in Angular are really a tiny little feature built on top of directives or at least the ng-controller are stuff.
That you use in your views. Whenever you use engine controller, you can make a directive. People have started to call these kinds of directives as component directives because they feel like components where you have a list of users or user view or whatever.
That’s exactly what Angular 2 is doing now. They’re adding this concept of components that are like web components but in the Angular framework. All they are, are most trimmed line API to the directives that we have in Angular where you have a directive that has a template, an isolate scope and controller.
For the past few months I have been writing everything from those on the UI level. So there’s no ng-controller anywhere. There’s no NG include anywhere. Everything is a component, so essentially, everything is a directive. But…
[crosstalk]
Tero:
…Directives is that there are these different used cases for them that they are not separating Angular 2, which are the components, the template directives and the decorators.
That’s what makes them difficult to think about when there are so many different used cases built into this one application service or this one concept, which they are now changing. That has been my path.
Jason:
May be we can dig a little bit into a concrete example to make that a little bit easier to understand on the example of a rapid payday loan website. Say I have a form and it has five fields or something like that. Obviously, we all know how you will rate in traditional HTML. Along what lines might that break up in terms of directives?
Tero:
That depends a bit on the application. The way I’ve done it is that you might have component called “Your user editor form” and that’s a directive essentially.
Then, when you dig into that component’s template, you see some more components like probably a text field component that consist of an input, the label for it and maybe some validation or configuration for it.
It’s the level of extraction on top of the standard HTML elements, that’s application specific. It’s really not that dissimilar from what they do in ember. Essentially, that’s what they do in Angular 2 that you can in Angular 1 as well.
Jason:
You find that this makes it easier to make you code less repetitive and stuff like that because I can imagine if you have a directive for that particular form that exist one time, but then inside of that you might have a form directive that’s generic to all your forms in that application.
It might not just be a regular form tag, there might be more to it because everywhere in your application, you want to have your forms a certain way and then same with you input fields and stuff like that. Does it take out a lot of the repetition?
Tero:
It takes out some repetition and it seems to essentially do that mostly in the sense that it makes things easier to reuse because you have these more contained things that you can put in different places.
The main problem I had with the ng-controller was mostly to do with how it makes things not in capture, like you have these inherited scopes and you start to share things via those scopes.
Then you are in trouble because of a sudden your controller depends on something magically being from the parent scope and you can see that everywhere. The way that introduces repetition is that you have a similar used case somewhere else in your app but you can’t take this code.
And put it there because you haven’t set thing up over there the right way or it’s difficult to use that same controller or the same template over there. What our components really help with that is that the components enforce this isolate scope.
Or you enforce it on yourself really but you this rule that every component has an isolate scope which means that all of its inputs are explicit. You have to pass them in as an argument. It can’t see anything else from the surrounding scope.
When you see a component used somewhere in your view, you see, “OK, it has the attributes, that’s what it needs and it doesn’t need anything else because it can’t see anything else.” Then you can say, “OK, I will use that same thing over here.” You can be relatively certain that it will work.
Jason:
OK, that makes sense. You wouldn’t want too much data to be implicitly flying around because then you’d have these hidden dependencies that would get pretty mysteriously, pretty quick, I can imagine.
Tero:
Yeah, that’s what happens to me at least. I have heard similar stories from other people.
Jason:
Taro, who would say your book, is good for? What kind of person will find it most interesting? Where can we find it? Where can we find you if you want to share your Twitter or anything like that? How can we find your book and then you?
Tero:
The book is not the first Angular book you should get if you are thinking of learning Angular. It’s probably the one you should get when you’ve built an app and felt that you don’t understand the framework as well as you would like.
You really want to get deep into the level where you understand how your framework works, so you can extend it when you need. You understand when it gives you strange areas where those come from and how you can fix them.
You have the mentor model of the tool that you’re using and that’s your application, there’s no barrier after which the code becomes mysterious, which quite often happens with frameworks. That’s really the purpose of the book.
I’m self-publishing that book which is on my website, which is Teropa, T-E-R-O-P-A.info, which is also hosting my blog where I write about Angular and other topics. You can get the book from there and you can also reach me on Twitter, which is the same handle there, Teropa, which is T-E-R-O-P-A.
Jason:
Awesome. Tero thanks a lot for talking with me, a lot of good stuff that you share. Go check out Tero’s book everybody. All right, thanks Tero.