The Changelog: Software Development, Open Source - MEAN.js & Full-Stack JavaScript (Interview)

Episode Date: April 25, 2014

Andrew talks with the fellas behind MEAN.js, Amos Haviv and Roie Cohen. MEAN.js is a full-stack JavaScript solution using MongoDB, Express, AngularJS, and Node.

Welcome back everyone. This is the change log where members support a blog podcast and weekly email covering what's fresh and what's new in open source. Check out the blog at the change log.com. Our past shows at five by five dot TV slash change log. You're listening to episode 119, Andrew Todd to the fellows behind Mean.js, Amos Aviv and Rowie Cohen. Mean.js

is a full stack JavaScript solution using MongoDB, Express, AngularJS, and Node. Great show today. It's sponsored by Codeship, Rackspace, and Harry's. We'll tell you a bithip, Rackspace, and Harry's. We'll tell you a bit more about Rackspace and Harry's later on the show,

but our good friends over at CodeShip, also a partner of the ChangeLog, they're a hosted continuous deployment service that just works, easily set up continuous integration for your application today in just a few steps and automatically deploy when all your tests pass. That's the way to do it. CodeShip has great support for lots of languages, test frameworks, as well as notification services. They easily integrate with GitHub, Bitbucket, and can deploy to cloud services like Heroku, AWS, Nojitsu, Google App Engine, or even your own servers.

Get started today with their free plan. Setup takes only three minutes. No excuses to have untested code in production. Head to CodeShip.io and also check out their blog, which I love, by the way. Blog.CodeShip.io. One more thing to mention for our members. You can save between $294 and $2,994 on your first year with CodeShip. So make sure you take advantage of that. Thechangelaw.com slash benefits. If you're not a

member, what are you waiting for? Membership is just 20 bucks a year and you support us to support open source. Once again, CodeShip.io. Sign up, three minutes, it's all it takes. Do it today. And now, on to the show. We're joined today by Amos Taviv and Roey Schwaber-Cohen talking about Mean.js. It's a product-oriented, full-stack JavaScript boilerplate. So why don't one of you guys give us a, well, first of all, why don't you guys introduce yourself? I guess, Amos, you can go first.

So my name is Amos Haviv, and I am a web developer for about 12 years now. I've been through the days of i5 and QuixMode through the birth of the new generation browsers, and finally to where we are today in this exciting new world of JavaScript in the server and stuff like that. I do a lot of side projects, I guess, because you have to do something for your soul.

And one of the latest side projects I had was MinIO, which evolved to be MinJS. Yeah, so there's a little bit of drama around that, which we'll kind of touch on a little bit later in the show. But we'll kind of avoid that as much as possible just to kind of shine a light on the good of Mean.js. So that's cool. So you've been around. You've been doing this for a while. Yeah. Rowy, why don't you?

So I've been a developer in Israel for the past nine years, I would say. Yeah, I come from more of a PHP background, but recently also found the Lighten node. Very interested in all of what this framework has to offer. And then Angular is, again, one of the newer tools that I've started using in the past maybe a year or two. And I'm currently working for a company called Leafly here in Seattle. Yeah, that's about it.

Awesome. So why don't you guys give us an introduction to what Mean.js is in its current form. Okay, so Mean.js is a full stack javascript boilerplate um it was born out of uh our attempt at um a better flow for this kind of stack so the term was coined um in the mongodb blog actually um and we basically found out that it was super efficient. Amos basically wrote the stack, I think it was six or seven months ago? No, no. Am I making a mistake?

Yeah, it's about a year ago. The blog post was written by a developer called Valery Karpov on the MongoDB blog. I used to do, I'm a freelance developer, so I'm involved in several projects, and I recognize a certain pattern in projects where developers use MongoDB as the database, Node as the web server, and AngularJS as the client web framework, and decided those projects could look better, be better organized if they put in some sort

of order. So I created a mean stack, which I used for about two months before we released it as an open source. I thought the name Min was cool, and when I looked it up, I found out several people are already using it, so I just released it as Min to address the namespace, I guess. It basically was constructed to offer MVC, whatever, structure to both the server side and the client side in a way that represents your entities properly. I think what I tried to do was help developers

coming from strict type languages with background in Java, ASP.NET, and stuff like that, step into the world of Node.js web applications and feel a little more comfortable. Right. So the point of Mean, just sorry to interrupt, the point of Mean, so it's opinionated, right? It's Mongo, Express, Angular, and Node.

And this is something that you guys basically noticed was like a really common trend for a Node stack, right? Which was this thing called Mean. What is it about Mean.js? Now, I've used all of these things, and all of them are relatively easy to get started with on their own. What is it about Mean.js that kind of makes it easier to get started with the whole stack

rather than trying to do each one individually? So I think the most important stuff we wanted to address, the most important issue we wanted to address was the interface between the different parts. You have your AngularJS application running and you want to communicate with your Node server. So your Node server should present some sort of REST API for AngularJS to use. And we wanted that interface point to be properly organized. So when you download the stack,

you get a folder structure and a couple of config files that help you configure the different parts of the application, like the connection point between Node and MongoDB, where we use the Mongoose module, or a user authentication layer, which uses the popular passport module. And we wanted to give this all out of the box to let developers just begin writing their code instead of, I don't know, trying to figure out how to build their project and just concentrate on building what they want instead of the infrastructure, which I used to see developers taking a lot of time dealing with the infrastructure and the proper way to connect those parts.

Right. I think we have a very important concept that we're trying to relay with Mean, which is first of all, we chose only if not like mostly if not only popular components. So we

intentionally chose to go with Mongo instead of Couch. We intentionally chose to go with Express instead of some other framework that does routing. We chose to reduce our Jade imprint eventually because all of these things were coming from the community. So we were trying to pick, again, components that are really popular from the one hand. And from the other, we really wanted to not abstract away the simplicity of all these frameworks. So we don't want to create some sort of like a layer that takes all this complexity away from you as a developer.

We wanted you to still be hands-on and really understand how the parts work, but that doesn't necessitate you learning each of the components and like really knowing how to integrate them properly. And we found that it was really easy to start creating vertical stacks, which means all the stacks in the server, all the parts of the server and the client for a given entity. It made that whole process a lot easier and a lot faster. Right. So this is different from, a lot of our listeners are lot faster right so this is different from a lot of our listeners are rubyists and this is different from rails and that rails is its own thing right it builds all

the layers into its own thing and this would be similar if you guys were to say build your own express that had its own templating and its own database and its own you know all that mean it takes the other tools so you still have complete control over the tools individually, and it allows you to, but it makes it easier to kind of connect it all together. Yeah, I think one of the more prominent patterns we saw with Mean is the amount of forks that were kind of unusual to see. Yeah, about 1,000 forks already. Yeah, so like, yeah, the total is about 1,000 forks,. Yeah, so the total is about 1,000 forks. And the reason for that is people like different flavors of Mean,

and they like different flavors of full-stack JavaScript, really. So if we look at this entire picture, we're of the mind that all of these flavors are totally valid, and we're not necessarily opinionated in a way that says, like, our flavor is better than any other flavor. It's just that we found these tools to be super popular and super helpful and powerful and we thought that they were our our best choice for the scenarios where we were at the time so i was um developing for a startup called go mango and i had to rewrite my website really quickly and it was sort of

built with a lot of fragmented pieces of jquery Angular and Node in the back and some PHP and some.NET. All of these systems were working together, but not very well. And my first experience with Mean.io was when I basically converted my website that was built before that. It took about eight months to build, and I converted it in about two weeks. So I feel, I really felt a very significant and real, um, uh, change in, in the speed, uh, of my development. And I think it really, it really has a lot to do with a, the fact that we're doing only JavaScript, um, and not like switching between languages, which is immensely helpful. And it's sort of easier to keep on thinking sort of the same way with thinking. And I specifically mean about thinking about

modularity and thinking about, you know, asynchronous workflow instead of a synchronous workflow. All of that together creates this effect of everything is so much easier and faster. Gotcha. So the idea that you're using using Mongo instead of Couch or React and Express instead of Happy or Getty or different things, that's your choice. But what happens when somebody forks this and it's Rean, right, with all the same stack except React instead of Mongo, and that one kind of takes off as the popular fork? That's a real problem that this open source project faces.

Right. And so what happens there? We're actually not... Yeah, we're not seeing it as a problem. We don't view it as a problem. Yeah, we're not seeing it as a problem. This is a great... Amos, you can go.

So we're not viewing it as a problem. We actually find this as a great opportunity. I personally hate religious technical discussions like the editor wars of the 80s. I find it extremely unproductive. I believe everyone should choose their tools. I'm really pro a variety of tools. So we faced this early on.

Roy actually helped one of our more passionate developers. Yeah, Martin Jennev, I want to call him out. He's like an awesome dude. Yeah, he's like an awesome dude who runs the 100% JS blog. And he wanted to make a Min fork using Ember. And Roy helped him doing so. And when we saw this coming, we and Roy started creating different forks of Min.

We created a Jane fork, which used a JagLinkDB as an obfuscation layer for different databases. I played with the idea of breaking the Angular part and letting users use the web frameworks they want, like Ember, Backbone, Ocal, whatever you like. And I helped the company implement their own web framework inside Min. So we find this, this is actually one of the things we find inspiring because we don't see Min as the goal. We see it as a starting point for something much bigger. JavaScript full stack is a vision not yet fulfilled.

Yeah, it's very new. Yeah, it's very new. We experienced firsthand the possibilities in this field. As Rory mentioned, the gain in performance developers get when they use a full stack JavaScript boilerplate is impressive and we want to push towards that location, we even

considering starting a project called JSFS, we'll talk about it sometime later, but JSFS will contain the different flavors of full stack JavaScript it's But JSFS will contain the different flavors of full-stack JavaScript. It's in the far future. I don't know how far, but...

It's still in its infancy, yeah. Yeah, but that's... We find this as an opportunity, not a problem. We would like to see developers implement their own flavor of whatever they like, stack, call it whatever they like. I think we're trying to also take the discussion about JavaScript

to a newer place which talks about not only the components that you use, but rather the patterns that we see emerging from these tools. So the full stack thing comes naturally because it's all JavaScript and all in one language. So it's much easier to describe it that way. But I sort of feel that with this framework in mind, we can start talking about more complex ideas and then start thinking about how are we

collaborating across this ecosystem? Because like one of the problems we were facing, and that's something that you start facing when you're doing full stack JavaScript is how do you do package management for the front end, for the back end? And these are like larger issues that are relevant to the entire sort of full stack JavaScript community, right? Or ecosystem, and not just the mean. We're going to pause the show real quick and give a shout out to our sponsors, Rackspace. They love open source. They dedicate themselves to supporting open source

and the developer community. And they're doing that with the changelog. They're supporting us. They can support open source because we support open source. And now you can make something awesome on them. They want you to come in and sign up for this and get money basically to use their services. It's pretty cool. So if you're a maker each and every day,

you're thinking of something new, amazing, awesome. And, and you, you want to put it out there. Rackspace would like to give you something special just to say, thank you. Sign up today for their developer discount and get 300 in free cloud services on your rack space cloud account this discount applies to new products like their performance cloud servers and cloud queues you're even eligible for early access that's right early access to new features and new products that they roll out. So go ahead and sign up for this today.

Make something awesome and get started today. Developer.rackspace.com slash devtrial. So just out of curiosity, Amos, as somebody who is around in the editor wars, which editor is the right one to use with Mean? Developers prefer different kinds of editors according to the way they use to program. I think when you maintain a large code base, you would prefer using an IDE or a tool that allows you to dig deeper and assist you with understanding the complexity of your code.

And when you write a lot of code like we do, I prefer my editors as lean as possible. I currently use Sublime. The guy writing Sublime is awesome. I'm addicted to multiple characters. So that was a joke question. You're not supposed to really have an answer for that. That's not fair.

No, no. You stepped into a field I'm talking so much about. We're both kind of like editor fanatics and we're like totally interested in any new editor that comes around because part of us does feel that there is some sort of a gap between what we need as developers

when we're trying to like maintain a full stack application. It's sort of getting difficult because you're juggling a lot of balls and it sort of feels like sometimes you're encumbered by your editor. And yeah, that's also another conversation we sort of feels like sometimes you're encumbered by your editor um and and yeah that's also another conversation we sort of want to have with people gotcha so actually uh to kind

of ask this question uh i think it was rowey did you say you came from like php land yeah mostly yeah so one of the things to get started i mean specifically in like node land and with you know full stack javascript is the ability to learn and the ability to learn like the new environment and all that. Um, what was it like for you and what, what, what does it, how does mean kind of help people when they're getting started in node land? So, so my experience was that, um, everything requires a lot of experimentation. Um, and well, once you get the gist of, uh, you know, how JavaScript works in its core, um, once you get the gist of how JavaScript works in its core once you start understanding

that not everything is synchronous everything sort of starts making more sense so I had a rough time starting out and I didn't have a whole lot of documentation on Node because I started playing with it when it was still not really around as a production framework at least.

And what we're trying to do, again, with Mean, is sort of start with frameworks that are already well-known, already have a community and some sort of good documentation with them. And we really tried with Mean.js to expand our own documentation and sort of make it easy for you as a developer to start fiddling with JavaScript. Because again, if you're a JavaScript developer, and even if you're not a JavaScript developer, it's not very complicated. Whatever is happening on the service side is really quite simple.

It's a model and some routes and the stuff that's going. And that's obviously like uh really simplifying the the picture but but in terms of what you need to uh know it's it's it's very very limited um and and and the whole and and the fact that we chose these popular stacks kind of uh created this this weird effect that like our community support is sort of built in and we don't really need to invest in uh supporting each of the components on its own but rather we can only um sort of interact with issues that are pertaining to the stack itself and the way you connect these parts

together so that sort of makes it easier to sort of document and and solve issues and so on so forth yeah unique part of your documentation with mean.js is, like, if you read through it, the first, you know, I don't know, 10 lines of the documentation are like, go read Mongo's documentation. Here's a manual to use. Go read Express's documentation. Here's a guide to use. Go look at AngularJS.

Here's a guide, da-da-da-da. And then, like, once you get past all that, it's really just like you can read the whole documentation in one sitting. And so you'll obviously want that, it's really just like you can read the whole documentation in one sitting. And so you'll obviously want to come back to it and reference things. But it's neat because you guys do benefit. This is an odd type of a project because as much as you are depending on other pieces of open source, you're also benefiting from the other pieces of open source. So one of the, so the upside is, you know, as that piece, as Mongo progresses, you guys progress with it,

as Express progresses, you guys, you know, progress with it. What happens when something ships to Mongo's, you know, like latest release and it, and it causes a conflict in your, in Mean.js, like how does this work? Actually, this just happened because Express is about to release their fourth version. You kind of need to stay alert to those changes. This is our mission. Our mission is to support the different changes in the different packages. We try to make those packages as lean as possible.

We try to use packages that are widely supported and not just like niche packages that might be deserted in a few months or so. So we have to keep up with those changes and offer an update to the stack itself. Updates are in general a huge issue when you offer a stack that is built from different components and you don't wrap it in a sealed module. So any update you do must be supported by the community.

And that's what we try to do with Min.js. We try to give it a more modular approach so we can update it without affecting or breaking your project. That's one of the biggest issues we have. I think we're not even trying to really solve these bigger issues. I think with projects like JSFS that may or may not happen, we might, again, create enough discussion about the issues that pertain to all of us. I mean, not just the mean stack, but the ream stack and the Jane stack and the amen stack or whatever stack it is.

We're all going to have a problem with maintaining our dependencies and maintaining our backwards compatibility when we ship things that are super dependent on other packages. And I don't think we're alone in this. And again again right now it's our mission to keep and keep maintaining a live very healthy stack um but we see that this issue is going to happen for everyone so we we sort of want to create a discussion about this as well so do you guys follow like beta or alpha releases of the other of the pieces of mean and and like integrate you know kind of proactively um yeah we try to to react to uh different changes when they do happen uh we try to predict what would happen to the

stack um when the the final uh release will be um but what we use is, luckily we have each dependency in the project is installed by using a package manager. The amazing NPM and Bower tools help us maintain the project solid while we test the different changes that come from the community. So before we release a new, before we upgrade the versions of our dependencies, we can test it without breaking the master branch of our project. Right. It is, though, very unique because people are not basically building very simple applications on this. And, like, the amount of complexity.

This is basically a web framework, really. And it's going to be hard to really predict 100% of, you know, breaking changes. But we are doing our best. Yeah, for sure. So you guys have a few other requirements which are not, like, specifically mean. You mentioned Bower. so you have npm well that's node basically bauer grunt a few other ones so these were the same kind of thing went into picking these over like grunt over um gulp there's another one that gulp yeah

just because they're like they're popular and they're they're well supported and and those is that nature like why you these? Yeah, basically. And I think that, again, someone might want to use Gulp, and that's super cool. And if that works for them, that's just another flavor of another full-stack JavaScript boilerplate, and I think it's super awesome. And it's just that we, again, just for those reasons alone,

which is maintain backwards compatibility and to not break with every new release, we're trying to pick the more supported and more well-founded packages. And we'll revisit this in a couple of, I don't know, weeks or so. Gulp is an amazing tool. The ecosystem is growing really fast. And when it comes a time to choose between those two,

I think we'll revisit this discussion again. So we need to, again, react to what the community, where the community is leaning to, toward. Gotcha. Gotcha. Yeah. Why don't you talk a little bit about JSFS? You mentioned it, and what is it,

and when can we, when will we start hearing about it? So JSFS is like a grander idea. Our dream. You can tell it. You can tell it this way. It's our dream. It is our dream. And it sort of like tries to talk about, again, larger problems and issues that you see when you're starting to deal with full stack JavaScript.

And some of those issues are like we talked about, you know, what flavor to choose for what scenario. And we sort of want to make it a level playing field and sort of give a face to all these flavors, but just like maybe make sure that the most prominent ones are shown to everybody. The ones that use the most popular components should be on top, we think. your file system and how you deal with deployment and how you deal with development cycles and how do you integrate a product lifeline to your JSFS sort of workflow. And we sort of want to address the larger issues that come with JSFS

and not necessarily focus on one stack or the other. And we hope to see something very soon. I don't think we have a set launch date for this yet. Yeah. Cool. So you mentioned that. I just wanted to make sure we hit on that a little bit. Going back to Mean, you have the concept of modules in Mean.

And I noticed the only module that you have is Mean SEO. Were modules an original part of Mean.js, or is that a relatively new addition? It's something we planned a few months back. We had a little struggle relaunching Mean as Mean.js, so we wanted to concentrate on writing proper documentation but it's one of our main goals to wrap Min with supplemental modules like the Min SEO module. It's not the only model we want to build, there are other models we plan on building in the next couple of weeks.

We're working on other tools, but modules are definitely one of the best ways to support a stack without breaking it, without making it vulnerable. Too heavy. So what constitutes like a module? What can we expect to see in modules for mean? So we're looking at anything that's, again, sort of like cross-stack and not necessarily for mean per se. So the mean SEO module

doesn't necessarily have to work on mean itself. It could work on other SPAs. This is a problem that, again, is very common to all JavaScript SPAs with crawlers, and that sort of solves it with Node in the back end. We're looking at ways to improve loading your scripts onto the page, compressing them, making sure that all that process is taken care of, again, behind the scenes.

And these are things that you don't necessarily have to care about if you just want to build a web application, but it would be better for you to have those things just to make sure your app is working properly. So we're looking into that. We're looking into some maybe, we're not even completely sure that we'll go into a more commercial sort of side of it

where we would try to maybe build a store or anything of that nature. But right now we're really focusing on features that would make your stack work properly. And if we could not necessarily build something that's super opinionated towards mean specifically, but rather solve a larger problem for full stack applications, that would be great.

Gotcha. So somebody could take, like, ideally, so mean SEO is an express middleware. So anyone using express for an SBA could essentially pull that in. Is that right? Exactly. We're going to pause the show real quick and give a shout-out to our sponsor, Harry's. This is a unique sponsor for the ChangeLog. We don't often get non-tech-related sponsors, but Harry's loves the ChangeLog.

Oddly enough, they love open source too, it's kind of neat that uh they wanted to sponsor the changelog but we welcome it it's it's it's different so uh here you go harry's was sparked by a personal experience of andy and andy is one of their co-founders and his experience that he had was is emblematic of the experience myself included but many of us guys have when we buy shaving supplies. This is Andy's story. Tell me if this somewhat resonates with your experience when you buy shaving supplies. And this is in his words, his first person. I went to the drugstore. I waited 10 minutes for someone to unlock the case where the razors were being held. And I bought a four pack of blades and of blades and I bought some shaving cream.

It wasn't the best purchase experience to say the least. And I walked out and looked into my bag and I had a receipt for over $25 worth of products and brands that really didn't speak to me as a customer. I just felt like there had to be a better way. And Harry's is focused on providing guys a great shaving experience for a fraction of the price of normal competitors. You know, I have to say myself, I've been using a Gillette Mach 3 for, I don't know, since I was 17, I guess. I mean, forever. And I'm using Harry's now. Harry's is awesome's a clean product design it looks phenomenal my wife uh would have bought it for me had she known about it prior to me

finding out about it but um it's great it's um it's high quality the blades are engineered in their own factory uh in in Germany for sharpness and strength. Blazer half the price of competitors like Gillette, my current and previous brand. I'm still kind of weaning off there, but I love my Harry's shaving kit. It's awesome. And it's shipped right to your door. The look and feel of the product is something you would be happy with. The quality of the shave, the price, go to harrys.com and use the promo code CHANGELOG to save $5 on your first purchase.

harrys.com, H-A-R-R-Y-S.com. So looking through your changelog, I think the biggest, again, not to hammer on the same point but like uh switching things out in an application like this is interesting to me i think the biggest change i see was when you you replaced jade with swig and um uh you you kind of hit on that a little bit why why did you do that and like what kind of conversations did you all have to have to like decide to pull the trigger on that? FELIPE HOFFA- OK, so templating engine is a really nice discussion we had with the community. The community of Min does have different preferences

for different. They do prefer a certain template engine. We started with J because it was the most popular template engine. We moved to Swig because it is faster and uses HTML syntax. Again, to help developers lower their learning curve of getting into Min. We're actually working on a generator, which is one of the most revisited issue requests. People are asking for a proper generator,

and that generator will support different render engines, especially when you consider that most of the views you use in a main application are basically Angular views and not backend views which uses template engines like Jade, Error, Hogan, or any other template engine. But we get a lot of opinions about it. We discuss about it a lot. We moved to Swig again because it is faster,

but we plan to support different Vue engines. It's kind of interesting that you mention it because that was one of the reasons we were talking about JSFS to begin with is because we saw that people were like feverishly just changing the, the, the template and it was like really a sore, a sore subject.

And people were like really up in arms about it. And we sort of figured that like maybe a better way to go about it would be to not necessarily decide, but rather supply a generator that could just open a new stack with whatever template engine you want because anyway, in Mean, we really don't use a lot of server-side templating, like Amos said. So we weren't really very, very opinionated, but we did have our opinion.

And again, the generator should maybe help with that sort of tension. Gotcha. So you talk about the generator. One of the questions, how does somebody get started with Mean? What would you recommend? Somebody comes up to you and says, I'm interested in building an SPA.

How do I get started with Mean? I think the first thing would be to look at the website. Go to the website. Start reading the documentation. It would be really easy to just download it, npm install, which would install all of your dependencies, and you can run the server and sort of look around the code. And I think for me personally, I really learned well by example.

We included a full stack example of an article. So you can see all sorts of things that you could do from like the point where you define your model through the routes and then the Angular service and the views, et cetera. And you can just like follow through the stack and sort of look at how it's implemented and then just play around with it and maybe implement your own stack. It would be really easy to do when we have the generator out, because all you would have to really do is pick a name and then set the structure, and then it would basically be reflected to you from the server in your Angular side with a service very, very easily. So if you do have, I think to start using Mean, you do need some sort of a background a bit in Node, like a very basic understanding of what it is

and how NPM works maybe and you do need some sort of knowledge and maybe even experience with Angular I wouldn't necessarily recommend this to someone who doesn't know any of these at this point but if you do have that kind of knowledge

then for sure I think if you just download it and walk through the stack and all of its parts, it's pretty self-explanatory. And if that's not enough, then Anos has really worked really hard on the documentation on the website. And lastly, and maybe most importantly, we are here to answer anyone's questions and we will do our best to really reply to issues. And we really encourage everyone to ask and talk to us because we just love it.

And I think one of the best things that happened to on a personal level to me, and I think to almost as well as seeing the amazing reaction from the community. And that's something that this is my first open source project that I'm really committed to. And I feel that the community support and engagement has really made a difference and really made it worth my while to actually do it. And it's super fun and people are awesome, really.

Best part of my day is discussing with developers what they build, well, about the projects they do. It's like answering those emails. It's like, so it makes you feel like what you do matters. You see people creating their dream project and they ask you for such simple questions and you can really help them get through. Right.

So we are pretty communicative about supporting the community and we'll make the documentation better. pretty communicative about supporting the community. And we'll make the documentation better. I promise you that. Accepting forks. Yeah, accepting forks. We're totally accepting forks. And if you want to talk to us about your own JavaScript full stack flavor, we totally encourage you to do that.

And we are totally non-denominational. So whatever kind of flavor you want to bring on to the table, I think we are going to limit the scope to just JavaScript and not other languages at this point, because otherwise it'll just be a big mess. But yeah, if you do have a stack,

we would love to hear from you. So one of the things, Amos, that you mentioned was, you know, it's like your favorite part of the day is answering emails about what people are building. Anything that we know of, like, that you could tell me that people are using Mean.js in production to get started with? I don't know if I can disclose this information because, no, they trust me. They show me their projects. They show me their, their code. I don't know if they, if I would like to disclose their projects. I've seen people create simple applications

and an hackathon application or something like that. And I, I've seen people restructure their company's 20 years old stack in MIN. I'm actually helping a couple of companies doing so. But we are about to open a built with section in our site and we'll invite people to share what they're doing. Gotcha. But I've seen... So we'll look out for that.

Yeah, look out for that. I don't want to get you in any trouble here. Yeah, better not. Awesome. So for our guests that are just listening, or for new listeners to the show, we ask our guests the same questions at the end of every show. So I'll go ahead and ask you them now. The first one I'll ask you, Rowie, first is for a call to action for the community. A call to arms would maybe be just build your stacks and just be involved in the discussion, really.

Let your voice be heard. We really want to hear from you. We really want to hear what you think about our stack. And if you have different ideas about how it should work or a different stack, we'd totally love to hear about it. What about you, Amos? Let us know what we're doing wrong, I guess. And how would somebody do that? Through GitHub issues or just flame wars on Twitter?

We have a community section in our website. You can use Twitter, Facebook. You can personally drop me an email or something like that. You can use the Google group. We're making ourselves available in an IRC channel. But I think the best way to do it is to just open an issue in the GitHub repository, asking us to change something or something like that. Okay.

Cool. Yeah. Amos, if you weren't doing this, what would you be doing instead? Oh, I would surf the amazing beaches of Sri Lanka. Every day. Awesome. For like 12 hours. We've actually had a few people say surfing.

So yeah, that seems to be a common trend amongst developers. What about you, Rowy? I'd probably be a musician, I think. Okay. What do you play? I play flute and piano. to roe soundcloud play listen to what no no no not yet i've been experimenting with like no no encouraging encouraging me he's making really nice music um that's roe schwaber cohen on soundcloud

yeah i just thought of you sorry Sorry, man. That's fine. That's awesome. Yeah, sorry. Your music career begins now. Amos, you might need to be looking for a replacement for Mean.js, so... Nothing's going to break this relationship. Don't worry. We've been through a lot.

Amos, programmer hero. Oh, that's a tough one. That's an easy one for me. Douglas Crockford, for sure. Yeah? The good parts. The good parts, yeah, for sure. He's the guy who made JavaScript all make sense to me,

and I have watched all of his lectures on YouTube, read all of his books. He's just an awesome dude. Yeah, for sure. Any for you, Amos? And Amos, you could even say your parents. We've had that before. Yeah?

Oh, that's... I think Dennis Ritchie, which wasn't really appreciated at this time. He died the same day, the same week Steve Jobs died. He invented the C language and contributed to the Unix. It was really cool. I like those ad guys. In the duo of Woz and Steve Jobs, I'm certainly the Woz kind of guy. That's good, yeah. They need support too, that's good.

Yeah. Yeah, totally. guys yeah that's good yeah they need support too that's good yeah yeah totally they do cool stuff awesome they do cool stuff they they just do it because they like to do it not any other yeah yeah yeah i mean you when you kind of start reading into a lot of that history you see that it's it's generally the people with more moxie that become famous and not necessarily i mean not not to take anything away from steve jobs yeah of course i'm old but um that you know he has some moxie and that's kind of what what propels him to like superstardom status versus you know the uh the wazes of the world and was he so nice

yeah yeah it's a nice guy it's a really nice guy oh awesome yeah well i wanted to say thanks so much for joining us on the show again it was Amos Aviv and Roey Schwaber Cohen talking about Mean.js which sounds like it's just getting started but it's got some tremendous movement behind it and I'm excited to kind of see where it goes

you mentioned this before but what is the Twitter for Mean.js that people can follow? it's meanjs.org the website is meanjs.org Twitter for Mean.js that people can follow? It's meanjs.org. The website is meanjs.org. We're Mean.js on Facebook and GitHub.

We hope Twitter would give us the Mean.js name because it's abandoned for some reason. But for now, it's Mean.js.org. Awesome. Yeah. Well, we'll be back next week with another show. Sorry that we have been absent a little bit I've been starting a new

a new job and so it's been kind of hectic so for our listeners we will be back next week and we'll be weekly from here on out so until next week let's say goodbye goodbye thank you guys thanks a lot, guys.