The panelists talk about the famo.us framework with Steve Newcomb.

Special Guest: Steve Newcomb.

 

  He’s Chuck Norris. He can require self in JavaScript if he wants.

  Hey everybody and welcome to episode 128 of the JavaScript Jabber Show. This week on our panel, we have Jamison Dance.

  Hello friends.

  Dave Smith.

  Greetings.

  AJ O’Neal.

  Yo, yo, yo, coming at you live from San Mateo, California.

  I’m Charles Max Wood from DevChat.TV. And this week we have a special guest, and that is Steve Newcomb.

  Hey, everybody. How’s it going?

  Do you want to introduce yourself really quickly?

  Sure. My name is Steve Newcomb. I’m the founder of Famo.us, Co-founded it with my best friend, Mark Lu. And it’s a JavaScript framework that enables you to build desktop websites, mobile websites, and mobile apps. 

  Alright. So, why don’t you tell us about this famo.us?

  [Chuckles] Well, the beginnings of Famo.us were, we were actually trying to build another app in regular HTML5. We actually had been funded to build, back in three, three and a half years ago, four years ago, a Pentris killer that was highly graphical. It was going to be built all across all devices, mobile devices, phones, tablets, desktop computers. And we had chosen HTML5 because if you remember back in 2010, 2011 era it had all these great promises with it. And what happened was we got deep into the project and realized that there were some pretty deep and inherent root flaws with the browser itself that were going to take years to fix before HTML5 was ready to really take on native performance and native-feeling animations. 

And we were sitting there with, I think we had spent maybe a quarter of our money, and that’s when we realized it wasn’t going to work. And I’m more of a platform guy in the first place and so was Mark. And we actually started just digging down into the browser and saying, “Maybe we could figure out what these root things are and take them out of the compiled code environment and put them into the JavaScript world where we liked it. And so, we asked our investors. We’re like, “Can we just go,” and we proposed to build a 3D layout engine that replaces the one in the browser and build a 3D physics engine that replaces CSS3 transitions in the browser. 

And the very first time we did a little test project, we were about 14 times faster than Chrome and three times faster than Safari on our first shot. And our investors said, “Let’s go for it.” We kept on going to all of our JavaScript meetup that we liked going to. And those were all of our friends. And everybody there was just dying with HTML5. We saw Facebook pulling out, Twitter, LinkedIn pulling out. And we’re like, “You know, this is closer to our hearts anyway. Let’s just fix this for all of our friends.” That’s kind of how Famo.us began.

  So, you dropped some numbers there: 14 times faster, three times faster. What do you mean by faster?

  Yeah.

  It’s still rendering in a browser. So, you’re saying rendering in the browser is faster than rendering in the browser.

  Yeah, that’s a good question.

  [Laughs] Good point.

  Right. So, we were calculating, so when you create matrices and multiply matrices and arrive at a composite matrix that then the GPU takes, that bits of matrix calculations is a CPU-bound activity.

What we had deciphered was that basically browsers were meant to layout and render text documents with the links. And the methods that the browser uses internally were highly optimized to do just that. And it does that very, very well. But when you ask it to render something like an app or a game, it’s a bit of the wrong tool for the job. And it starts stacking up and having problems in volatility right away. 

So, what we did is we built our own layout engine in JavaScript to manage the types of environments that we want it to generate more wisely. And so, we were measuring the CPU-bound matrix calculation differential between us and what’s in the browser. And that’s what that 14 times comes from.

  It sounds in some ways like a similar philosophy to something that React talks about, which is the browser does some things well but some things very poorly, and we’ll take the things they do poorly and do them better ourselves. So, React has the virtual DOM.

  Yup.

  Because the regular DOM is terrible. So, I still don’t understand what the underlying abstraction of Famo.us is. You mentioned matrix transforms. So, is it all, is it canvas? Does it still come down to HTML? Is it like SVG or what?

  Right, yeah. So, we have the notion that we create the scene and manage it in JavaScript in memory and then we could have it post to DOM or canvas or SVG or WebGL. And in that manner, we could simply use the right tool for the right job. So, we use DOM for content, for text, titles and things like that. And we like to use WebGL for high-end graphics and high-end fidelity types of things, shaders, lighting, things like that. And we wanted to have one render that could render to all of these things. And that was the initial abstraction. Does that make sense?

  It kind of does. So, there’s an abstractive rendering layer that’s all handled in JavaScript. 

  Yeah, we manage our own render tree in Famo.us.

  Okay. Cool.

  And so, there are a lot of similarities between us and React. In fact, we’re doing an integration project with React right now, with Pete Hunt. And we finish each other’s sentences quite often. 

  [Chuckles]

  We think a lot, very similarly on a lot of different issues.

  Tell me your thoughts on Dijkstra, then. [Chuckles] Pete and Dijkstra’s like…

  Yeah.

  Yeah, they’re big fans.

  Yeah.

  That’s funny. Cool.

  One thing that I think would be interesting to give some context on, we talked to Max about the Ionic framework a week or so ago. Can you compare the two frameworks and give us an idea of what’s different or why you might want to choose one over the other?

  I think Ionic is really inspiring from the standpoint of they do a great job of integrating with Angular. And they do a great job of making things easy, easy to prototype, easy to get up and running. And we’re actually, we take a lot of influence from their work there. And I think that’s super impressive work that they’ve done. What happens though is that any framework that relies on the browser to do the layout and to do animations eventually runs into performance volatility and performance bottlenecks. So, I’ve taken a lot of the Ionic templates that I love then you put them on Android and you immediately see that Android’s browser has problems. And it’s not Ionic’s fault. It’s the browser’s fault. 

And so, what we wanted to do would be to take those bits of the browsers that are broken and then make that available to the JavaScript framework so that they can use a proper animation engine that uses 3D physics and a proper layout engine that manages the scene more wisely. I could actually see a scenario under which the Famo.us engine could power Ionic’s templates. I think that would be a spectacular match. In fact, there are several other frameworks that we’re working with where we are becoming the engine to the templates or widgets or the IDEs that they’re building on top of that. 

So, a lot of people see us, Ionic and Famo.us as maybe competitors. But I see all frameworks that rely on the browser for animation and rendering could be benefitted by simply just using the free and open source platform of Famo.us to do the same thing.

  So, one of the things that I think is really cool about Famo.us is that you have once again, similar to React, introduced this abstraction layer between the developer and the DOM. Could you explain a little bit about how for a typical HTML app, how your rendering to the DOM is different than what a developer might expect. For example, when I was reading through your documentation, it became obvious that I don’t think you’re using divs and elements in a typical way that I would use them as a web developer. You’re doing some very novel things. Could you describe that?

  Sure. What we took inspiration from when we created the way that we render is we took inspiration from gaming engines. So, think how you render a console game, a AAA game. And in that notion, we simply had some basic foundational cornerstones that we wanted to stay true. And that is use the right tool for the right job. Don’t get tied down into something that forces you to use the wrong tool for the job. 

And so, we abstracted ourselves from DOM itself. And we actually see the Famo.us render tree as like the governing parent of everything. And what that means is that there’s a difference to a jQuery developer or a Bootstrap developer in that they’re traditionally familiar with appending JavaScript to DOM elements. And we don’t use that technique. That technique actually ties you to DOM in a way that we think that prevents you to growth. 

And so, the way we do it is anything that’s whizzing around on the screen or moving around on the screen, we actually create what’s called a container surface. And that is a div element. It’s just div class=”famous-container”. And that’s the surface that we could control in our render tree. And then the elements that are children of that can be regular old DOM. So, if you want to do regular CSS styling, regular HTML styling and layout, or rather just layout, as a child of that div, then you’re welcome to do it. So, forms, buttons, things like that, can all be children of a surface. And yes, it does take a little bit getting used to. 

And it’s one of those things that when you realize the power inherent in Famo.us and how deep Famo.us goes, that’s when you start seeing the benefits of it. And there is a pretty good learning curve with Famo.us right now. And that’s the biggest thing we’re actually currently working on, is making Famo.us easier to use.

  So, related to the learning curve, I wanted to say your docs are pretty amazing, the tutorials and the guided walkthroughs. Fantastic. 

  Oh, thanks. We graded ourselves a D on those. [Laughs]

  [Laughs]

  We thought they were terrible. We’re actually redoing them all right now.

  Well, they’re great. 

  Yeah.

  Oh.

  So, they can only get better.

  The Famo.us University is actually really cool too, with all of the interactive stuff.

  I guess I was talking about the University, not the docs.

  Oh that, yeah. Yeah that is, so I’m not a traditionally-trained engineer. I’ve had the opportunity to work on some pretty exciting projects in my life, but I don’t have an engineering degree. I learned by right click, view source, and then just learn on my own. I’m also a pretty severe introvert and I like being by myself. And classrooms full of engineers are actually quite intimidating to me. And I really, really think it’s super important to be able to provide people an anonymous way of going and learning anything they want to learn. 

So, I asked my board when we raised all the money, can I contribute an insane amount of that towards creating a free university that teaches Famo.us? And now, we have approval to teach just straight up JavaScript, HTML, and CSS as well. So, a huge part of that 25 million we raised is dedicated towards education. And that’s, just me personally, that’s just super important for me. And Famo.us University is going to do some awesome ways of teaching people in the future.

  Well, if you’ll pardon the pun, I think you are pulling it off famously.

  Ha-ha, thanks. [Chuckles]

  So, we’re talking about the DOM. But you also said that you don’t render in the same way that Ionic or a traditional web application would. And I’m still not clear on exactly what your rendering process is then.

  Wow. So, this can be hard to do without visuals or without coding. So, we render out tree in JavaScript.

  Okay.

  And using JavaScript. And then at the end, what we are able to do is then produce the flattest DOM possible if we’re rendering to DOM, because it’s very important to have flat DOM and to manage that DOM wisely or you’ll get, the worst case is reflow. But you can get a host of other things that cause frame rate volatility. 

So, Mark and I back in the early days created this app called [Mathan] that we hand-rolled the DOM to be the most optimal DOM possible. And we realized that anytime we wanted to append DOM, change anything, modify the scene in any way, we had to hand-roll it all over again just to optimize it so I could hit 60 frames per second. And the way to think of a frame is that we’re managing a scene wisely so that when we produce the DOM at the end, it’s producing the most optimum DOM structure possible for performance reasons. And that’s too hard for a human to be doing by hand. And we have a machine managing that instead. Is that good? It’s really tough to just describe what [inaudible].

  Yeah, it’s very good.

  Yeah. I think it paints a clearer picture of what’s exactly going on.

  The other big component is animation. We looked at the simple animation curves found in CSS. And you just can’t ever get it to feel correct and really native and really natural unless you have a physics engine. And we looked at Unreal 4 Engine. We looked at Unity 3D. We looked at native iOS. They all have physics engines. And we began saying, “Why can’t we build a physics engine in JavaScript and then integrate that deeply into our layout engine?” And so, that’s the other little bit of magic bits, is we can get, basically if you have a physics engine that’s what enables you to get native-feeling animations rather than something that you touch it and you’re like, “Eh, I can tell that’s HTML5.” Have you guys every experienced that? You touch a mobile app and you’re like, you know it’s HTML5. 

  Oh, yeah.

  It’s not native.

  Yeah, [inaudible].

  In Famo.us, it’s indistinguishable. We’ve replicated Twitter, Facebook, Yahoo Weather, some pretty complex stuff. And we literally put them in front of people as the test and say, “Can you tell which one’s which?” and they just can’t. And that should be the bar of when HTML5 has made it or not.

  So, is it fair to say that when you build up your render tree in JavaScript and then Famo.us converts that into DOM, is it doing so by absolutely positioning all of the elements?

  Yes. Well, we use matrix3d to position everything, yes. All of the surface elements. The child elements that are children of the surface could be, you can use regular CSS positioning to lay that out. Does that make sense?

  Yeah.

  So, the physics engine makes it feel more natural. How is that integrated into the web view and the JavaScript? So, you render to the DOM and then you have these animations that occur that have the physics engine. Does it just juice up the CSS animations or do you have your own animations somehow?

  Ah yeah. We don’t use CSS3 transitions at all. So, we calculate the full animation ourselves and then that is applies to the CSS3 matrix3d transform at the end. So, we don’t let the browser calc any of that. We literally put the resulting matrix3d transform as the result of the answer. A really cool thing to see all of this happening, if you go to the periodic table, the very first demo that we ever built that started this whole thing which is at periodic.famo.us and right click view source and then twiddle down the DOM elements until you actually see the DOM elements that are flying around, you can actually see our engine updating the matrix3d transform live. And that’s one of the coolest demos that you can do to see how our magic works.

  It’s full of stars.

  [Chuckles] It’s a really old demo, but I still love showing it.

  One of the themes I think from hearing you talk is that you don’t trust the browser. Do you worry that you’re betting against future improvements in the browser?

  No. In fact, we work with all the browser companies. So, what the idea was and what we say when we talked to the browser companies is that JavaScript for certain mathematical calculations now is nearly as performant as compiled C. And what that means is that things that were traditionally done in compiled C can now be opened up to the JavaScript community, which means we can move much faster and try new things out and learn and do faster. And then what we do when we actually meet with the browser companies is we give them our source code. And we’re like, “Please, please steal all of this and put this in compiled C,” because it will only be faster if it’s in compiled C. 

So, our hopes is that things like the Famo.us layout engine and the techniques that we use actually get and influence the browser companies to start making changes based on the fact that we can just simply move a little bit faster and try new things out in JavaScript. And we are already seeing and we’re about to hear, I can’t say what the announcements are, but a few of the browser companies are going to be announcing that they’ve made modifications based on being influenced by Famo.us. And that’s success for me, because then imagine two, three years from now a framework like Ionic that has a belief to rely on the browser only gets improvements down the line as a result of Famo.us’s leading work. Does that make sense?

  It does, yeah.

  I’d be happy if the browsers just completely stole everything we did because it just makes everything and everybody better.

  So, here’s a question I have. It seems that browsers generally introduce new bits of JavaScript as native code. But time and time again what I hear is that people who write this stuff in JavaScript rather than using the native browser components are actually faster. So, why don’t the browser vendors just include these libraries as part of the browser distribution instead of writing it native and getting it slower?

  Well, have you ever printed out the source code from any one of the browsers? It’s large. I have, since we’ve started Famo.us and I’ve started talking to all the browser companies and I have a lot more insight than I used to, I have a deep appreciation for how hard it is for them to do their job in the browsers. And the only way I could answer your question is wow is it complex. And I really feel for those guys. 

And all I can do is say I think that as a JavaScript community what we can do is just try to help shed light on as many areas as possible. And then they know a lot more than we do about the complexities of that browser and what will work and what won’t work. There are a lot of things that you think and a lot of things that we’ve done that we’re like, “Hey, just do this. It’s simple.” And then they try to implement and it breaks 29 other things that we didn't think of. And that’s why it’s so hard and so slower to get these advancements put into the browser itself.

  So, one thing I’m seeing on the demos is that they, or the wrapping stuff, they layout, whatever’s wrapping the app, it looks like an iPhone. Is this cross-browser or cross-platform? Does it go to Android as well?

  Yeah, so we support Safari, Android, Kindle’s version of Chrome, Firefox, and we are about to announce support for even Microsoft.

  Even Microsoft, poor Microsoft.

  Yeah, that’s actually…

  Do they have a mobile device? I didn’t know.

  [Laughs]

  Well, uh…

  Just kidding, just kidding.

  Well, we think about Mic-

  They have one. Is anyone using it? I’m just kidding.

  Yeah, well we think about IE on Desktop as well. And we do everything in matrix3d and Microsoft has some challenges with matrix3d. But we’ve made a lot of progress in that area. So yeah, we choose iPhones but we work on them all. 

  Is it okay if we talk about the mysterious future for just a minute?

  Sure.

  It seems like what’s happening in the web development framework world is that developers are getting farther and farther from the underlying browser technologies, at least in some cases. React and Famo.us are two really strong examples of that. 

For a long time, I think we’ve been predicting the end of JavaScript as a language that we write and that it’ll become a language that we target, our tools target for us, like in other languages we write but then they transpile down to JavaScript and we actually run that in the browsers. So, it almost becomes the Assembly language of the web. But now it’s seeming like the DOM is going to become the Assembly language of the web as well, and maybe even earlier than anything else. Would you agree with that? And do you feel like Famo.us is pushing us into a world where the developer eventually won’t even care that there’s a DOM under the hood?

  Wow, that’s a big question. I think that the world that we want in the future is the beauty and power of native capabilities but with the utility and ubiquity of web thinking. Let me tell you what I mean by that. There are some wonderful things about native but native has some big problems in it. Number one, it’s not SEO-able. Some basic stuff that we take for granted on the web just isn’t in there in native. But native gives you access to OpenGL and access to really true performance and things like that. We’ve seen some great progress in now WebGL and some JavaScript libraries that tap WebGL like three.js. But what Famo.us is trying to do on that front is then make it easier to tap these things. Have you guys ever coded in three.js or coded in just straight done stuff with

WebGL?

  It’s all a mystery to me. I have no idea how to do it.

  It’s really, it’s a double-nutter. 

  [Chuckles]

  It’s really hard. And so, one of the things that we’re trying to make true about Famo.us is saying, look, you should be able to use things like WebGL or a 3D physics engine or a 3D layout engine but you shouldn’t have to learn linear algebra or matrix math or understand underlying GL component tree. You should have a very nice and robust API to it. 

So, in the same way think back when Dave Methvin and team did jQuery and they made JavaScript easier to use, think of Famo.us as being a layer on top of these incredibly complex components that makes it easier to tap into a 3D physics engine without knowing how physics works itself. And if we are able to build really solid APIs, really solid widgets and templates and things like that, then we make life much more powerful for people to use. 

One of the most exciting projects that we’re doing right now is we’re rebuilding all of the jQuery plugin widgets in Famo.us with WebGL and DOM. And then we’re already rebuilding Twitter Bootstrap in Famo.us using WebGL and DOM with 3D physics in both. But the interface with each of those templates and widgets is in the global namespace. It’s a lot like coding with jQuery. In fact, it looks almost exactly like it. So now, you can tap the power of these things, these incredibly powerful things, but you don’t have to know the underlying bits of it. 

Does that mean we won’t need to know DOM in the future and we won’t need to know JavaScript? I think that there will be tools for designers in the low-code and no-code environment. But I think we’ll also always have an environment where more intermediate and senior developers do want to get down into and closer to the metal. And so, one of the core missions that Mark and I have is never act a person who doesn’t want to code and tell them they have to code. Let them still build beautiful things and not have to code. And let a person who wants to get down to the metal get all the way down to the metal. And that’s one of the tenets that we’re trying to hold true at Famo.us if we can. 

  Okay. So, it sounds like yes you’d like to abstract the DOM for those that want to abstract the DOM away and yet still allow access for people who want the direct access. Is that fair?

  Yeah. That is exactly right.

  What kind of tools does Famo.us give you for managing the larger organization of your app? Is it purely concerned with the rendering layer and animations or does it give you anything other than that?

  Excellent question. So, if you consider a larger more abstract construct like a model-viewcontroller platform, we would be considered the view layer in that paradigm. So for example, when we integrate with Angular to be able to control a larger swath of things, we become the view layer of Angular. When we integrate with Ember and Backbone, we do the same thing. Now React is just a different animal altogether. But the integration we have there, we’re effectively the view layer. So, Famo.us wants to be the Apple of view layers, if you will. We want to have that perfection in the view layer. And that’s our thing, if that makes any sense.

  Sure.

  Yeah.

  Just from going through the Famo.us University, it seems like a lot of the animations and events and things involve managing lots of state. Is that something that just shows up in demo code like that or is that, I’m trying of how to best phrase the question. It just felt like there was a lot of manual state management that feels icky after trying to get away from that for so long.

  Yup. So, that’s a function of how young we are. And this is all about how we’re trying to make Famo.us easy to use and then improving it at each version. So, consider that, I think Ionic is quite a bit older than us and we’re at version, we’re trying to release 0.3 this week. So, as we head towards version 1, we’re making the API better every single time. And we’re concentrating everything we got on making that easier and having less cruft involved and being able to manage things more wisely as we go along. 

So yeah, the way I like to describe Famo.us is you got a Ferrari engine and you got a gas pedal, and maybe a steering pedal but you don’t have any breaks and there’s no seats, and there’s no car doors. And we’re heading down this long journey of building an Apple quality JavaScript framework here. And it’s going to take us a while. And I try to, when people adopt Famo.us, I let them know this is still pretty raw and we’re taking our time building this right. So, trying to set those expectations is an important part of our process. And it’s been hard so far because people have very big expectations.

  So, from what you’re saying, today may not be the best day to build an entire production project on Famo.us. But if I have, say an existing Angular app right now in production, is there a way to use Famo.us in small parts of my app to get a performance improvement without replacing the whole page to be controlled by Famo.us?

  Yeah, two-part answer there. So, if I were a senior developer and maybe I really well understood Angular or I really understood React, I would dive into Famo.us with both feet. I would go all in. If I were a jQuery and Bootstrap developer, I would wait until Famo.us’s version of jQuery widgets and Bootstrap came out before I delve into it. 

We have a thing here at Famo.us called Famo.us Labs where we invite up to 40 people of all skillsets to come in and play with Famo.us. And then we watch them to see how they do. And we’re finding that senior engineers take about three days to get over the learning hump and then they’re just uncontrollably off on their own. And then we’re seeing jQuery developers really having a tough time. And so, probably my investors might kill me, but I would say if I’m a jQuery developer I’d wait a little bit. Bootstrap developer, wait a little bit. Ionic developer, I’d dive in. I’d try it out. If I’m a senior Angular or Facebook React developer, I’d go full bore.

  We’ll protect you from your investors. Don’t worry.

  [Laughs]

  Mark and I value heavily trying to be accurate in these situations. But sometimes, I’m going to still try to hype it up somehow. But that’s really where we are. And in terms of can you use Famo.us in just part of your app or do you have to go greenfield, that’s also been a big one for Mark and I. One of the things that we’re going to be releasing soon, are you guys familiar with Docker?

  Yes.

  Mmhmm. Yeah.

  Love Docker.

  So, there’s Docker, there’s Docker containers, and there’s a couple of new companies coming out that are also doing some really fascinating things with the concept of containers. And so, Mark and I a while ago concentrated on the concept of the notion of containers is that you’re containing a system within something and making it highly portable. 

And so, Mark and I envisioned something that we call a frontend container that would be, for example if you talked about a frontend container it would be, let’s take Carousel, jQuery Carousel, the most popular jQuery widget that exists. What if a frontend container built in Famo.us was not only the Carousel GUI but also the developer tools that go along with that GUI? And then also the cloud infrastructure that would support running that GUI and would include things like CDN services. It would include setting the settings on that Carousel, A/B testing, analytics. 

And that what a website or a web owner could do that has a desktop website, a mobile version of that website, and a mobile app, instead of replacing and doing this big re-platforming project, they could replace things one widget at a time. And so, they could go after their big money, big important widgets first, and replace those with a container that upgrades just that contained bits to a modern cloud infrastructure, modern developer toolset, and modern 3D physics engine with 3D layout just in that one container. 

And so, think of the hero moment on the New York Times or the hero moment on Airbnb. Those widgets are all important for those folks. And it’s neat to say that you just look at your website or your mobile website or your mobile app, divide it into its widget tree components and say, now we can create a roadmap to update those one at a time. And so, I think that frontend containers are going to be probably one of two of the biggest stories this year for Famo.us.

  It sounds like you are leading into this already, but I was going to ask how do you make money? I imagine services around this containers idea is part of that. 

  Yup. So, the widget contains with it, widgets, templates, all of the products that sit on top of the platform. So, the platform of Famo.us, i.e. the physics engine, 3D layout, mixed mode, all of the deep underpinning stuff that makes everything work is free and open source. And then we’re going to layer products on top of that platform that have cloud services attached to those things. So, we will have Carousel, Lightbox, Bootstrap, Isotope, all these things we’re re-envisioning in Famo.us. And we will be attaching things like A/B testing, analytics, credit card services, all of the things that are associated with running those widgets. And those are the areas that will be making money, so cloud services effectively.

  That does remind me I was going to ask you about testing. What is the testing story with Famo.us?

  Yeah, up until version 0.3 not much. But we’re finally getting into the testing bits in Famo.us. And so, you’ll start seeing that roll out here internally first. And then we’ll roll out to Famo.us Labs and then out to the public. So, internally we’re already doing some testing here. But next stage is Famo.us Labs, the 40 or so people in our basement. So, it’s not there yet but it’s coming.

  Now, is that you guys testing Famo.us or is that users testing their own apps?

  It’s the ability to test that your stuff is working on all the browsers.

  Okay.

  And working performantly and things like that.

  That makes sense.

  One of the things we want to have is all the developer tools for perf testing, all the types of testing that you can imagine, being built in and coming with the core widgets and templates that we have. And then we just want to have the ability to add your own testing to anything that you’re custom rolling yourself.

  Alright. One other question I have with this is most of the apps in the demos, they’ve got a custom look and feel as opposed to some of the other app frameworks that I’ve seen that mimic the native look and feel.

  Yup.

  Do you expect people to just create a custom look and feel or do you have components or styles that make it look like an iOS app or an Android app?

  Right. So, the making it look like any given native platform ecosystem is, internally we call it the Human Interface Guide or the HIG. So, we are definitely creating a Famo.us HIG with our own iconography, with our own layout, and all the components you would expect in a HIG. And there will be a Famo.us HIG. If you want to build an iOS HIG or an Android HIG like they now have in the new one that they rolled out, the flat HIG that Android has called Material Design, Ionic is working on Material Design. Other open source JavaScript projects are working on that sort of HIG. And we’re probably going to let the open source community support those sorts of things. We want to promote our own HIG because we can do it in full 3D with GL. So, we really want to start taking that HIG to a new level and associate that with more of a, “What if Apple built the web?” concept. 

  Yeah, Apple has their HIG as well.

  Yeah. So, we hope that the open source community starts picking that up. And we’re already seeing signs of that sort of work being done by our community. 

  So, another, oh go ahead.

  So, would you have to build two apps then?

  No, no, no. You can just simply say, if on iPhone do this. If on Android, do that.

  Okay, makes sense.

  And that’s just standard JavaScript stuff. That’s not anything special.

  From going through Famo.us University, it felt like while you could still use CSS to manage how app is laid out, that’s definitely not the happy path in Famo.us?

  That’s correct. So, the laying out of the big bits is something that Famo.us should be controlling almost pristinely.

  How do you transition into that workflow? If you’re working with maybe designers who are used to CSS and HTML, do you just say “Don’t worry, I’ll take care of it,” and then you have to code it yourself?

  Yeah. I think that’s a function of giving designers a better tool. So, one of the projects that we’re going to be working on here is building a designer’s tool. And we can show examples of, imagine if you mirrored something like Photoshop but then you could also do live 3D animations with the physics engine but you’re actually live on the device that you’re intending to build for. And you’re actually generating pristine Famo.us code as part of that. 

So, we’ve done scenarios where without any coding at all, we have a partner company that we work with and we built VentureBeat from top to bottom. And we’re building another prominent media site right now top to bottom without a single line of code. And the designer can get in there and drag and drop and play with just a better toolset, frankly. So, I don’t think any designer’s going to miss CSS3. They would much rather have an inspector and a robust toolset that lets them do animation. And the big thing that I’ve seen is that animation is now part of design. And you can’t really do 3D animation or physics-based animation in a tool like Photoshop. You have to do it live on the device that you’re playing with. And those are the types of tools that we want to offer designers.

  That makes sense.

  Yeah.

  Can you talk a little bit about the marketing leading up to the release of Famo.us? To be frank, it was probably the biggest thing that turned me off of Famo.us because it felt very sensationalist. It felt like they were trying to create a club that I wasn’t cool enough to get in. And like, [inaudible]

  [Laughs]

  Famo.us. It’s amazing. But man, did I not like it.

  Oh, my.

  When it first launched.

  What was it that particularly turned you off?

  You had a waiting list to see it, but it was supposedly an open source framework. But you had to sign up.

  Oh, yeah.

  I don’t know. It just felt really weird. Most open source frameworks go on GitHub and then you can look at them. But you couldn’t even look at the code.

  Yup. So, the answer is pretty simple. It’s part, we did a face-plant. It’s part some stuff was going on that forced us in that situation. But here’s what was going on when we started building Famo.us. Right away some of the bigger companies took notice. It’s now public that Samsung is an investor of ours. But I only let them invest after saying, “It’s arm’s length distance. You have no control.” 

And we were very, very worried that if we chose the wrong open source license, that one of the larger companies, one or more of the larger companies would simply take what we built and make it private. We had studied many use cases where it had happened before. And because especially we were building really low-level physics engines, really low-level layout rendering engines, we deeply wanted to make sure that we wanted to go open source but we wanted to do it in a way that none of these bigger companies could take our work and make it private. 

So, we were actually researching our open source license for a year before we could actually come up with one that we thought was something that protected us. So, a lot of that time and waiting was waiting for the open source licensing to come to a conclusion of what we could actually do in a way that made us feel good on all fronts. We saw a lot of our brethren in the JavaScript area just randomly choose MIT or we have…

  Huh, that describes how I pick licenses.

  [Laughs] Yeah, me too.

  That’s what we saw…

  What’s this ISC thing? It’s the default in npm. Sure.

  Exactly. Yeah. We have lots of friends at a lot of the JavaScript platform companies. And I heard just nightmares of people who chose MIT and then suddenly people were stealing their crap. And then they regretted that and they really wished they had done some other license. And then we’re friends with some of the core contributors to Cordova and we talk about the Apache License and how that has its own string of problems with it. And we really wanted to make sure that we didn’t destroy the open source project before it ever got off the ground. And we’re like, “Well, crap. This is taking forever.” And so, we couldn’t actually open up the Git repo until we had the licensing figured out. 

And in terms of marketing, we didn’t have any marketing department. Why did the bloggers cover us? I think that’s because I’m still known for Powerset which became Microsoft Bing. And all those guys wanted to know what I was up to. And I’m like, “Go away. I don’t want to talk to you.” And then they would write something about us. 

  And to be clear, it was fantastically successful. Lots of people head of Famo.us. I think I just had some inner hipster that was like, “What is this thing that is being teased but I can’t see it yet and I have to sign up and wait for it. And argh, I’ll just go use Ember and it’s free and it’s open.”

  Yeah, I totally don’t blame you. There were nights I’d crawl up in the fetal position saying, “My god. I wish this could be different somehow.” But the press loves to hype these things. And we now actually brought on a marketing department to literally make sure we can control the hype a little bit. I totally agree that the press just has really said that we can do things that are ridiculous. And I

prefer a more steadied approach and say, “Look, we do have a real physics engine. We do have a real 3D layout engine.” But I always try to temper it by saying, “But we got a long way to go before this is the last platform I’ll ever need.” But I hear you on that. It’s the one thing I wish we could have done a little bit differently. I am glad we had so many people sign up though.

  Yeah, it seems to have worked out very well.

  Yeah. My god, we have so many people in our newsletter list. And it’s just an amazing amount of traction. But I do agree that the hype bothered me as well. And we try to tamp that down a bit now.

  It seems like there are a few different models for these kinds of frontend frameworks. There’s the Angular or React model where there’s a large public company that just produces it as a consequence of their work. And then there’s more the Meteor or Famo.us model where there’s a private company that’s producing open source software as one of their products and then tries to make money through monetizing that somehow. Can you talk about maybe some of the strengths and weaknesses between those two approaches?

  Wow. So, I think that if you are a private startup that’s building an open source project, in order for an open source project to live on its own, you have to have a contributing workforce of the open source community that isn’t part of the paying body, if you will. Google sponsors Angular, Facebook sponsors React, Google sponsors three.js. Meteor’s on its own. We’re on our own. And the question you ask yourself is what happens if funding for the project dies? Either the main corporate sponsor doesn’t decide to fund it or the startup runs out of money. Either way. Those are the two, I guess really bad situations. 

But what I found is those startups who are very good at fund-raising and very good at growing themselves are actually better funded in funded in some ways than some of the corporate entities. So, we have more people in the core Famo.us team than Angular has on the core Angular team. We have more people in core Famo.us than Facebook has on core React, I believe. If you look at those scenarios though where the corporate sponsor then pulls back their funding, and I won’t name those but there has been a very famous one recently, you see that that project has problems almost immediately. 

So, the good thing about something like Famo.us is we just raised $25 million so that we’re going to be funding this Famo.us project for many years to come. And that’s the thing I’d look at if I were a developer because choosing a developer platform is so much more than just a technical decision. It’s a career decision too. So, I would have trouble betting my career on a project unless I saw it had significant long-term funding because these projects that are open source come and go. I get the jibblies if it’s anything less than $10 million in funding, if it’s a private company. And if it’s funded by a corporate company, I want to make sure it’s nice and healthy. Google Angular is really healthy. I think that’s the model of a corporate open source project. Facebook React is awesome as well. 

You know, I look at other open source projects and they scare the bejesus out of me because I’m like, geez, if I integrate that into my stack and then it loses money to fund it. I’d look at how many core contributors there are. And in many cases, it’s one or two core contributors. A fascinating case study that I just finished is I looked at all the old jQuery plugin widgets. So, jQuery foundation funds jQuery itself and does a wonderful job of supporting that. But the widgets that sit on top of jQuery are individual contributors, not funded by anybody in almost all cases. And I went and I actually contacted most of the core, most of the biggest jQuery widgets or jQuery platforms. And in almost every single case, the core contributor that created the thing in the first place has now got a job. And they don’t really focus on it. And I think that’s really sad, because some of those are most favorite libraries. 

So, I always look at it as a developer chooses these things and it’s a career decision. So, you got to create your company the way Google handles Angular. It has to take that into account. And I think there are a few projects that do a really good job of that.

  So, I wanted to ask. You mentioned that Famo.us handles the V part of MVC. Do you pull in something like Angular to handle the M and C?

  Yeah, we have picked three platforms to go and do a deep integration with. So, we have a Google Angular team here on site that we pay. And there’s up to, I don’t know, five people on that team depending on any given week. So, it’s three to five people. We have also chosen Facebook React as a core integration partner. And we’ve also chosen Ember as a core integration partner. And for those three projects, we are sponsoring significant sponsorships to make sure that we get those integrations up and running and then build them so that they are live and available for everybody.

And Google Angular is in a 0.4 release already. Actually, I should say Famo.us Angular, the integration project, is in 0.4. And we’re soon going to be releasing Ember and React.

  And so basically then instead of calling jQuery or something to manage DOM stuff, you’re calling the Famo.us APIs?

  Yup.

  Very cool.

  Yeah. And we are maybe preannouncing this a little bit, but we hope to say that we’re going to be doing a big thing with jQuery as well. And that’s in the widgets though, that’s a different type of integration. 

  Alright. Well, if people want to know more about Famo.us or get a hold of you and ask you questions, is there a good way to do that?

  Yeah. So, obviously you can go to the website, Famo.us. And if anybody wants to email me questions, my email is Steve, S-T-E-V-E, steve@famo.us, F-A-M-O dot U-S. 

  Very cool. Well, let’s go ahead and do the picks. AJ, do you want to do a pick or three?

  Yeah. So, I have two and two half-picks. And I have to give a disclaimer. I haven’t used this, but I recently found out about SQL Cipher. And I thought that it was really cool, because I’ve gotten into encryption a little bit lately. And the idea of securing data and how do you make sure that something’s secure? Because you have to, is physical access the weak point? Is being able to get access to the box the weak point as in SSH in with a bogus account or something? Where are the weak points? 

And one of the weak points of security is if the data is encrypted at REST. So, your endpoints like HTTPS and SSH and all that might be secure. But there may be a way that somebody somehow does get in there anyway and then your data is unencrypted. So, SQL Cipher is an SQLite plugin that encrypts the data. And so, I don’t understand entirely yet but it looks pretty cool. And it supports SQLite full text search.

And then another thing is there’s a Node module that’s really old. And I don’t know if it’s, well it’s abandoned but it may also be complete and that may also be why it’s not been updated in a while. But it’s ursa. And it allows you to do public/private key encryption in Node.js. And so, I’ll put a link there and then I’ll link to an example that I created showing how to do it both ways. But yeah, encryption is starting to fascinate me a little bit more and security in general. So, those are my picks.

  Awesome. Jamison, did I ask you for picks already?

  You did not. And boy, do I have picks for you. There’s a thing called Hacker School, which is a retreat for programmers. You take a three-month hiatus and go work in New York. It’s for people of all skill level and experience. And I was reading their manual and they have this great entry called no feigning surprise. So, they have a list of rules. No feigning surprise is one of the rules. It’s basically you can’t be shocked by someone not knowing something that you know. So, you’re talking about encryption and someone doesn’t know what public key encryption is because they just overheard AJ talking. You can’t just say, “You don’t know what public key encryption is? Everyone knows that.” It’s designed to create a friendly environment. I just really like that rule. I think I’m going to try and do it in my life.

The next three are all related to music and coding to create music. There’s something called Sonic Pi. It was talked about at Strange Loop. And it’s this graphical code editor for creating music. It’s geared towards education and teaching kids to code. But it teaches me stuff, too. So, I guess I’m a kid. It’s really fun to play with. And I think it works on Raspberry Pi and OS X right now. I don’t know that it works on Windows, but I think they’re working on support for that.

The next one is this Clojure library called overtone which is built around creating and manipulating music in the repl, so you’re live editing your code and creating music on the fly. People have done some amazing things with it.

And the last one is a link to the opening of JSConf EU. I wasn’t there but I just watched the YouTube video of it. And they do this really cool 3D projection with music going in the background and then the lights come up. And it turns out it’s these two guys coding and playing guitar and piping it through a browser. So, the amp is in JavaScript. Amazing stuff. Those are my picks.

  Very nice. Dave, what are your picks?

  I have two picks for you today. One of them is an oldie but a goodie. It’s vim, the editor. [Laughter]

  Eww.

  What are you talking about?

  That is correct. 

  I am a huge fan of vim. I’m not an Emacs hater. But I love vim. And I just wanted to pick it because I love it so much. Specifically also, if you’re using vim you would do yourself a favor to install the Pathogen plugin which will help you install other plugins with great ease. It lets you just drop files into a directory and poof. You’ve got your plugin installed which makes it a lot easier. So, it’s a plugin to install plugins called Pathogen. 

My other pick, this is one that probably a lot of people are already familiar with. But if you’re not, it’s something that I use at work every day with my team and I really like it. And it’s called HipChat. I think many people probably already use this. But if you don’t, it’s a really nice chatting application that has a lot of really cool features that when I first started using it I thought, “How come my chat hasn’t always been this way?” I came from an IRC background and HipChat has some really cool features that I didn’t even know I missed. Those are my picks.

  Alright, very cool. I was a vim user for a long time and then I switched to Emacs. And no hard feelings here. [Laughter]

  Emacs users just can’t help resist, but insert that they are an Emacs user. [Chuckles]

  Yeah, well Emacs comes with the package management built in. But you know, if you have to install a plugin to get it, I understand. [Laughter]

  Emacs comes with everything else built in too, right?

  So, is the GNU Foundation coming out with the Emacs OS laptop anytime soon? 

  I would be a customer if they did.

  There’s not a laptop big enough to run it.

  Yeah.

  I’m just teasing. 

  Anyway…

  I love me some vim and I appreciate Emacs users. 

  Well, they’d have to make a laptop big enough to compensate for Emacs ego is all I have to say. [Laughter]

  Anyway, yeah so I’ve got a couple of picks here. The first one is I’ve been reading the Michael Vey books by Richard Paul Evans. And he just came out with Michael Vey and the Jade Dragon. And it was a pretty decent book so I’ll go ahead and pick that. 

And I’m going to pick one of the podcasts I listen to. It’s called Stuff You Should Know. And it’s pretty awesome. 

  Oh, I love those guys.

  Yeah. Well, one of them has a terrific name, Chuck.

  Chuck. [Chuckles] Charles W. Chuck Bryant?

  That’s right. 

  [Chuckles]

  So yeah, so those are two of my picks. And let’s go ahead and we’ll give Steve a chance to give us some picks.

  Sure. So, I’m going to nerd out a little bit here. One of the things that I like doing is working with robots. I’d urge everybody to check out NodeBots.io. Pretty cool stuff if you’re into Node and also bots. 

And I love Sandstorm. Sandstorm.io, they are doing, so if you’ve ever played around with Docker, Docker’s really hard. It’s really hard to get up and running exactly what you want. And Sandstorm’s a new take on it that is a container at the app level. And I really think what they’re doing is fascinating. And you can check out what they’re doing at Sandstorm.io.

And then one of my favorite designers, and I always love staring at anything from animated GIFs to just anything cool that flies around on the screen, Hakim El Hattab is one of my favorite designers. And he can be found at Hakim.se. That’s H-A-K-I-M dot S-E. And I love just clicking on everything in his repository and just playing with it. So, those are my three picks.

  Very nice. Alright, well go check out Famo.us. This is definitely on my list. And we’ll wrap up the show and we’ll catch you all next week. 

[Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]