Basically, a good way to describe it is . . . let’s compare, Ruby on Rails is synchronous, right? It’s the opposite of asynchronous and a good analogy for me, to help me understand asynchronous programming is this: let’s say your web application is a kitchen. In your kitchen you have chef who is cooking something and that chef needs several sous chefs to get him ingredients, right? In Ruby on Rails, when the chef is cooking something and let’s say he needs the salt, he needs to wait for the sous chef to get him salt so that he can continue.
This is why when you look at an OJS, an OJS calls itself non-blocking and this is what they mean by non-blocking. It means that, on Ruby on Rails, while I need to wait for my salt to continue cooking; I need to wait for a sous chef to come. Whereas, in nodes I don’t, I can just tell my chef to get the salt and he’ll give me a promise that he’ll give me back the salt and I can continue doing stuff and I’m going to expect the salt. I don’t have to worry about it, it’s done. I just continue going.
So, there’s this concept of promises, which no JS Angular provide very good libraries to work with. Like in Angular JS you have a library called “Dollar Queue”, which work in Angular JS, which is really good for resolving promises on the front-end when you’re making calls. The concept of promises are great because they allow you to do many things on the front-end and on the back-end.
So Ruby on Rails, the supermarket, you have lanes in supermarkets and you have queues. In Ruby on Rails, you basically have a cashier, you have queue for things to happen and if you want to scale on Ruby on Rails – the only way to scale on Ruby on Rails is to add more lanes, you add more ….
Harris: It gets very expensive because you are scaling in horizontal. You just keep adding and adding and adding lanes and what happens with that is that you reach a point where it becomes very expensive and very hard to scale. Whereas, with nodes, it’s different, because it is asynchronous, you don’t need to just add more lanes. There is many more ways to do that. It is easier to scale out actually.
Richard: Right. So what you’re saying is that because it’s not this serial type of activity where you have to wait for the resource to come back to you.
Harris: Yes, that’s correct. Yeah. And what’s great and Angular is really good at that because it’s like . . . and yeah. That is absolutely why. And another thing that needs to be taken into account is that Ruby on Rails is very server heavy. Servers, they cost money; you have to worry about them. Angular and nodes lets you to do a lot more on the client. It makes sense, right?
So one thing that you’ll notice is that the industry, in general, is moving from what it used to be fat servers and thin clients to fat clients and thin servers, which makes total sense because you would rather let the heavy-lifting be done from a user’s computer, which has a very fast processor. I have a MacBook Air right here, I7 chip, really fast processor. Why would I let the server do the heavy-lifting when I can have the client do the heavy lifting? Which is better. It makes more sense.
So Angular is really good at kind of removing that heavy-lifting from the server. So, “persistence of the data” of the client, Angular is really good at that. For example, let’s say when you load a page from the Internet, so Angular is developed to make single page applications.
So what they mean by that is that when you first load your web up, the time you make a request to load a page, that is the only time you are going to make that request in the duration while you are on that application because Angular has something called “template cache” and if you want to look it up it’s “$” and “template cache”, which basically caches your entire templates on the clients so there’s no more reloading, there’s no request, no loading.
So once you go somewhere and you go back, you can always go back instantly and it’s all being fetched locally. Also, it’s really easy to save something to local storage. Just removing that loading is really great, right? So it makes an XHR request, saves it to template cache and keeps it there, which is really good.
Richard: What recommendations would you have for somebody who is listening here and who says, “I want to learn this”?
After that, if you start diving into frameworks, Angular JS is the first front and end framework I tried, and there’s a lot out there. There is Ember, there is React right now, which is very popular. But really, Angular is like, at first, you’ll pick it up, you’ll be able to do stuff. You’ll be like, “this is easy”, but it has a really steep learning curve. Really, it does, once you start trying to do things.
So, really, the best way to is reading and doing together. Don’t forget to learn and to read but don’t only just read, but do as well. Don’t only just do, but read because you might be doing it wrong and there’s a lot to learn so both, I think keeping that balance is really good. And when I say doing, the best thing is decide, “Okay, I want to do this,” pick it up and go for it. You’re going to run into a lot of obstacles, you are going to run into a lot of problems, but every problem that you run into is something new that you learn.
Richard: Right, exactly. And so you should look at it as a learning experience even though it can be a frustrating experience, it is a learning opportunity for you.
Harris: Yes, you look at it as a learning opportunity even though it can be frustrating and that’s why places like Fullstack is great because it lets you do more of the learning and reduces the frustration.
Richard: That’s true.
Harris: It’s really what you want. What I believe you want in a [inaudible 00:15:07] which what I believe you want. Another thing, which framework do I recommend? A friend of mine was telling me the other day that React is going to be the next best thing. A friend of mine was like, “I really like Ember.”
What I would say is, don’t really listen to anyone. Pick one and start because in the end, they are all MVC frameworks and they are trying to do the same thing in different ways; except, I have to say, some framework are obviously more complete than others.
I personally would recommend Angular because if you pick a framework, like Backbone, Backbone is very simple, but you have to do a lot of things to get the same function that Angular gives you out of the box. Something I can build in Angular in two hours, in Backbone would probably take me all day because the simple thing that Angular lets you do out of the box aren’t in Backbone, and you have to do that yourself.
Angular has two-way data biting, which is really important and really good. Two-way data biting basically allows you to easily, in real-time, communicate from your viewer and your controller in real time and synchronize data in real-time from your viewer and your controller. If you want to do that in Backbone you would have to implement.
Richard: Yeah, okay. Might not be something you want to face. If it’s already done I can see the advantage there.
Harris: Right, as in Angular, where it’s already done, so there’s these little things that if you use something, like Backbone, you have to implement yourself. Why would you want to spend time implementing?
Angular is right there, it was made to be an extension of HTML. If you think about it, HTML was made to deliver static documents. Angular is trying to make HTML something that’s made to make web apps, which is something different from static documents. These things are really very important when you’re making web apps. Things like two-way binary, that in my opinion, I don’t see why I would want to spend that additional amount of time just implementing that when I know that I am going to need it every time.
Also, something like React, a lot of people are liking because it is simpler than Angular. Angular is huge, so when you start Angular, if you are overwhelmed, don’t worry. It’s really big. I think a lot of people are overwhelmed. Even the people who have experience in Angular because it’s just huge. One thing I want to say to anyone who wants to start, when it comes to the documentation in Angular, if you are trying to learn, don’t even bother looking at the documentation.
Harris: Only look at the documentation if you want to confirm things that you already know because the documentation in Angular is famously terrible. But if you want to confirm stuff, go for it. But don’t go there to really learn. Instead, read books. There are a lot books out there that are recommended. React, on the other hand, does things very differently. It’s a library. But also, like I said, Angular is a complete package. Most of the time, if you are using Angular, you’re not going to need to implement essential things. If you are using Angular, you pretty much have everything you need right out of the box.
Harris: And if you master Angular, it’s really easy to pick up on your MVC front-end frameworks.
Richard: Your other frameworks because you learn the MVC structure and off you go.
Harris: [inaudible 00:19:14] yeah.
Harris: So it’s not only consumer products, even enterprises I am starting to hear about enterprise level companies that are starting to use nodes. So yeah, definitely it opens up a lot of opportunities.
Harris: Yes, exactly like you said, I’m open for opportunities right now as I am basically wrapping up at Fullstack. I am looking for opportunities and thank you for inviting me.
Richard: It’s absolutely my pleasure. I know you are looking for opportunities in both New York and Montreal, and all over. Is that correct? You are pretty much open?
Harris: Yes, I am pretty much open. What is more important for me is where I am working.
Richard: Exactly. Well this has been really great. We should sign off and again I want to thank you very much and congratulations on wrapping up your commitment at Fullstack. That’s pretty remarkable.
Harris: Thank you, thank you very much. It was a really good ride. And again, thank you for inviting me. It was good to talk about that.
Richard: Yeah, absolutely.
This article is part of my Web Development guide.