Panel

Ben Combee (twitter github blog)
Gray Norton (twitter)
Jamison Dance (twitter github blog)
Joe Eames (twitter github blog)
Tim Caswell (twitter github howtonode.org)
Charles Max Wood (twitter github Teach Me To Code Intro to CoffeeS...

Special Guests: Ben Combee and Gray Norton.

 

Is somebody clicking something in the background or tapping or..?

I’m tap dancing.

Clickety click, click, click!

Ooh, yeah.

Practicing my tap routine for the talent show.

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

Hey guys! I’m @jergason on Twitter and jamisondance.com on the regular internet.

Awesome. We also have Joe Eames.

Coming live from a smoky, dirty basement. [laughs] That’s me.

A smoky, dirty basement, huh?

Yeah. My kids burned something today and I need to tidy up my office.

Oh, I thought you were going to say that you went and work for one of my former employers.Anyway, I’m Charles Max Wood from devchat.tv. The thing that I have been working on lately isIntroduction to CoffeeScript. If you are interested in learning CoffeScript, go to introtocoffeescript.eventbright.com and sign up for the online training that I’m going to be doing next month. You can get early bird tickets to the end of this month, I think. We also have a couple of guests; Our first guest is Ben Combee? Is it Comby? Combee?

Combee. Yeah, I’m Ben Comby, @unwiredben on Twitter and I’m the lead architect for the Enyo JavaScript framework heere in Austin, Texas.

Alright. And then we also have Gray Norton.

Yeah. Hi, I’m Gray Norton; @graynorton on Twitter and I manage the Enyo team from a sterile conference room here in Sunnyvale, California. No smoke or interesting basement projects going on here.

Awesome and it looks like I missed Tim Caswell.

Hello, I’m here.

We all missed Tim.

My Skype says that Tim– it’s still ringing Tim’s Skype, so he’s only partially here I guess. So this week we are going to be talking about is it “EnyoJS”?

That’s right.

Do you want to introduce it a little bit? I really kind of buried. I was out of town last week and I have been catching up and I haven’t had a chance to look at it.

Sure. Why don’t you give a quick introduction Ben and I’ll hop in.

OK, yeah. So Enyo is JavaScript framework that — at HP has been working on for a while. It actually came out of the webOS project, which I remember the PalmPre phone and then the touch pad that came out last year. When we launched the original Tree phone, we had a framework that we callMojothat we had. So the idea behind webOS was that, you build applications entirely in HTML and JavaScript and they base the writing on top of a web engine directly on the device. So, this framework called Mojo, which was very much organized around the phone or around a small vertical screen doing lots of list, moving back and forth between different screens, that didn’t scale very well to a tablet.

And we had a team that had been working on this tool calledAres,which was a in-browser web development environment. And they kind of manage to somehow get this component-based layout system working with Mojo. But in the process of doing that, they ended up writing their own framework calledEnyo. So, we had the first version of Enyo came out with the touch pad last summer. And since the hardware was cancelled last fall, the team kind of figured out what do we do next, and so we released Enyo 2 in January. And it’s a cross platform framework targeting all sorts of mobile devices, iOS and Android, but also targeting desktop web application development.

So is it kind of a competitor to things like Ember and Backbone?

Not really competitor to Backbone, I think maybe we compete a bit against Ember. I think the one of the way to think about it is, Enyo is pretty very much around the idea of organizing application into of lots of components, reusable components. So you can kind of like take a bit of functionality out of one app, put it to another. So I think we kind of fit more into the world of like a sensor touch kind of a framework, that does all of the rendering from JavaScript into your application DOM, whereas I think a lot of other systems are more in around doing templates or annotating existing HTML files, you know adding functionality on to those.

OK, that makes sense. I’m working with a company right now that I usingXJS,which is what kind of what underlies sensor touch. And so, from the layout in JavaScript perspective, for me, so far it’s been a world of pain.

I’m just wondering is there a different mind-set that you have to have in order to really make the layout in JavaScript to make sense over just building some HTML and manipulating the DOM?

I think so. I mean, if you look at where we were coming from originally in designing this and we are starting with the visual designer. So rather than the person building a bunch of HTML, they’d actually start with in our Ares tool and drag buttons around, drag input fields. Basically kind of set up a UI in the application directly. Similar like where you build app in Visual Basic. And so, the Enyo framework is very much organized around that idea that, you are letting the JavaScript handle the rendering of all the HTML rather than thinking of the terms of pages and then going back. And you are kind of thinking in a different level than if you are working in HTML directly.

So, you are thinking in terms of maybe components instead of page elements like divs or what have you?

Yeah, I mean, ultimately, you are going to be creating divs using the DOM, but you tend to organize your application around the actual UI element that the user works with rather than the HTML items.

But I will say that Enyo actually sort of creates a bridge from all the familiar that you’re accustomed to building UIs using HTML and DOM directly and sort of the high level world of components. So, the original architects of the framework spent a lot of time sort of discussing philosophical matters related to framework architecture. And one of the key principles behind the Enyo architecture is the notion that, “It’s all turtles all the way down”. That’s a quote or a reference to —.

But the bottom line is, you can actually work very close to the DOM in any you want. So if you have a UI library called Onyx which sits on top of the Enyo core, which has a bunch of high level controls of that have direct analogues on the DOMs, such as sliders and progress bars and things. But you can use sort of the base kinds or classes to use more typical terminology, in Enyo directly without using the higher level UI constructs and those can map more or less directly to the DOM Nodes that you know and love and you can style them using CSS.

Right.

So, I worked on the Enyo team for about a year, during the touch pad development. And at the time there was no Ares or Enyo, so we had to write Enyo by hand. And it took me a little while to get used to, but once I’ve learned the framework, it was really nice because you just make your components and you plug them together. And for the built in apps in the product, it was really nice because we can embed apps inside other apps. You could have this little panel like the your Wi-Fi config and they can be in the config app or it can be embedded on this other app and since it’s all componentized, it’s really nice.

And it sounds like you can do that with Ares on the web now as opposed on the tablet.

So we basically we have the original Ares, which was built around Mojo in the phone style devices. It’s still online ares.palm.com. So you can kind of look back and see where we came from. Ares too is a version that we are doing for Enyo development and that is still the process of being worked on. And we are actually using the Ace Editor that Cloud9, (the company Tim is working with now) has been doing is kind of editing component of that. So that’s in development. Yeah you can check out the source code at our GitHub but we don’t have a demo version of that online right now.

There are some instructions though in the readme and that repo and it’s actually not at all difficult to Ares repo and get it running locally on your machine.

So, this kind of leaves me to another question, it seems like initially since Enyo was aimed at the tablet and writing apps for the tablet as opposed to writing apps for the web, two questions and I’ll ask the first one and then we’ll move to the second one. Is there any chance that you will be moving Enyo to some kind of desktop application development? Or are you going to keep it strictly on the web?

So, for desktop app development, I mean the area that we have been looking at a lot has been Windows 8, because Windows 8 comes with a JavaScript runtime. And basically kind of its own phone get style container for doing JavaScript applications. But windows 8 environment has some restrictions versus just doing standard web. They kind of taken a lot of the content security things, where you can’t put into your inner HTML any script tags or event handlers directly. And you know, few other things like that and just kind of gone full-bore with trying to make sure the content can’t mistakenly inject the program code. So, having to do some work around that we’re also doing some work around just understanding the other restrictions Microsoft’s done. But I think we don’t have any specific announcement of when we will have a Windows 8 application version ready but, it’s something we are actually working on.

Let me take say different angle on that question because I think the key thing to understand about our vision for Enyo is that, we are really looking to help developers build native quality, cross platform application experiences using HTML, JavaScript and CSS, that can run really in any type of environment where you have a modern web runtime. So we are explicitly targeting mobile devices, phones and tablets as well as desktop machines. And really, frankly are agnostic with respect to whether an Enyo app at the end of the day is running inside a container like from gap or native shell of any kind in the Windows 8 runtime. And certainly, there things we need to do to ensure that we work well on all of those environments, but the bottom line is our objective is really to help people build great application experiences using pure web technologies that can run anywhere.

So, I’m not very familiar with Enyo, but just from browsing the docs in the website it looks like it’s very much focused on mobile. But from here in your talk, it sound like goal is to write ones that run anywhere.

Where have we heard that before?

That’s what I was thinking too. [laughs] right? But assuming you have written an Enyo app, what kind of changes do you need to make, to make it work well on a small-form-factor and on just a desktop web browser too?

There are a number of things that you can do to write a new app in such a way that it will work well across different form factors. And certainly, we don’t claim to have a monopoly on good thinking in that area. So obviously, if you’ve been following the trends around responsive web design, and all the techniques that have evolved there, virtually, all those techniques can be employed within a new app. And we encourage people to employ them where they make sense. Because after all, Enyo is (at the end of the day) is just JavaScript, HTML and CSS.

To go along with that, there are number of things within Enyo itself that make it easier to write UIs that adapt to other form factors. And probably, the most visible, tangible one that I could mention would be the panels metaphor that we came up with when we were first moving from just smart phones on webOS, to smart phones and tablets. The idea is essentially that you have an application UI, which is laid out in logical panels that lead in sort of typically in sort of a horizontal space, but that you anytime is viewing maybe on the phone just one of those panels at a time. Whereas on a tablet in the landscape, maybe you get two panels on a tablet on— I’m sorry, on a tablet on portrait, maybe two panels the tablet on landscape or desktop or maybe able to view multiple panels at once.

But from the user point of view, regardless of the size of your viewport, you get the sort of physical feeling of space of these panel and you understand as they slide in from the right side and slide them back out to the left and move back and forth. And so, that is the metaphor that we employed very consistently across the webOS apps. And one which we find works well for a lot of different types of apps, particularly those that have any kind of hierarchy goal navigational structure. So that is the kind of the construct that is built in any OS or the first class element.

I’ll also add that another thing that we do is we have kind of a layout system. And so, if you’ve done work on web kit where you’ve used the Flex Box CSS, you know that that’s kind of very powerful way of doing apps style layouts. We build a simple version of that which we callFitablefor doing layout across components, where you have like a few items that are fixed size and you want one other item to grow to the size of the container, whether that’s the entire browser screen or just a part of the page that you are at.

Yeah and the reason why we did that was simply because we wanted to ensure liability in the new apps across the widest platform as possible. And of course you are going back as we are as far as IE8, you can’t be using Flex Box there.

So, that’s another question that I had was, what’s the browser compatibly as far as, you know, you are only going back to IE8. Are you supporting all the versions of Firefox? You know, what other browsers are you targeting?

So yeah, IE8 is as far back as we go for Internet Explorer. That’s the last version that’s available for XP systems, so that’s kind of why we wanted to pick that as base line. For Firefox and Chrome, we generally mainly just support the most recent one. We are not supporting Firefox 3.6 and if you’re on Firefox 4 or later, you are in the upgrade system so you are moving to newer versions pretty quickly. The same applies to chrome. For Safari, I guess we are basically supporting the most recent Safari and one version back. Because Apple has been updating Safari for some of the older OS releases. And then we have like a patron site which lists the various compatibility things. We test occasionally on Opera, but we are not spending a lot of time with that. On mobile devices we are kind of going back to Android 2.3, iOS5 and 6 are supported, 4 best efforts there. And then we have been testing on Windows phone. Windows phone 7, the browser has some issues that we are not really happy with but, we are hoping that Windows Phone 8 is going to turn out a lot better.

And when you say you are testing it, is that automated testing or do you just kind of fire up an app and fiddle with it and see what doesn’t work?

So fortunately, the nice thing about having the resources with HP is that we have a fairly large QA team. So we do have automated test for a lot of the core stuff when we are dealing with the UI differences in mobile devices, we basically have a team of dedicated testers that go continuously through and check on the different platform and final bugs against us.

Right. So, it is a supported project within HP?

Absolutely.

I’m a little bit curios about how that works. I mean, you hear about some of these at least in the world that I live in; most of the folks that work on open source are generally employed by smaller companies. You know, people who are employed by larger companies like AT&T or something to work on open source stuff. Do they have some other way that they see, that they are going to capitalize on this either by putting out a commercial license or is it going to be used on internal projects or what’s HP’s benefit in this?

Yeah, so we are in the fortunate position on the Enyo side of building a key enabler for a number of revenue generating business opportunities, both within our business unit which is essentially the former Palm, as well as elsewhere in HP. So, of course, in order to run the Palm business, we were shipping phones and tablets. And so, in the process of doing that, we built a full stack OS, webOS which we talked about. We built of course a new application framework, we built a lot of cloud services that we’re backing the OS and the applications that ran in the OS. And we can’t go to a lot of details on future revenue models, because we are sort of in the process of launching the group now under its own identity and we have some partnerships we can’t talk about yet.

But the bottom line is that, our full stack OS and our cloud services will have significant revenue potential and Enyo really is a necessary piece for making those things happen. And then we also are working pretty closely with HP’s massive enterprise services business. And those folks are getting asked more and more by their enterprise customers to help deliver absolutions that run, not only across different mobile devices but potentially across desktop and mobile as well. And so, Enyo is generating a lot of demand from within HP enterprise service as well. So we don’t– it’s not part of Enyo’s charter to directly contribute revenue and so our really one of the key principles that we are operating under is that Enyo is and will remain completely free and open source.

Yeah. That makes sense.

So, can I ask a question?

No.

I don’t mean it to be offensive at all. Framework saturation, right? There are so many frameworks out there that have so many people like talking about how awesome, that I feel like there is no room in my heart for another framework. Why should I, because there is a — right, to investigate new framework with things like that you are giving up the chance to build your skills in something else. So, I have two questions here; what kind of projects would Enyo work the best for? And like, what basic difference than all the other framework that are out there, I guess.

Well, I think the projects one is a bit easier just to kind of initially answer. Enyo is kind of a standalone system for building complex applications. So, a good application is the email application we have on the touch pad. So, that’s the really dealing with a complex status or with an email store. It’s showing information several different ways, so it’s going to have to render both view of the email folder or this hierarchy folders than individual messages. And it wanted to have a consistent user interface for doing that. So, if you try to do all that directly in HTML, you end up with something which might be functional but you don’t necessarily have all the nice UI bits that you have on a desktop application. So, email was one of the most important apps on the touchpad and Enyo kind of came around, it’s like how do we built all these components necessary to build something as complex as email app or as complex as a spread sheet application, the Docs To Go built around Enyo sorry not Docs To Go, that was Quick Office. Docs To Go is on the older webOS.

I mean, it’s when you are looking at kind of these classical desktop style apps. I mean you can do a really nice version of something like, what is the big Twitter client—Tweetdeck, with its multiple rows of information coming all at you at once and kind of a constant rendering of different kind of data sources. I think if you are building something that feels like a website, Enyo is probably isn’t the right framework. If you are building something that feels like a desktop application, then I think it’s a great way of organizing an application.

Sure. That makes sense.

so, can I jump on that for a minute? Because you are talking about application look and feel or application style web apps, look like desktop apps. I’ve never quite understood why you would choose that over maybe a native app. Are there reasons why you would pick one over the other?

I think the big reasons to go for a web based application that looks like a desktop app, I mean, one of them is you automatically have this kind of cloud sync built in. I mean, I’m thinking like the Trello application, a Todo Task Manager. I can access out on whatever mobile device I happen to have with me whether it’s a tablet or a laptop or someone else’s laptop. And I have something I can immediately jump in and deal with. Whereas with the installable desktop app, I’d have to figure out like, “OK, do I have a version for this operating system that goes to running?” I mean, I might be Tim’s system where he is running custom Linux and obviously there is no exe I can install. So, I think that is one big advantage.

I think the other one is we are entering a system where, if you have an application based on a website, it’s a lot easier to maintain that and update it. So, you have a point of sale system that’s, people are running on 15 different computers. Having on the website means you are updating one place versus having to build some sort of installer and update mechanism where you push changes out to all the different computers.

I think another point is just that, it wasn’t that long ago that we were doing the lion share of our computing on desktop and laptop PCs. But, obviously over the last 5, 6 or 10 years, we are doing a massive amount of computing now on our phones and our tablets. And there’s a whole way of additional types of devices that are sort of undergoing that transformation now; things like TVs and cars. I guess in our vision, it doesn’t make a whole lot of sense over the long haul for either people who are developing apps or for people who are consuming apps, if you have a lot of sort of wall garden ecosystems springing up around each of these different device platforms.

And as a developer, you have to be running native apps for five different platforms. And as a consumer, you have to buy the same app on multiple different platforms or at least, there’s some cognitive load that comes around thinking about, “Well if I want to get this particular thing done on my TV versus on my phone or my tablet, I might be using a different application.” So, to us, taking the long view, and we don’t really claim that this is a transformation which we can make ourselves or that it’s going to be easy or happen overnight, but we really have a vision of the web as a universal platform for apps. And one in which you don’t have to have compromises around user experience. So, I think there is a great user experience that people associate with native apps for mobile and desktop platforms. And it’s challenging to approach that on the web now, but we think that you know, it’s possible to come very close a lot of the time, with the a true cross platform app. And we think that especially if we and people who share a vision like that keep pressing, we think that’s the for the logical destination for all this; that the web really becomes the dominant app platform.

So, I have a question about this. I mean, the goal is to make it an uncompromised experience but, I’ve done web on mobile and web on web based apps and browsers for years and years. I’ve done this since the 90’s. And the biggest problem I’ve had is performance. Do you think mobile will eventually get fast enough that it will perform fine?

I think we have seen a trend at that direction, I mean you’d look at the iPad 3 and you’re dealing with something that is couple orders of magnitude faster than the original iPhone. And that was just a few years ago. I think we also are getting to a point where mobile devices are really going to have same computing power as desktops. I mean it’s just been amazing how much more powerful I think the mobile devices have become as we reduce the chip sizes, as we come with better power sources. And also, as we figure out paradigms, we shift a lot of the computation work off the device you happen to have in your pocket and push it on to your own personal cloud or servers that you work with out there.

I mean, dealing with HTML, dealing with JavaScript, you are kind of putting an extra layer on top, versus what you’d get if you are coding directly in whatever the native language of the device is. But, I think as the web world learns some more of the techniques, I mean, we’ve done a lot of optimization work in Enyo around things like how do you render lots of items into the DOM and have a nice continuous scrolling experience. So, you end up using kind of combination of a flight weight pattern, where we don’t necessarily associate Enyo live objects with everything that we render. Plus a paging system where if you are scrolling through a large list, you automatically have like a page of what is visible, a page of what is not visible, but you don’t have the DOM filled with 50,000 items or you are not going to be seen right now. So, you kind of put them in to the DOM just in time for you to view them and take them out so they don’t clutter memory. And these techniques like that can be done to make mobile or just to make the web experience feel better. It’s tough, but I really do feel like the computer powers have been improving tremendously.

So, I’d like to kick in here some of my own personal experiences. When we built the site’s HTML5 player, one of the things that I wanted to do was have the same code base running not only on the desktop, but on devices. And we pushed and we pushed and we pushed and it just seemed like what we are trying to do was create a car that can also haul stuff and we end with el camino and nobody wants and el camino.

So you know, we ended up actually writing a really good HTML5 player for the desktop. And I think it works actually pretty good on tablets, but on phones it just doesn’t cut it. And we are making all kinds of considerations that, for to make it work well. And for desktop, the user experience is just so different based on screen size and input. Keyboards and mice, versus your fingers. That’s a huge difference and we had a really qualified UX designer working on a project with us. Talking about how the different users would experience the application from the different types of platforms and how to make that work. And responsive design only goes so far.

This is not a world where responsive design fixes the real issues of what’s it like in a good native app on a phone or on a tablet is significantly better than a good website. Unless you are talking about a very informational website, but an app like a video player, it just doesn’t cut it. So do you feel like we will really, as an industry, solve that problem? Be able to do the right ones run—Well, I’m not talking about OSes anymore, right ones came out we’re just talking about you know, Mac, Windows or Unix and Windows. And now we are talking about different devices and different input types. Do you feel like—it just seems the problem just gotten harder we’ve been trying to solve this problem now for 20 years.

If you look at like what Microsoft is doing, they kind of decided that touch is a primary input method going forward. And like windows 8 seems to be deprecating a lot of the mouse and keyboard in favor of touching or actually even a kind of their desktop apps I mean–

I think that’s stupid. [laughter]

I think if you look at where people are doing the majority of the computing, touch devices are really starting to overtake the desktop. Except for people that are kind of needing a desktop or a laptop style device because they are creating or editing a lot of content or programs, those kind of things. Yeah I mean you are going to see a lot of application that tend to be touched or very touch responsive first and then kind of have affordances for more desktop mouse type use.

That’s an interesting answer because basically what you are saying is, or what I’m reading between the lines what you are saying is, touch is going to be the primary interaction and so, likely we’ll make concessions for people that want mouse and keyboard input, that will be a less– that will be the second tier citizen.

I think for a lot of cases that is going to be the case. I mean, I just seen initiatives where people are trying to run android applications on AMD processors as part of Windows now. And even though you can hook up mouse and a keyboard up to an Android device, touch is primary there. And I just really feel like touch is kind of the future for interaction for the majority of the users.

I would also say though that even if true sort of touching the screen type of interaction doesn’t take over the desktop world, (which I suspect it may not) I think the experience of using it for example via track pad on a newer laptop, in many ways, physically has a lot more in common with using a touch screen device than with driving a mouse around the desktop. And I think we are seeing a convergence of sort of UI patterns, where we are in the latest versions of OSX and of course Windows 8 is a really obvious example, are starting to adopt patterns that became popular on touch only mobile devices. So, you know, I think the distance between a desktop user experience and a phone and tablet user experience is closing.

So, you know, to get back to your question, do you think we are going to solve this admittedly very difficult problems around write ones that run anywhere, I can’t say absolutely that we will, but I feel like definitely, not if we don’t keep trying really hard. That is not to say that every single app developer out there should be investing a lot of their effort in trying to do this, because you know, you’ve got business goals and deadlines to make. And in many cases, it may not make sense to venture off into this unchartered territories but I guess we see ourselves as really focusing on pushing that ball forward because we think the destination is one that’s well worth reaching. And if one doesn’t keep pushing on it, we won’t get there.

So, I collect gadgets as many of you know, and one of my most recent gadgets is the MK 802 which is basically an Android device on a stick. You plug it in to your TV HDMI, you plug in a keyboard and mouse and you got a computer. And it’s been very interesting using Ice Cream Sandwich interface with a keyboard and mouse. And at the same time, I’ve been working on Cloud9 IDE experimental interfaces and I want a tree view that’s mobile friendly. So, as long as you only use clicks, only on big targets don’t rely on double click or right click, you can have an interface that works on desktop or on mobile, whether they are using a mouse on mobile or a touch screen, it doesn’t matter. There is an intersection on interfaces that work on both. And while a fully optimized app, you may have to customize the desktop in mobile versions, you are still saving a lot of time if it’s the same code base, which is customizations instead of like rewriting it in Objective C and rewriting it again in C++.

Personally, I hate that idea just because having being a programmer I’m often a power user in applications. And you know, taking the lowest common denominator of input devices or of input methods is basically just removing all the features that are making a power user a power user let you do that.

I mean, you can have stuff on top of it. I mean, you can still have a right click menu for devices that have right click. But, if you want your same app to work on multiple devices without rewriting everything, then you got to stick to something that works with everything.

Right.

Yeah. Or if you can—I mean, the more you can simplify it, the easier the code is to write and maintain. So I mean, there’s definitely a trade-off and if it’s buggy because they reach too far to provide those features, then it’s a different—I mean, it’s just as bad as if they don’t have enough features.

Yeah, just to me, it reminds me of the nightmare of a manager saying, “Hey, great. Using this technology now we can build the best possible apps on 6 different things and I only have to pay a quarter as much.”

[laughs] Yeah we will see that work, right?

I mean it goes back to the question I mean, what problem are you trying to solve when you create and application as well. I mean, there are certain applications where maybe it doesn’t make sense to show the same thing in a desktop or a tablet or a phone. And you know, it just depends entirely. I mean, if you wanted it to be accessible in all of the devices but work well on one or do you need like totally different ideas about how you deal with the information depending on what kind of screen you are viewing it on.

I think that is kind of true Ben, you kind of bring up a good point and that is it really varies by the apps. Some apps just work great. A lot of things are going to work great on multiple devices. Like here in Salt Lake, there is a theatre company that called Megaplex Theatre and they have an HTML5 website to hit on your phone. And it works fantastic. Just a great, great website. And it works great on the phone and it works great on the iPad and I don’t know if they are desktop, if they did a responsive design and cutting out things or the desktop side is really different. But, you know, something like that is perfect. Obviously, when it comes down to like a coding editor or something like that, I would cry the day that’s implemented the same across multiple platforms.

Right. So we are running out of time a little bit, I mean we still have another 5 or maybe 10 minutes that we can talk. But I wanna make sure that we are covering all of the different aspects of Enyo. One question that I have, because we are talking a lot about like sort of the widget or app reusable chunk of code or reusable interfaces, I’m wondering, do you provide any mechanisms for themes or do you just expect people to UCSS?

That’s actually a good question. So the Enyo core really doesn’t have a UI and we have Onyx widget set on top of that, which does provide a very definite user interface that our HI designers inside of the palm grade figured out. The 2.1 release, which is what we are finishing up this week and next week, now has support for less dial theming. So, we kind of went through and kick all the CSS our designers came up with and parameterized it and provide instructions on how to modify the variable set to do a custom version. But the framework is set up so you can define your own widget sets. I mean we’ve had developers in our community go and take the look and feel to the original webOS phones and turn that into a widget set. So, it’s you know, we kind of like a base UI class for common form elements. So if you create a new widget set, you wanna follow that but, you know, we kind of designed it from the start that you could have different look and feels plugged in and you set your own component.

All right the other question I have as far as the kind of the reusable– I don’t know what the right term is like. Like widget or mini app within the main app or whatever. So, are you aimed to more like sort of a modularly designed application? Or you know, if I do have an app that takes up the whole screen and provides different like maybe list all whole people in my list of clients or you know, whatever. Do you have the elements that are aimed more that way for like a large one screen, one widget app?

Actually a good example, we have app calledSamplerthat shows all the different samples for the different widgets. And so, each of those samples you can run on its own web page, but then you also have a view there where you have can navigate through the hierarchy to find your particular sample and that shows up on the side of the screen on its own area. But then, you can click buttons on the bottom which then show you the source for it or launch it in a new window. So I mean, I think you can totally do this kind to of like a collection of applets design with Enyo pretty nicely, but that’s not the only way of designing your apps.

Right. So, one other thing that I wanna aim at here real quick is (and this was way back in the beginning of the show I said I had two questions and I’d ask you one and I’d ask the other), the question is basically, do you feel like or maybe the better question is how do you feel like coming from more of the palm webOS based background, how is that colored the design of what is now a web technology?

I think you know, the focus on trying to build native quality app experiences using web technology is on even on device that have a lot of computing power is– that’s probably the way in which our palm legacy has informed our direction the most. Because when we launched webOS three years ago, we made the decision to make our native app runtime, build a web stack and yet when consumers and you know, reviewers were looking at our app experience, they were of course comparing those apps to the Epson, iOS and Android and other OS where they are using their native development stack. So, we were in the situation where we really needed to squeeze every last drop of performance and polish out of the stack. And so, I guess my answer is that, we were really focused on creating the app like experience and coming as opposed to that native experience as we could. And so, in a lot of the decisions we made about the nature of the framework and that the set of problems that we and focused most of our time on, we are doing them by coming from that place.

Alright. Cool. Any other questions that you guys have before we roll over to picks?

Yeah, I got a question. The same question I ask every week. What’s the best way for people to go about learning EnyoJS? What’s the best learning path and kind of what’s the learning curve like timelines for getting in the, you know–

So we have a basic tutorial up on our website which isenyojs.com,which will take you through– I think right now we have a building Twitter search application but we are going to have to rewrite that at some point in the future because of Twitter’s API in terms of service changes.

I just wanna point out; former panellist on the show, Yehuda Katz, he tweeted that Twitter user APIs are becoming like tax in the —. [laughter]

Well we actually, we didn’t even—we were using the search API for this, so that one never require any authentication. So maybe it will stay alive but we are definitely violating the terms of service in displaying tweets. So, we have that tutorial and we also have a very active user forum that’s linked off our site. And I’m on there and several other core developers are on there. We are answering 20 odd questions a day from people that are exploring and trying things out. And then we have a huge number of formal webOS developers and people who are just stuck around Enyo that are building apps or are active there, helping other people as well. So I think that’s the best way right now.

Yeah, so I mentioned in addition to tutorial, we have a growing set of docs in our developer guide which you can find in enyojs.com and click ondocsand there is some good introductory material there that go along with the tutorial. And Ben mentioned theSamplerearlier; definitely poking your way through the Sampler and there’s—you have the ability to view the source and then another sample within the sampler at any same time. So, that is a great way to get your Enyo beneath you.

And I think once we have Ares too out the door, that will be a really good way because then you can visually build something and see what the source looks like for to it and then add functionality.

Yey for generated code! So what kind of a – how long would you expect somebody if they jumped in and needed to pick up EnyoJS. How long do you think it would be before they were proficient enough to just you know, building app without too much need for hand holding a reference?

Well, we had a Hackathon in Sunnyvale a couple of months ago. And we came in with people that had no experience with Enyo or maybe just had looked at the website and had built up some sort of application by the end of the day. So I think you can get a feel for some basic stuff pretty quickly. I think the biggest thing we have seen is there’s been developers that have come in to Enyo without a lot of JavaScript or CSS experience. And so, not only we having to teach them the framework, but teach them more about how does a synchronous method work or why my stuff not layout the way I want it to. And things like that.

Yeah, I still ask those questions.

So, one last question. A few of us in the podcast tend to do things with some of the best practices like testing and what have you. Does EnyoJS play nicely with the testing frameworks that are out there for JavaScript?

So, there’s a back when we are working on the touch pad and we are working with Pivotal and they did a lot of work with they built Jasmine, so there’s been a lot of work with Jasmine. There is a basic test framework that’s actually comes with Enyo and it’s we use it for testing our core things. And we are starting to spend some more time with some of the tools which lets you do like testing in a browser core you know, running on a server, but we haven’t– we don’t have a lot of great experience to pass on about that yet. It’s still kind of in the process.

Right. And I would imagine also that just by the nature of Enyo, some of the testing you can do automated, the right information is showing up in the right elements or the right components on the page. But then, also since you are doing so much with the layout look and feel, that you are obviously you are going to need some kind of visual inspection as well.

Definitely. I mean we use tests for lot of like the core component model that we have a lot of Ajax codes underneath our internal testing so, we are kind of in the middle building on the better test suite for our own use kind of going from the core outward.

Right. That makes sense. Is there anything that we didn’t talk about that we should cover when we are talking about EnyoJS?

I would just add that we have a really great community of contributors. I mean, we started off just very close, just our own development team. But really since we released the final version 2.0 back in June, we have been getting a huge number of pool request from people and we are very open about taking contributions that are good from community. We also have a gallery on our website where, something that doesn’t necessarily go into our core code, but is still useful for other people. We have a way of highlighting that and you can go toenyojs.com/galleryand see about 60 different user contributions that we’ve accumulated so far.

If somebody wants to contribute, what the best way of doing that? Just checking out the code, looking at your tickets or bug lists and picking one or would you rather have talk to you first?

I think engaging with the first is a very good idea because we have some directions that we publish about where we are looking at. Like we are in the middle of doing a pretty significant integration with Backbone that provide something with the MVC model for the future. So, someone duplicating that MVC type work you know, probably wouldn’t have much chance of getting it accepted but if you just wanna build your own UI widget and have that exposed to other people, just go at it and talk to us in the forums. And we actually the way to add something to the gallery is submitting pool request to us updating the gallery meta data. So, it’s very easy.

OK. Cool. Was somebody else trying to jump in when I asked my question?

I was just going to say that you know, the gallery is definitely a great place to look. And then I think Ben was right to bring up the community because we are all from a sort of from the point to of view of the sense of problems we are trying to solve, we may get closer to a frameworks from —. We are actually huge admirers of the community model around jQuery. And so everything right down to sort of the Enyo architecture where you have this really small type core and then all of functionality around layout and Uis built as optional library is very much designed to encourage the community to help us built useful stuff on top of Enyo. So, we definitely want community involvement of all kinds and would love it if few years down the road, we can point to a huge and booming community of people who feel invested in Enyo as we do.

All right, terrific. Looks like we are about out of time, so I’m going to move us along to the picks. Jamison, do you wanna start us off with picks?

I can start us off for sure. I have two technical picks this week; one is a great article about MongoDB. It was on Hacker News the other day I think. And I found that most of the articles on MongoDB especially on Hacker News are just people kind of whining about it.

Like any other technology it has strengths and weaknesses. And there’s just this bandwagon that people love to jump on where they only talks about its weaknesses, but it does some things pretty well as well. And this article is called “Things I wish I knew about MongoDB a year ago”, which is this nice little performance tweak and hacks and some cool features that I didn’t know. Talks about the query profiler and theexplainfeature and some interesting things about how to use indexes correctly and stuff. So, that’s my first one.

My second one is a Gist blog post about promises by Dominic Denicola or something, but he talks about some of the purposes that—or some of the roles that promises fulfilling helping you manage async code and how lots ofpromisesimplementations don’t get them right. And I’m not super familiar withpromises, soit was really helpful for me to understand a little more about how they work and how they can help you manage async code without dealing with callbacks as much or nesting call backs as much. So, those are my picks.

Awesome. Tim what are your picks?

I’m going to pick the MK802 Android stick, because it’s really fun to hack on. And you can get the original for under $50 on Amazon.

When you say “stick”, what does that mean? Like a stick?

It looks like an oversized USB stick, except it has HDMI on the side. You just plug it in to your TV.

Oh, OK. I thought you meant like a pole or something.

No, not exactly. But yeah, it comes with Ice Cream Sandwich and you can also boot customized ROMs on there. You can boot from Ubuntu or whatever. Someone I know put webOS on there for fun but, I don’t know, it’s a fun hackable device.

Cool. Android on a stick; keep it cool so it doesn’t melt.

Yeah, it gets pretty hot.

All right. Are there any picks?

That’s all I got.

OK. Joe, what are your picks?

My first pick (which I’ve already picked before and was a little self-serving) isDomoand the reason

I’m going to pick Domo was our boss just announced this week that it’s giving everybody a

Christmas break. And so we all have from the 22ndthrough the 1stoff over Christmas, which is like 11 continuous days. Of course four of those are weekend days but, I was pretty happy to hear about that. So my wife and I are going to go someplace cool. So I’m going to pick Domo.

Is that a recruiting call?

That is a little bit of a recruiting call. But mostly, just a neener-neener that I get a Christmas break and you guys probably don’t.

[laughs] I’ll have to talk to my boss. He is kind of a jerk, but I might be able to work something out.

Your boss is a huge jerk. I don’t think he is going to be considerate of you at all. My second pick is I’m just going to re-pick what Jamison picked last week;XCOM. I bought it mostly because of what Jamison said.

(Yeah!)

And I have completely ceased all extracurricular programming activities.

Because of it. And on the same vain, when I can’t play XCOM because I’m not at my desktop or on my laptop, then, I’ve been playing this iOS game on my iPad calledKingdom Rush, which is a tower defence game but way better than any other tower defense game that I’ve ever played. Totally awesome.

And then my last pick, (which is back to programming) is the bookThe Clean Coder, which is completely awesome. The second book in saying no, made me realize the last 15 years of my life as a programmer has been completely me lying to everybody I talk to.

Liar.

Liar? My pants are on fire.

Is that where the smoke in your basement is coming from?

[laughs] I think so.

Alright. So, I’ve got a couple of picks here. The first one is Tweetbot. They just released in the Mac

App Store and I think it was released today. Yeah, today;Released October 18, 2012. Anyway, its $20 but the interface is smooth, clean and nice and it does lots of cool stuff. So anyway, I really like it and I’ll put a link to it on the show notes. It’s in the Mac App Store, like I said.

And then the other thing that I wanna pick is I just bought a whole stuff from Amazon. And the reason I bought was because I’m going to be doing a podcasting club for my son’s elementary school. And so, I just wanted to share some of the stuff that I bought. Now, I already have the Mackie 802– XENEYX 802 mixer and then I bought a new mixer. So, that’s the old mixer that I used to use on these shows. In addition, I bought—I don’t if I’d say that they are inexpensive, but they are less expensive than like the top end professional microphones. I got two of theShure SM58 microphone, about $100/piece. And then I got some Windscreens for those. I also picked up– I have an extra pair of headphones. I’ve replaced them with the ones I use now. I used some pretty nice ones, but anyway, so I picked someJVC Super-Aural Headphones. So they are over the ear headphones. You just get better sound out of those and then I picked up aGriffin iMic,which is just a USB sound card. And that way I’ll have two inputs and two outputs audio wise for my laptop when I go to do the recording and stuff. And that way, I can pipe stuff in and do some cool audio effects with the kids, maybe talk to them about how to put a soundboard in and stuff. And just make it all work, so that we can get some recording in and get them podcasting. Those are my picks. I’ll have links to all that crap from Amazon in the show notes. And then we still have the guests to do their picks. So, Ben why don’t you give us your picks?

So I have two picks; one of them is the Parrot AR Drone. I was just at JSConf EU in Berlin last week and the people were hacking on these. And basically, I saw a guy that has a Wii controller hooked up to an Arduino, hooked up to a Mac running Node, which was then controlling the AR Drone. And they basically were using that to try to get the drone to hit a big button, when pressed was going to open source project on GitHub. And after about 5 minutes of flying around, they finally hit the button; but then script at that button ran wasn’t tested and failed out. But the drone itself was very cool.

Second pick. In addition to JavaScript Jabber, one of my favorite podcasts is calledVideo Games Hotdog. And it’s done by the guys who do theKingdom of Loathingonline game. But it’s just the basically an incredibly funny look at what people are playing video games both new and retro. And it’s what I listen to when I don’t have time to actually play any video games myself.

Awesome. Alright Gray, what are your picks?

So, I have to admit to have– I just sort of was wracking my brains for picks while you guys were making yours. So they are going to come a little bit on the left field, but there’s a couple of useful Mac Apps that I’ve just started using. So we have a really active discussion area in 37signals’ Campfire room that I historically had a really hard time keeping on top of, until recently I tried this Mac App calledFlint, which has made all the difference. I’m actually able to stay on top of the camp or the discussion without ruining the rest of my day.

So, it’s super clean interface that I can look at when I at the time and all that. So, that’s been good. I also recently moved. I’ve been trying to find a good GUI Git client that I like. And having messed around with a couple, including most recently Source Tree from Atlassian, the recommendation of another team member I recently triedGitboxand so far, so good. I’m liking that super clean GUI interface for Git.

But probably, sort of the most enthusiastic person I can make is like coming from way outside the tech world unless you consider just the fact that its sits on a piece of optical media to be a technical tie, but the bottom line is I’ve really been enjoying an audiobook. It’s actually Rob Lowe’s autobiography,Stories I Only Tell My Friends. And at kind of random, my wife listen to it, loved it and I’ve never had been a particular Rob Lowe fan, but it turns out super interesting guy, super articulate and reading some super interesting stories of his life has kept me siting in my car outside the office after I have arrive the last couple of mornings. So, I highly recommend that.

Awesome. And we’ll have links to all that in the show notes as well. So, real quick, we’ll wrap this up. I don’t think there are any announcements. I just wanna remind folks that you can go to my Introduction to CoffeScript course and that’s introtocoffeescript.eventbright.com

I have an announcement.

Oh, you have an announcement? Go on.

The Node Knockout is coming out. It’s similar to the RailsRumble, where you just hack for a weekend on a project with the team. And you just compete to see who’d make the coolest thing. I don’t really enjoy the competition part; it’s more of just a get together with a bunch of people and make something awesome. I think there are still some open group spots. So, if you go to nodeknockout.com you can see more information about it. It’s the weekend of November 10thto the 12thI think. So it’s coming up soon and it could be a great way to learn more about Node and JavaScript if you wanna get team and jump on.

Awesome. Sounds terrific. Alright well, we’ll wrap this show up. Thanks for coming Ben and Gray and we will catch you all next week!

Thanks.

See ya.