Several members of the Oasis Digital team attended ng-conf in Salt Lake City recently. This month for the St. Louis Angular Lunch (April), we had a roundtable discussion of the conference and what we all learned at it. Here’s a video of the discussion:
Transcript
Here is the discussion, transcribed to text. This is a lightly edited, draft transcription, so any errors are probably from that process.
Michael McNeil: So, welcome to our April Angular Lunch. I’m Michael McNeil, the general manager here at Oasis Digital. Our topic today is the Angular conference, and we have four of the attendees in that conference that are speaking here to the group.
Because of a technical snafu, we did lose the introductions from the original live video, so we’re recreating the introductions here, but all of the audience comments were captured.
So, we have with us Bill Odom, who is an instructor in our Angular Boot Camp class. We have Paul Spears who is also a lead developer here at Oasis Digital. Jack Balbes who’s also a developer here at Oasis Digital. And Kyle Cordes, who is the principal and founder here at Oasis Digital. We’re here to talk about the ng-conf.
Bill Odom: Two big things leap to mind for me. During the opening keynote, a couple of members of the Angular team really made a point of — I won’t say walking back their earlier stance on Angular 2.0 — but they definitely put a different spin on the way that we’re going to get from where we are now to Angular 2. I know that in the wake of the European NG conference, ng-europe, several months back, there was a lot of controversy and confusion around what happens next with Angular. A lot of people felt like their investment in Angular 1.x had been wasted, and everything was just going to be thrown away, and everything was going to be totally new under Angular 2. So, what had been the point?
The Angular team worked very hard, and I think did a really good job of communicating that they see themselves as shepherds and stewards of a very important community and framework. So, they’re taking a much more orderly approach to getting us from where we are now to where we’re going to go. They walked right up to line of saying, “We’re really sorry for how we talked about this before, and please give us another chance.”
But that was kind of in the air.
I think they did a really good job of recasting a lot of people’s thoughts and perspectives on that. I know I personally feel a whole lot better about how we’re getting to Angular 2 and what it will take for us to move from where we are now to actually using Angular 2 in production.
The other thing that really impressed me — and I think this was treated a little bit in the keynote, but probably more as just kind of thematically throughout the conference — is the spirit of collaboration and cooperation among a lot of the major framework contributors.
Microsoft was a surprising presence at ng-conf. They were on stage with Google several times talking about the work that Google and Microsoft are doing together because Angular 2 is going to be written with TypeScript, which is a Microsoft variation on javascript. I found that very impressive.
There was also talk of cooperation between core members of the Ember team and the Angular team. Yehuda Katz was brought up and he is extremely well known in both the Rails community and in the Ember community. The fact that he is a significant contributor to what will be happening inside of Angular 2 is very, very impressive. The team actually went as far as to say, Look. This is not about some sort of misplaced competition, or tribalism among the different frameworks. There doesn’t have to be a winner and a set of losers. This is much more about doing a good job of solving users’ problems. And sometimes the right solution will be one of these other frameworks and that’s not wrong. We should all be working together to make everything that we do better.
They seemed really serious about it. I hope that spirit gets out into the larger Angular community and these other communities as well. Because it’s very easy for us to take pot shots at each other. But it’s a lot more effective, and frankly a lot more fun, if we’re all kind of working toward similar goals. We want to make the world better. We want to make our users’ experiences better, and the Angular team was very, very open and forthright about that. I found that very heartening.
The migration path from here to Angular 2 and the sense of collaboration and cooperation among the Angular team and several other major framework creators and contributors, those were the big things that stood out for me.
Paul Spears: For me, the two major highlights. One of them was getting a chance to actually see the Shadow DOM in use. We actually got to see a presenter go up on the stage, write some real code, show some real code, see it running. Just showing how the shadow dom is going to play a role in Angular 2.0. That was for me the first time I’d actually seen the actual code behind that, and to see how that actually affects performance, and the talks surrounding performance in addition to that. All that was real nice to see, and being able to have more confidence in Angular moving forward, and being able to address the areas that are kind of sticky right now in performance.
The other area was…. Bill mentioned it a little bit when Microsoft got up and talked, and they actually announced that they're doing away with AtScript. They're no longer making another variation of JavaScript that we have to learn. Now we're just using TypeScript on top of JavaScript, and being able to just pick one path to go down and improve it rather than diverging in yet another different language.
That was a real big moment for me where I'm just like, yes. This is great. Finally we're trying to come together and improve the cooperation between these various companies, and seeing how well Microsoft and Google are playing together and are getting serious about real collaboration, and I am really excited to look forward and see what happens there.
Jack Balbes: So yeah. So building up off of what Paul and Bill said, it was interesting to see a little bit more light shed on the path forward to Angular 2 and what that's going to look like, seeing the presentation about the new router, which is going to be a big piece of that path forward, being able to selectively update or upgrade pieces of the application to Angular 2 and leave it, so that you don't have to do it all at once and kind of amortizing that cost over time was really interesting.
Another fun talk was the “ng-wat” talk, which I definitely recommend going to taking a look at if you've done any kind of work with Angular. You'll have run into these things that this [Shai Reznik] guy is talking about, and you'll have a good laugh.
Kyle Cordes: I would echo everything everybody else said, but to me really the unifying theme was maturity of the platform. Obviously 2.0 is going to be a big leap forward in maturity, but even short of that, even in the 1.0 version series, they're no longer talking about sunsetting it soon, they're talking about continuing to polish it and fix things. There have been many more bugs fixed since last year.
Many of the important new features, especially the router, are going to be available in the 1.x sequence. Animation has some new stuff coming. You put that all together, and there's just been a huge focus on the maturity and suitability for building big, complex systems. I think we've seen a lot of implicit focus on that all the way across the Angular toolset, compared to, say, a year or so. We're really looking forward to that, because that directly impacts our work every day.
Participant: What are they doing to mitigate the threat of having the Python 2 vs. 3 dilemma? Will there be enough incentive to actually transition from 1.x to 2, or are we going to have two environments?
Paul: Yeah, so I think the biggest way that that's going to be mitigated is the fact that they are making very sure that you can continue to write 2.0 apps without ES6. The hardest thing to kind of wrap your head around when looking forward to 2.0 is realizing that it has less to do with the Angular changes, and more about the changes in the surrounding technology.
So, yes, you have two different environments, 1.x and 2.0. But the differentiating factor has more to do with your team's capabilities of picking up the latest web development technologies as a whole in dumping those into your stack. If you succeed at that and learn how to adopt those technologies, then making the Angular transition is pretty non-trivial. That’s how it's appearing to me.
Bill: Another thing that I would say is, while they've committed to supporting, and they've been very public and loud about that commitment. What that translates to, at least from what we're hearing is, 1.4 and 1.5, with 1.4 I think was released yesterday or the day before? I think it's finally real. And then 1.5 being a transitional release between the 1.x and the 2.0 release. But what they're not saying is "And we will continue to make 1.x better and better forevermore.” The energy around improving the framework and making it do more, bigger, better, faster, stronger, is clearly going to be focused on 2.0 going forward. And if the folks at a place like ng-conf (and this may be a mistake), but if the folks at a place like ng-conf can be considered somewhat representative of a community, people are very, very excited now about 2.0, whereas before they were extremely wary and cautious.
People want to be able to take advantage of what they're seeing coming. Because, as much as we all like Angular in this room, we all know that it's got kind of a "learning wall" associated with it.
2.0, from what I am hearing, if they manage to pull it off, is a lot easier to get into. So, as big and popular as Angular 1.x is right now, it wouldn't surprise me if we didn't see a much faster adoption of 2 than we did of 1, simply because it looks like it's going to be a lot easier to get into.
With that said, it's evergreen browsers only, it's not reaching back into IE9, IE8, things like that. So, there will be a natural division between the folks that can adopt it, even if they want to, which is one of the reasons I think that 1.x will be as well supported as they're claiming it will be, for some period of time because there's just not really any other choice for a huge fraction of the browsers that are extant in the world right now.
Anyway, the excitement around what 2.0 will bring, the additional simplicity of it, the fact that it will be better optimized for things like native or for mobile development. There are a lot of carrots out there to bring people over to 2.0. Oh, yeah. Definitely speed. So, the fact that we'll have a reasonable transition between here and there doesn't necessarily mean that there'll be a lot of incentive to just sit there forever and ever, just cuz. Is that fair?
Participant: Someone in this room told me (I don't know if I should reveal their name, Chris Harden) that one strategy for migrating is to, right now, start using the new Angular router. And, do I understand correctly that if you do that, feature by feature in your existing app, you can have some that are using Angular 2, some still on Angular 1. Did they talk about that at the conference?
Kyle: Yeah, they went on about that quite extensively. About how the new router is… Is it available in 1.4? Do you remember?
It's supposed to be.
So 1.4 RC0 just shipped about 4 or 5 days ago. And apparently includes the new router, and although you can't realize this today because 2.0 hasn't shipped, you're supposed to be able to intermix route by route, 1.x and 2.X. So they will be able to easily coexist. Not only can they coexist on the same page, they can actually be mixed together in the same application. I am a little skeptical how well that's going to work, but I'm encouraged they're at least going to give it a shot.
Jack: I was going to add that also. Kinda goes back to the previous question of saying "Okay, well, how do we make that transition easier from 1 to 2?" That makes it a lot easier if you can do it piece by piece.
Absolutely. Hugely easier.
Participant: So, a lot of talk has been done on things not to do and things to do in preparation to migrating to 2.0. Based on your own experience, what it the set of things to avoid doing in your existing Angular development so that you are better prepared for the transition?
Kyle: This means that I'm not going to take the microphone unless I'm forced to. They didn't talk about this, but what I can gather from the slides that were on the screen, is the only thing I would be really hesitant to do is building my own tooling to ease some things in 1.x that are going to be eased in a totally different way by 2.0.
So, for example, the directive definition objects are really a pain, and there are people out there that dislike them enough that they're writing their own higher level abstraction to create, you know, whatever component-style directives.
And I wouldn't say that's a bad idea to do things like that except that maybe you're innovating in this direction, and they're innovating in this direction, so to get there you're going to have to kinda roll back and then go down their path. But even then, I wouldn't say necessarily you wouldn't. You do what you need to do to ship what you need to ship. But definitely, if you're looking to solve problems in 1.x that are being solved a different way, you're probably going to be spending some time you'll never get back once you move.
Bill: This is going to be a kind of odd way of answering it, because what I'm going to say is, don't not do a lot of things you should be doing in 1.x today. For example, there are ways of structuring your application that are more modular, more granular, so that your application isn't one big monolithic thing. So, a thing I would avoid doing is the more monolithic approach to building an app. Don't shove everything in your app into one module, for example. Take maximum advantage of using directives. Try to componentize as much as possible in your application, because it will then give you that more granular structure that you could begin to take advantage of, that piecemeal transition stuff that we were just talking about.
Also, if you've done that sort of decomposition of your problem into these pieces, I think it'll be much easier to translate that into the new 2.0 way of thinking as opposed to the 1.x way of implementing those things. Because a lot of those concepts are going to stay the same. If you've been building element-level directives that are components, and attribute-level directives that are behaviors or decorators, those have direct translations into 2.0. So don't not take advantage of those things in 1.x, and I think you'll be in pretty good shape to take full advantage of 2.0 or at least easily get there.
Also, just build solid, well-structured, well-crafted applications. Make sure that you have good linting and hinting going on in your JavaScript code. Go ahead and take advantage of some of the tools that we know we're going to need. Go ahead and integrate them in so you're not trying to make an overnight transition from ECMAScript 5 to TypeScript or ES6. Mark is the local expert on this as far as I'm concerned, so he can give you all the tricks in the world about going ahead and beginning to integrate ES6 into your workflow. I would go ahead and take advantage of those things, so that you don't have to eat the elephant all at one time when it comes time to make that transition.
Participant: So, I can add to that. So, at Maritz, we have a project that is in production, using ES6. We haven't run into any problems related to ES6, so I wouldn’t shy away from that. We're using Traceur right now. That's only because Babel wasn't really such a big thing back when we chose. Maybe we'll switch at some point, but I think either of those is a fine choice.
My two TypeScript-related things, one is maybe more of a statement. So, I'm a little concerned and I wonder if the Microsoft people addressed this, that TypeScript has a way of describing types. I hope that the Microsoft people are watching the progress. And the ECMAScript TC39 type annotations originally were going to be in ES6, I guess now that's now slipped to ES7 or ES 2016.
Kyle: There's actually talk that… I heard at least one person express that it was unlikely to make it in 7 either. There's too much disagreement. So the innovation is going to be [?] proprietary and [?] …
Participant: Yeah, but my main concern is, I don't want types in ES whatever to be different than TypeScript. So, we'll see what happens there.
Kyle: We can only use what can be used. There's TypeScript type system, which gets quite a bit of criticism. People say that Facebook's flow type system is a much more suitable and appropriate type system, but it has, you know, no adoption so far compared to Microsoft's . And then there's a different type system coming out of the ES working group. All I know is, I really miss having a type system, so, if I have to translate later….
Participant: Right. And then the second thing related to TypeScript is that, I think they've always said that you don't have to use… Well, back when they were talking about AtScript, they said you won’t have to use AtScript if you don't want to, and I imagine they're still saying the same thing about TypeScript.
So, if I'm writing my own components in Angular 2, what is the alternative to using annotations? Did they discuss that?
Kyle: So, the annotations, they're just a shortcut syntax. They showed a slide of exactly how they translate. It's a trivial translation. You can just write a few lines of code that just attach some objects to a constructor function, and that's analogous to a class annotation. So, you can make a first-class citizen, written using ES5, and it'll all be fine.
Participant: Is it that much of a headache to go that route? Or is it…
I just wanted to see if there was any higher level of detail that you guys could provide as far as like, how much of a hassle it'll be to write something in TypeScript vs ECMAScript 6 vs ECMAScript 5. Like, is it thirty percent more difficult to do it in each level down, or something like that, or is it just, here's a couple lines here, a couple lines there, that sort of thing?
Paul: It's much easier to write in TypeScript. There you go. [laughter] No. It was still kinda a little hard for me to get a sense of how much of an advantage I'm getting. Obviously there was a lot of syntax going away, a lot of lines of code going away, but it wasn't clear to me at what level of mental overhead it's going to take to make that transition. Am I going to have to know five or six tricks or secrets as the result of moving up that step in the abstraction? Is it going to be worth it? From what I've seen, it certainly looks like it's worth it. But the examples are still too sparse for me to get a good feeling of, like, is it any kind of quantifiable difference between the various sets.
Bill: My guess is that, they're all ("They" as in the Angular team) they're very gun-shy around the problems that things like DDOs have caused. Directive definition objects are a nightmare, especially for people just getting into Angular. The whole point of Angular is all about directives, but directives are arguably the biggest hill to climb. And a big, big part of that is DDOs. So, how do you deal with that? Well, you try to make the syntax easier to understand right out of the gate.
So my guess is, this is totally conjecture on my part, my guess is that the whole idea behind annotations as opposed to just taking an existing object and throwing a few properties on it, is to make that initial encounter of the syntax easier to swallow. My guess is, that after you've gotten over that now-much-smaller hurdle, you'll be like "Oh, okay. I totally see what this is actually doing." And then the difference between TypeScript annotations vs just adding a few properties to an object (whether that object is an anonymous object or a function), will not be that big a deal. Maybe slightly more syntax. You know, a few more semicolons in spots.
But, the overall difference in syntax will not be enough to keep experienced developers away from just using ES6 syntax where it makes sense, so I don't think there will be much difference there. The difference between ES6 or Typescript and ES5, I think will be significant. And I think it'll be plenty significant enough to encourage people to stay in the land of ES6 and TypeScript. But I don't expect the difference between Typescript and ES6 to be huge enough that, if it makes more sense to stay in ES6 than to fully adopt TypeScript, that it'll be that big a hurdle. Again, all conjecture on my part, because like what Paul said, we've seen almost no real code, and no one's done this at-scale in the outside world just yet.
Paul: So, to kind of round that up also, almost all of the examples that we have seen, they've been exclusively around directives and the DDO, and how to move away from that. So something concrete that we can say, is like, if you think about, right now, what you have to do to create a directive whose sole purpose is to exist as an attribute on some other element to modify it's behaviour. Mentally, we have to just wave our hands and say "This directive is a construct that should only be used in this manner", and then we have to know what attributes and the DDO to go up and down and set the right way, and there's still holes where you can fall in and nothing preventing you from using it, whereas ES6 is a far more succinct way of expressing that, because it is literally two different… Not ES6… TypeScript.
Two different annotations that you provide when declaring, “Hey, I'm actually making a widget-element style directive,” or, “I'm making some sort of directive whose job it is to be a behavior or a decorator.” Those are now completely separate things and they handle that translation for you. Closing that gap between your mental expectation, the implementation in code, and then the actual use of the directive, like, the mental bridge that you have to make sure everything's used correctly, that starts to go away as you climb up towards TypeScript and 2.0.
Participant: So, migration aside, or that could be as well, you mentioned “ng-wat”. What other talks would you say we should definitely not miss? What's the one talk that each of you would recommend we go watch after this?
Jack: So, the keynote talks from the core Angular team, and then there's another talk by somebody… I think it was somebody from the TypeScript team talking about their work with the Angular team, and how they've come together to kinda make Typescript into what they were envisioning AtScript was going to be. So I think there's the two keynotes from each day, and then the TypeScript/AtScript talk to watch.
Kyle: I can contribute one. So, possibly the most important talk to me was… There was a performance talk. We're building systems for customers at a complexity scale where we are experiencing Angular performance pain, so others in our position are feeling a certain attraction towards some of the newer competitors. And it was really thrilling to see that the current Angular has improved quite a lot, and at the 2.0 stage it'll be parity or better with the best-in-class performance libraries for when you have a whole lot of the bound data on your screen. I thought that was a really important fact to get visually in front of everybody at the conference.
Paul: Kinda like I said in my opening impressions, there was a talk about the Shadow DOM, and it was actually showing some real code surrounding that and how to use it, and can I give you a little bit better explanation of just how that works. Because up until that point to me it was just a nebulous concept that there's something like that out there, and it was a little bit more concrete, show me some real examples, I really appreciate that one.
Bill: I was gonna pull up the schedule and just kinda flip through it see if anything specific jumped out. One that I'm going to watch again just for practical purposes, I'm going to go back and watch Brian's talk on the new router, partially because everybody on this panel is teaching Angular right now to people, and now we have three routers we need to talk about in class. We've got the built-in router, we've got UI router, which is like, when you outgrow NG router (which is about twenty minutes into using NG router), what do you move to next? This UI router. Well, now there's another choice, and that's the new router.
Brian's talk is a pretty good overview of that, in it's current state, but also a really good picture of the fact that it's not done yet. They're still under very active development. So, again, just for practical purposes. Not one of those talks that you look at and you're like, "Wow, that was really inspiring, I'm…" No, it's like, "Yeah, I need to know that crap. That's going to be important." So I'm going to go back and watch that one again.
The other one, which I only saw part of it, and I'm basing this mostly on audience reaction, because I came in tail end. Apparently Igor gave a talk that was this kind of life-changing set of epiphanies that he wanted to share with everyone, and I'm totally bummed that I missed it because everybody came out going "Man, that was the most amazing thing I've ever seen in my life!" And I'm like "I was getting Ice cream, what happened?" So I will go and rewatch that one, only because of watching how the audience reacted to it. Did anybody here see the talk?
Paul: I kinda walked in at the tail end.
Yeah, exactly. All of us are like "We were in the hall!" It's the last talk from Igor Minar. So, whatever it was called. So, if my schedule ever comes up I'll give it to you. Any others that jumped out?
Participant: I have two questions, and I'll just ask them both…
Now so we don't have to keep the microphone back and forth. The first one is… Actually it kinda dovetails into what was just said. Given what you know about ngNewRouter, if you were starting a project today, would you use UI router, or would go with what I hear is kinda an anemic ngNewRouter. I haven't actually used it yet. And then the second question is, I know ngNewRouter and ngAnimate are both dual-life 1.4, 1.5, 2.0 type things. Are there any other things that, come 1.5, they're going to dual-life to help with that transition or did they announce anything like that?
Kyle: On your second question, those are the only ones I recall being mentioned. I wouldn't be surprised if more emerged over time. I'll hand this to you in a minute. Paul's going to tell you about another one.
On the other question, routing is really a hard problem. And that's because… Which I'm also going to hand from Paul. Paul stumbled across an idea that he called "Router-first development", Which is the idea that, really, figuring out the routes in your application, that probably should be the organizing principle of your application. So that means that choosing a powerful router is really important. There are three choices that all have trouble. The old built-in router is okay, but it has no features. Specifically, it doesn't have a bunch of features you really need to build a complex application.
Bill: Its biggest feature is…
Kyle: Having no features.
Bill: Everything that you know about it is like in one…
Kyle: Right, one page of documentation is all you need. We're using UI router at scale, on real work, and I think the biggest strain we see is that I feel like UI router is maybe starting to stagnate a bit. Because everybody knows the new router is coming. And so, although we're a lot happier with it than we were without it, I would actually… If I was starting a brand-new greenfield project today, given that 1.4 shipped RC0 five or six days ago, I would try using new router first, because that's the most future-proof.
Paul: I'm in complete agreement. In addition to the fact that it's probably more future-proof, there's a lot of ideas that new routers either already got, or they're definitely on track chasing them. Unfortunately I don't recall the specifics, but when I was looking at it and they were talking about it, I was like "Yeah, yeah. Yeah, it looks nice. I'd love to have that now." And it is a completely different way of thinking about it from the old router and UI router. They kinda take a state-transition based approach. It kinda encompasses the idea that I had after working on these things enough, that really, the routes for your application need to be the framework which you hang everything off of. And in adding the routes in alter as you discover them, you're just going to end up hacking a bunch of your Angular code backwards along the way. And it looks like it's going to tackle that problem up front, of like, get your routes at the top level and then hang stuff off of it.
Bill: Is it fair to say that if you're only exposure to routing in Angular is with the built-in router, then some of what Paul's saying may seem a little odd? Is it fair to say that your deeper experience with UI router as kind of a state management system for the application is what's allowed you to kinda embrace this, what we're calling router-driven development. If you only had ngRoute to work with, I don't think you'd be where you are on routing. Is that fair?
Paul: Yeah, absolutely.
Kyle: I think if you only had ngRoute and you were building a non-trivial application, first you need to write a router…
Paul: Exactly, exactly.
Kyle: …That's good enough for your application.
Paul: Yeah, exactly what Bill was saying. It's only though that deep exploration of UI router and seeing how you can use that to piece together the larger ideas of your application, that you're going to come to that. And then be able to even successfully transition into using the new router in the way it appears that they intend for you to use it.
Bill: Is it also fair to say that, even though the new router looks really cool, it is not a superset of the capabilities of UI router yet, Brian was pretty open about that, that it doesn't do everything UI router does. It does some things that UI router doesn't do, and does them in a different way that's very compelling. But if you really need everything that UI router does today, you're not going to get that from the new router, and probably won't get that even eventually from the new router, because it's not going in the same direction. Is that fair?
Paul: Yeah. It's a whole different idea for how to do routing.
Bill: Well, I just wanted to ask.
Michael: Mark, you want to offer a rebuttal for UI router?
Participant (Mark): It's the best that's there today.
Kyle: That's why we're using it.
Participant (Mark): Yes, exactly.
Michael: We do need to wrap up. Sorry for the last-minute commercial, but we do have an advanced Angular class in two weeks here. So if anybody's interested, it's a three-day class, and we'll be getting deep into many of these things.
Participant: That sounds awesome, who's teaching that?
Michael: This guy. Oh, and this guy. And then I think… Kyle, you're slated to be there as well. Anyway, thanks for coming. If you're not on the mailing list already, let one of us know, and we'll get you on the mailing list for the lunch. Appreciate you coming, have a good rest of your day.