The panelists discuss the MEAN stack with Ward Bell and Valeri Karpov.

Special Guests: Valeri Karpov and Ward Bell .

   

Dude, I see a picture of you wearing a suit. 

 

VALERI: Yeah. I’ve been known to occasionally wear a suit. 

CHUCK: I’m sorry.  

 

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] 

 

CHUCK: Hey everybody and welcome to episode 92 of the JavaScript Jabber Show. This week on our panel, we have Joe Eames. 

 

JOE: Hey there. 

 

CHUCK: Aaron Frost. 

 

AARON: Hello. 

 

CHUCK: Jamison Dance. 

 

JAMISON: Howdy, folks. 

 

CHUCK: I’m Charles Max Wood from DevChat.TV. And this week, we have two guests, Valeri Karpov. 

 

VALERI: Hey guys. What’s up? 

 

CHUCK: And Ward Bell. 

 

WARD: Hello everybody. 

 

JOE: Chuck, aren’t you going to check that you pronounced the word Bell correctly? [Chuckles] 

 

CHUCK: Ward, how do you say your name? 

 

WARD: I say it [in Italian accent] Ward Bell. [Laughter] 

 

CHUCK: Grazie mille. Alright. So, we brought you on to talk about MEAN development or the MEAN stack or whatever, I guess they call it a couple of different things I’ve seen. So, MEAN stands for MongoDB, ExpressJS, AngularJS and Node.js. So, what is it about this particular stack that is so appealing? 

 

JOE: Besides the acronym. 

 

VALERI: The acronym is very pippy. And I credit the acronym for giving it a lot of its buzz. [Chuckles] 

 

CHUCK: You should have called it AMEN, AMEN stack. [Chuckles] 

 

VALERI: People actually have suggested that. But on the other hand, I don’t know. I don’t think AMEN would be as pippy. [Laughter] 

 

CHUCK: MANE? 

 

VALERI: MEAN has a little bit of attitude to it and I kind of like that. 

 

WARD: And you know, we threw a B in front of it to put Breeze on it, so we call it B.MEAN. 

 

JAMISON: B.MEAN. 

 

VALERI: Yeah, there’s also MEANS with Sails, a couple of other spinoffs that I’ve heard. It’s [chuckles] oh man, it’s fun. 

 

CHUCK: When I did the Google search, it came back with Mean Girls. [Chuckles] 

 

VALERI: Oh man, that’s an SEO fail. 

 

CHUCK: Yeah. 

 

VALERI: Need to work on that. 

 

CHUCK: Well, that’s what you get when you just google MEAN instead of MEAN stack or MEAN, anyway. 

 

WARD: Have we said what it stands for? Because there are other people poaching on it, too. 

 

CHUCK: Am I looking at the wrong MEAN? I said Mongo, Express, Angular, and Node. 

 

WARD: Ah, but I just saw somebody do one where they substituted MySQL for the M. So, I thought we should say it explicitly. 

 

CHUCK: I just want to apologize people for their own lives if they’re using MySQL. [Chuckles] 

 

VALERI: Oh man, 2006 called and wants its technology back. 

 

CHUCK: Oh, man. 

 

VALERI: Not to hate too much on MySQL. It has its uses, but I mean, no pun intended, right now I

definitely think that MongoDB is the better general purpose database out of the M’s, MySQL or MongoDB. Again, the thing that really got me on to MongoDB, just getting started right off the bat, was there are plenty of other database products that I had used and none of them were just quite as simple and intuitive to me as MongoDB. What I want to do with a database, I want to be able to go in, I want to store something, then I want to be able to query for it by whatever I just inserted. And with MongoDB, it was just like, “Oh, okay.” I just download a tarball, I unzipped it, I ran a program. And all of a sudden now, I can start inserting things. I haven’t had to go set up a table. I

haven’t had to install anything. It just let me get started and basically got out of my way, which is the mark of the best products, I think. 

CHUCK: Yeah, I tell people, I have clients come to me and they’re like, “So, I keep hearing about this NoSQL thing. And since my product is going to have a million and a half users on it, I need to use MySQL.” And sometimes MySQL lends itself very well to their problem and sometimes it seems like a relational approach would work better. Of course then, I’d put them on PostgreSQL. But I think it really just depends on your problem domain. I think in a lot of cases, it doesn’t matter because you’re just putting stuff in and pulling it out. But yeah, I think there’s a place for both paradigms and it just really comes down to what you need and what you’re familiar with. 

 

JAMISON: That’s your answer to everything though, Chuck. 

 

CHUCK: Yeah, I’m a consultant, so it depends. 

 

JAMISON: You sit squarely in the middle. [Laughter] 

 

CHUCK: I really like both. So… 

 

VALERI: Oh, funny how consultants and some SAS people are similar in that regard. And well, disclaimer, I currently work for MongoDB. But that is also my opinion as well as the company’s opinion, that MongoDB is awesome. 

 

CHUCK: No kidding. 

 

VALERI: Since the disclaimer, anything I say on the show doesn’t reflect my employer’s opinions necessarily. But also, I’m not necessarily speaking on behalf of MongoDB here. Just wanted to get that out there. 

 

WARD: Yeah, I think that’s important because while I really appreciate your enthusiasm for Mongo and I

have enthusiasm for Mongo, I think we need to explore the reasons for the choices around that and to recognize the challenges that you face when using it in certain kinds of more traditional application environments. I know this is all, “Let’s all get enthusiastic about the MEAN stack,” because that’s worth doing. But losing our heads about it [laughs] maybe we don’t want to do that. 

 

CHUCK: Yeah, I do have to say though, that having the MEAN stack for example, having something where it’s, “Look, here is a stack that we know works and here are some practices that you can use that work well with it and here are some frameworks that hang together nicely,” there is definitely some advantage to that. Because there are a lot of people out there then using the same tools for the same things and the entire stack benefits. 

 

VALERI: Yeah, absolutely. The more people use it, the more tools are built around it and the more useful it becomes. It’s one of the interesting things that people see, coming back to the database space in that you can sit around and argue that CouchDB or MySQL or Cassandra are better for certain purposes than MongoDB and you might actually be 100% correct. But the big advantage of MongoDB, at least I feel, in addition to the fact that it’s a very simple product to use is that there is a huge community around it. And basically, we actually have engineers that are -- or we have support rotations where people spend their time going around answering Stack Overflow questions. So the community is there. The support is there. And the tools are there. 

 

CHUCK: Yeah. 

 

VALERI: And I think that that makes things a lot better. And I hope to see that, the same community building up around the MEAN stack. 

 

WARD: Yeah, I agree with that. 

 

JAMISON: I think an interesting thing to consider about talking about technology choices in general is how much of it is we pretend like we’re making the objective best decision, but it’s really hard to have perfect information about both what your problem is actually going to be and what the technology is actually going to do when fit into your problem. So a ton of our talk about how good things are as rationalization is backed by emotional things. And I think there’s this logo about Node that I like, “JavaScript is fun, and so Node is fun,” that’s a great justification to use Node. And MongoDB, it’s also really easy to get started with and just get stuff up and running with. So, that’s a great reason to pick using it because it feels good. And if you run into technical problems later on then that’s a different issue. But no one has perfect information about the world when they decide what they’re going to use. So, using what you like and what’s enjoyable to you. 

 

VALERI: But you can think of some pretty objective advantages. But again, you can’t have perfect information, but there are certain things like, “Oh, if I’m building a web application, at some point I’m going to have to introduce some complex concurrency. I’m going to have to have say, I’m going to have to do a csv dump of my data 12pm every day. So, the analytics guy can sit around and play with it. Or I might need to do say, n concurrent requests to Facebook to get to, I don’t know, to deference some data pointers or something to that fact and get some location information. And if you want to do that, that’s really where Node.js shines where you can come in and just do this very sophisticated concurrency in an event-driven format. And eventdriven code really makes a lot more sense to me in terms of how the concurrency is managed simply because you don’t have to worry about being interrupted at any given time. You don’t have to worry about guarding things with locks. So, it makes that sort of task of building out sophisticated concurrent programs a lot simpler. And again, that’s one of the things that I’ve seen the MEAN stack really have a good advantage over more older and more developed web development stacks, say a full Ruby on Rails stack or something to that effect. [Crosstalk] just that concurrency is stupidly easy. 

 

JOE: That’s interesting, Valeri. You know, I say most people jump over to MEAN thinking, “Hey, either I’m doing Rails or I’m doing something else and I want to try that’s a little bit more on the edge, maybe.” And so, they jump over to MEAN but they’re probably not thinking from a concurrency standpoint. Most apps aren’t really like, other than scalability-wise, for concurrency you’re not thinking about, “Oh, I need to be doing something crazy concurrencywise,” so you’re not necessarily driven over to that stack because of that. Would you agree with that? 

 

VALERI: I would agree with you there. It’s not something that people think about when they first get started. It’s not something that I thought about when I first started building my first MEAN stack application. It wasn’t exactly high on my list of priorities. But as the applications evolved, I started to see, “Oh, it would be great if I could do this, that, and the other thing,” always just adding one more thing, maybe things like, “Oh, I want to be able to notify the administrator every time something happens but I don’t want to slow down my response times for that.” So, I just want to handle that asynchronously after I’ve returned everything to the user already. And where this really clicked for me as MEAN stack as just a tool for making a very concurrent web server came from when me and my roommate actually started doing Bitcoin arbitrage. My roommate came to me in March and just told me, “Oh, there are all these Bitcoin exchanges and the prices are just so wildly different that the math works out where a few times a day, we can execute some trades and make some decent money.” And so, I sat down to do that and I just wondered how can I do this? Oh hey, why don’t I just use Node? Node is really good concurrency, right? And then basically within an hour, I’d gone from nothing to basically just throwing out live trades, mostly because I can listen to a Socket.IO stream here, I could ping a REST API there, that all comes together seamlessly. And oh by the way, I have a web server running on top of it powered by Express so I can serve up whatever price analytics and history of trades and all these things right from my browser. And as somebody who had just left their job at a high-frequency trading firm, this just blew my mind because I had just come from a job where basically we had huge teams of people getting paid exorbitant salaries to do pretty much that. 

 

CHUCK: Now I want to ask, I’m going to redirect just a little bit here. I’m pretty familiar with what MongoDB is about, what Angular is about, and what Node is about. I don’t think we’ve talked a whole lot about Express. Can you talk about what that gives you on top of Node? 

 

VALERI: I would say that the biggest advantage of Express is again, it’s a product that gets out of your way and lets you access Node. But it gives you on top of Node a

very simple framework for building up a RESTful API on Node.js. So, a Node server without Express would make things a little bit more difficult where you would have to define your routes, you’d have to be able to go in and pull various things from HTTP headers, take care of parsing that. Whereas Express gives you a nice little framework for thinking about things in a modern MVC web framework fashion. The framework is based on Sinatra, which is a Rails competitor, basically a Ruby server MVC framework. 

 

CHUCK: Kind of. Sinatra’s not really MVC, but it is a very lightweight way of managing web applications. 

 

VALERI: True. 

 

CHUCK: And you can definitely add the model component to it. 

 

VALERI: True. The M is explicitly missing from Express. Yes, you’re right. But the M, you can add on yourself. It’s relatively simple. 

 

CHUCK: Yeah. 

 

VALERI: The big advantages it gives you, the framework for writing a function that takes in an HTTP request and outputting an HTTP response without having to necessarily deal with the ugliness of setting up all the correct headers, computing the response length, various things like that. 

 

JAMISON: So, we talked a little bit about why if you’re using Node, Express is a good decision. We talked about why Mongo could be a good decision. Can we talk about why Node is a good fit, or why Mongo is a good fit for Node vice versa? 

 

CHUCK: One thing that comes to my mind is that the document is, at least for the most part, very comparable to a JSON object. And so you can take an object, probably less any functions you have on there, and put it into Mongo fairly straightforwardly. 

 

VALERI: Yeah, that is again, the first advantage that I would think of with Mongo and Node, is that if you have a JavaScript object, you want to save it into a database, okay. It’s saved as is. You pull up a Mongo shell, you run a query, you get back pretty much the exact same object you saved. Maybe if you hadn’t added an ID field, it will add an ID field for you, it being the Node.js MongoDB driver. 

CHUCK: Okay, one other thing that comes to mind is the fact that the MongoDB console and any, I can’t remember what Mongo calls them, but they’re basically stored procedures, are all written in JavaScript as well. And so… 

 

VALERI: The shell helpers? 

 

CHUCK: Yeah, well… 

 

VALERI: It’s one of the ways we call just the query language, do you know what I mean? 

 

CHUCK: Yeah, the query language is basically JavaScript. But also, you can actually tell it to do map reduce functions inside of Mongo to manage some of the data that way. I’ve done that with analytics where you basically log every instance and then it goes in and it actually distills it down so that you get reporting and things like that in MongoDB. And the database engine is actually managing that logic in JavaScript. 

 

JAMISON: Yeah, you can always eval JavaScript and most queries let you pass in arbitrary JavaScript as an expression that will get evaluated. I can be a lot slower, but… 

 

VALERI: Although putting on my MongoDB hat, we don’t recommend that you do server eval… 

 

JAMISON: Oh, yeah. 

 

VALERI: Where you’d send eval in your queries. You can do it, but we recommend that you don’t. And probably 99.99% of the time, you don’t have to. And yeah, unless you really, really know what you’re doing, the answer is no, don’t use it. 

 

JAMISON: Yeah, I think I’ve done it once in a couple of years and it was just exploring on the command line. You don’t want to expose your server to cross-site scripting. I don’t know. [Chuckles] 

 

WARD: So stepping back… 

 

VALERI: One of the funny things that you end up with when you’re in the SAS base is the realization that if you include a feature, somebody will find every possible way there is to use it incorrectly. So, eval ends up being one of those things where people just try to use it and get shot in the foot. 

 

WARD: One of the things I think we’re circling around when we’re trying to identify the value of the MEAN stack, at least for me, is that I think we have a vision of a particular kind of application, probably something that would be called a single-page application delivered over the web, and what’s running through our thoughts is that we get to use JavaScript from one end to the other. And I think that that’s what’s really attractive, for me anyway, about this stack, is I try and think about how I would put it to use even in the application space that I’m most familiar with, which is business or enterprise applications rather than consumer-facing applications. I’m wondering if that resonates with you guys or whether I’m just smoking something different. 

 

JAMISON: No, I totally agree. I was just thinking some people, they have lots of visceral reactions to Node and Mongo and for some people, that phrase “use JavaScript from one end to the other” just probably made their heads explode with rage. 

 

AARON: Yeah. They’re crying right now. 

JAMISON: But for some people, I don’t know. I enjoy it. I think JavaScript is fun. 

 

JOE: Not only that Jamison, but what is the payoff for getting to put a single, getting probably a vast look of your developers if you’re doing MEAN stack at your shop, only working in one language across the board? What’s the payoff there? 

 

JAMISON: Well it’s not sharing code, because that is a pipe dream. 

 

AARON: Yeah. 

 

VALERI: Oh, there is a lower barrier to entry in terms of understanding the codebase. You don’t necessarily have to look for somebody who can be like, “Oh yeah, of course I know Go and C++ and Ruby and all other things,” in order to be able to balance you codebase, especially if you’re a small company where you only have maybe a handful of people. You would like it to bring on people who can understand everything front to back. And that’s one of the advantages, I guess from a business perspective. 

 

CHUCK: Yeah, but I want to disagree slightly. Yeah, Ruby isn’t JavaScript and Go isn’t JavaScript, but we’ve been building apps with the Java or C# or Ruby or whatever backend and a JavaScript frontend for years and years. And sure, people tend to know the nuances of their server-side language much better than they know JavaScript in the browser and I can see that as an advantage. But at the same time, we have large well-written enterprise applications or ever wellwritten small applications where somebody wrote the backend in one language, the frontend in another language, and they were fine. 

 

WARD: They do work fine, but you still have impedance mismatches at the connecting points. And that’s one of the things that really pop out at me whenever I work. I work in all these different stacks, right? But the thing that pops out at me when I work in what we’re calling the MEAN stack and with all of its intended tools, Grunt and so forth, is how at the points at which the different layers meet and the tiers meet, you’re not translating from one representation to another. Well you are, but you know what I mean. You’re not changing. You’re not having a technology transfer. So, you’re not dealing from say a static type like the way the customer is structured in a statically-typed language on the backend and then saying, “Well now I got to turn that into JSON and then I got to rehydrate that back on my client as something else.” And those things go away. And the other thing that really pops out at you is that the cycle, the development cycle, you iterate completely around that, from spinning up the backend to developing on the frontend and moving back and forth, it just feels comparatively frictionless. And that just isn’t true when I’ve got a different technology that I have to spin up in the backend. 

 

CHUCK: I want to disagree with one point and then agree with another. And really, the point that I want to disagree with is that most, JSON to JSON or whatever, most languages have a pretty seamless process for importing JSON and turning it into whatever you need to. And you actually have to do that with JavaScript anyway, if you want to do any kind of inheritance or add any functionality to the JSON in order to make it a functional object. But the thing I want to agree with you on is that the contextswitching that you have to do is mitigated somewhat. You can have the same style guide for the frontend and backend. You can use the same processes. For the most part, you can use the same tools. Yeah, you can’t share code, but you have all of those other things going for you. So you don’t have to change environments. You don’t have to change the mindset on the tools. You don’t have to handle as many of the differences between the two languages and the way that their virtual machines work. But at the same time, you do have to be able to keep in mind that Node.js is not the same as the engine that’s running in the browser. And there are going to be some mismatches that happen there. It’s just that the mismatches aren’t at the linguistic and syntactical level. 

 

VALERI: I’m going to make a quick disagreement there with the statement about code sharing. Yeah, for the most part code sharing is not going to happen, but there are a couple of cases where it actually can be advantageous, which is number one: enums. Again, if you could have a common enum on the client and on the server and not have to deal with keeping the two in sync or transferring them with protobufs or something to that effect. And number two is the testing paradigm. One of the things that I’ve really found very advantageous is having my tests written in the same language and the same way. I have Karma running my client-side JavaScript tests in Jasmine and I just run Jasmine on my server-side tests as well. 

 

WARD: I’ll throw another one into the pot, which is the validation logic. Obviously, your final validation logic needs to be on the server. But it’s very helpful to user experience when you can project that same validation logic onto the client. And if you have simple things like the order date has to be before the ship date and stuff like that, these little things that go on, and it’s really nice to be able to move some of these rules around or have them execute in both sides. So, I’m not minimizing the differences on the two sides. What I’m saying is that the points at where they come together, they come together in a much smoother fashion. You’re dealing with structural types at those boundaries and types that you can monkeypunch. And all of these things make it just easier to move back and forth as a developer when you’re trying to write an application on both sides – the client and the server – at least in my experience. 

 

CHUCK: Right. I do want to ask a question about that. When you are sharing the validation code or some of the other behavioral things that are more or less the same backend/frontend, do you use the same JavaScript files and just expose them to the web side? Or do you actually duplicate the code in one way or another? 

 

WARD: I would prefer to factor it so that there’ll be some that’s purely server-side. But I would factor it in such a way that, that’s the value is that I would be able to literally reuse the code. 

 

CHUCK: Yeah. 

 

WARD: Now, I’m not saying that’s everything. I really think that there’s much more involved here. There’s a common JavaScript culture. There’s a common toolset. Like what Valeri’s talking about with the testing, when all of these things are all shared and all of the programmers on the application are speaking in the same way, working with the same tools and so forth, and can be repositioned to contribute significantly at any place up and down, I think that’s a real positive. 

 

CHUCK: Yeah, I can definitely see that and I identify with the opposite. I worked with a company that had a Ruby on Rails backend and a Flash frontend. And the two really didn’t mix. And it would have been nice to be able to have the frontend guys speaking the same language as the backend guys. And there’s a definite advantage there. 

 

JOE: Yeah, that’s true. I think the industry’s seeing some pretty interesting things. In 2000, everybody was a server developer doing a little bit of web stuff, right? In 2012, I think we saw a huge rise of just frontend developers. Certainly, that’s not anywhere near the majority, but guys who were just working in JavaScript probably hit certainly a bigger peak than they’ve ever hit before for the number of jobs like that. And now we’re getting back to where we can say well, they can be hardcore frontend and still go into the backend because they’re using the same language. 

WARD: How about this other factor, too, which is that there’s an enormous amount, there’s an explosion of open source library solving this problem, that problem, a problem here and there, in the JavaScript space that people are [visibly] grabbing and forking and redoing. And there just seems like, if you want something that you don’t have, you can go out there and search for it and plug it in. And I just didn’t find that that is easy to do or is common in the C# or Java space. 

 

VALERI: A lot of that down to, well at least for the Node space, that comes down to the advantages of the Node package manager, npm, which is one of the things that makes the MEAN stack really shine, in my opinion, is the 50,000+, as of a couple months ago it’s over 50,000 npm packages. Again, npm has its own problems, but the things that they do right are things like all I have to do to get started with using a repo, it it’s a well-written repository, is I clone it off of Git, I go in, I run npm install to install all of the dependencies, I run npm test to test it, and now I could go in and start tweaking it. I don’t have to go in and start finagling with my binary path. I don’t have to really go around and set up proper build tools or set up a different source control tool that I don’t necessarily use, like having to install Go from source via Mercurial, which is a pain. 

 

CHUCK: [Laughs] 

 

VALERI: It’s a huge advantage to being able to lower a barrier to entry from “I don’t know anything about this repo” to “I’ve taken it down. I’ve installed everything I need to install and I’ve run all of its tests with basically three lines of code, or three lines at your favorite command line.” It’s pretty damn cool. 

 

CHUCK: So, I want to get into another holy war that I see periodically and that is you picked Angular over say Ember or Knockout or any of the other dozen or so popular frameworks out there. Was there a reason besides the acronym that you did that? [Chuckles] 

 

VALERI: Well, my usage of Angular goes back a very, very long time, all the way back to 2010, late 2010 when basically Angular was written by my mentor when I was an intern at Google in 2009, a guy by the name of Miško Hevery. If you have not read his blog and you’re a JavaScript engineer, I highly just cannot recommend it enough. The guy’s a JavaScript genius. And he definitely is one of the people who taught me how to write JavaScript well. There’s a lot of bad JavaScript out there. I’m very much guilty or writing a fairly significant amount of bad JavaScript in my lifetime. But Miško did a great job of teaching me the correct way of doing things. And well, from there when I got started with Angular, I had come from basically just using jQuery. And that wasn’t quite cutting it in my use case. So I got started using Angular very, very early, did some personal bug fixes while I was getting started. So I’m very, very familiar with Angular and it’s the way that I think about things. And in all the time that I’ve used it, I have not really seen the necessity to move off of it. I’ve tried Ember. I’ve tried Knockout. And they haven’t upped the bar enough from Angular for me to move off to something else. I don’t necessarily have any real pain points with Angular when I’m using it. It’s just a library that does pretty much everything that I’ve ever wanted to do on the UI side and then gives me suggestions for what I could to, things that I hadn’t thought of. So it’s extraordinary. And I have a lot of experience with it and that’s why I put it into the acronym. 

 

WARD: Well, I have used the others and I actually have a pretty high regard for not Knockout [inaudible]. I think of Durandal as being an equivalent. It’s more than just data binding and Knockout is about data bindings. So when I look across the choices that you have for a presentation framework, I think that the others are worthy. But the thing that people are finding really attractive about Angular is that it doesn’t lean on observability in order to know what’s going on when it’s doing its data binding. I think that’s the really distinguishing feature as a developer. And the consequence of that, you may say, “Well what the heck does that mean?” The consequence is that when I get that object from Mongo coming over, I don’t have to transform it by making each of its properties observable in order to make it bind. And just taking that whole business out of the equation makes it a much easier introduction to wedding your presentation framework to whatever’s going on in the backend. It just seems like the writing of the code is less, you don’t get trapped into morphing the JSON coming in in order to make it presentable. And taking that out is the biggest thing. And I think that’s one of the reasons that Angular really won. Now, it just so happens that it’s also beautifully written, as you say Valeri [chuckles]. And it has the wonderful testability features and it has the built-in dependency injection and all these features that as a long-time client developer in technologies like Silverlight and C# that I would expect when I’m trying to build a single-page application that is heavy in client-side execution. And they’re all built right in and they drop out of the box. So Angular is a great choice. It’s not the only choice, but it’s a great choice and I think it fits right in. 

 

VALERI: [Chuckles] I guess the question that we need to ask is, “Will it bind?” [Laughter] 

 

JOE: Nice. 

 

VALERI: Oh no, that’s actually another very excellent point about how, and something that I’d like to harp on a little bit more where the fact that you can basically just take an object immediately from your JSON, immediately from your server, and you don’t need any extra work to glue that to your user interface is extraordinary. And probably one of the biggest advantages that I’ve had is that again, as somebody who’s worked for relatively small companies for much of my career, I have seen that basically whenever I have to interface with a designer, I want the designer to have as much autonomy as humanly possible. I don’t want to have to go in and micromanage and tweak their jQuery or something to that effect. So now, with the MEAN stack, pretty much all I do is I write a $http.get or puts in order to get back some JSON data. I populate, I assign that value to some object in a scope, and then my designer can basically just go in and without having to write any JavaScript on their own because, well tragically there may be designers out there that write good JavaScript but I have not worked with them [chuckles]. So in my experience, yeah, I don’t want my designers writing actual JavaScript. So this gives them the ability to just go into the HTML, not have to even bother thinking about JavaScript and just go in and say, “Okay I want this particular variable. I want the user’s name to appear here. And I want them to be able to change their name in this input field,” and have that automatically propagate all across the UI without having to do any extra work. 

 

CHUCK: Yeah, there are definitely some nice things about Angular. I’ve played with Ember and Angular and I tend to lean more toward Angular myself. I have one more question and that is, and this is something that I hear about most technologies that are not PHP, and that is that the hosting story for PHP is really simple. It’s usually installed just about anywhere you want to host, on shared hosting, on most servers. All you have to do is put your PHP app up somewhere and then point Apache or Nginx at it and it just works. Do you see MEAN becoming mainstream enough to get to that point as well? I know that there are, and I guess this is a question more along the lines of Node or maybe Express, but you know, is there a simple hosting story for MEAN or Node? 

 

VALERI: I’ll take this question first, because first of all, as somebody who has had experience dealing with Apache, you make it seem like dealing with Apache is very simple. 

 

CHUCK: I did gloss that, didn’t I? 

 

VALERI: And I’ve heard of people who, their fulltime job is managing Apache config files. It’s not an easy thing to do. The advantages with running basically MEAN or everything on top of Node is essentially all you have to do is install Node. That’s it. You install Node, you run your test, and then you basically just run a Node process and point it to your main file. And there you go. You have a web server. You don’t necessarily need Apache or Nginx or any of these other things. It makes it considerably simpler. And as a matter of fact, actually if you all have heard of DigitalOcean, which is an EC2 competitor that gives you SSDs and serve highperformance hard drives on your instances, they actually now have basically an instance that comes prepackaged with Mongo and Node in a MEAN stack setup, which is very cool. It takes you from having to, saves you the effort of having to actually go through all the effort of having to go sudo apt-get install node. Well, saves you one line at the command line, which is [chuckles] great I guess. But yeah, I think that’s one of the advantages of the hosting setup, is it’s already very easy if you’re on an Ubuntu box or a Mac box or even a Windows box, it should work. And if you want to make that even easier, go to DigitalOcean and spawn up an instance with them already installed. 

 

CHUCK: Yeah, I [inaudible]. DigitalOcean is awesome. I love those guys. 

 

WARD: And all the cloud providers make it easy, so why waste time with that if you just need a server? Just pop it up there. Or I guess the answer to that is if you’ve got an internal application. But it’s pretty easy in the cloud and it’s pretty easy on your box. 

 

CHUCK: So, one other question I have then is if you deploy more than one MEAN application to the same server, do you need something like Nginx or Apache then to proxy that and say this domain goes to this app and this domain goes to the other app? Or is there a way to work around that? 

 

VALERI: To the best of my knowledge, I don’t have a good answer to how to do that. You might need Apache and Nginx. Again, you can make them listen to different ports. But Ward, feel free to chime in. I don’t have a good answer beyond that. 

 

WARD: No, I don’t know how it differs from other situations. You spin up a different endpoint, you spin up another. Yeah. 

 

CHUCK: Yeah, it’s not that different. I just didn’t know if Express or Node gave you that kind of an option where you could configure it and say, “I’m running two applications on the same VM,” or something like that. 

 

VALERI: I would imagine it is in some way possible, but I have never actually done it so I can’t actually say. 

 

CHUCK: Yeah, I think the common practice is yeah, to set up Nginx or something and then just tell it to proxy back to another port. And so, effectively, it’s just routing based on domain name. 

 

VALERI: And that all still brings me back to another interesting point about the MEAN stack and one of the paradigm shifts that I’ve seen in my coding in that particular realm, is with other web frameworks I’ve used, I’ve had often a tendency to basically things start spilling off into multiple processes pretty quickly. You start having to set up cron jobs. And god, I hate setting up cron jobs. They’re such a pain. 

 

CHUCK: [Laughs] 

 

VALERI: I have a different process doing Nginx. I have to worry about my memcached, all these other processes. And with the MEAN stack, I’ve seen that, “Oh I can basically, why would I use a cron job when I can schedule things internally in my server?” Just say, “Okay, this should run at 6pm.” That makes life an awful lot easier. A lot of these things start moving into the server, having to set up Apache or have an Apache instance running and having to set up things like modphp or modpy, all of those tools, so Apache doesn’t spawn up a new process for each and every single request. All of these different things just move into your one server, even memcached. Again, you don’t necessarily even have to use memcached with MongoDB because MongoDB is very, very good about using as much available memory as is humanly possible for [keeping your data] in memory. 

 

JAMISON: That is such a positive way to spin that. [Chuckles] 

 

CHUCK: What do you mean? 

 

JAMISON: Oh, I mean it uses all your memory, right? That could be a bad thing or good thing. 

 

CHUCK: [Laughs] 

 

VALERI: Well, if you have extra memory, then you’re not using all of your available memory. 

 

JAMISON: Sure. 

 

VALERI: But I think that’s part of the point of having memory in the first place, is you want to use it, in theory. And I guess, again that is something that people have criticized MongoDB for. They have their beef with that. It can use a lot of memory and if there is available memory and all of your data doesn’t fit into memory, it will still try to use all available memory. But that’s mostly because you want your data to be in memory because you don’t want to read from the hard drive pretty much ever, because hard drives are slow, especially if you have a web application. The hard drive often ends up being a bottleneck if you’re doing things right and still hitting the hard drive. So, [inaudible] if you want to make sure, just never read from the hard drive and the positive spin on MongoDB’s memory usage. 

 

JAMISON: So we’ve talked a lot about all the strengths of the stack. Are there any gotchas or pitfalls or things to watch out for? [Inaudible] MEAN stack? 

 

CHUCK: Or places that… 

 

VALERI: No. [Chuckles] 

 

WARD: One of the things that spook me is, and it’s absolutely fundamental to JavaScript, is lack of the developer control over memory management. You just have no idea where things stand and whether you’re running out, what to do. And that always scares me a little bit. Do you guys have a good strategy for that? 

 

JOE: Crickets. 

 

JAMISON: Restart your server periodically. [Laughter] 

 

WARD: Yeah, but you can’t say, “Hey I’d like to start a garbage collection right now please. This would be a good time for that.” You got no visibility. You can’t do anything there. And there’s no interest in the JavaScript world, the ECMAScript people as far as I know, to address that. And so I worry about this gradual accumulation of stuff. [Chuckles] And then suddenly, it just lights up one day and says it’s over. I guess we should all write our code such that it’s easy to just not worry about it and let it restart. But that bothers me. 

JAMISON: There is one incredible blog post about people debugging memory leaks in Node. And it’s intense. They’re all on the SmartOS and using DTrace and generating all these graphs and stuff. But they have really specialized tools and it can be painful. Yeah, so that is one issue. 

 

CHUCK: Is this a problem that frequently occurs? 

 

JAMISON: Not more than any other garbage collected language. But in every garbage collected language, you can have memory leaks. So it happens sometimes. 

 

CHUCK: Yeah. Well, in most garbage collected languages that I’ve seen, you can trigger your own GC. But yeah, if it’s a really frequent problem, then I can see people being concerned. But if it’s something that most people aren’t really going to run into, then I don’t know. 

 

JOE: And let’s be clear. Memory leaks were invented by non-garbage collected languages. It’s certainly not unique to garbage collected. [Chuckles] 

 

CHUCK: That’s true. 

 

JOE: So for the stack, it’s really not necessarily an issue because of the stack, right? Isn’t that mostly Node? MongoDB, does it have memory issues? When it comes to the browser, if you’re doing JavaScript in the browser, Angular is no more or no better or worse than anybody else at memory allocation, right? So it really comes down to just Node when it comes to just managing your memory? 

 

CHUCK: Well, the other thing is that if you create a memory problem on the browser, it’s those people that have the millions of records or whatever that you’re displaying, and there are ways to mitigate that. But on the server, if you crash the server that people are connecting to, you’re going to affect a bunch of people all at once. 

 

WARD: Right, which is why you’re looking at servers that are designed to fail. It’s a little bit like the argument against ESDs. They go down more than [rust] does, but the answer to that is just have a lot of them and design for failure. And I think that’s pretty much what people do on both ends. It’s just that it feels uncomfortable. Let’s be clear, it’s not an Angular problem. This is a JavaScript problem. This is a fundamental of JavaScript. And the way it impacts you isn’t just that you get an out of memory exception [chuckles]. A world of garbage collection requires you to have about twice as much free space as you’re actually using. And so as you begin to chew into it, the performance just suddenly starts dying and you don’t know why and you have no visibility in what’s going wrong. So this is one of the areas in which just programming in JavaScript is harder than programming in some of the other environments. And we should be honest about that. 

 

JAMISON: So, there is an option to expose the garbage collector in Node. I was just googling this because I thought I heard of it. I’m pretty sure this is mostly for testing though. I don’t think you want to do this in production. But we’re not talking about stuff that wouldn’t be picked up by the garbage collector anyway. We’re talking about leaks. So running the garbage collector wouldn’t find your leaks, so you’re still not going to get that memory back. 

 

JOE: Right. 

 

WARD: Yeah. Often it isn’t just about leaks. It may not necessarily be a leak. It’s maybe that you’ve accidentally accumulated too much stuff and you don’t know that you’ve got too much stuff unless you have some other metric on it. But you have no idea about which environment you’re in or how much memory you’ve got. So you don’t know how much you have to play with, if you want to make decisions about say flushing a cache or something like that. So it isn’t just about memory leaks. 

 

JOE: Yeah. And if we’re talking about weaknesses, I think there’s another potential weakness that’s also something that we mentioned as strength earlier on and that is if you’re dealing with just one language, what you might be looking for is developers that need to know JavaScript really well, which still even in this day and age can be hard to find. 

 

VALERI: A lot harder than people think it is. [Chuckles] 

 

CHUCK: Yeah, but at the same time, I’ve been a hiring manager and hired people that didn’t know the technology we were working in and they were smart enough and had enough experience and skill to pick it up. 

 

JOE: Do you think there’s potentially an issue with the market getting flooded with people doing client-side development that want to move to the server but just have no idea how to code on the server? 

 

CHUCK: Who knows? 

 

WARD: I don’t think they know how to code on the client. [Laughter] 

 

WARD: No, seriously. What you did as a frontend developer historically, you had very few JavaScript responsibilities. You had no need to think about your JavaScript lasting very long or worry about polluting the global space because you were just going to refresh anyway. Learning to program in this other way in which you’re going to have a client that lives for a long period of time, and that’s what Angular is useful for, right? We’re not talking about using it to get a few nice animation effects. We’re talking about building a client that lives, the session is there for a long time. And I don’t think there are a lot of frontend developers who have had experience building that kind of a client-side JavaScript app. 

 

JOE: Right. 

 

CHUCK: Yeah, I agree. 

 

JOE: So I want to ask a question. If you got people out there that are very interested in MEAN stack and want to learn it, where do you think is the best place for people like that to go? 

 

VALERI: Oh, the resources out there are still somewhat limited. I think that it’s slowly but surely improving. Right now, the things that come off the top of my head would be MEAN.io which is a wonderful MEAN stack skeleton and other tools maintained around the MEAN stack by some guys in Israel I think it is. There’s also my blog, shameless plug, TheCodeBarbarian.com. I have a few posts about the MEAN stack and why it’s useful, how you can get started, how you can build a very simple to-do list application with it, and a few simple use cases like building an online store where you want to change between viewing prices in different currencies. Those are the things that come to mind right now. I would love to hear some other people’s opinions. If you want to learn about AngularJS in particular, you can look it up on Google. Egghead.io also has some excellent tutorials that I’ve heard are truly wonderful. That’s pretty much all that I can think of off the top of my head right now. 

 

 

CHUCK: I still maintain that they should have registered MEAN.io in Ireland. [Chuckles] 

 

JOE: I like the MEAN.io. I just completed my course on MEAN development on Pluralsight. So I definitely want to recommend that one as well for learning MEAN. But when I was preparing for that, I went through and tried to find all the places where people were giving fundamentals of how to learn MEAN, just to get ideas for what other people were using to teach people MEAN. And other than MEAN.io, I really didn’t find much in the way. So definitely, here’s a shameless plug for my Pluralsight course on MEAN development and introduction to it. 

 

WARD: Well, if it’s as good as your other courses Joe, I’m looking forward to seeing it. Plug that. 

 

JOE: Hey thanks, Ward. Thank you. 

 

WARD: [Chuckles] But I do think that the A is where you go to spend most of the time anyway. And there’s lots of good stuff on being a good Angular developer. 

 

JOE: True. 

 

JAMISON: Yeah, the Mongo stuff, their docs are pretty good and they send out, you can subscribe to some newsletters and [inaudible]. 

 

VALERI: There’s also a MongoDB university, which is another thing that I forgot to mention. They have numerous courses including so-called M101JS, which is basically MongoDB with an emphasis on Node.js development with MongoDB, a roughly 40-hour video courses and nice little tests that will give you an exhaustive knowledge of the very fundamental stuff with MongoDB with a little focus on the side of how you interface with MongoDB using Node. 

 

JOE: And I think learning MongoDB, especially from scratch, is actually really straightforward. My one complaint is I wish it was just a little bit easier or less picky about where you configured your data to be. 

 

JAMISON: What do you mean? 

 

JOE: Well I wish it would make the smart choices if I hadn’t adequately pointed it at the right place for data to go, it would just say, “Alright, well I’m going to put your data here because you haven’t really told me.”

 

JAMISON: Oh, you forgot, when you have to create the directory for it to store the… 

 

VALERI: Yeah, if the directory doesn’t exist, it won’t [still] refuse to start up. 

 

JOE: Yeah. Yeah, it’d be nice if it did or warned you and gave you something really meaningful and a nice option, just start it up for you. But other than that, I think that Mongo is awesome to pick up and get started with just from scratch, absolutely. 

 

WARD: As long as we’re doing shameless plugs, we have a B.MEAN sample in our portfolio samples for Breeze, if you want to see how that can work. 

 

JOE: Yeah, I think that’d be interesting. I think we’ve talked about Breeze before, but Ward at least highlight what does B add to B.MEAN? 

 

WARD: Well, when Valeri was talking earlier about on a client all you do is make an AJAX call with $http and the world is your oyster. And the Breeze premise is that maybe there’s more involved if you have a rich object with capabilities that is on your client. Maybe there are some other concerns that you may want to deal with there, such as validation and caching and dealing with a self-assembling object graph. A common thing even with Mongo is you’ll pull down a document. But not everything you’ll need will be in that document, or should be in there. Eventually, you’re just going to have some kind of reference to something that’s sitting someplace else, otherwise the document gets ridiculously large. So, something like, say all the information you would want to know about a product in an order or a line item. So how do you connect those dots on the client side if you want to? If you’ve got a collection of product information or colors or statuses and stuff like that, Breeze can reassemble those so that you have the full object graph but your communications over the wire can be focused on just the parts of the document that you need. So there’s stuff like that and we have a query language you’re actually able to use on the client so that the client can customize what kinds of, the client developer can make decisions about what queries they want to make. And when those queries arrive, we translate those into Mongo queries for you. And from client-side, if you know LINQ, it looks LINQlike. 

 

JOE: So, I’ll agree with you here that Breeze has an awesome purpose. When we were doing some major work over at Domo and switching over to Angular, one of the things we wanted to figure out was how we were going to handle our models in the client-side, because we had some really rich models that we’d written in Backbone. And I spent a lot of time looking through all the options for modeling and everything else was extremely barebones. I went so far as to actually hook up Backbone’s backbone.model against Angular, which is really actually quite straightforward surprisingly and easy to use. It has a lot of benefits. But Breeze is the only thing that really gave you a rich model. And when we were doing something very serious, because we had a hundred thousand lines of JavaScript that we were going to be porting over to Angular, we knew that we needed something serious on the client-side for modeling. 

 

WARD: So, it’s all good. [Chuckles] 

 

JOE: Indeed. 

 

CHUCK: Alright. Well, we’ve already been talking for an hour and five. And we usually get to the picks about 20 minutes ago. Are there any other things that we need to talk about with MEAN stack to help people understand how best to use it or maybe when to consider other options? 

 

VALERI: Give me another three hours. 

 

CHUCK: [Laughs] Yeah, it seems like a terrific way to go. And so yeah, go check it out. But are there any gotchas that people run into or things that people find difficult or is it really just as easy as installing Node.js and MongoDB and then hooking things up with ExpressJS and Angular? 

 

VALERI: A lot of the ways or a lot of the difficulties come from the fact that one, I absolutely love JavaScript. I think it’s one of the best languages in existence. Maybe a controversial statement, but I think JavaScript is extremely elegant. But with great power comes great responsibility. JavaScript gives you a lot of flexibility and it gives you a lot of flexibility to shoot yourself in the foot and write code that’s going to be impossible to test, impossible to maintain. And a lot of the difficulty that I’ve seen, at least from consulting work comes from just people don’t quite have the understanding of how to write effective JavaScript. And number two, a lot of the other difficulties come from again as was mentioned, is that Angular is a complex library. Well, both a library and a framework. It’s pretty dogmatic about how you should write things correctly while also still giving you about three billion ways to doing the same thing. And a lot of the difficulty comes down to understanding how Angular should work and how it should be written. 

 

WARD: It would take too long to go into what I think is an important understanding of the difference between NoSQL and SQL databases and why they both have a reason for being and why they both have vulnerabilities. And Mongo doesn’t escape from the challenges that are faced by NoSQL databases. But it’s way. 

 

CHUCK: Shh, don’t tell Valeri. 

 

WARD: [Laughs] It’s way beyond the scope of this talk, of our discussion. So we could just leave it at that. But it almost sounds like when you do that, that it’s got to be an either/or. And I don’t mean to imply that or that one is bad, because you realize that one has flaws. I don’t think that’s what I’m saying. Not at all. Otherwise, I wouldn’t be here talking about MEAN and talking enthusiastically about it. But I do think that you really have to be aware of what choices you’re making and what consequences you’re making when you go that route. 

 

CHUCK: Yeah, I just want to pile on that a little bit. I’m pretty well convinced that most languages, as well as most frameworks, are set up to handle about 80% of the cases that would come their way. They can handle it really without too much trouble. But there’s that other 20% and sometimes there’s a better way. But give it a shot and see where it shines and see where it doesn’t. Alright. Well, let’s go ahead and wrap up the call, and by wrap up I guess get into the picks. Jamison, do you want to start us off with the picks? 

 

JAMISON: Sure. I just have two. One is, I think by the time this goes out, the call for papers might be closed. But if not, you should submit a talk to speak at MountainWest JS. It’s a JavaScript conference here in Utah that’s coming up in March. It’s going to be great. 

 

VALERI: Did you MountainWest JS? 

 

CHUCK: Yes. 

 

JAMISON: Yes. I will post a link. 

 

VALERI: Cool, because I will definitely do a CFP for that. 

 

JAMISON: Yeah, that’d be awesome. 

 

CHUCK: Yay, payoff. It will be closed by the time this goes out. 

 

JAMISON: Well, if it’s not, submit. If it is closed, then come. It’s going to be great fun. The next pick is just a soundtrack and a video game. I played this game called Risk of Rain. It’s an action rogue-like, if that means anything to you. It’s super fun. It’s really polished, really well-done. And the soundtrack is amazing. So I’m going to post a link to the soundtrack because it’s been my programming soundtrack for a couple of days now. That’s it. 

 

CHUCK: Cool. Joe, what are your picks? 

 

JOE: Alright, so I think it’s fairly obvious that I’m going to mention my course. Right about the time that this episode comes out, my course on MEAN development should be released. I think it’s called Developing Applications with Angular in the MEAN Stack. And so it’s a great place. It’s a very introductory level course. It’s all about putting the four pieces together. It’s not an advanced course by any means. So if you are looking for a place to learn MEAN, that’s definitely a great place to go, over on Pluralsight.com. My second pick, my last pick, is going to be the new Zelda game on the 3DS. I picked up a 2DS because it was a little bit cheaper than a 3DS. And if my kids got a hold of it, they wouldn’t break the hinges. And got the Zelda game, the A Link Between Worlds. It’s won Game of the Year awards. It’s just been really fun. But it is incredibly hard. It reminds me a ton of the original Zelda game. But I’m constantly getting lost and going online to find out what I’m supposed to do next. [Chuckles] But I really enjoyed it. 

 

CHUCK: Awesome. Alright, I’m going to pick a couple of things. If you’ve listened to the other shows that I do from this week, I’m picking the same thing on all of them because I just got back and I haven’t really had a chance to think of anything. So the first pick, my family went to Disneyland and we had a terrific time. We actually got a house that was a couple of blocks from Disneyland so we just walked to the park every day and then we’d walk back when we needed a nap and it was terrific. So a lot of fun. And I highly recommend, if you’re looking for a terrific way to spend a few days, then go to Disneyland. The other pick I have, halfway back, well not quite halfway back, from Disneyland to here is Las Vegas and I was there for New Media Expo. And New Media Expo is the big podcasting, blogging, web TV, YouTube kind of crowd. And it was a ton of fun. And I met a lot of cool people, met a bunch of podcasters that I really admire. So if you’re interested in learning how to blog or podcast or if you have any of those and you’re looking to take it up a notch, then by all means go to New Media Expo next year. I don’t know yet when it’s going to be, but the last two years it’s been in January in Las Vegas. And the other nice thing about that is that they’ve set it up so that it ends when CES starts. And so I was able to go to some CES press events while I was down there for New Media Expo as well. And so that was a lot of fun. So yeah, those are my picks. Valeri, what are your picks? 

 

VALERI: Sure. Well first of all, I would love to, while we’re on the subject of shameless plugs, I’d like to link to my blog once again, TheCodeBarbarian.com. I’m going to make it a New Year’s resolution to write more often. However, I have maybe about 10 or 12 blog posts right now on various topics ranging from the MEAN stack to nutrition and general rules for how to be a better developer. Also, I’d like to pick out one of my favorite books. It’s the Book of Five Rings by Miyamoto Musashi. It’s actually a 17th century book on Japanese swordsmanship. But I find it to be a very interesting guide on how to be proficient at pretty much anything. And especially relevant to JavaScript is Musashi’s no-nonsense guide or no-nonsense mentality of basically mind, body and spirit aligned toward one purpose. Stick to your principles and get it done. So I think it’s something that would be an interesting light read for aspiring JavaScript devs. 

 

CHUCK: Awesome. Ward, what are your picks? 

 

WARD: Alright, I’ll blast through them quickly. First of all, everybody should go to BreezeJS.com [chuckles] which is our open source product that we talked about earlier. The link is there. It’s too late for you all to go to ng-conf, the very first one. And Joe is one of the founders of that conference that’s going to be next week. I’m looking forward to that. Maybe there’ll be some video. The Angle Brackets, they have intersections in the spring in Orlando, is a great conference. It’s fascinating to see how single-page apps, Angular, and I suspect we’ll be seeing a lot more Node and Mongo are showing up big time in the staid Microsoft .NET world and you can see it happening there. And then on the fun side, if you’ve ever wanted to fall in love with Siri and she sounded like Scarlett Johansson, you’d want to see the movie Her, which I think is a winner and a really poignant, surprising tale of the love between a man and his female computer voice. 

 

JOE: Nice. Hey Ward, now might be a good chance, since this episode should be released during day two of ng-conf, to mention that the conference sessions will actually be streamed live and put up on YouTube. So I don’t have links that I can give here in the show notes. But for those who are listening to this, it should be going on right as you listen to it if you got the episode as soon as it’s released. 

 

WARD: Wow, that’ll almost be like being there, except it won’t because being there is going to be a lot of fun. 

 

CHUCK: [Laughs] 

 

JOE: And definitely tastier food. 

 

VALERI: Y’all need to advertise that more. I actually did not run into ng-conf until December 20th of last year. So apparently, I haven’t been following the community enough. But either that or you all didn’t advertise well enough. So I’ll make sure to look out for it next year. 

 

WARD: Well you haven’t lived until you’ve seen Frosty and Geddes do their show on Angular tied into various electronic devices. It is funny. 

 

JOE: [Laughs] 

 

VALERI: Oh man, that sounds awesome. 

 

JOE: Yeah, it is. 

 

VALERI: I don’t have words to describe how awesome that sounds. 

 

CHUCK: Alright. Well, thanks for coming guys. It’s been a terrific conversation, a lot of things that we discussed. And hopefully, we’ll get some people to try out MEAN and see what it’s all about. See how it can help them out. And I guess we’ll wrap up the show. We’ll catch you all next week.