[This episode is sponsored by Hired.com. Every week on Hired, they run an auction where over a thousand tech companies in San Francisco and New York and LA get on JavaScript developers providing to put the salary and equity upfront. The average JavaScript developer gets an average of 5-15 introductory offers and an average salary of over $130,000 a year. You just can either accept an offer and go right into interviewing with the company and neither with that any continuing obligations. It's totally free for users, and when you're hired, they'll also give you a $2,000 signing bonus as a "Thank You" for using them. But if you use the Adventures in Angular link, you'll get a $4,000 bonus instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired to get a $1,337 bonus if they accept the job. Go sign up at Hired.com/AdventuresinAngular.]
[Ready to master AngularJS? Oasis Digital offers Angular Boot Camp, a three-day, in-person workshop class for individuals or teams. Bring us to your site or send developers to ours classes in St. Louis or San Francisco – AngularBootCamp.com.]
[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]
[This episode is sponsored by Digital Ocean. Digital Ocean is the provider I use to host all of my creations. All the shows are hosted there, along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPSes are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code “Angularadventures” you'll get a $10 credit!]
CHUCK:
Alright. Well, hey everybody! Welcome to Adventures in Angular episode 63 – I almost said 163 but we’re not quite there yet. [Chuckles] This week on our panel we have Lukas Reubbelke.
LUKAS:
Hello!
CHUCK:
We also have a few guests joining us. We have Rob Wormald.
ROB:
Hello!
CHUCK:
We also have Patrick Stapleton.
PATRICK:
Hey guys!
CHUCK:
John and Ward are going to be joining us here in a little bit. John had to go pick up one of his kids and Ward is watching his other kids which is kind of a scary proposition if you really think about that. But anyway, so we are doing this on Crowdcast. If you're watching it on YouTube Live you probably want to go over there; crowdcast.io/e/charleswood5 is where it’s at. And there’s a chat room and some Q&A. So we’ll just go ahead and start with the first question in there, mainly because this is something that I am curious about. I also have – this question I asked to Brad Green when we did Angular Remote Conf and there was some interesting feedback there, too.
But the question is basically – I’ll just read it word for word – it says, “First and most important question –.” Actually I don’t think the feedback was from Brad, I think it was from another episode of this show. Anyway – “when is Angular 2 out? But seriously, with Angular 2 final nowhere in sight, do you feel that other frameworks – COF, React – are starting to become more popular and will people bother to go back to Angular 2 once they have learned React? I’m holding out learning yet another framework but it’s becoming more and more difficult as employers start moving over to
React.”
And then imprinttocc says, “I’m a contractor and recently started noticing employers wanting React over Angular.”
ROB:
The shorter answer is it’ll be ready when it’s ready. There’s not a good answer to that question but the second part of their question – “will people come back?” – I think the shorter answer to that is ‘yes’. It’s crazy fast [inaudible] –.”
CHUCK:
Oh, looks like we’ve got Ward and John.
JOHN:
Hey, it’s Ward!
WARD:
This is a backup. This is an old show.
CHUCK:
Yeah, we brought in some help because we couldn’t find you guys.
LUKAS:
Ward and John 2.0.
CHUCK:
Yeah.
WARD:
Wait a minute.
JOHN:
So?
WARD:
What’s going on here?
CHUCK:
We’re answering questions; we’re talking about why people should do React. [Laughter]
LUKAS:
But more importantly – Ward, are you even wearing pants right now? That’s what everybody wants to know. He’s stunned into silence. [Crosstalk] Nobody can hear you Ward.
WARD:
I didn’t realize we were live.
CHUCK:
Yeah, we are live.
WARD:
Wow, I’m messing up the show.
CHUCK:
It’s all good.
WARD:
Alright. Well, here I am – a face in the dark. It’s good to see friends though.
LUKAS:
Ward, don’t be alarmed that there’s a really tall bald guy right behind you – oh.
WARD:
Oh my God! [Laughter] Okay I have totally derailed you. How far into the show are we?
CHUCK:
Well, we just started. The question that we’re answering is basically – and I think we’ve talked about this on past episodes, but when is Angular 2 going to be out? We don’t know. So since we don’t know when it’s going to be out, looks like more people are moving over toward React and are they going to come back? Should we hold out learning React? And this is asked by a contractor who’s starting to notice people moving to React because Angular 2 isn’t out.
WARD:
Wow. It’s all Rob’s fault. [Laughter]
CHUCK:
Rob was actually going to explain to us.
ROB:
So the first part of that question – “when is it out?” When it’s ready, when it’s awesome. Will people come back and should you learn React instead of this.
A, yeah, people will come back because it’s incredible even in the release dates right now, it’s awesome – it’s crazy awesome. And should you learn React? As an Angular guy, I think React is a really cool framework and I think that – I don’t want to say that Angular 2 learns from React but I
think there’s a lot of similar conceptual stuff and I think that learning a little bit of React is not a bad thing and I think would probably help you be better at Angular, too. [Inaudible] I put that right; you can use Angular 2 very much in a way that you're using Angular 1. But you can use Angular 2 also in much more React one-way data flow way.
Yeah, I think anything you do with React is going to help you with Angular 2 when you get to that point and I think a lot of the same principles apply. You might answer that.
WARD:
Yeah, I think it’s a great thing to learn a variety of frameworks just like it’s a great idea to learn a bunch of languages. I would go look at Aurelia, too. I think you should survey the field; I’ve looked at Ember because they have been making changes. If you're of the mindset to be looking at frameworks right now and trying to make decision, I think that you should survey the field because like learning other languages and databases and so forth, you get important insights in what it is that you finally want to do; and then when the time comes to make a choice, you can make it. As Rob says, I think many people find Angular 2 to be a fine choice.
CHUCK:
You had me until you said Ember. [Laughter] Yeah, I agree. It’s interesting though because a lot of times we feel like we picked Angular and people don’t want to be wrong but – and the other thing is I feel this camaraderie with other Angular folks but if I go find out that React actually is better, then my life has changed. [Chuckles]
Good thing or bad thing, you can make that the distinction. But overall I completely agree. Go learn the way they do things and then if it turns out that you miss Angular land then come back, and then if you find out that React is better for certain applications then use the right tool.
ROB:
The big secret is let the Angular team and the React team talk and they – Angular 2 will theoretically be able to use React Native. There’s [inaudible] – it’s not like a ‘do one or the other’ for the rest of your life. There’s a lot of overlap and everybody’s friend and I don’t think that that sort of framework works or as they say they are.
CHUCK:
I don’t want to hear this. I’m an Angular purist. [Laughter]
LUKAS:
But let me jump in here real quick; I think there’s a lot to be said about as you're going through the frameworks and seeing how they're doing things because a lot of times we would get blunders like, “Well, this is how Angular does it and that’s just how far as we go.” And so going and looking at React and feeling like, “Hey, what is this functional Reactive thing that I’ve been hearing about,” or even entirely different languages to the point where I think a lot of good ideas in JavaScript has actually come from the Clojure camp.
And so first it’s Functional JavaScript which is written by Michael Fogus – he’s a Clojure guy and it’s just a phenomenal piece of work that is put together around functional programming in JavaScript. And so just going out and trying new things expands your horizons. You can always come back to Angular or whatever framework you use, but now you’ve got a different perspective which ultimately makes you a better developer.
ROB:
I think we’re all used to the Angular way – do it the Angular way. And I think that the fact that Angular 2 is very much like a kind of ground up, brand new framework means that the Angular way that we know may not be the Angular 2 way, right? I think it’s good to go and see what the other guys are doing, as Lukas said, to kind of see what may be is the better way to do Angular 2; what’s the next Angular 2 way to do things.
PATRICK:
Yeah I think venturing out to other frameworks or anything is good for getting perspective in different ways of doing things.
So I created a list called Awesome Angular 2 to showcase the breadth of the Angular 2 ecosystem, how it’s going to grow. Essentially it’s showing Angular 2 in different languages other than just JavaScript. And this is to show that there’s other part of the ecosystem that’s going to branch out. For example, we came up with Clojure – all the cool stuff that came out of Clojure are going to be linked in to the JavaScript because of React. We are going to see the exact same thing in Angular 2.
When it’s released, then we see how it ties in to these other ecosystems and how the developers there will start [inaudible] to their version of Angular 2 which will trickle down to the JavaScript version; but then everyone wins.
The number one thing about Angular, in my opinion, is the community; and that’s just because of how the community was born. And I think because of that that’s why you can’t ask your developer – that’s why you can’t go around and ask any developer; they pretty much know about Angular and that’s because their community is so [inaudible]
CHUCK:
I think a lot of the anxiety that comes out of this is – one, nobody wants to use old stuff, right? I want to be using the latest and greatest thing, and so the fact that there’s an Angular 2 somewhere out there on the horizon means that we want to be using it and we want to be a part of it.
The other thing is that most frameworks that I have used, either on the frontend or the backend, if there’s a major version change like this, they are breaking changes and then compatibilities, and so there’s a lot of anxiety over the Angular 2 way being so different from the Angular 1 way that working in Angular 1 now, basically, is obsolete knowledge. And the feeling that I’ve gotten over and over and over again from the Angular team is that that just isn’t the case here with Angular 2. But the other issue we have is then trying to explain this to people who aren’t in the Angular space like our clients and our bosses. We want to keep using the “older technology” or the technology that’s still coming out or that’s already out rather than the stuff that still coming out. They want to use the latest and greatest stuff, too, and they don’t understand that Angular 1 is still a powerful framework that does a lot of good things.
So basically, the thing that we’re facing here is wanting to be up on this stuff and then our bosses thinking, “Okay, well let’s just hold out until Angular 2,” and they’ve been holding out for months now and they're getting impatient because they want to get work done.
ROB:
So I think there’s two parts, right?
CHUCK:
Yeah.
ROB:
The first is that- the thing about Angular 2 is that it’s much closer to JavaScript, right? There’s a lot less Angular-y things about it, and so in terms of starting a new project today, I don’t think – it’s definitely not a good idea and I’m not going to say that on a podcast ever. Not a good idea.
But certainly be aware – go play with it, see how it works. There’s a lot you could do. You could probably write your entire data layer of your application in such a way that it would be reasonably straightforward to drop it into an Angular 2 application.
There’s a lot you can do – write code today that isn’t going to prevent you from moving to Angular 2 when it’s ready. Of course, there’s the whole ng upgrade thing, right? So the ability to run them in [inaudible] with each other, which I think will be a huge thing. We’re just starting to see that evolve, but that as a thing should hopefully soothe a lot of those fears that people have. It’s going to be pretty cool when they're running one within the other.
So if you're writing an Angular 1 app today and a few months from now you want to be able to write
an Angular 2 component for the first time and drop it in there in your Angular 1 app. Do it incrementally; that to me is a really nice middle ground solution.
And use TypeScript today would me my thing. If you use TypeScript today, everything’s awesome and you’re like 80% on the way to Angular 2 anyway and it makes that kind of stuff nice and easy to drop in in the future.
CHUCK:
The only other thing that I can see there though is people saying, “Okay, well let’s say I write in Angular 1 now, do I have to do a complete rewrite when I move to Angular 2? And what you're saying is if you do it in TypeScript, then not so much.”
LUKAS:
Well, I mean I don’t think – TypeScript’s not a requirement for that but I think that – the point is, if you writing an Angular 1 app today, you'll be able to incrementally upgrade it into Angular 2 rather than getting the whole thing and starting all over again. That’s one of the big goals of the ng upgrade project is to allow you to, as things come online and as things ready, swap it piece by piece.
So if you want to make a grid component in Angular 2 that’s super fast, then drop it in your Angular 1 app – you can do that. I don’t think it’s a ‘do one or the other’ kind of thing.
WARD:
I also think that we put too much emphasis on the syntax and the technology and not enough on what I’ve always found to be the hard part of building an application, which is getting it its design where I get the user experience right, getting the flows right, figuring out what goes where; what’s the structure of the approach, what’s the – how am I going to navigate. What should it do in terms of getting the data; what kind of data should we present – these are tough, tough questions and you spend a lot of time building any application, re-thinking those things over and over again as you evolve and learn really what the application should do.
It’s my sense that if you were to do that with this architecture and strategies that you know from Angular 1, that you end up in a place that isn’t so distant from what you would do in Angular 2. You’re still going to have to create those templates; you're still going to have to figure out where it goes on the screen; you're still going to be thinking in terms of the dependency injection is, the mechanism by which you assemble the parts. You're still going to have a router and you're going to navigate from point A to point B.
So the syntax is going to change but the basic way in which you figure out what your application should do and how you should break it into parts that fit together – at the level of the ones I think is the hard part of an application, I think working in Angular 1 puts you in great shape for going to an Angular 2.
CHUCK:
So what you're saying is how you solve the problem is more important than how cool your stack is?
WARD:
I’m afraid that that is my position.
PATRICK:
Yeah, I would also agree with that because it’s like the majority of the performance problems that people would run into with Angular 1 is the developer code itself. So one release, say, JS repay challenge, which is really interesting because it’s basically measuring the repay rate for each framework; what was interesting is that if you actually look at Angular 1 performance optimization version which is just using React [inaudible], the Angular 2 and the React version which is also optimized, you’ll see that Angular 1 is actually faster than React. You’ll see that Angular 2 is actually faster than React. And then you realize that the problem isn’t really performance; it’s really just the developer code. It’s really just the developers writing more performant code for their organizations. That’s what a [inaudible] really is; it’s just allowing you to maintain your code in a better way.
ROB:
And on top of that, even a lot of times people ask me, “Well, what’s your best Angular advice for writing code?” And my playbook for that actually has nothing to do with Angular; it actually comes from Clean Code which is actually a Java-centered book, but it talks about single responsibilities stage, no fine grained code, and even up to the point where I actually went in and read John Papa's style guide the other day just start to finish. And a lot of the advice in there can actually be tied back to just general good programming principle.
So they're not necessarily – Angular has introduced these new programming paradigms that have never existed, is a lot of times if you have a good sense of what makes good code and you understand these best practices across the board on Clean Code or the style guide, then moving from one to two or any other language for that matter is not nearly as complex as it would appear to be because you have that strong foundation.
JOHN:
I think there’s a mental hurdle that a lot of people have when they're looking at learning new technologies. Keep in mind we just came off from doing a hackathon for Angular 2 just yesterday and I see this not just there but in the enterprise that they work in, the people they talk to conferences of while there are so many things to look at when solving this problem. And this could go with technology or building a house or having a family.
When you look at the 5,000 things you have to do to accomplish to get to your goal, everything is overwhelming; everything is ‘oh my gosh’, not only is my cheese [inaudible] it’s not even cheese anymore. But you have to just look at the problem and solve things one piece at a time. And when you look at what it takes to go from Angular 1 to Angular 2 or to go from another framework in Angular 2 if you’ve never done Angular 1, I think when you start to take the pieces apart, and as Ward said, how do I assemble my pieces? What are my pieces? Do I have something that does logic? Do I have templates somewhere? You start breaking these things down, they're not so hard. They're very discreet pieces that you can assemble on your own.
When you start trying to figure out how are all the plumbings working and you're looking at everything as a whole, it becomes forest for the trees, it’s overwhelming like anything is. So I think the key here is to remember when you're looking at anything new – whether it’s Angular or Go or whatever you're looking at – Docker, you want to make sure that you're looking at what you want to accomplish, take it piece by piece, step by step. Everything’s overwhelming when you do it all at once.
PATRICK:
Yeah, more on that point – one of the difference is in Angular 1 and Angular 2 in terms of architecture is the component driven design. And the component, you can think of it as just – in Angular 1 – as just a controller; you have a controller and a template. Now the difference between that and Angular 2 is that you have many components and they go into each other. And what it’s really doing is allowing you to divide the problem into smaller sets so it’s easier for you to reason about, like what’s going on.
So if you were to write Angular 1 style application in Angular 2, you would have three components
or something and then your template will be huge because you're – to mimic the exact same template design in Angular 1 and everything in the controller, and then in Angular 2’s case, to a component which is just a class.
WARD:
And I would argue that when I designed my Angular 1 application, I’m constantly refactoring that down into what look like component with the components that they're going to be in in Angular 2. It’s kind of an anti-pattern in Angular 1 to have this gigantic piece of html that goes on forever in a gigantic controller with thousands of lines in it.
We’ve seen it; we’ve all seen it but that’s an anti-pattern; that’s not good on Angular 1 and it’s not going to be good on Angular 2. So if your practice on Angular 1 is good, I think you're going to end up with parts that translate very favorably over to Angular 2 when the time comes.
I also want to say that this is – we talked in the beginning like everybody loves everybody and we got to look at everybody; it’s not like we’re going to give an award for participation in the end where everybody goes home with a ribbon. [Laughter] We’re ultimately going to have to decide, okay? So you are going to make a decision and I think people come down into different places but I think that Angular 2 is going to win a lot of business because it’s going to be that good and it‘s all that we keep talking about not knowing when it’s going to arrive.
The arrival is in sight; that’s fair to say, don’t you think? And it’s not like it’s another – I don’t think we’re waiting another year by any means. So I think you're going to find something you like after you look around and it could very well be Angular 2. I don’t think you're going to be – I think it’s a fine choice; I don’t think you're going to ever regret it.
ROB:
I think if you like Angular 1, then you will love Angular 2. That’s the way that I think about it. If you're an Angular dev now and you like it, and you like the things about Angular that makes Angular Angular, then Angular 2 kind of carries over all those concepts that makes a lot of them ten times better. That’s the way I think about it.
WARD:
I don’t actually felt that way; I’ve noticed that at hackathon – the people who –. There were groups; most of the people had some Angular 1 experience.
CHUCK:
So the question though is, and I totally see this from a point of view of being a contractor. I’ve done a fair amount of that. So how do you explain to your client when they come to you and say, “Well, Angular 2 isn’t out yet and you want to use Angular 1,” – how can you boil this down to a good explanation of why to go with Angular or whether or not they should go ahead and pick React?
PATRICK:
I would say that the community is a lot more advanced because it’s been here for six years, right? And the React community is still just beginning; so not everything’s filled out. They're so – right now, if anyone’s in their actual zone know that there’s this thing of everyone trying to figure out what’s a good router now because everything’s changed and now they’re like, “Oh, we’ll see this router or we’ll see this router.”
In Angular, you at least have to baseline experience of everything. We have a router provider for you. The more the point of Angular 1, everything’s already set in there for you; you could google [inaudible] and find it in Stack Overflow which – everything’s there. And the thing is you could build really, really fast with Angular 1. Its strength is that you could prototype things and it’s really fast with it.
JOHN:
If you want to build applications that work for your business today, Angular 1 is a great way to go. It’s mature and it works, and there’s problems where we’ve already fallen into holes on and climb their way out of Angular 1 that we haven’t done so on other frameworks that are younger and less mature.
CHUCK:
Yeah, that makes total sense to me. And ultimately if you’re a contractor and you're talking to folks, I do another show on freelancing where we talk about this stuff. And find out what the problems that they need to solve are and then explain how you'll solve them with Angular 1. And then if they're concerned – ‘well, what about Angular 2 coming out?’ – then you can say, “Look, if you need the performance characteristics or the other advantages that come out in Angular 2 when it comes out, then they’ve got a really clean and clear upgrade path. But for right now, let’s get something out there that works and works well,” and give them the value proposition on what you're going to do for them as opposed to quibbling over technology.
The other thing is you as the contractor or the programmer are the expert in the technology; they aren’t. And so – I’m not saying beat them over the head with that, but I have pointed out to several people that you hired me to understand the technology for you and this is the way that I understand it.
WARD:
I want to throw another thing into the pod which is this – I’ve been spending my time here looking at some Angular 2 and I knew Angular 1, and I would say that I know for everything that I ever did in Angular 1, how I would do it in Angular 2. I know exactly how to get from point A to point B.
I can’t say that I would know how to get it because I don’t know React that well or some of these other frameworks that well so I can’t give you that assurance that everything you do and almost the way you do it – not talking syntax here, but the way you think about solving a problem. I know the exact way to get from whatever it is you're doing today in Angular 1 to the way you're going to do it in Angular 2 and it’s not going to be a hard leap.
Now, you can trust me, you cannot trust me – whatever. But I know it as much as I know my own name, and I think some of the others of us who have been living with Angular 2 would be able to give that – make that same statement. I’m looking at some nodding heads but go ahead and say it guys.
ROB:
I would say that that’s absolutely the case. Having been in the guts of it for a while, I think that a huge amount of concepts poured over right, like the names of something’s changed, then okay, we’re going back and forth on some names and things right now. But I think conceptually everything you know how to do in Angular 1 would pretty much pour over to Angular 2; it’ll just be that much better.
We keep having this Angular vs React discussion and I don’t know that that’s about it because really if you're going to choose React, you choose React and then you’ve got to choose some way to manage your data. Are we going to do Redux? Are we going to do Flux? Are we going to do Reflux? Whatever the [inaudible], they are not [crosstalk]. It’s not a main decision. I think there is actually Reflux now. [Crosstalk].
JOHN:
And it has to make ACID guarantees, so therefore it has a reflux.
WARD:
Aww, you're beating me to that one, man!
CHUCK:
Oh, I knew it was coming.
ROB:
See, I think it maintains the same complete package that you get from Angular 1, right? It’s just everything that much better. I’m going to say that probably 12 more times. [Crosstalk]
WARD:
I’ll go one step further on you on that, Rob. If you're going to use React, use React! Go for it. There’s nothing wrong with it. I’m not going to try to stop anybody from using any framework they want to use. There’s nothing wrong with it, but if you want to use Angular 2, go for it.
I don’t think anybody should be trying to convince anybody else to use a framework, right? If you want to use Angular, if you want to use React, go for it. I do believe that today, that is a great idea to start looking at Angular 2 and figuring out how it works so that you can make your own evaluation, your own determination on what you can build tomorrow when it comes out. But I’m not going to sit here and say ‘use Aurelia; use React; use Angular’ – make your own determination.
CHUCK:
That’s true. We are looking for results, right? Does it work? Does it do what it needs to do?
I think we also answered this question but I’m going to pull it out because it’s a similar question and that is, “I’m a beginner in programming and I’ve been learning Angular for my first framework so I go ahead with Angular 1, away from Angular 2 and stop wasting my time on Angular. If I should continue with Angular 1, will there still be job opportunities with Angular 1 skills or not,” and I think we’ve –.”
JOHN:
Hell yeah!
CHUCK:
All of the concepts translate through, all of the experience is going to be very relevant from Angular 1 to Angular 2; is there anything you want to add to that from somebody coming in as a beginner?
ROB:
You know what, a job today in Angular 1 is probably still the best framework. There are a billion Angular jobs out there at the moment; they're not going anytime soon. I think that if you learn Angular 1, then you can be the awesome guy who comes in a year from now and then helps them upgrade to Angular 2 and you kind of get the best of both worlds.
Again, like everybody else have said, if you're a new programmer you should be learning best practice programming – best practice application development. And that applies to Angular 1, Angular 2, React, Aurelia – whatever you want. That’s – your focus should very much be ‘how do I properly architect an application regardless of the text [inaudible] behind it.
PATRICK:
I would just like to point out that people are still making money writing classic ASP. [Chuckles]
LUKAS:
Oh.
CHUCK:
True. Alright, let’s go ahead and get the next question. The next one is, “To TypeScript or not to TypeScript in Angular 2?”
ROB:
Yes, TypeScript absolutely.
PATRICK:
TypesScript, yeah.
ROB:
Next. [Laughter]
CHUCK:
Does anyone disagree.
JOHN:
No, I can’t. The more you spend time with it and with the tooling that supports it, the more you say, “Hey, I’m glad to have it.”
ROB:
I will mention; one of the big irritating things, if you like about TypeScript, previously is this idea of the TSD or the TS – or whatever that [inaudible] – .d.ts file and then this TSD and definitely types and all the kind of rigmarole that goes along with that. The TypeScript team at 1.6 has added some really cool stuff as far as getting types distributable to Npm, so that whole ecosystem is used before. It’s improving very rapidly and I think that if you like to drag TypeScript into the whites and it’s improving very rapidly. And the tooling around it in the next, maybe, two builds from now of Angular 2 will be three snaps and you're up and running with type stuff completion [inaudible].
What’s up and running is amazing and I would say the challenge right now is there’s a little bit of configuration to get it working properly, but I have seen the future of that and it looks really, really awesome.
WARD:
We had – John and I had a very funny experience yesterday at the hackathon. We would watch people who were new to TypeScript take it on; and they would start typing away and something like facial studio code, and the IDE would be sitting there and telling them what the method was going to be and how to spell it. And everybody is so used to not having any help whatsoever that they would ignore all the help that they were getting and keep typing and scratching their head and wondering how it was spelled and the IDE was saying, “Hey, it’s right here! I’ll even tell you how to use it!” It’s going to take a while for people to get used to the idea that maybe, just maybe, a language support could be helpful.
JOHN:
Yeah, I’ll put it this way. So instead of saying ‘should I use TypeScript’, let me ask people back – would you like it if you could make less errors to your code? Would you like it if you could know what the API is for all the methods? Would you like it if it would autocomplete? Would you like it if it told you when you did something wrong before you actually run the app? If you like these things, you may be a TypeScript addict.
CHUCK:
That’s just crazy talk.
ROB:
It is pretty crazy when you get autocomplete. It’s pretty awesome. And I would say even if you're not going to do a thing or two, like TypeScript in general, yeah. If you even slightly considered using ES 6, you're sort of 90% on the way to TypeScript anyway so you might as well just make the extra 10% jump, right? I think ES 6 is an absolute no-brainer; you should use that, and if you're going to use that you might as well use TypeScript.
JOHN:
To time in with what Ward said about the hackathon, it was shocking to me how many people I saw who literally – one guy was typing at a component’s name. The component name was – I don’t know – character details saying ‘components’. They’d go on thirty character name, and what they did is they started typing the whole darn thing in and immediately three letters in. It’s like, “This is the name,” and they were misspelling it and keep going back. The IDE is blinking out and going,
“Dude, it’s right here.”
CHUCK:
That’s awesome.
JOHN:
“Right here, dude.” And I’m just watching it, looking and going, “Wow.” And this was multiple people all night long and – this is not bad people, right? This is behavior. We’re all driven to these tools and for years they haven’t given us any help. And now they're screaming at us and I think it’s going to be amazing when people look up and see what’s happening.
CHUCK:
One other thing I want to point out with this, at Angular Remote Conf we had probably four or five examples of basically live coding. Usually the downfall with live coding is your internet goes out but with the Remote Conf when the internet goes out the live coding snafus don’t matter.
But anyway, it was really interesting because a lot of times, all of the information for the component including the template and some of the data definitions and things were all on the same file. And so it was all in the same place; all of the information that you needed including in line templates and everything else because they built it in TypeScript and we’re kind of making it all work out that way.
My experience with other frameworks – I’m thinking rails in particular – where you have a data model and then you have the controller, and then you have the view and they're all on different files; it was really nice to see that everything was in the same place. And if TypeScript gets you there more easily than using ES 6 or ES 5, then it makes a lot of sense to me just to be able to put all that information in the same place.
ROB:
I think we’ve all – at some point as an Angular developer you probably complained about the Angular documentation at some point. It’s massively improved over the years, but I think that you just have to go look it up and find out where it is on the webpage. And to be able to just put your cursor over some class or something and have the IE pop the docs up for you, it’s pretty incredible. The amount of times – I don’t think – I don’t know if I go and jump into the Angular doc as much with TypeScript. I think you’ll just hover it over and it’ll tell you what it’s about, and if you document your own code it’ll tell you about your own code, which is just ridiculous, right? It’s awesome.
JOHN:
And if you click on one of the things in – like ES code for example; you click on one of the Angular things like a router, it’ll actually take you right into the definition of it in the source code which is pretty awesome.
ROB:
Yes. TypeScript absolutely do it.
CHUCK:
Alright. The next question is, “How do you integrate third party libraries like Firebase or D3 into an NG2 app, taking into account that NG2 runs on one-way data flow paradigm fueled by an Arc’s implementation?
WARD:
You just use it; I don’t know. If anything, some of these things are easier to use, then they would’ve been under Angular 1. I’ll give you a quick example – let’s suppose you decided to use jQuery.ajax for your – to make your calls, to go get the data. You can do that now; if you remember your Angular 1, you have to remember when the called back comes in, they call the apply. If you don’t do that, your Angular 1 app doesn’t know that you went off – that you were cheating on them and you left HTTP behind and you went out with a cute jQuery.ajax so it just doesn’t know that you were cheating.
But Angular 2 knows you're cheating; it knows you use jQuery.ajax; it knows that it came back and it just fits right in. so many of the different libraries that you may choose to use play more naturally with Angular 2 than it did in Angular 1, so I think it’s a strength of Angular 2.
ROB:
And I think that we should say that the fact that there is this one-way data flow paradigm and then Rx is in Core and there’s a lot of Reactive things, and I talked about that at Remote Conf, right? That’s awesome and it’s great and it does some really amazing stuff, but it’s not required. There is still two-way data binding. It works slightly differently but for all intents and purposes it is still twoway data binding, right?
And again, I think the way you think about it doesn’t really change the way that it works under the hood might change a little bit but you’re still going to write a directive or you're still going to write a component; it wraps your jQuery calendar, whatever. The same kind of paradigm exists there.
WARD:
Actually, you bring up something which I think is even better. Where you used to have to write a directive in order to interact with these things, in many cases you don’t have to write a directive at all. You no longer have to say, “Oh, I’m stuck. I don’t want to touch that thing in a way that it’s not in touch before. I guess I’ll have to go off and write a directive about it.” No, often times you can just use the straight out Angular 2 binding to hook right up to whatever that thing is and you're good to go. So a lot of the massive of custom directives goes out the window.
JOHN:
True.
PATRICK:
Remember that Angular 2 is more of like pushing everything into a language and standards? For example, whatever the requirements that is working well with Polymer, and Polymer uses all the native events and everything. So more tuned to your point, you could use some other third party library that takes control over an element and then immense a native event and you could hook in to that with Angular 2 and that’s great.
WARD:
And you didn’t have to write anything special because you're just using Angular 2 the way it was intended to be used.
JOHN:
Yup. The key to this stuff is when using Angular 2, you're really just using ECMAScript 6 or TypeScript. There is very few Angularisms that you're playing with, so using other libraries is actually easier nonsense because you don’t have to worry about, “Oh, that’s the Angular way,” it’s really just a JavaScript work.
CHUCK:
So just using powerful language features that you already have because you're using ES 6 or TypeScript.
JOHN:
Yeah, there’s less things in your way,
CHUCK:
Alright, the next question is the TypeScript autocomplete/help, etc. that we were discussing before, what tools or IDE’s are we talking about.
ROB:
In theory, anything that supports TypeScript. So the Angular team is using a lot of visual studio code, which is a really awesome thing. I think WebStorm does this, Visual Studio does this. I would think that probably any modern IDE that speaks TypeScript should be able to work with this. I pretty much use Visual Studio code all the time now. Adam does this for sure. I think Sublime probably will – I don’t know; I can’t speak for anything.
WARD:
There’s a plugin for Sublime and that’s the stuff, yeah. And Visual Studio – if you're a .net programmer – I know there must be three of them out there – I was shocked I had to do some of these stuff in Visual Studio directly and fire that up right often recently. That’s a fine job of working with TypeScript; really superb.
CHUCK:
I’ve also seen plugins for Emacs – I use Emacs – and I’ve seen plugins for Emacs that do the type ahead, look up and auto-complete and things like that. And it has TypeScript support for Emacs as well – I’ve seen several plugins for it. So I haven’t hooked those up yet but I’m pretty sure that you can find plugins probably for even Emacs and Vim that will do a lot of what we’re talking about here.
JOHN:
Let me clarify something too that I think – and all those editors do have it; I’ve seen it in all of them, especially in the hackathon we did yesterday. People are using their own tool but the one thing – reason that I like VS Code as well is that in all those editors, you have to add in a TypeScript plugin to make it work, which is fine but in VS Code it’s actually baked in. so TypeScript is actually baked into Visual Studio code so if you want to use that, you download it in your Go. The other ones, you download your tool like that on and then you just add the plugin for TypeScript and it’s good to go.
ROB:
And I think me being – like I’m a total OS 10 – open source guy, and for me to be discussing the benefits of Microsoft IDE for me is – should tell you how awesome it really is. That for me is incredible that I’m using a Microsoft language and a Microsoft IDE on my Mac everyday and it’s what I want to use. It’s a choice and I love it, like it’s really, really, really good. Check out VS Code for sure.
CHUCK:
Alright. The next question is, “What is the current state of the Angular 2 router?”
JOHN:
Oh boy!
PATRICK:
Oh man.
CHUCK:
It’s kind of an open-ended question, isn’t it?
ROB:
Functional but not yet done, I think is a good way to put that. [Crosstalk] He’s the politician!
WARD:
It works; everything I’ve tried to do with it from major functionality works perfectly fine. There are a few minor things – not big gaps but minor gaps. Things like the other otherwise route and stuff like that that we had that I think that may be filled in.
It’s a little awkward in a few places and I think that’s a fair way to say it, meaning I can make – I can do what I want but –. For example – I’m going to give you a concrete example – if you want to have a link, an href, and you want to go from one place to another with the router, it kind of works like UI router does. But instead of saying ‘hey, go to the router named this’, you have to tell it ‘go to the router named this or wrap that inside of this array and then pass an object in that array that tells you the parameter name and the parameter [inaudible]. And you end up putting a lot of stuff in there that it does feel as natural as it should in my opinion. It works great but I think there’s some syntactic sugar that can do that easier.
ROB:
To be less diplomatic, and I will [inaudible], that the Angular 1 router that we all – nobody uses because we all use UI router, right? It’s kind of what it is and I think that’s the thing that UI writers learns a lot from that. But one of the cool things about Angular 2 is it has this – I think it’s currently called dynamic component loader – and it’s whole job is to pull stuff off disks and lop it into somewhere on the screen.
And so a couple of weeks ago I put together a Plunker using React extensions and some of that. I wrote a pretty functional basic router in 30 lines of code, so if the Angular router isn’t going to do what you want to do, and I know the UI router guys are talking about how we’re going to do UI writers too for Angular 2. Well, it’s so – I guess the framework provides you the tools to do really whatever you want. So if you wanted to build your own router, you had some special use case where you wanted to dynamically load components and build a dashboard or whatever, that kind of stuff you can do without too much trouble in Angular 2. Again, I think the frameworks providing some pretty awesome tools and the router – the current router – is just one implementation of that, if you like.
PATRICK:
Yeah, more on the syntax – more of what John was talking about, the router link – the reason why its API is a little bit more [inaudible] than before I know the future in Angular 2, that’s ES 6 templates. So being able to say r: the arguments in their variates and [inaudible] way, that’s going to be available and I think we’re all – we can talk more about it, or maybe not. The social – that’s the reason why it’s more [inaudible] now but it’s just another layer of sugar that’s going to be added later.
And to more of the point of features missing, I would say that I had a hard time trying to figure out how to convert a simple application with named routes to this UI router features to Angular 2. There’s also these abstract routes where not a lot of people actually use theses. I would say it runs features in the UI router but yeah, it’s coming [inaudible] you think a component is in there and that’s why it’s really, really easy; it’s like 10 lines if you can actually get into the source codes so that’s pretty cool.
JOHN:
Yeah, I think start to the bottom and then build up. The concepts are solid I believe, in the Angular router, and I believe the functionality is there. To be [inaudible] data binding, right? When data binding was first announced in Angular 2, everyone kind of went, “Oh my gosh, how are we going to write all that long syntax?” And the way things work is you get it to work, [inaudible] done, they get to concentrate then they get it to work, and then they work on the usability of it. And I think the router and data binding is much more useful now, and I think router is at that stage now where it’s ‘let’s just smooth off the edges, let’s polish this corners and let’s make it a little more useable from a developer’s standpoint it’s definitely a good thing to use, I just think that that’s not – not into [inaudible] in some ways right now.
ROB:
I think this is a good place for – you should download John Papa’s repo. You did that – you got a demo. Play with it and I think that this is a good time to try it out and see ‘okay, what don’t I like, what do I like?’ And I think John, a couple of times, has said – I have seen issues from him that said, “Oh, it would be better if we did this, right?” Now is a good time to try it out and figure out what can be better. If the Angular team is 30 people who are – who can make their own best guesses, but this is a good time to try stuff out and say, “Maybe this could be better; maybe this is a good thing.” And I think you opened that issue of active link or whatever, John. Again, that’s a feature that only [crosstalk].
JOHN:
Yeah, the active link is one. Another – it’s funny to hack last night, Ward and I found some interesting things like you have to use title case now for your routings or your esses – they call them es, which is a weird name. So using a title case tripped a lot of people up last night. A big one was using the tuple inside of the link. Cheer people up.
We had a lot of people who really struggled to use a router last night in the hackathon. It kind of surprised me because while I – not necessarily happy with the way its usability is – I thought that it would be something that you could just say, “Oh, I get this syntax to move forward.” Ward, don’t you think that was your impression, too, or are we seeing something different?
WARD:
No, I saw the same thing. Now, I have a rabbit hole here which is I can’t understand why anybody would ever use a tuple in a public API. I think it’s nifty cool internally as you're working things over, but can anybody tell me why they would ever say, “Wow, the public API from my widget is a tuple.” Is there a worse choice than that? I throw that out there for a view architect.
PATRICK:
Yeah, again I mentioned a little bit – it’s more of like one of the super secrets, amazing features of Angular 2 and that’s AC bindings. So basically, the syntax for the router in that case would be r or router-link-colon then the argument.
Again, there’s going to be a more [inaudible] but it’s in the future. There’s a better fit of this refactor – again, this refactor is literally pushed in a few days ago – but one of the other cool things about it is that you can convert template into a tree. Just think of it as a JavaScript j-subtree and then you're able to figure out the components.
So think of it as one of the cool features – being able to mimic one of the features in the browsers and that’s a few touching links, so you could actually crawl the template, figure out what links are in this particular template and then get the component out of there. And then from there you’ll be able to figure out what data is needed. And then from there you could walk the whole component tree.
There’s a lot of really cool advanced stuff you could do in Angular 2 because of this future factor.
There’s reasons for this [inaudible], it’s more like they're just going to add much of it later hopefully.
ROB:
Yeah, the new compiler that landed a couple of days ago, it never caused some issues in 38, but I think that it’s a huge step forward and I think it’s going to enable some really super cool stuff like that, like sugar and I’ve signed in to observables on that. And the really cool things about it is it does offline template compilations so effectively. You can write your templates and then as you build stuff for production, you can pre-compile them into JavaScript which means startup time is faster.
It does a lot of really cool stuff that it enabled and I think that that kind of thing will definitely get better for sure.
CHUCK:
Wow, all of that off of what’s the current state of the Angular 2 router.
LUKAS:
And 7,000 less lines of code. That’s what I was told.
CHUCK:
Alright, we have three questions left in the hopper here, and one of them is a large, open-ended question but we’ll hit these first two and then we’ll see where we’ll get with the last one.
So the first one is, “Any really good reason D3/Angular resources? What are some things to look at in regards to performance when implementing D3 with Angular? Or are we doing a rather large view in D3?
PATRICK:
I get this a little bit. So this goes all the way back to what we were talking about of – so I’m more [inaudible] in terms of Angular 2 but it requires Angular 1. So in Angular 2, you're able to interact with these polymeric components which are just like white boxes. They're just like these random html and then it emits native events and then you interact with it. So you do the exact same thing with D3; you interact with this directive and inside this directive, you do your D3 thing as you normally would. And basically, what you do is whatever you get in your data, you just tell D3 to rerun her and then D3 would just vanish that. The same thing applies for Angular 1 and 2, and that’s how you would interact with the two.
Actually, I had a talk on this on ng-vegas about D3 and Angular.
CHUCK:
Nice.
ROB:
And I think the short end to that is there’s the a lot of stuff that it’s going to work the same but I think that it’ll be really cool to see what happens when people start – what is in Angular 2, D3 – D3 spec library look like. Or D3 component library that’s built for Angular 2. What can we do with that? Can we make it reactive? I think there are some really cool stuff that will come with this.
I’m looking at the same thing. Whoever asked that question has to tweet me about it; I’d love to chat about it because that’s something I’m looking at for sure.
PATRICK:
It’s also worth noting that D3 is still in the jQuery days and I say that as a declarative query days. What Rob was saying, it would be way better to then use actual templating system to actually manage your [inaudible]. And I think someone made that in Angular 1 so it might be [inaudible] in Angular 2 and then add more sugar.
WARD:
Another thought about in this is what I didn’t get from the question was what the motivation was to go to D3. It might’ve been to make some things that they could’ve done in other way more performant, and in that case you’ll get – you’ll have the opportunity to reconsider your motivation in the outcome because now that you can do things not only with dirty checking but with immutable objects and with event-based objects.
Some of the forces that might have driven you to say, “Wow, maybe I should do this in D3,” maybe those forces are no longer present and you’ll be able to do it in a way that is more natural to the problem that you have in front.
Again, that’s not a knock on D3; that’s just simply a question. I can’t tell why you're taking an existing view and moving it to D3; I just don’t understand that part.
CHUCK:
Alright, the next question. This one’s addressed to Lukas.
“I am attending AngularConnect in two weeks; should I see the real Angular Keynote or wellbehaved Angular 2 components with Jeremy and Tobias?
LUKAS:
So, the official answer is you should see the well-behaved Angular Keynote. [Chuckles]
CHUCK:
The real well-behaved Angular Keynote component.
LUKAS:
And that’s going to be me. Sha is going to be the misbehaved Angular Keynote. [Chuckles] You could crop that cop routine there. Oh no, I’ve said too much.
CHUCK:
Alright, so the last question – this is the one that is open-ended. I think we can do an entire episode on this question, that’s why I’m saying we’ll see where we get. And I’m also okay just [inaudible] in and saying we’ll cover this in a future episode.
The question is, “How does structure of big Angular application?”
LUKAS:
Read John Papa’s Style Guide. [Chuckles] Next! My drop.
PATRICK:
It depends on everything. The use case.
WARD:
Well, I read once that the secret to writing a really large app is to not write a really large app. [Chuckles]
CHUCK:
Yeah.
JOHN:
Bingo! Bingo!
WARD:
And that applies no matter what technology you adopt. But you make a big app and you're going to make a big mess and I don’t care what technology is. That doesn’t mean that the problems that isn’t big, that doesn’t mean the features that you have to deliver aren’t big; but the first thing you go after is to figure out how to break that down into sensible sizes, work flows and models and processes, and see how you can make those operate as independently from each other as possible and then weave them together in a sensible way so that the user feels comfortable as they move from one work flow to another. That’s just good general advice.
After that, it’s all commentary; it’s all following the guidelines that you’ve seen John’s guidelines lead you into that direction.
LUKAS:
I think one of the really neat thing having tried to build a couple of things now is that the idea of this component – it’s not directives; there’s not seven ways to do everything now. There are effectively components and I call them services or whatever you want to call them.
What Ward said there about ‘don’t build a gigantic application’ I think is what you can think about it is you're holding a bunch of tiny applications. Each component is like a mini app if you like and that’s mini apps inside a mini app. So each component becomes this unit that you can move around and the router’s really good at that. You can think about the routers just moving you from mini app to mini app – that’s a good way to think about it.
This is the kind of stuff that we will learn as we start to build them, but I think the idea of a components – and again going back to React’s components – that is like a miniature app that you can think about in isolation. It’s a good way to think about it.
The thing that the UI gives us is the ability to weave these things together and share stuff between them. So yeah, I think that that’s going to be an interesting question to learn about. Definitely like a
bunch of components. Like in an Angular 1 app and like in any good app, really seen UI stuff and the vast majority of your logic in services or whatever you want to call them. It’s model view controller with a different name, basically.
JOHN:
Yeah, I’ve been calling a – you call them components and services – I do the same thing, but I also look at them more theoretically as nouns and verbs, right? We’ve got things in Angular 2 that are the nouns – they're the things that exist in our app. Now we’ve got the nouns as components, and then we’ve got the verbs; those are things that are going to provide something, some kind of service to our application – filters pipes, whatever you want to call them, services, classes. Those things are all actionable things that provide those components things.
There’s really just two flavors with the way I break it down.
WARD:
I think that the other unsung thing of testing an app – big or small, but especially big is, “Hey, how about writing some tests?” [Laughter] It would be just like, “Nah, don’t write tests – who wants those things?” [Crosstalk] I know. I can’t wait to go to a client and see tests. But really, that’s something that you should be able to do; that’s something that the framework you choose should be helping you make your way through it and be able to write tests efficiently and feel good about them as you write them. And that’s also something I think that Angular 2 is going to be good at is it’s going to be easier to write your tests.
LUKAS:
Testing better be good in Angular 2 or Ward is going to lose it because Ward [chuckles] hard to make testing awesome in Angular 2.
WARD:
What do you mean ‘going to lose it?’ [Laughter] I’m going to go crazy! I’m going to go crazy! I’m coming right to your house and I’m going to get you if you don’t test.
LUKAS:
If you're worried about testing in Angular 2, I can tell you that Ward has got you covered. Definitely, he’s going to solve that problem. True story bro.
JOHN:
I think it’s fair to say that Ward Bell knows more about testing Angular 2 than anybody in this room in this moment and time.
WARD:
Nah, you're killing me. You guys are killing me. You're just trying to – but keep it up though, keep it coming. [Chuckles]
CHUCK:
Alright, well I think we’ve been going for about an hour or so so I’m going to cut the questions off here, but do we want to do picks real quick or do we want to just end the show?
LUKAS:
Sure.
CHUCK:
Alright, we’ll go ahead and do some quick picks. We’ll start with the guys that aren’t usually on the show. Patrick, do you have a pick or two for us?
PATRICK:
Oh man, so I didn’t apply for this but my pick would be Angular 2. [Chuckles]
LUKAS:
That’s cheating.
PATRICK:
Yeah. [Laughter] Now no one else can pick it.
CHUCK:
Alright Rob, show them up.
ROB:
So my pick would be slightly more specific. I’ve just finished some refactoring on the Angular 2 HTTPs library and if you maybe wait until the next bump, there’ll be some cool new stuff in it. But I really want people to play with it and tell me about it and tell me what your use case is because it’s different from the first one. And so play with Angular 2 and observables is how that works. My picks are definitely observables and specifically Angular 2’s HTTP library because I love some input on how you're going to use it as an issue open on the Angular 2 repo right now about transformers and receptors and all that stuff that you do in Angular 1 today. I’d love you to play with the new library and tell me how you used it and what could be better and what kind of stuff you're going to see.
CHUCK:
Alright. Ward, do you have a pick for us?
ROB:
Testing.
WARD:
That’s not my pick. My pick is go find yourself a local hackathon and surround yourself with other people who are stumbling around the dark because I noticed that; it was really encouraging when I was talking to other people who were attending there and they got a lot out of working with each other, finding things out together and realizing that they have the same question as other people and finding out what are the different ways in which those questions could be answered. So it’s a great way to get your feet wet rather than doing it in your closet at home.
LUKAS:
Can I check back in? I have one that I just remembered.
CHUCK:
Sure.
LUKAS:
Somebody asked the question about two way data binding and this two way paradigm and how we integrate with things and how we build custom components and one way data flow versus two-way data binding. If you check out Angulartips.com, [inaudible] has written a really good article on how to build your own components. I think it’s a really good introduction to the basic mechanics on how to build a component. So Angular 2 – Angulartips.com is a good pick for sure.
CHUCK:
Alright. John, do you have some picks for us?
JOHN:
My pick is Visual Studio Code. I think you want to find a good adverb that you really love but I’ve been really loving VS Code lately and especially for its TypeScript and Angular 2 support. It’s been doing great ad they just added recently – just now, I think – theme support so you can customize and create your own themes from pretty much any text [inaudible] themes. I know that’s an important thing in my stable; I like my themes. I like to [inaudible] so Ward can’t see my code.
CHUCK:
Alright Lukas, do you have some picks for us?
LUKAS:
I do. So I thought – actually, Rob’s talk that he gave at Angular Remote Conf. everything is a stream. I’ve actually watched that twice; I thought it was pretty awesome. Hopefully the video will be available someday somehow.
JOHN:
Can I just pry along and say I really thought so, too, and not just because Rob is there staring at me but it’s true; it was really well done. [Crosstalk]
CHUCK:
I don’t know anything about when the videos will come out.
JOHN:
Yeah, I watched the live stream. I observed that very closely.
LUKAS:
Whoa! I see what you did there.
CHUCK:
Uh-huh. It’ll come out in about a month and half.
LUKAS:
Yay! So that was a great talk but as a result of that, I started actually looking at [inaudible] has done a lot of really good work on RxJS, and there’s actually a series on Egghead about reactive programming and so I watched that over the weekend and it was just phenomenal, like pfff! Yeah, awesome series to watch.
WARD:
I subscribed to that theory and I expect you to map your way right through it.
CHUCK:
We actually recorded an episode about RxJS yesterday at JavaScript Jabbers. Keep an eye out for that as well.
I’ve got a couple of picks. I’ve been doing a video journal on Periscope; talking about what I’m thinking about my business and things like that. And since we have a video, I will show off what I have here.
So I spent 250 - $2.50 – on the little tripod that I’ve got here. And then this clip that goes on top of it; I’ve got a clip; it’s spring loaded and it’s big enough to hold my iPhone 6+. It’s just spring loaded so one end of it comes out. We’ve got these rubber ends on it that hold the phone in place so that when I’m talking to my phone, I can just set it in front of me and then you get this nice view of my face.
But it’s been working out really well and I really, really enjoy being able to get feedback from people
on some of the stuff that I’m think about through Periscope. The picks are Periscope – I’ll put links to the tripod. I got it off at BMH Photo and the phone holder clip thingy that I got off of Amazon.
WARD:
I’m sorry Chuck – what does having the phone pressed to your face do for you and how does that relate to – what is Periscope?
CHUCK:
Periscope is a way of basically doing a live video stream. It auto tweets to Twitter when you do it because Twitter owns it. And the videos are available for 24 hours afterward. Incidentally, I’m also using a system called katch.me and ‘catch’ is spelled with a ‘k’ and it will actually download those videos for you off of Periscope so that you can make them available for longer than 24 hours. And so I’m planning on embedding those to my blog and just having them out there so that people can go back and watch what they want and put them on a podcast feed because I’ve had some people asking where they can watch the older ones.
Anyway, it’s just kind of an interesting thing that I’m doing because I have people asking me questions about podcasting, about business, about programming and they want to know what I’m up to so I figured that’s a good way to do it. And the other thing is it give me a chance to think out loud about some of the stuff I got going on. Anyway, those are my picks.
I just want to thank all the folks who came. We had about 25 people at one point watching or listening on Crowdcast. We’ll probably do this again; I think it was a pretty positive thing. And so yeah, thanks everyone for coming. Thanks Rob and Patrick for being willing to jump in and –. [Crosstalk]
PATRICK:
Yeah, I’d like to do this again.
CHUCK:
Yeah?
PATRICK:
I like Rob’s background; it’s like way better to my refrigerator.
CHUCK:
Yeah, we’re going to find out; it’s like a canvas behind him or something. [Laughter]
JOHN:
I’m waiting for the tiger to leap over the fence and bite its hand. And I’m waiting for Patrick to go to the fridge and hand me a beer.
PATRICK:
Sure, yeah. I’d see.
CHUCK:
That’s not nearly as fun. Alright, yeah, I’m going to go ahead and end the broadcast. But thanks again everyone for listening and thanks to all our panelists for coming in and answering questions.
[Hosting and bandwidth provided by The Blue Box Group. Check them out at bluebox.net]
[Bandwidth for this segment is provided by Cache Fly, the world’s fastest CDN. Deliver your content fast with Cache Fly. Visit cachefly.com to learn more.]
[Do you wanna have conversations with the Adventures in Angular crew and their guests? Do you want to support the show? Now you can. Go to adventuresinangular.com/forum and sign up today!]