Can ActionScript really be Faster Than JavaScript? - Lately in JavaScript podcast - Episode 15 - JS Classes blog

By Manuel Lemos
manuellemos.net
<email contact>

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Introduction (00:20)

Is ActionScript Really Faster than JavaScript? (2:08)

Is CoffeeScript Worth Trying? (10:06)

Underscore.js (21:37)

Impress.js Presentation framework similar to Prezi (32:20)

Latest JavaScript Objects published in JSClasses (37:35)

Upcoming articles in the JSMag magazine (54:00)

Conclusion (57:03)

Introduction (00:20)

Manuel Lemos:  Hello. Welcome to the Lately In JavaScript podcast. I'm Manuel Lemos the host of the podcast as always. Over here it's a bit raining. I hope the noise of the rain is not interfering in this podcast but...

Michael Kimsal:  What? What? Can you speak up? There's too much rain. I can't hear you.

Manuel Lemos:  I think Michael does not need an introduction anymore because...

Michael Kimsal:  Hey.

Manuel Lemos:  ...he's very famous in his...

Michael Kimsal:  In his own mind, yes.

Manuel Lemos:  ...no. In his own street.

Michael Kimsal:  Yes.

Manuel Lemos:  Hello Michael. How are you doing?

Michael Kimsal:  Well I'm famous. That's how I'm doing. I have to stay indoors because all my neighbors know my name.

Manuel Lemos:  OK.

Michael Kimsal:  Oh, goodness. Hello.

Manuel Lemos:  Well it's always great to have you in the podcast and even greater today, we have a guest. Actually a returning guest.

Michael Kimsal:  Return. Yes.

Manuel Lemos:  Zach Kessin. Hello Zach. How are you doing?

Zach Kessin:  I'm good. I'm good. Well getting over a bit of a cold, otherwise I'm good.

Manuel Lemos:  Yeah. Well you are in Israel, right?

Zach Kessin:  Yep.

Manuel Lemos:  Well you guys are facing the Winter. I don't know how is it going but over here the weather is hot because it's Summer and since and it's not raining it's a bit hard to deal with but today, we, since this is a podcast of JavaScript, we are going to move on right to the very interesting series of topics.

Michael Kimsal:  Yeah. Woohoo. Go JavaScript

Zach Kessin:  Send some of that, why don't you send some of that rain over to us we could use it.

Manuel Lemos:  Yeah. No. I can use it too because the weather becomes also pleasant when we deal with the rain but back to the podcast.

Is ActionScript Really Faster than JavaScript? (2:08)

Manuel Lemos: I would like to start with a topic that will probably give a good discussion but it's related with an article that was posted in a blog of Adobe in which one person of Adobe talked, is actually claiming that Actionscript is much better than JavaScript.

Well the main claim is since Actionscript which is the scripting language using Flash supports a strong typing unlike JavaScript, when you compile it to something executable it tends to be more efficient because it knows the types of the variables and it results in more efficient machine cover. Did you guys read about this article? What do you think?

Michael Kimsal:  Zach, as a guest, you can have the first crack at this.

Zach Kessin:  OK. I mean I just read it. As for the suite and the fact that he claimed that Actionscript is faster than JavaScript, I honestly don't know if it's true or not. And I suspect it's one of those things that there's a really big it depends and if you choose the right benchmarks either could be, you know, a lot faster.

That being said, I think that the thought that an untyped language which is always inferior to a typed language is a bit of a fallacy.

There are very strong arguments both ways. If you look at language type systems, you have everything from completely untyped, I think to a JavaScript where we can store dynamically typed and untyped which includes very powerful things like Lisp to extremely strongly type which includes very powerful things like Pascal, there's really a complete range in between.

I've seen really good code written in all of the, you can really good code or really bad code and all of the above.

Manuel Lemos:  Yeah. I think it really is not claiming merits about the language itself but rather what happens at runtime when it needs to compile to native code to where it benefit from JIT compilation and whatever.

Michael Kimsal:  I'm going to throw out a pure anecdote. This is a friend of mine who shall remain nameless. "Hello Michael." He was a, he still is I think a Java guy, by and large. He's done a lot of Java.

He'd done some Objective-C years ago and a lot of Java but a few years ago start working, he's worked at a couple of companies where he's done PHP and he had a lot of reservations about, and I think still, still has a few them like well you don't have strong type then you don't have this, it's just, it's going to be a nightmare. And after a week or so we were talking and he said I can't believe how fast it is.

Now he wasn't necessarily saying this is in all cases faster than Java but he was expecting things to be slow because he had been, he'd learned for years. Well a compiler needs to know types so that it can make things faster and yes, PHP is untyped or loosely typed, type juggling whatever you want to call it but there's so much less overhead.

There's so much less other things that are going on that it makes up for the fact that something doesn't know the types ahead of time. Pure anecdote. I don't think it's an exact one for one match but the Actionscript guy, assuming it was a guy, making this argument sort of feels like somebody that's, you know, in some ways getting left behind partially because of just the popularity of JavaScript coming out there.

And yes, there maybe a few technical merits that Actionscript is better. It's proprietary, it's closed, it's losing...

Manuel Lemos:  Right. Losing.

Michael Kimsal:  ...and it's not there. It's losing ground. And I think sometimes people that lose ground, the technologies that lose ground are not technical merits, ah, just on pure popularity stuff they get frustrated. But what can they do, hey we're faster. Look at all these benchmarks. We can do these loop five times faster than JavaScript. No one really cares.

Manuel Lemos: Exactly.

Zach Kessin:  I remember  a conversation somebody was having about, somebody was asking how should I sort a bunch of elements to be shown in an interface. And there was this complex discussion of this sort versus that sort versus asort, you know, whatever. And somebody finally asked so about how many items are we talking about? Answer about 50. And they're like, oh, just choose whatever sort of library comes with your system. On a modern computer, nobody's going to notice when you're sorting 50 items.

Michael Kimsal:  Yeah. The hit to the file system to load the library one time is going to be far more than, you know, sorting it five million times. You're going to have a bigger hit just keeping it memory management, keeping it in memory right in the execution of the sorting.

Zach Kessin:  I mean there's the famous quote, I want to say is from Uncle Bob, Robert Martin, you know...

Michael Kimsal:  Just say it.

Zach Kessin:  ...that premature optimization is the root of all evil in programming.

Manuel Lemos:  Well in this case, you're just mentioning the actual compilation to executable code which should be provided by the virtual machine engine eventually a JIT compilation and well when we are talking about speed in a browser which is, that matters for Actionscript at least, I think it may or may not be important for instance if we are dealing with animations that need to be smooth.

And I don't know if the end it will be a big advantage for the actual Actionscript code to compile to run faster or pure CPU tasks because graphics and whatever, all is I/O operations because the CPU is communicating with the graphics hardware and whatever it does in the end, I suppose it has to wait for the tasks to finish.

Michael Kimsal:  Yeah.

Manuel Lemos:  So...

Zach Kessin:  And one thing that, one thing I'm...

Manuel Lemos:  Maybe what it saved is not important.

Zach Kessin:  One thing I've noticed whenever I moved into a typed language with a few exceptions is just how verbose they seem. I mean I played with Haskell which is lovely but like in Java, you know you have to explicitly tell the type of everything if you have a variable, you know, NI=1.

Wouldn't it be nice if you could just say, well OK, clearly I is an N, you don't have to type N for it, which Haskell...

Michael Kimsal:  Oh, but you forgot to import java.lang.integer as well. You could do that. So, yeah. In Actionscript, yes. I'm going to type these. I'm going to say this is what it is and the compiler can figure this out.

The use cases where that is important for end-users is becoming fewer both with faster computers, faster hardware, improvements in JavaScript itself and rather, and I feel like Adobe's paid to themselves a quarter with Actionscript for a long time. 

They could have focused more on opening it up and say, you know what why don't you run Actionscript outside of the browser? Here's much like JavaScript's done with things like Node and Rhino.

People have been exploring how to get JavaScript out of the browser and make a broader audience for people to adopt it. And if you adopt it on the server then you're also going to want it on the client. Have we seen Actionscript on the server? Have we seen Actionscript outside of anything other than plugins, network, and certain versions of certain browsers? No we haven't.

So technologically, it may be better but politically, they have shot themselves in the foot so many times in terms of mind sharing, community adoption that I just don't see where they have to win. People don't care about tech specs.

Manuel Lemos:  Right. Well actually, it seemed like a desperate attempt to get some attention.

Michael Kimsal:  And you gave it to him right there. We just talked about him for six minutes.

Manuel Lemos:  Yeah. Right. I think that's more than enough. I think. What do you guys think? I think there are more important topics to comment and actually...

Is CoffeeScript Worth Trying? (10:06)

Manuel Lemos: And unfortunately we don't have all the time to talk extensively about everything that we'd like so we need to move on to the next topic. Actually it is something that I think Zach could actually talk more about that.

CoffeeScript is a language I should say. I'm not sure if that is accurate because I am not an expert on that area but I think Zach could explain to everybody that is listening probably is not aware of what this Coffeescript. What is it about? And what it's useful for? And what does it have to do with JavaScript?

Zach Kessin:  So Coffeescript is a little language. It compiles into JavaScript You can use it in the browser. You can use it in the JS. The compiler takes Coffeescript in and spits JavaScript out and you can actually, in the browser you can even load it directly into the browser although they don't recommend doing that for production work. If you just want to play around and test it, it works quite nicely.

The nice thing about JavaScript is or about Coffeescript is it includes a couple of nice features that JavaScript doesn't have and it keeps you away from the really ugly bits of JavaScript. I love JavaScript it's great language but if you've ever read Doug Crockford's JavaScript the Good Parts, and if you haven't you should, you know, he lists some really dumb design mistakes in the language like the fact if you don't stick var into a variable may make it global which I think we can agree was a really bad idea. 

And so in Coffeescript that's not a problem. If there is no var statement, it just automatically inserts vars wherever it needs to. So you just say X=1 and it sticks the var in for you at the top of function all that. It has a couple other really nice things that it can do. So for example it, if the function, in JavaScript we tend to define a lot of little itty bitty functions.

The function keyword is, instead of having the word function you just have an arrow dash -> so you can just say, by the way if you haven't done so you should go to coffeescript.org and look it up it'll show you.

So that you can define functions very easily. You can also use what's called the fat arrow where you use => to define a function which does the exact same thing except for it binds the outer this to inner this, so that if you ever had that bug where the this that the inner function is not the same as the outer function and you want to just sort of bang against the wall, solves that problem.

It has splats so if you have a parameter, a function usually takes two or more parameters. You can do parameter one comma parameter two dot dot dot and it'll just shove everything into second parameter.

Basically doing slice of the parameter but it just sort of hides that for you. It also has var comprehension. So like take an example here math.cube num for num in list where it just takes those numbers cubes it, similar to math should I say map it also has some other really cool features in it.

Manuel Lemos:  Right. So from the point of view of those that are used to develop in JavaScript what do you think are the main advantages at using Coffeescript?

Zach Kessin:  It's a little more concise. It has nice other features that you just can't do easily in Ja-- I mean you can but it's just, in JavaScript where you can just do things like you can say if X is, if you have like an array and you want to see if X is in an array you can just say X in list and it works.

Also that this keyword is alias to the @ sign in Coffeescript so you can just say at if you're typing this a lot. The really thing I think that really gets you though and there are a couple of nice little things that you can uhm... There's the question mark operate which helps you just see if a property exists or you know, you a problem of...

Michael Kimsal:  Nulls

Zach Kessin:  ...X dot Y dot Z and Y is null and blah, blah, blah and absent using something like Monad which let's talk about some other time. 

It's a really nice way, you follow sort of destructuring environment where you have basically (A, B) = (B, A) and switch two variables around or like that.

Michael Kimsal:  Wow. Let me ask you a couple of things here because I've been aware of Coffeescript for a bit and I think, well I haven't used it on any projects myself. I did a little, at one point I think I got a "hello world" running or something but I've not incorporated it into anything mostly because that most of the projects that I work on are not green field.

I'm inheriting something else and most of my time is just spent figuring out how that stuff works rather than refactoring to use things like Coffeescript but I'm wondering and I googled around for this and I saw a little bit but I'm wondering what the current tooling support is?

Because, one of the things we've seen in the last three or four years things like Aptana coming out and making really making JavaScript and the concept of understanding JavaScript third party libraries a first class citizen in the modern IDE and I realized full stack IDE's aren't for everybody but Aptana I think really gave people a view of wow I can have auto complete for JavaScript that I can have to understand it.

Do you see some of the same attention being given to Coffeescript in the tooling market? Or is it maybe a little premature for that?

Zach Kessin:  I'm not really the right guy to ask because I hate IDE's.

Michael Kimsal:  Oh I get it. They're not for everybody. I did see some reference to support in text mate for example.

Zach Kessin:  There is very good Coffeescript support in both Emacs and VI. I'm a text editor kind of guy. By the way another really useful case for the Coffeescript, if you ever sink in to the file of compressed illegible or, you know, how am I going to read that JavaScript? There is a JavaScript there's a Coffeescript compiler on the web. Google for it, you'll find it.

Cut and paste the JavaScript in there it will convert it to Coffeescript to which it will be at least somewhat more legible than the JavaScript was.

Michael Kimsal:  Interesting. Almost like a JavaScript beautifier but it takes it one more step.

Zach Kessin:  Right. By the way it's also useful for if you're trying to figure out, I know how to do this in JavaScript how do I do it in Coffeescript? You write five lines in JavaScript cut and paste it and it'll translate for you.

Really if you're experienced with JavaScript then you're familiar with JavaScript then you should take about a day to learn Coffeescript because with a few exceptions, try Catch's work a little bit differently. 

It's really just the thing, the other thing you have to know about Coffeescript is it takes a lot of heritage from functional languages like say Haskell or Erlang or a Lisp. So in Coffeescript every function returns a value, so unlike JavaScript where by default things just returned undefined. In Coffeescript every function does return a value of simply the last thing you used.

Michael Kimsal:  Interesting.

Manuel Lemos:  Yeah.

Zach Kessin:  So again similar to say a Haskell or a Lisp where any of a number of functional languages that had done this for well Lisp for 50 years so it's not like it's a radical new concept.

Manuel Lemos:  So from the point of view of those that are listening who are not aware about Coffeescript, do you guys think it is, it would be worth studying Coffeescript and trying to use it to get some benefits or probably not worth the time because it's yet another thing to learn and in the end probably is not a great production increase. What do you guys think?

Zach Kessin:  Well I did use it for two green filed projects at a previous job and it both cases I thought it was a real good choice. There are some other things it features like you can do pure docs like you could in say Perl or PHP where you have a multiline string of various forms. 

Also a string interpolation whereas if you can, like in Perl where you can put them over a double quoted string, $foo, and it'll pop the value of that into the string. You can do that when you got Coffeescript as well which is always one of those things I felt was missing in JavaScript

Michael Kimsal:  Uhmm.

Zach Kessin:  So...

Manuel Lemos:  What is the verdict?

Michael Kimsal:  My verdict well...

Manuel Lemos:  Thumbs up or thumbs down?

Michael Kimsal:  I think Zach's verdict is probably going to be thumbs up, mine would be and I don't want to put up in your thumb there but mine would be a cautious yes especially for new projects if you have.

Because we all have loads of time on projects but if you have a project that you're not starting yet and you figured that it's going to be rather computationally intense in JavaScript, I think you owe it yourself to investigate multiple tools whether it's in front of libraries or whether it's something that's a bit more abstract like Coffeescript that will give you the power to be more concise and more expressive.

And I say this to somebody, I've done a lot of Groovy over the years and I would recommend that, performance issues aside for remember with Groovy, there's power in being able to write something that's less concise but gets the idea across.

And even if it takes you a little bit more time, if this buys you a lot of maintainable code over the next two or three years, looking at some of the things you can do in Coffeescript and two lines in Coffeescript that end up being five or six lines in JavaScript then multiply that by a thousand, you're going to have much more maintainable code. So it might be...

Manuel Lemos:  Right. So your verdict is maybe?

Michael Kimsal:  Yeah. It would be a you should investigate more and you should not rule it out just because it's something new, which I think some people tend to do.

Manuel Lemos:  So if somebody does not have the time, should invest or maybe give it some time later when are more free?

Michael Kimsal:  It all comes out of your personal schedule I think if you got some time now, I mean well it comes really this is a professionalism standpoint. You should always do investigating, spend some of your time investigating and learning new things that make your job not just up to date with the latest buzz words but that make you more productive and make you more valuable.

Coffeescript may not be it three years from now maybe something else would come along but if you can demonstrate, you know, that you learned this you get value out of it, you provide value for the people and for your clients or for your employer I think it's generally a good thing to do.

So generally yes on Coffeescript unless you have some major reason to not do it. Existing projects you have to refactor a lot would be a big reason not to.

Zach Kessin:  The other thing I would point out is that Brendan Eich who created JavaScript in the first place is apparently a big fan of Coffeescript.

The one down part, the one negative for that should in case it's take for full disclosure is if you have to debug it it's a little bit harder but I've been told things are getting better on the front, in that you end up having to, you know if you are stepping through a code in FireBug or something, you have to sort of go from the Coffeescript to the compiled JavaScript and look at that and figure out what's going on there. 

It's actually not nearly as big a pain in the neck as you think it is because basically it's a very one-to-one translation so if you're already familiar with JavaScript doing with compiled JavaScript you know what's going on. But it's, I think it's still a net win, I really do.

Manuel Lemos: OK. I see all listeners probably, that did not know about Coffeescript the probably will figure if they have time to invest on something that maybe more productive in some cases and then they will decide.

Underscore.js (21:37)

Manuel Lemos: OK. Let's move on now with the podcast and then I think Michael was willing to talk a bit about underscore.

Michael Kimsal:  Well I wanted to bring this up in the context of a recent presentation and Zach you may be able to talk a bit more about the technical stuff of underscore but I wanted to keep this brief and maybe explore it in the future.

There's a guy named Kris Jordan @krisjordan on Twitter and dot com and all that, gave a presentation to our JavaScript user group the other day about functional programming with JavaScript and writing a, how to write an SQL DSL a domain specific language using functional programming concepts in JavaScript and using the underscore JavaScript library.

That was my first exposure to underscore though I've had some exposure to functional programming in general. It was a very eye opening experience for me to watch somebody who's really good at JavaScript take some basic concepts and refactor them into something more functional and we ended up, in about 20 minutes or so, he ended up with a rather expressive DSL for doing SQL-like functionality.

So here's a list of players, he had basketball players and he was able to do things like select from this list where this condition and that condition or this condition. There was nested predicates. I'm getting a little too deep probably than I wanted to go but he was able to do this with thoughtful functional programming and a lot of extra functionality that the underscore JS library provided.

Underscore provides, Zach, he maybe able to give a bit more mechanics about this but it provides a lot of methods or functionality that are available in some other functional languages but aren't built in to JavaScript. Things like mapping and filtering and so on.

Did I do it a decent job of what underscore is? There's probably more to it than that. What's your experience or feelings with that?

Zach Kessin:  Actually in one of those green field projects I used the Coffeescript, I also used underscore and was quite happy with it. First of all, actually map and filter are actually, at least in recent browsers, part of the JavaScript array prototype object.

So you can, if you're using recent browsers IE, not IE7 just do that. That being said, I love underscore because it does give you a nice functional thing.

I'm a huge proponent of functional programming. If you look at my code I've written in JavaScript or Coffeescript, you'll often see basically I take an array and then basically just do some map, map or map, filter, filter, map, filter whatever where each of those predicates in there is usually a one line function.

And actually in underscore case, in some cases you don't even need a function you can just say, you know, for example if you have a list of objects just for nomenclature statement, if I say a list in this case I'm assuming that it's a homogeneous list where you have an array of they're all the same type whereas array I'm not making, so just sort of a mental model.

Suppose you have a list of airports, right? And you'll have, I had a code so you know, for Ben Gurion Airport, you'd have TLV and the location will be, country would be Israel and then maybe you have some information about the runways and a bunch of other stuff and then you have lots of other reports.

So you know you have one with Heathrow and you just want to pull out those airport codes right? Just that one field, there's a function there called pick or pluck, it's called pluck where you can just say the field name and it'll just takes one list and just boom it turns to a new list of just that field.

Or a more general case is you can do a map where basically, if you ever played with Haskell, Haskell has this wonderful notation for types which I've been adopting into JavaScript because I'm just kind of strange that way, but basically map, ut just takes a list of one type of function that takes type A to type B and returns to a list of a different type.

So you have these map, filter, reject, reduce, which basically lets you do fun things that basically takes it all down to one value. You can take it away and I don't know, think you can find the average and the standard deviation but reduced pretty quickly. If that's something you, that's something you need to do.

But it's just this wonderful thing and you end up with this code which is very, very declarative. JQuery there's some more things naturally, the reason is they both sort of revert to being more or less Monads and mathematically but that is a topic for another day but...

Michael Kimsal:  Well you're bringing...

Zach Kessin:  ...but yeah.

Michael Kimsal:  ...you're actually highlighting the point of discussion that came up in our meeting the other day as he was demonstrating some code.

Someone said well you're doing premature optimization and there was a bit of a discussion about that like well if you're just pulling this out and pulling this out and putting all these stuff around it. You know, this is actually making the code bigger than it might have been had you just gone with a more, let me just squish everything together like you would normally do in JavaScript 

And there were a few of us that were saying, no, no, no, no, no, shut up this is better. Yes you end up in some cases, you end up writing a little bit more code not always. And I think as you hit a point where as the project will get larger, I think, certainly with something underscore you used in the proper hands, your code would be dramatically less that might otherwise have been.

But there's initially you're actually making, writing more code than you might need to to separate things out but the code what we ended up seeing Kris do, it was eminently more readable and maintainable not just for him but for somebody else.

I can imagine somebody else coming into that project a few weeks later who'd never seen it before, it's far more understandable than the typical, I'm going to pick on JQuery because he's the most popular, the typical JQuery on click do this and I'm going to nest a bunch of functions together in one thing and chained them together.

The thinking that using something you underscore sort of forces you to do I think for a lot of people would be painful upfront but once you hit that you're going to be able to give yourself and your clients and your employer much more maintainable code over the long haul. That's a kick of mine lately because I'm taking over code that is not very maintainable and...

Zach Kessin:  I mean one thing I've noticed since I started using underscore, first of all by the way in addition to underscore is also a backbone.js which inherits from it which adds in a whole bunch of data handling and restful data loading and models and stuff like that.

And if you've learned underscore, loading backbone is really trivial but that's a side point. One thing I've discovered since I started doing that, I never write loops anymore and I'd barely ever even bring an if statement.

I can't think for, the last time I actually had to think about I had to write a loop is just I always go with a map. You know, I like higher order functions. They're very nice abstractions. I just say, OK. I have list A I want list B how do I take one element of A to B? What do I need to fill? Which ones do I need to reject? Which ones do I need to keep in? And write it down to a couple of steps. It tends to be as I said map, filter, map, map, filter.

And each of those is one line of, you know, each of those map and filter functions tend to be one or two lines quote and if you set up, put them in line you've put them in sort of a global namespace just to keep them external, they also become trivially easy to test. Because there's only so much that can go wrong in a two-line function.

Michael Kimsal:  Yup. Well that was a whole other kind of subtopic that came too is by separating these things out. It certainly not just JavaScript by making smaller units of functionality in any language they become easier to test independently with each other.

So I mean it really, it's not a new concept but I think for people that have done copy and paste JQuery for a long time, these are somewhat new concepts. And we'll get back to the maturing and the professionalization of JavaScript as a front-end or as a technology in general, that's still slowly maturing and I think it will continue for several years.

Zach Kessin:  Yeah I expect... And the truth is JQuery also has as much as the same advantage if you actually use it well.

Michael Kimsal:  But, but, you know, I could say the same thing about PHP. But most people don't use it well because we've had a decade of copy and paste culture. Let me search for something in Google, this function does this, copy and paste it there you go. And it's been an advantage, I've said before JQuery's the PHP of the front end. I say it.. but I say it.

Zach Kessin:  I think that's kind of a, I mean the thing about both JQuery and underscore that I love, OK, so this idea came out on Haskell, by the way it seems like all the really interesting ideas these days are coming out of Haskell, of what you call the Monad. I'm actually writing a short ebook for O'Reilly on Monad, it should be out eventually, that basically it's this wonderfully, it's sort of a programmable control structure it's the best way I can describe it where basically once you start running code Monads, you have basically a data and your functions just become this wonderful abstract algebra where you going to write down an algebra of your functions and things like your SQL parts are just kind of pop out.

Michael Kimsal:  It did happen but at the moment I'm still happy to watch other people do it and learn from them. I was never good at math either. So...

Zach Kessin:  I'm actually giving a talk on this, probably before this is actually put on the net but on next Sunday at Tel Aviv JavaScript meetup we'll talk it up.

Manuel Lemos:  OK. We'll be there.

Zach Kessin:  Come by I'll buy you a falafel.

Michael Kimsal:  That's sweet.

Manuel Lemos:  And I can learn what that is.

Michael Kimsal:  Speaking of falafel...

Zach Kessin:  It's ah, falafel is Israel's national food. It's a fried chickpea thing. It's truly amazing and it's become almost an item of religion here.

Manuel Lemos:  Yeah. I bet that would give a whole topic for the podcast although we already not talking about JavaScript.

Michael Kimsal:  I can't imagine a topic of religion, you know, something of religion happening in Israel. That's kind of pointing to me.

Zach Kessin:  Yeah.

Manuel Lemos:  Related to a JavaScript I'm afraid not.

Zach Kessin:  We should be so lucky. That would be saner than what happens here, don't get me started.

Michael Kimsal:  On that bombshell. I'm good at, OK, yes I'm going there. I went there. Let's reign this in and move on, Manuel I think has some time concerns that he's late for another...

Impress.js Presentation framework similar to Prezi (32:20)

Manuel Lemos:  Yeah. Well actually we all have. I'm sure that's a topic of underscore and Haskell and Monads are all give good topics. Maybe in another episode we can get back to that but we are running to the end of the podcast and I still like briefly mention a topic that probably is not really, really important but it relates to the start topic of this podcast.

It's about impress.js, which is basically a presentation framework. It uses many of the possibilities of CSS3 transforms and transitions and stuff to implement animations like Prezi. I think everybody knows Prezi, right?

Michael Kimsal:  Yes.

Zach Kessin:  I think so. I looked to the impress.js. I mean it gives like a slideshow but does like all sorts of cool zooming and panning and these cinematic.

Manuel Lemos:  Well it seems to be, well at least attempts to do the same as Prezi. Prezi is available at Prezi.com but it is all implemented in Flash. And the impress.js is an attempt to do similar effects using JavaScript on the CSS 3. And did you guys try any of the demo animations? Presentations actually.

Zach Kessin:  I did and it was gorgeous. Unfortunately it was like...

Manuel Lemos:  Was it smooth for you?

Zach Kessin:  It was very smooth. Unfortunately what wasn't smooth was trying to write my own because basically their documentation consists of the words read the source code.

And it's like, I was using the X.JS library for a while with little bunch of stuff for like several years in fact and one thing I will say about X.JS, their docs are amazing. The documentation is fabulous and read the source code as documentation, if that's your documentation that's a pretty good way to make sure I'm not going to use your product. Honestly I don't. Show me how to use it, give me some examples and then give me a walk through and...

Manuel Lemos:  Well the point I wanted to bring is that at least in my machine problems because it's a bit slow, old, and the animation did not run as smooth as the Prezi animations on the same hardware. So maybe there is plenty of room for optimization in impress.js.

But I wonder how much of that lack of smoothness of this impress.js animations are due to that claim of the Adobe guy that compiled Actionscript which is what runs on Flash will eventually run faster and would it make any difference in the smoothness of the animations? Well I don't know it's just supposition.

Zach Kessin:  Honestly, Manuel I suspect the answer is almost none because his major claim was that JavaScript is an untyped language is inherently slower than, or it can't be optimized as well as Flash just typed but most CSS transforms are not really happening in JavaScript they're happening in data browser code.

Google has a tool and I don't remember what it's called that you can actually see what percentage of your site going slow was due to what?

And you know, for example in JavaScript every time you're going to make a clall into the DOM to manipulate something on the screen you pass out of JavaScript into the native code written in C++ or what have you of the browser. So if that code is running slowly, it doesn't, JavaScript doesn't matter.

Manuel Lemos:  Right. It's true. Could it be a problem with the browser? Implementation of CSS. I'm running chrome here.

Zach Kessin:  Could be. I don't know. I mean it's an interesting question. The question how do you optimize fancy graphics in web browser's probably something that we could do an entire series of shows on although probably I'm not the expert on that by any means. So...

Manuel Lemos:  Well I think probably it's just because the implementations of CSS 3 animations and transitions and so on is probably not as mature as whatever are the resources that are used in Flash movies and stuff.

And I agree with you that all this is probably not due to any additions as of compilation efficiency of the virtual machines.

Zach Kessin:  I mean I suspect there are some of that in there but I think at best a very small second order effect. I think the native renderings and CSS renderings, I think that one reason it's much more important.

Manuel Lemos:  Well I think we probably have to wait a little more for CSS 3 to be more mature in terms of implementations in the browser.

Latest JavaScript Objects published in JSClasses (37:35)

But moving on with the podcast now we're going to move to one of the final sections the one which we mention briefly about a few classes, objects of JavaScript that should be in the JS Classes site and this time we seem to notice an increase in the number of objects that were published in the end of last month.

And this is probably already a consequence of one feature of the site that was introduced in December which is basically a report that goes to the email of each author that tells them what they are doing in terms of users that are using their objects, classes and what they can do to improve their rankings because the site computes rankings comparing for instance the number of users that have used each class and sums all the users of different classes for the same author so you can see how each is ranking.

This newsletter, actually a report gives suggestions like encouraging the authors to send more interesting objects and this month we have quite a few more than the average.

And what do you guys think were the most important? Zach would you like to start?

Zach Kessin:  Sure. I mean I've been kind of out of, since last month I've mostly been and not coding so I kind of just sort of threw some things here.

The jQuery PhotoWall here that somebody, that Andrei I'm going to try to pass his last name, he's from the Ukraine, to put looks like it'd be really useful for the circumstances. If you need to integrate a photo wall into your app and it's only not a crazy thing to want to implement, then it looks like it would do a nice job. And I have an ugly code here...

Manuel Lemos:  Actually in the end of the fact is probably what method is most, I think it's similar to the way Google presents Google image results.

Zach Kessin:  Probably.

Manuel Lemos:  It's the different pictures of different sizes is all tiled.

Zach Kessin:  One word of warning folks don't open up the sample screen shot in the office it is rather not safe for work. Of these sample images there are at least two women not wearing much clothing or at least none at all really.

Manuel Lemos:  Maybe it was marketing stunt from the author.

Michael Kimsal:  Can you send me that link? I just want to add it to my blocker so that I don't go there. I'm just saying if you send it to me.

Zach Kessin:  Sure.

Manuel Lemos:  We are in 21st century. It's not that shocking.

Michael Kimsal:  Oh no I'm just saying I want to block it though. So you know, I want to add it to my blocker.

Zach Kessin:  Look I mean I'm just bringing it up because some places are more conservative than others and depending on the office you work in, if you suddenly bring up a picture of a woman's unclothed to the chest you might piss some people off, just saying.

Manuel Lemos:  Yeah. Well now that you mentioned it everybody wants to see it.

Zach Kessin:  So yeah, so Andrei if you now suddenly get 200 hits you can blame me.

Manuel Lemos:  Actually there is, in the forum for these packages, all package published in js quasi site have a forum for the users to comment about, ask questions and inclusively post package ratings what they think in terms of different tasks or utility consistence, documentation, examples and so on.

And there's also a guy that comment, did not write the class at all and just comment the pictures seem obscene because they contain nudity and well...

Zach Kessin:  I wouldn't call them obscene but possibly inappropriate will be I think more accurate. But on something more interesting or at least more relevant.

Manuel Lemos:  I need to watch out for that because Google may punish the site, they might consider not good for safe search.

Zach Kessin:  Oh there's that too. Also the fact that corporate firewalls will give you prompt.

Manuel Lemos:  But what did matter is that the object is useful but other than that what are the class would you like to mention? I think we have a little more time for you to comment on one another.

Zach Kessin:  The Image in movement class here was written by Michael somebody, I cannot, his last name I'm not sure how to pronounce but he's in Italy.

Manuel Lemos:  You may try.

Zach Kessin:  It was really use-- what?

Manuel Lemos:  You may try to pronounce the name. We always try. It could be Michelli Prigigalo.

Zach Kessin:  Prigigaio yeah.

Michael Kimsal: Michaelli Prigigalo.

Zach Kessin:  Yeah.

Manuel Lemos:  OK.

Michael Kimsal:  It's pronounced just like it's written.

Manuel Lemos:  It's so odd that we even forget to tell what you're going to say about the object itself.

Zach Kessin:  Well it lets you move something down around inside of a ah...

Manuel Lemos:  A container.

Zach Kessin:  ...container. Unlike the sort of small does one thing hopefully does it pretty well JQuery plugins that they don't try to solve every problem, they just solved, you know one specific problem that you know if you need to do that...

Manuel Lemos:  Just use the plugin.

Zach Kessin:  You know, it'll do it or if not no big deal. You know it also has advantage that if you're only trying to solve one problem, you can try eight things at one point, if I only need one of them well the other seven just kind of ride along as baggage.

Well so this kind of thing, if you need it it's useful. I don't quite know why everybody feels the need to include a copy of JQuery with JQuery plugin I mean really.

Manuel Lemos:  Yeah. Well that's something that we already commented before. Sometimes jQuery is not needed at all but people seems to got used to work with JQuery everywhere that now they can't get rid of it when it's not needed.

Zach Kessin:  No I'm not saying it's not needed I'm just saying you don't actually have to include a copy of JQuery itself in the package, you know.

Manuel Lemos:  Oh yeah right.

Zach Kessin:  If I'm already using JQuery I've already got a copy of it. I don't need to...

Manuel Lemos:  Well sometimes it's useful because some users do not quite realize that when they really need to have JQuery they don't have it there.

Zach Kessin:  I'll give you that.

Manuel Lemos:  But I agree with you it's really not needed but it's a criteria of the author but also talking about that I think it would be fair to mention also the Scroll Content package which is also a JQuery plugin that does I think it's almost practically the same.

Basically to have for instance of you have an image or actually it could be something else displayed in a page and for some reason you don't have a browser area large enough to display it  completely, it renders it inside the container.

And then you can scroll it either with keys or using your mouse to drag the visible area and this other plugin was actually I've noticed it's from the same author I just did not realized what would be the difference.

And anyway Michael, what would be the other object you would like to comment.

Michael Kimsal:  Well there were a couple that jumped out of me this month. One specifically to kind of tie in with the talk I was talking about before, the underscore talk where Kris Jordan was doing SQL DSL.

This month Tom Schafer from Germany put together an SQL database manager SQLite. It's not a full GUI but he's created a library that lets you manipulate a SQLite database directly in JavaScript

Manuel Lemos:  Right.

Michael Kimsal:  And it's, I was trying to compare the way it was done with the way Kris did his and certainly this is not as, he's not using underscore. It's not as clean as what I saw Kris do but it's also not as, Kris's was not as full featured.

I think he could've eventually got to that point but this one that Tom's put together has more. It manages joins and things like that as well too. So it's got more meat to it.

And actually we wrote a couple, I wrote to Tom saying, well I have a couple of questions. I haven't heard anything back from him but that's, because I only wrote a couple of hours ago. Imagine in Germany they're already in bed or I'll be out at the pub or something so. 

But I was impressed with that, anybody doing SQL stuff trying to put a JavaScript front end or JavaScript layer on top of SQL stuff, it's always an ambitious goal I think and I thought Tom pulled it off. At least what's there so far, I think he pulled it off pretty well. The other one, oh go ahead. You want to comment on that something?

Manuel Lemos:  No not really.

Michael Kimsal:  Or you want to talk about it too?

Zach Kessin:  I actually had a question. Was this he's trying to do, use the in-browser SQL lite, that's part of HTML5?

Michael Kimsal:  That's what it seems to me to be. It doesn't seem that he's using an external SQLite database. It looks like he's using the built-in.

Zach Kessin:  Because the problem is that that SQLite in the browser is more or less going away.

Manuel Lemos:  Right.

Zach Kessin:  The various working groups is, it's five working groups have more or less abandoned it in favor of indexed DB for a variety of technical reasons.

Michael Kimsal:  Not to that extent though. What he's created as an abstraction layer could probably be refactored some as actually what he's got is there's a sequel thing and there's a DB and then there's a separate adapter that is specific to SQLite. So...

Manuel Lemos:  Right. It's more an abstraction layer.

Michael Kimsal:  Yeah. So I think it could be modified. It maybe as simple as dropping in an index DB adapter at some point at least that's the impression that I got. I mean I haven't studied every single line of code with this but it's, the minified version is like 12K the core of the JavaScript is 37K and the adapter itself is not very, SQLite adapter is not very big so... 

There's a lot of abstraction stuff and then a SQLite adapter. I imagine that there maybe another adapter in the future which I foresee.

I'll just jump over the one other library I want to mention by the class is, our friend Arturs Sosins. Hello Arturs. And this is, I haven't had a chance to use it directly but I wanted to call this out just because I like the direction that he's going and this is an object that is specific for Titanium apps and I don't think we've seen enough of, most of the JavaScript classes that we've seen so far have been things to do with browsers or...

Manuel Lemos:  It wasn't the first one.

Zach Kessin:  What's Titanium?

Michael Kimsal:  OK. Titanium is a tool kit from Appcelerator. The company's called Appcelerator.

It's a tool kit that let's you write JavaScript They provide some JavaScript APIs that will let you tie in to specific hardware of iPhone and Android are the two that I know. I think they support BlackBerry now too. So the idea is you can write JavaScript, CSS, HTML apps that will get compiled down into native iPhone, native iPad, native Android, native BlackBerry apps.

Manuel Lemos:  And desktop right?

Michael Kimsal:  Now there's a separate, you can do that but there's a separate aspect. They almost a separate SDK if you're targeting desktops and some of the things that are available for ah... Because actually the other thing you can do with desktops is you can also bundle in PHP, Python or Ruby interpreters.

So you can PHP code with JavaScript and make a native desktop app. You can't bundle that with Titanium if you're targeting mobile devices. And I've used Titanium, I used Titanium about a year and a-half ago for a project and I have a friend that was for a while, I don't know if he's still doing it but he was a mobile app development shop and they were just chunking out mobile apps.

You know here's an IOS, here's some Android version and he's been using Titanium for a lot of that because if you're not doing anything too specific if you're not doing anything that is just specific to iOS, Titanium provides a nice common, what's the right form to say...

Manuel Lemos:  Abstraction?

Michael Kimsal:  ...common, yeah common abstractions. You could use the compass in Android. You can use the compass with that, you just call the Titanium compass stuff. So they compile all the native apps.

Now what Arturs has done is he created a sort of a nice little animation or an object that provides some animation at the background if you do it with Titanium app.

Manuel Lemos:  Yeah.

Michael Kimsal:  It's nothing, in and of itself it's not all that exciting, no offense Arturs, but for me it was exciting to see somebody doing Titanium stuff and with the recent announcement of HP's from the Touchpad that they are open sourcing their Enyo.js they started it, it's not going to be fully open source until September so I think we got some time before we delve into that as a topic too much, but I'd like to see people contributing JavaScript objects that target Enyo or maybe PhoneGap or Titanium or Node or things like that too.

Manuel Lemos:  Right.

Michael Kimsal:  Expand out our understanding of JavaScript classes not just for browsers but for server site and mobile devices too.

Manuel Lemos:  Yeah. We got a few components not specifically for browser applications but there are not many and these were actually the first for Titanium?

Michael Kimsal:  Titanium, yeah.

Manuel Lemos:  Just a reminder for whoever who is listening that would like to submit components for those other known browser platforms to feel free go ahead.

Michael Kimsal:  And I don't mean to interrupt, I'll throw out something else that I'd like that Arturs did because not everybody necessarily has the Titanium SDK already set up. He made a l little YouTube video of this is what it looks like.

This is what the Titanium development environment looks like and here's what this object looks like running inside of that. So you can get an idea, people or Titanium developers, they are already going to understand it they'll grab it. but if you're not a Titanium developer you can get an idea what it does.

And still study the code. I would encourage more people to get into Titanium even if you're not planning on doing a lot of mobile stuff right now. If you ever think you need to do mobile stuff, it's a great way of leveraging your JavaScript skills and targeting multiple devices.

Zach Kessin:  PhoneGap would actually give you some of that as well.

Michael Kimsal:  Oh yeah. They're different approaches and actually we talked about PhoneGap last month a bit because the company Tura has released their Mulberry platform which is sort of like rails for PhoneGap effectively and they just came out with version .3 last week and they're doing more of that so I may want to revisit in a little bit too but I like these abstraction layers that let you target mobile devices without having to write native code for every platform. Enough said. Manuel move on.

Manuel Lemos:  Well I will just like to conclude this section to comment on now another object. Again from Michaelli Prigigalo, I hope I'm making it good try to spell his name.

And basically this object is yet another JQuery plugin that actually does something that can be useful for many applications although many browsers support something like that for instance for textarea inputs to have a sort of a holder element that allows you to drag and resize the area of the element on the page.

But in this case you can use it for any other types of elements not just textareas and I think this can be useful for many purposes I have been thinking about and the other users who also I'm sure they will find it useful. But anyway this concludes the section about the latest fast published in the JS Classes site.

Upcoming articles in the JSMag magazine (54:00)

Manuel Lemos: Now we are going to just move to a final section. I hope it's not soon, Michael do you have already the upcoming list of articles for the JSMag magazine?

Michael Kimsal:  We got some. There's going to be some last minute changes. We've had some I think probably due to the holidays and beginning of the year we've had some cancellations but Mike Schwartz has been really for the past few months has been writing a