Rachael L. Moore, Senior UI Engineer: AngularJS Best Practices for New Developers

Rachael L. Moore, Senior UI Engineer: AngularJS Best Practices for New Developers

AngularJS as an evolving, long-term UI framework tool

Rachael L. Moore began making web sites as a freelance web designer in late 90's. Today, she's a Senior UI Engineer at OpenTable specializing in the implementation of enterprise-scale interfaces using HTML, CSS, and JavaScript.

In this Codecast, Rachael shares her view on the benefits and drawbacks of AngularJS, gives a teaser, inside-view into the growing realm of web components development for user interface enhancement, and encourages active commitment to accessibility principles.

Key Theme » Framework Sobriety

Basically when you’re picking a framework you have to remember that every single choice has trade-offs. At the same time you’re making some things easier, faster and better, you’re making some other things harder, slower and worse. That’s just how it is. These kind of random cults that kind of rise up around certain frameworks are a little silly from that perspective because each framework is great in its ways, and not so great in other ways.

Our job is to look at what our product needs and make the best pick. Basically, a good (web) architect’s job is to allow us to make that choice at the last possible second. Because we never have all the information we need when we’re putting together a product. The longer we can wait to lock ourselves in, the more information we’ll have and the better our choice will be. – Rachael L. Moore

Quotes

"Learn some profiling tools and then be conservative. Know kind of what’s happening under the hood."

"I think that we have had a huge explosion in tooling over the last five or so years. One of the things that people used to say about web development was that it had a low barrier of entry...One of the things that might have been a contributing factor to this low barrier of entry, was the fact that the languages that you were writing your code in – and then the languages that you were deploying were the same languages...You would write HTML and you would deploy HTML. It made it faster and more direct for a lot of people."

"...focusing early on in your career, [it] makes a lot more sense to be a full-stack developer, it’s really important for you to be able to learn how everything fits together and all those layers of the stack..."

The Codecast

Watch on YouTube

Full Episode » Transcribed

ERIK

Alright, hello and welcome to the Viking Codecast! My name is Erik Trautman, founder of Viking Code School and apparently today I am just an avatar. (Laughs) We had a little bit of technical difficulties getting this off the ground but we’re all here now and all is well. I am really excited to welcome Rachael with us, who is a long time UI developer, front-end developer, designer extraordinaire. We’re going to hear all about everything that she has been able to do.

We are going to be talking specifically about some things around AngularJS.

I am really excited to welcome Rachael! Rachael – thank you for coming, thank you for being here and I guess usually the best way for us to kick off is to just learn a little bit more about you. So would you mind just kind of walking us through, what you’ve been through?

RACHAEL

Sure, and I made a couple of slides so I’m just going to share this.

ERIK

Oh, great.

RACHAEL

So, thank you for having me. I am Rachael, I’m a Senior UI Engineer at OpenTable. I moved out to San Francisco on the West Coast about two years ago from the East Coast, from north Florida, which as we say there is basically south Georgia – so don’t think Miami! My background is I started doing freelance web design about, I guess it’s been actually 15 years ago, I started around ‘98, kind of self-taught myself HTML. CSS was not as big of a thing back then ... 'cause it barely worked across browsers. We mostly did labs and tables. So then I switched from being a web designer to doing more code, a couple years after I got into the industry, like working for companies directly.

Then I switched to your kind of front-end development, and now I concentrate very much on UI engineering, specifically for the web. What I have been working on with Angular especially, over the last two years, has been what I call UI components that are based on the kind of new, up-and-coming web component standards. The reason that we do this is, I like to say, that web UI’s are a little bit like a jigsaw puzzle – in multiple ways.

First of all, when it comes to UI, we’re combining information architecture, visual design, motion design to kind of put together something that suggestions actions to the users. Then when we code all that up, we’re coding it in a bunch of different languages. We’re writing CSS, we’re writing JavaScript, we’re writing markup. We also have raster images, vector images and we just have plain text.

The web UI becomes a clear picture when all of that stuff is put together. We can kind of look to how to do that well by looking at standard HTML. The issue comes up in when we don’t want the standard HTML’s appearance, we have our apps, we need to do our branded UI’s. It’d be really great if we could make it just as easy to use your branded UI’s as it is to use standard HTML.

Angular, actually, really helps you do this by allowing you to create element directives that when you put them on the page, work just like standard HTML elements. So that’s what I’ve been working on the past two years with Angular, and I am happy to take any questions that you guys have about it.

ERIK

Just a note to anyone who is viewing you can also use the Q&A app which I think is on the left side, possibly on the top of your Hangout window. It’s the little teal-colored one and you can ask a question there, you can ask a question on Twitter, you can ask a question pretty much anywhere we can find it. Otherwise, those of us, the students who are here – feel free to fire away.

STUDENT Q: [Andrew]

Hi, I had a quick question. This may be a little off topic but having learned a bit of AngularJS 1 and just reading a lot about the industry and how there’s many options for front-end frameworks...I was just wondering how the landscape looks in terms of AngularJS 2 and is the transition pretty rough, or how are people handling that?

RACHAEL

We’re not using it yet. I think right now our current plan is to use it, and we’re keeping an eye on it. I’m not part of the core team, I haven’t put one together so: take this with a grain of salt. It looks like the full beta is going to be out real soon, so in my opinion that’s kind of ahead of schedule, it's ahead of when I would have expected it to sort of show up.

Insight-tips for easier transition from Angular 1 to 2.

As far as like picking is concerned: the way that I see it is Angular is a web application framework. And, to a degree, so is React, it concentrates only on one part of the stack, the same is true with Backbone.js,Ember.js, and their job is to kind of provide you with the tools necessary for you to build your product and get out of the way.

Everybody has very different tastes and opinions about what that actually looks like, about what’s actually needed, and what they feel is getting out of the way. What "getting out of the way" means to someone might be "getting in by way" to somebody else.

Basically when you’re picking a framework you have to remember that every single choice has trade-offs. At the same time you’re making some things easier, faster and better, you’re making some other things harder, slower and worse. That’s just how it is. These kind of random cults that kind of rise up around certain frameworks are a little silly from that perspective because each framework is great in its ways, and not so great in other ways.

Our job is to look at what our product needs and make the best pick. Basically, a good architect’s job is to allow us to make that choice at the last possible second. Because we never have all the information we need when we’re putting together a product. The longer we can wait to lock ourselves in, the more information we’ll have and the better our choice will be.

When it comes to using AngularJS 2 it looks really exciting to me. I think it’s got some great enhancements. I like a lot of the ideas behind it. It looks like...basically what they’re doing right now is every kind of new, semi-major version of AngularJS 1 that they’re putting out – they’re kind of trying to make that gap between the two a little smaller. To make it easier, with 1.4, 1.5, probably 1.6 – if and when there is one. Just making the transition from one to two a little bit easier. So, basically if you’re currently working with AngularJS 1 or you’re afraid of it – just try and use the latest AngularJS 1 – and try and keep up with the releases as close as you can. That will kind of help you transition to AngularJS 2 a little bit easier. But the component syntax that that released in Angular 1.5, that was really important. But you can see with Controller As that was helpful, and the Binder Controller that was 1.4, and 1.3 that was really helpful.

Was there another aspect to that question that I didn't get to?

STUDENT Q: [Andrew]

No, no, that’s great – thank you.

RACHAEL

OK.

ERIK

I actually have a question. You have obviously come quite a ways and seen a lot in terms of the development on the front-end and obviously things were very different not too long ago. So, I’m kind of curious about specifically with relation to your job as a front-end developer, UI developer - what’s changed in the last few years or I don’t know exactly how many years you want to tick off on that, but from sort of operating within the HTML/CSS environment to bringing JavaScript into the browser, to then taking this superpowered framework-sized approach to things. How has that evolution affected your day-to-day?

JavaScript's early days of use & progress.

RACHAEL

It’s really kind of interesting because there’s a lot of places you can kind of make pit stops on that. It used to be that JavaScript was considered sort of an "enhancement" to HTML and CSS. You mostly only used it kind of sparingly in a D-HTML style to kind of make your HTML a little bit more dynamic. You didn’t build entire kind of algorithms in the client using JavaScript.

So, first of all what’s changed in the last six or so years is, how important JavaScript is to being really successful as a web developer – and how much you can do with it. That’s been a huge change that’s been a little good and a little bad, because I went through the era of unobtrusive JavaScript and I personally was very persuaded by a lot of the ideas in that. But there are certain things you simply can’t do with unobtrusive JavaScript like these single page web applications.

ERIK

For the benefit of everyone, do you mind kind of talking briefly about unobtrusive JavaScript?

RACHAEL

Unobtrusive JavaScript was kind of like...the whole point was kind of make your website or application work without JavaScript. Say someone came to the page and JavaScript was turned off, or there was a network failure, and they didn’t get all the scripts they needed – if they clicked on a link the link would still navigate somewhere. It was sort of the idea, it might not work the exact same way but it not might work as well and it may lack some bells and whistles – but the general idea was do as much as you can with lower level kind of, non-scripting technologies.

If you want a link, use a link. Then if you want, when JavaScript is enabled for that link to open up – not by navigating to another page but by opening up a modal – enhance that part of JavaScript, but make it so that it would still work when JavaScript's not there.

That was great, it had a lot of really good (0:11:57 inaudible) when you got used to that. With a single page web application they are also sometimes known as a "thick" or a fat client application. A lot of the code that actually creates the functionality runs in the client. So there’s no such thing as the application being able to work without JavaScript, because the application is literally written in JavaScript.

That means less full-page refreshes, less need for back-end stuff. But, it kind of makes it a little bit more challenging for accessibility, and for kind of, fault tolerance.

ERIK

Cool, and then kind of circling back to the original one was specifically in terms of the way that you approach development on almost a day-to-day basis. How has your toolset changed, and also your ability to do different things?

RACHAEL

Web dev's evolving complexity – "tooling" as one response.

Well, it’s a little bigger. I think that we have had a huge explosion in tooling over the last five or so years. (Laughs) One of the things that people used to say about web development was that it had a low barrier of entry, and it's hard to always say why that’s the case. One of the things that people point at that might have been a contributing factor to this low barrier of entry, was the fact that the languages that you were writing your code in – and then the languages that you were deploying were the same languages. There wasn’t this long "I have to compile to a binary and then send it out, and then who knows how it’s going to run on the target environment." You would write HTML and you would deploy HTML. It made it faster and more direct for a lot of people.

That was the thinking. Now, between preprocessors and transpilers, and just the fact that we’re moving more and more functionality into the front-end on the client, that means more testing of the client – just the whole pipeline and the tooling situation is now really intense. That’s a huge part of my job, now over the last four years that I didn’t even really think about before.

I mostly think that’s a good thing. I like Dev Ops culture, this idea of cross-functionality, and being able to learn from people who have different specializations. On the other hand, it can be pretty frustrating when your build pipeline gets in the way of you being able to do your work. (Laughs)

But like I said earlier, everything has trade-offs, right? So that’s another big change. I think those are the two biggest ones.

ERIK

So what toolsets do you actually use then, as part of that deployment process?

RACHAEL

Doing mostly UI, I kind of leave off on the whole "build artifact" stage. But mostly we do a little bit of transpiling, copy script to JavaScript, now it’s C-Note. Future JavaScript to current JavaScript. So we’ll do copy script compiler, ES6 to ES5 transpile. We’ll do SASS to CSS. Then we’ll do minification, and kind of combining those into a single, distributable file along with HTML templates. Then we have a bunch of testing. We have JavaScript unit tests, CSS unit tests, end-to-end tests. So we’ll use Karma and Protractor, and something with the CSS visual testing frameworks - the name has escaped me at the moment.

That can take...we have one application right now that the whole testing process takes about 45 minutes, from start to finish.

ERIK

Wow.

RACHAEL

Yeah, it’s pretty long, everybody is complaining about it. (Laughs) So one of the nice thing about working on the UI components is we try to build the tests with the UI component, and because it’s so small and focused, almost no test runs take very long. And, theoretically we can share the tests. At least, that's what we're hoping.

ERIK

I think the idea is there is a difference between working on a full application and working on a UI component may not be familiar to a lot of folks. Do you mind just talking about how that goes down, what’s the difference?

RACHAEL

Sure. Let me find some examples, it makes it a little easier.

ERIK

I promise I will stop hogging the questions after this. All of you in here you’re up next. (Laughs)

RACHAEL

Alright, here’s an example of a UI component, harkening back to that definition I gave earlier – it’s mostly just an HTML element. In this case we’ve used an Angular attribute directive to enhance the normal "checkbox" input. When we do that, we can kind of think about the checkbox controls the generic element. We start where HTML leaves off. We enhance it with our particular brand name, and then we just have some text. Obviously, if I’m going to test this, all I really have to test is that when I use this, this shows up on the screen. And when it’s not checked it looks like this, and when it is checked it looks like this.

On the other hand, if I am thinking about this checkbox here in my application, I actually have to test that, when this box is checked, and I submit with the correct password – that when I leave and come back – I’m still signed in.

Obviously one operates at a much lower level and is much easier to test and take less time to test because the test itself is less complicated. The entire application would include checkboxes, but obviously we’ll have lots of other things, too. Excellent responsive design going on here ... so, this is like the entire application, and this is an example of a component that I network on.

Hopefully that was a clear explanation.

ERIK

Yeah, those are really cool, I could sit and watch you play with them all day.

RACHAEL

(Laughs)

I am looking for component resizing, but this one is going to be a lot of fun. Checkboxes that we’ve done, we did text also - we did this one such that the input type text in the text area are kind of true in the same component, in two different modes.

ERIK

Are these available open-source?

RACHAEL

Not yet, we’re getting much closer. The whole suite will be but we don’t want to do it until we have the theming completely finished because obviously, we don’t think that most people are going to want to make guest-centered themed applications. It’s not like we’re material design.

ERIK

And so the idea of theming would be essentially the theme is sort of like a "skin" on top of it?

RACHAEL

Exactly, yeah. I think that’s one of my biggest pet peeve’s sort of - that (CSS frameworks) they make getting rid of or customizing the default not as easy as it could be where you have to print a lot of dead code or you have to write a bunch of overwriting rules. I don’t like 700 variable long style sheets. As far as I’m concerned, I can write border radius 3px (pixels) myself – rather than having a vARIAble that represents a border radius that I may or may not actually have. So we’re hoping to kind of, do it in such a way that they can be distributed without any kind of theming whatsoever, just basically the bare necessity, as far as styles are concerned.

ERIK

Cool. OK, I have one more (question) before - do you know any UI component libraries that you found helpful to learn from, like open source ones?

UI component libraries to learn from.

RACHAEL

All of them, definitely. Twitter Bootstrap has a lot of really good stuff in it.

ERIK

Are there ones for Angular?

RACHAEL

Angular-specific UI component libraries.

There is an Angular UI library that basically takes Bootstrap and kind of wraps it in some directives and services. So basically, make sure you load Bootstrap on the page, the CSS part of the framework and then you can pull out the various Angular directives. It’s been pretty popular. We have referred to its code for ideas on (0:23:21 inaudible), also Angular material with (versions) 1 and 2. (Version) 2 I believe is out, those have some great - those are great ones to reference. There is also just a bunch of other ones, Semantic UI is really interesting, just philosophically, and you know, there is JQuery UI, bunches of them.

ERIK

Great. Thank you. I promised I would stop hogging the spotlight here so someone else have a question, and by the way as a note, anyone can submit questions from outside, via the Q&A app.

STUDENT Q: [Jeff]

You talked a little bit about UI libraries. Do you have any go-to, just Angular libraries, like we use RestAngular a lot in Viking and UI Router, as just go to plug-ins I guess, that you use? Do you have any go-to’s that make developing in Angular any easier?

RACHAEL

Angular developer libraries.

Definitely the Angular UI Router. They are releasing a new one, though, for the core teams for AngularJS 1 series that I believe is out now in beta or something along those lines, and that one may take over as my go-to. But I think mostly the ones that are always big go-to’s for me are like, you said Angular UI Router, Angular Animate, the full version and Angular Mocks. Those are the ones that I always find myself using. Other than that, no. Not because there aren’t good ones, just because those are the one’s that I always found myself using.

STUDENT Q: [Jeff]

Awesome, thanks.

ERIK

Other questions? Just curious if you have any other questions here. I can always keep going.

So, one thing that I think surprises a lot of people, or even makes them a little anxious about getting on the job, as opposed to just kind of learning up and building side projects, is the idea of support and accessibility. Sort of, what is the difference between building my side project for myself and my friends, I don’t really care versus actually being on a Dev team that has an obligation to serve their users across all their platforms.

What are the big changes, the big issues in that jump that you’ve encountered, particularly being on the front-end in this new environment?

RACHAEL

Accessibility is needed (& often ignored).

Funny enough, I think I probably actually ended up doing a lot more work towards accessibility and really why it supports personal projects, versus professional projects. Especially with UX design, driving product development. The general – this is my perspective, but the general idea is you come up with a few representative users. And, like in my experience typically, those users don’t include people that are blind or deaf or have mobility issues, unless of course your product is for someone, for people who are elderly then that would make a stand to your persona.

Because the persona don’t actually include it, we typically don’t find ourselves spending much time on it. Because not only did the product design not take it into account, neither did the visual design, and now that we’re coding it up – which is really more like the third step of the process – we’re sort of inheriting a lack of emphasis on it.

I would honestly recommend when you do your personal projects – take that as your sandbox. 'Cause, most of the time the only way you’re going to have the time to sit down and really learn the tools that you need to properly support accessibility is going to be on your own time, at first. That’s just a reality. Most companies will say they just don’t have time for it.

Tools to learn for enhancing accessibility.

Those tools I would definitely say, is learn ARIA, definitely learn that. Take a step back and look at some of those unobtrusive JavaScript, like "top 10 best unobtrusive practices," because those are typically good accessibility practices, as well.

Then, when it comes to internationalization, one of my favorite things is like mock translations, where you take your English string and you sort of mingle it and make it twice as long. That kind of allows you to code UI’s that are a little bit more tolerant of on-the-fly translation changes, early. Before you actually have the real translation or even the real text. That’s been really invaluable.

ERIK

Cool, so what are the other - I mean are there any low-hanging fruit that people can take a look at? ARIA sounds interesting.

RACHAEL

Let me think: if you’re not going to full section 508 compliance, the WebAIM website is really great. It’s got some really good tips.

Everything else, is really not low-hanging fruit. Everything else I think you can do that tends to be where the effort really comes in. I have actually sat down and used a screen reader and talked to people who have used screen readers and I know for a fact, through personal experience, that this is a better approach than this. That’s where, of course, the real time-saving actually comes in.

ERIK

So in a world where we’ve moved away from unobtrusive JavaScript, to fat clients – how does accessibility play in, how do you reconcile that?

RACHAEL

Now that’s kind of what ARIA is - that’s not the only thing –  but that’s one of its reasons for being. They tend to have a sort of false equivalency of people who don’t have JavaScript and people who are on / using accessibility assistive devices. This isn’t necessarily the case. In screen readers it will totally execute JavaScript, but if it’s not a standard HTML template, how does a screen reader communicate to the person who is just having text read off that a button popped up?

ARIA has a lot of tools to sort of earmark what could happen if they interact with this button. It’s going to pop up a menu and gives the screen reader some way to tell them, "hey, a menu just popped up, you probably want to choose from one of these three things." Otherwise, you’re not really helping the screen reader to direct the user to the next appropriate step.

ERIK

Thank you. We have a question from the Q&A queue, so this one is:

What are some tools or techniques you found for optimizing the runtime of an Angular application? As you can imagine as an application grows it starts to become sluggish, especially if you use lots of filters and ng-repeats. We’ll start with that one.

RACHAEL

That is - so, being mostly on the UI layer, and also working on a new product over the last few years, we haven’t really found ourselves in this situation. But also newer versions of Angular make that question a little bit easier to answer (laughs) because we did have this one - just a second and I will share my screen again. One of the few places where we have had a big performance issue that we needed to address, is this right here.

You will see right now it’s being a little sluggish. The thing that is actually being sluggish here is the network request and the parsing of the response. Because what we have, is about 13,000 restaurants that the restaurant endpoint delivers to us all at once. You can imagine that not only transporting and then decoding adjacent object with 13,000 restaurants – but panning and searching. This was an ng-repeat at one point. So one of the things we did here was, this was before Angular had the bind once syntax, so we had to kind of make our own bind once syntax.

What we did was we didn’t want any watchers on this stuff, because every time you search it’s going to get repainted anyway - so there’s no need to have a bunch of watchers in the background when we can just repaint the whole thing.

This one was a little bit challenging because we had to sort of circumvent most of the default Angular work for us in order to eliminate those watchers. Now we can probably use bind once and have a fair amount of improvemnet. Another thing we did here was basically cause it to only ever have about 50 restaurants in the DOM at any given time, and we just basically change out the set of which 50 is showing as you scroll, which drastically reduced compile time.

You can go real, real far with those types of issues. But I would say get to know your profiling tools – which in itself is pretty challenging. These tools here creating profiles and looking at the timeline for memory and paint, those are really, really useful techniques to have under your belt.

ERIK

So if someone is not familiar with how any of these work, can you give ten seconds on what exactly is going on there?

RACHAEL

UI "under the hood".

I shouldn’t have done the whole thing - alright. Paul Irish and Addy Osmani (inaudible 0:35:01) have some really great - they’re development evangelists for Google and they have some really, really good ideas explaining how to use this on a lower level. But basically, a bunch of things are happening to get this UI on the page ready for our customers to interact with it.

In terms of this, we have the JavaScript – stuff that’s all running and we also have just like the style sheet being parsed, the layout happening, and then the painting happening. Basically what you’d want to do here is, you can look at this one. This is where we are delivering fonts through Typekit, it took this to load, 0.8 seconds, that’s not something we actually care about. But you can imagine if for some reason that was taking 8 seconds we might want to look into it and we would be concerned. But that’s more of a network thing.

If you guys have used this one, to look at how long things take to load and in what order, that’s this - this is your JavaScript actually running – your style sheet actually being parsed and painted onto the page. Basically, it gives you a lot of information about what was happening, how long it took. What you can do is for example if you have a style recalculation that’s happening when you don’t think it should be happening, or you have one that’s slow, is you can attack that one directly and get it down.

So, learning to use these profiling tools is really useful. It’s often in the full app – like this where you can see there’s a whole bunch of stuff going on, so it’s actually hard to zero in on something and find useful information. While sadly enough that’s often where you see your problems, is when you put everything together. But then once you’ve identified one, it’s good to kind of pull it out and work on it independently – which makes this a lot easier to read. And then make use of bind once when you don’t need the two-way data binding, or even one-way data binding. That will reduce the number of watchers. Scott Moss also has done several talks on "Angular watchers" that are very, very useful about how to find out how many watchers you have going, and how to make better choices about when to have them and when not to.

ERIK

Cool.

RACHAEL

General advice.

This one took almost a whole second. Aside from that, those are two general pieces of advice: is learn some profiling tools and then be conservative. Know kind of what’s happening under the hood a little. Realize that when you’re putting together directive and ease, dot-equal sign or when you have a controller and you have some data in your scope and you’re sort of using it in three different places on the page that that’s data binding stuff happening in the background. Try to only use it when you need it. Other than that it’s going to be one of those things where you have to find where your problems are and be able to deal with them one by one, which is very contextual.

ERIK

Cool, thank you. We have a follow-up here, which is:

Do you follow a particular style guide for writing clean, modular code in Angular?

RACHAEL

We mostly follow John Papa. I think we have a few that are unique to us, but mostly John Papa's, is where we refer to. If you don’t know that one, I’ll find it.

ERIK

It would be awesome to see the link.

RACHAEL

So this guy here, for some reason I don’t actually have it starred. He is kind of the industry standard for style guides. He is already working on one for AngularJS 2. This is primarily what we follow.

ERIK

That’s awesome - thank you. And, other questions from the audience? These are great questions so far, thanks guys. I know some of you are working with Angular right now...

STUDENT Q: [Jeff]

So I have one last question that might be slightly off topic, because of the prevalence I’m seeing of everyone kind of pushing React further because it only queries a phantom DOM, or whatever...

Do you feel, that in general UI design is going in that direction for more responsive design, or does Angular still have a good place in the wait, and is it still a better choice, I guess?

RACHAEL

Benefits & drawbacks of using Angular vs. React.

Not wanting to get into that mess of framework fandom - so there are things that I like very much about Angular and there are things that I don’t.

I like that it’s a tool for addressing some of the places where you see problems a lot which is kind of this glue between your business logic and your actual tree of your GUI, which is like the HTML and CSS that is actually currently visible and is part of what the user sees. One of the biggest causes of bugs is like when you’re kind of that glue between here’s my DOM and here’s my business logic and they have to sort of - based on my business logic this has change. Based on what my user does this, my business model has to change. Basically, Angular gives you a tool that is still very oriented in HTML, to build applications while avoiding that problem.

React, specifically, concentrates on the DOM diving thing. It’s very aesthetic in what it does, it’s not about the virtual DOM. Kind of like JSX, that’s kind of an aesthetic choice. The virtual DOM what it does is it provides a different kind of syntax, through JSX, to figuring out what the difference is between the DOM that you currently need, based on your application state and the DOM that you currently have.

To me I’m not a huge, huge fan of React because most of the stuff that React concentrates on is not stuff that – to me – as an individual person who is not a developer of web standards, so take this one with a grain of salt. To me, almost nothing that React does is something that can be standardized – which is why I’m not terribly interested in it.

If I wanted to write code that had my templates in my HTML I could still be using JQuery. It wouldn’t be as fast because it would have a virtual DOM, but as far as that part is concerned, to me that’s a matter of personal preference. As far as the virtual DOM is concerned, I think obviously it’s a great idea because it’s very fast. But on the other hand, that’s kind of an implementation detail as far as the browser is concerned. The browser can become more efficient at doing DOM changes in a lot of ways. It just doesn’t seem terribly likely to me that there will be one virtual DOM implementation that Blink and WebKit and Edge will all adopt.

That’s why I tend to not really keep up with React that well. Because I just don’t see it really, truly lasting – except in terms of the framework. I’m a little more interested in things that are actually going to become web standards. And Angular is a framework, too. I think you can see some of the influence of AngularJS 1, or on web components or at least on Polymer. Which as one of the early kind of implementations that web component standards, has had a lot of influence on where the standards are going.

React has come out and said that they won’t be adopting any web component stuff as part of the React framework, and so to me that’s just - I really can’t see it going in that direction. I am sure that React will remain around and will remain popular and will remain useful but I don’t think it would be at all accurate to say that’s where UI development is going. Because as far as web UI development that’s all about what the browsers implement. I just don’t see the browsers implementing most of what React is known for.

STUDENT Q: [Jeff]

That is actually a huge relief because I wholeheartedly agree, but it’s nice to actually hear a seasoned UI developer say that and actually know, because Angular seems to make a lot more sense, but for a long term framework and actually committing to. But it’s good to hear that at least other people have similar opinions.

RACHAEL

Yeah, this probably comes off as critical of React. It’s not really intended to be except in the sense that when it comes to web frameworks, there are frameworks - you can do a web framework one of two ways.

You can do it in a way that’s kind of like "poly-fillic" which means I’m probably filling a need the browsers will fill. I’m kind of working towards something I think could become a web standard or an API that the browser will actually be able to provide to me. That’s one way of going about it.

Another way of going about it is saying this isn’t something a web browser would ever do but it’s something that’s useful in a lot of cases, so here’s a utility for it, here’s a library for it and both of those things are really important and there is space for both of them. React to me seems a little bit more like: we’re solving a specific problem in a way that we don’t anticipate browsers will necessarily do. Whereas Angular kind of does a little bit of both. They do certain things, like wouldn’t it be great if this was something the browser could do for us, and also this is some specific stuff that the browser probably wouldn’t do for you. I don’t think it’s likely that we will ever have a specific "envied star system" in the browser, I think that will always be in the realm of frameworks.

On the other hand you can see a lot of influence, or a lot of commonality between implementing an Angular directive and custom elements. Custom elements have a better life cycle, but the general notion of let me have my custom HTML tabs, to me is a little bit easier to see the progression from Angular to custom elements, than it is to see the progression from React to custom elements.

STUDENT Q: [Andrew]

Awesome, thanks. I have another quick question - I guess I’m interested in learning from - you’ve been in the industry for a while and learning new things I guess, comes easily. Let’s say if you were presented with a skill sprint or a hit-list framework, how would you go about - for example if I were to undertake learning AngularJS 2 what steps would you take to learning - what’s your workflow?

RACHAEL

Hilariously, if I were going to learn anything from scratch right now it would be React. (Laughs) I have only played with it a little, so there’s probably more stuff I haven’t seen yet. But, the stuff that really works for me is kind of attacking it from the fence.

Strategies for learning Angular from scratch.

First of all, I think it’s really useful if you kind of understand the reasoning behind a thing. Kind of go into Angular’s website and reading their treatise on how everything fits together and why they did it that way, that’s great. But you won’t remember it – or I won’t unless I have actually sat down and worked with it and seen it in action and gone - "oh, yeah, they said - OK."" So I like to pull up the more academic stuff in one window and be reading it and then come up with a good problem, either one that I just recently solved on something else or something that have a lot of opportunities to play with various parts of the framework.

If you were going to use Angular, you would would want to do something that had no HTTP requests because then you would never be able to use any of the tools and the utilities for that. That’s why that to-do list app is so popular because it gives you like lists and having to make HTTP requests. So then I like to just sit down and basically redo an app that I just did. So I already know the business case for it, I will do it in the thing that I am trying to learn. I find that’s the most useful because, when you sit down and are doing a real feature, you always find that there were unanswered questions no matter how well you thought it was planned, or there’s stuff that you didn’t anticipate that was more challenging to do than you thought it would be.

If you pick something like that, you already know where those areas are, and you figure out whether it was easier or harder to address them in your new thing. It allows you to sort of, make that a one to one comparison. Without - because you’ll see in demos, people just ignore a vast swath of the problem and go, "see how easy that was?" but it doesn’t do anything. So I like to do something that’s a little bit more detailed so that I can be sure that I’m assessing it as accurately as possible.

STUDENT Q: [Andrew]

Cool, thank you. The reason I ask is when I was going through learning Angular, there was a lot of stuff that was not very obvious to me at first when I was first learning. I would go to the docs and I would read through their explanation, and I’m like "yeah, I don’t get this at all." I would do some of the stuff and then build to kind of get a better idea of how to actually implement. Sometimes the necessity kind of brings the reasoning that you just mentioned, like "why do you use link functions?" You don’t know until you actually - this app, I need something to do this thing.

RACHAEL

Yeah, especially when it comes to directives. It’s really hard to find cases for that and probably my least favorite part of Angular of the framework is the AngularJS 1 directive lifecycle, that’s probably my least favorite thing about it. I find that lifecycle to be kind of - "What? Come on!"

It’s partially vocab because they call it the compile phase but the compile phase - they’ll call it compiling (inaudible). So if you pull the compile service in and you compile, it compiles and links, so that’s kind of confusing.

Once you learn it you’re like "OK, OK - this compile is different from that compile, it’s the same wording but it’s two separate things." Yeah at first, especially when you’re sitting down in front of the docs, I have had many moments of “Oh!” I think with directives, also, one of the interesting things like with the UI library, it has been a number of things that we have run into that we never run into in our app by itself.

Before we were trying to make completely independent, completely reusable UI components, there were all kinds of little nuances to directives that we never ran into. They were there, but we never had to know them and they never caused a problem. Whereas, when we were doing the UI library, that directive lifecycle became very, very important to us. (Laughs)

STUDENT Q: [Andrew]

Cool, thank you so much.

ERIK

Thank you. I think we are drawing to a close, but I do have one question that I think is probably on the minds of at least of half of those who are listening. Which is specifically, is on getting hired as a front-end developer, which is the end-goal of many of our listeners.

Specifically as someone who is coming from a non-traditional background, what can you do to stand out when you’re looking for a role on the front-end team?

RACHAEL

Getting hired as a non-traditional (self-taught) developer.

You know it’s a really hard question to answer, and I have been on both sides of it. We are actually trying to hire for a bunch of things. But my team, specifically, is trying to hire somebody to develop these UI components.

Sitting on both sides of that interview, I can definitely say that: kind of being yourself rather than trying to impress is very important.

Don’t just give the answer that uses the buzz words. Explain it fully, explain your thinking fully even if you think you might be wrong about a certain part. Being a good developer means you have to ask a lot of questions, you have to think through your problem in a very sequential way. You have to be able to then communicate all of this stuff to other people. I have tended to find that we will have people who will come in and they will just give completely correct answers but at the end of the interview we’re not sure if they’ll be good fits or not. Even though the answers were correct we never heard why they thought so – which is actually a lot more important than just getting it right or giving a right answer.

Honestly I think that focusing – early on in your career makes a lot more sense to be a full-stack developer, it’s really important for you to be able to learn how everything fits together and all those layers of the stack. But I think, kind of tailoring your resume, tailoring what you talk about to what’s relevant to the position helps – rather than mentioning that you know .NET, (for a shop doesn’t use .NET, they don't reall care)!

Doing a little bit of research beforehand I think makes a huge, huge difference. Because you are able to sort of talk about your experiences with things that are relevant to that company in a much deeper way than you would have, otherwise.

ERIK

Great, Rachael thanks a lot. I know we got started just a little bit late, but again let me be the first to say thank you. Is there a way that people here can reach out to you, a public profile or something to say thank you?

RACHAEL

Yes, I am @morewry on Twitter. I will also send out these slides that I made for you guys. Maybe put it on the VCS Google+ page. I know there wasn’t much to them, but they’ve got my contact information on the ticket.

ERIK

OK, great. Well thank you for that, thank you for coming and talking to us tonight. I really would love to continue this, but we all probably have dinner waiting. (Laughs)

RACHAEL

Me, no. I have to be here until midnight. Just kidding. (Laughs) It was wonderful meeting you guys!

ERIK

Everyone else, see you next week!

Contacting Rachael

Twitter

GitHub

Rachael's Slides shared from the Codecast

From n00b to ninja, we'll help you to become a developer
Subscribe to get expert guidance on learning, building, and getting hired delivered right to your inbox each week.


We guarantee your privacy 100%. Your information will not be shared.
NOTE: Comments are disabled outside of the "https://www.vikingcodeschool.com" production environment to prevent Disqus from assigning the wrong URL and forcing us to map away from `localhost:3000` each time.