Can JavaScript Totally Replace Flash Now? - Lately in JavaScript podcast - Episode 13 - 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)

Interview with Dino Gambone (0:55)

Can JavaScript Totally Replace Flash Now? (16:27)

Google can Execute JavaScript on crawled Web Pages (31:45)

JavaScript code coverage with ScriptCover extension (35:57)

Animation Timeline Editing with Timeline.js (39:48)

Importing JavaScript packages into JSClasses site from Git repositories (44:25)

Latest Objects Published in the JSClasses site (47:24)

Articles in the latest issue of JSMag magazine (54:55)

Conclusion (56:36)

Introduction (00:20)

Manuel Lemos: Hello, welcome to the Lately in JavaScript Podcast. I am Manuel Lemos, always the host of this show, and also always I have here with me Michael Kimsal also for this episode which is number 13.

Michael Kimsal: (Howls) Good morning.

Manuel Lemos: New special effects.

Michael Kimsal: That was my sound board. Good morning.

Manuel Lemos: How are you doing? I suppose you are quite fine.

Michael Kimsal: I'm doing excellent.

Interview with Dino Gambone (0:55)

Manuel Lemos: That's what I can see. Well, today we have a guest on the show, Dino Gambone, and he also is a contributor of the JS Classes site as well as JSMag magazine, hello Dino, how are you doing?

Dino Gambone: Hello, everyone, a pleasure to be with you guys today.

Michael Kimsal: So, Dino, where are you coming in from, where are you based?

Dino Gambone: I am located outside of Philadelphia, Pennsylvania, in a nice little suburb area north of Philadelphia.

I am currently a manager of web development services for the company I work for which basically what my team does with both revenue and high-visibility web app for our clients, so when they have something that needs to be really cool, a big complex problem for other people to solve then you can come to my team and with a lot of JavaScript, HTML and some ASP.NET we usually hit it out of the park.

Michael Kimsal: And what are you wearing?

Dino Gambone: A work outfit, so I'm wearing a dress shirt and pants.

Michael Kimsal: Okay, there you go, you got it right from the horse's mouth. So, Manuel, it's your turn to ask a question.

Manuel Lemos: Yeah, that was a quite relevant question.

Michael Kimsal: It's all in how you say it because I could have said, hey Dino, what are you wearing, (purring).

Manuel Lemos: I'm glad you didn't.

Michael Kimsal: Okay, so back to you, Manuel.

Manuel Lemos: Well, Dino, you have been as I mentioned a contributor, actually you just started being a contributor of the JS Classes site and wrote some articles to the JSMag magazine.

Dino Gambone: Which I just happened to find listening to Lately in JavaScript.

Michael Kimsal: Awesome.

Manuel Lemos: Yeah, and what I was wondering if you could comment a bit more about what you do related to the JavaScript world that motivates you to also write these classes and articles that you are putting out.

Dino Gambone: Well, like I mentioned, I am the manager of web development, so most of the work we do is web based, so it's usually either web services or web sites. When it comes to web sites it's really heavy HTML5 or HTML and JavaScript, jQuery, AJAX, anything that we can really offload onto the client.

Basically we moved to a model that put as much work on the client, distribute as much of the workload to the client as possible using AJAX just to get the data back and forth.

So while their web apps are very JavaScript heavy just because the amount of power JavaScript's got, with the emergence of Chrome and Firefox really pushing the envelope on JavaScript's speed, and IE finally getting off their butts and kind of picking it up a little bit, they're still a mess but at least they're moving in the right direction.

And then you've got the iPad and iPhone which with the iOS Safari browser is actually a really nice platform for web development, so everything we do we're really targeting HTML and JavaScript front-end, that's vast majority of the work that goes in our projects is on that front end.

As far as what drives me to do what I do with Michael and actually started writing a blog, it's my passion, I love writing code, I've been doing web development for over 15 years, that means I've written websites for Netscape4 and IE3 when I first started out and that's what we're dealing with.

And unfortunately back then we didn't really have as much compatibility between the browsers as we do now which is a little scared when you think about it, so it's always something I've really just loved doing.

I've always told the higher-ups in the company if you give me a project and you ask me which is the better approach, the best top of web for developing a project I'm going to tell you nine times out of ten it's going to be a web site because there's absolutely very little that I can't do on a web application using both HTML and JavaScript that I could do on a desktop, and really with HTML5 I think that's almost gone down to nothing.

Michael Kimsal: That certainly has changed. I think those of us who have been in the web world have always liked web apps, you'd like to say well the Web is always the best choice because it's distributed, because of centralized security, whatever it may be, but there's always been a lot of things that you couldn't easily do, even things like drag and drop file upload.

Dino Gambone: That's the one thing that always, you know, I always ask them up front, do you need to do anything with files, if you don't we're doing that as a web app.

Michael Kimsal: Yeah. But I think as you mentioned HTML5, as we get more progress with future standards, as we get more capable browsers, things like offline storage, local databases, the last few years we've seen a lot of work earlier with Google Gears and then offline storage, local storage, local query ability, all those sorts of things that seemed you had to use a desktop app for those things ten years ago and you don't have to now.

There may still be legitimate reasons whether it's security or distribution, there are certainly still some reasons to write traditional desktop client apps, but the technology of the Web, the browser, and what you can do locally has in some ways it doesn't feel that radical, but you go back 15 years, I go back to the mid-90's as well, if you think about what we can do now, what we take for granted as commonplace now it has been pretty radical, I don't think it's really felt like it year-to-year so much.

Dino Gambone: No, somebody who's really started in the 2000's really doesn't have that background, what you were really able back in the late 90's and even early 2000's with even JavaScript was so different between IE and Netscape, and then once Netscape kind of died off it was really just IE, but only the rare pieces of JavaScript and still you know you had Firefox come on the scene and really explode the browser war again, everything just really went nuts.

Around 2005 Google jumped in and of course you always had Apple in play there, but once that kind of got rolling JavaScript just really matured, I mean it's just amazing, EcmaScript 1.5 and all the things that had changed even in the past two years, like you mentioned, the web database for all client's storage.

AJAX, people don't realize, one, AJAX is a Microsoft invention, so Microsoft did contribute stuff to it until, you know, it really wasn't used heavily until more recently when people are really incorporating into all the browsers, and now you have the whole, alright, we have WebSockets because Ajax is great for getting realtime information sending it to the server and getting a response, but you don't always want to ping the server, you want to get that push back to the client, WebSockets fills that void. There's workarounds in the past, but nothing beats a true native implementation. 

Michael Kimsal: Well, now that you're brining up push, I have visions of the three -inch large Netscape push book with the green spine from 1996, what goes around comes around, what is old again is new again.

Long polling, I'm thinking PointCast, that's the other thing I was thinking of, oh, it's push technology, no, it's really just long pole. But that's a whole other kettle of fish which I think some of us, Manuel and I, have kind of beat that to death in the past a bit.

You're welcome to beat the corpse a little more, but in some ways those of us that have been doing this, I know Manuel's been doing this for what, 12, 15 years or so, web stuff, you've been around for a long time, it does feel like we're seeing a resurgence of ideas that were popular 10, 15 years ago.

JSON is another, that's a repeated idea, but that has been another construct that has evolved or come about in the past few years, I think that was Ward Cunningham developed the idea behind that and made it very straightforward and simple, it's native to JavaScript, and that has really exploded and made it just an expected way for people to exchange data, none of this XML schema and all that, it's just here's a block of data, un-serialize it and you're good to go.

Dino Gambone: It's simple and it makes sense to do and you won't deal with XML. Just if you look at it how amazing is it that there's all these features of JavaScript in there, they were never planned to be in there, they just kind of, oh, you know if you do this and this you'll all of a sudden have this brand new, you know, delivery platform just because it's built into the language.

You never expected it, it was never written for that, it just happened to be there, just come out of nowhere. 

Michael Kimsal: And a lot of the patterns that we're seeing emerge, best practices, both in frameworks like jQuery, Dojo, things like that, and just best practices people suggest for JavaScript now, a lot of them are ideas that were around many, many years ago and it's felt to me like to be only in the past three to five years that people have been giving serious software architecture thought to JavaScript.

I think as the dominance of IE has gone away we've seen the rise, and I don't know if it's causal or if they just happened to occur at the same time, but we've got this rise of your Firefox, Safari, Chrome, maybe to some extent Opera, but they largely have very compatible JavaScript and DOM engines, more similar than different, and IE has historically been the odd man out there.

Whatever standards they may support it just has typically not been at a JavaScript compatible level, so as the others have together become, if not a majority at least a large minority block, that can work with the same JavaScript code, we've seen more advances not in JavaScript engines necessarily, though we've seen SpiderMonkey and things like that with speed increases, but we've seen a development in people taking it seriously.

And it's easier to take it seriously if instead of, well, I'm going to write great JavaScript code but it's only going to work on Netscape 3 and I can't get it to even work on Netscape 4, because we've seen maturation and we've seen this consolidation, it's easier to say I'm going to spend more time on it because this is going to be long-lived, it's going to be in a long-lived project and it's going to run on multiple platforms.

Anyway, I've just ranted there a little too much but I think, as you're saying, these things weren't necessarily designed in, but like many good languages they can be flexible enough to have good practices applied to them and they fit. There you go.

Manuel Lemos: Well, I had actually a question related with an object that Dino sent to the site. We will get back to that object later, but my question is related with what you do.

You mentioned you work in web development, but from what I could see in this object it seems to be more for games or probably other 2D applications. Are you working also on games in JavaScript or something related?

Dino Gambone: I do. If anyone's read the article that I've written for JsMag they will see that all my articles are very heavy game background. Game development is something I've done on the side since I've been in college when I first started playing with muds which are basically tech-based games that ran on a giant UNIX system, you know, just type space, and it's more kind of like those Zork games where you say go east, go west, go up things like that.

Michael Kimsal: Go old Zork, yeah.

Dino Gambone: Yep. So that really has always been a passion of mine was game development and building just.. I'm not looking to build the next World of Warcraft, the next Modern Warfare, I just want to build something that people enjoy and you know what, if it gets great reviews fine, it's just something I love doing personally. 

Manuel Lemos: So that's a hobby, right, or something related with your actual work?

Dino Gambone: Unfortunately you can't make. unless you're in the right position you can't really make a great career out of game development right now, so my professional job is actually more of the pharma-medical fields.

Manuel Lemos: Oh, I see.

Dino Gambone: Yeah, and data analytics, that's where I'm currently employed right now. I've been doing game development for quite some time, but it's never been an official production release of any game at this point.

As far as what you can do a search online for various tech articles I've written pre-JavaScript in JsMag, and most of them are going to be about game dev, talking about just different fundamentals of isometric based games, stuff like that.

I've helped contribute to the community in that whole isometric field, isometric is that -- I don't know if anyone played Diablo back in the mid to late 90's, that kind of 45 degree down onto the character, that's isometrics.

So before 3D graphics was really prominent people wanted to have 3D-like feel so they did isometric with basically 2D tiles just kind of arranged slightly differently. 

Manuel Lemos: Okay, we'll get back to that topic ahead when we talk about the latest objects published in the JS Classes site, and we will have the chance to talk a bit more about those games and otherwise 2D or 3D related applications based on JavaScript.

Can JavaScript Totally Replace Flash Now? (16:27)

Manuel Lemos: But right now we are going to move on with our podcast, we have several interesting topics, some somehow related with JavaScript either directly or indirectly, and I'm going to start from this recent news from Adobe that they are ceasing the development of the Flash plugin for mobile browsers

And at the same time I also saw this site Occupy Flash. It seems there is a great trend to occupy everything now, and this occupyflash.org site is basically yet another attempt to exercise some pressure to make Flash use in web mainly cease permanently because nowadays we have technologies built in browsers using JavaScript that allow us to implement similar capabilities that were provided by Flash.

Did you guys see this site and also follow the news about the Adobe initiative? What did you think? 

Michael Kimsal: Dino, you can go first.

Dino Gambone: Alright, I'll go first. Steve Jobs had it right I guess when he released the iPhone he was like no Flash because it's big, it's bloated, buggy, it slow. The Web is going to evolve to the point where you don't need Flash anymore.

Four years later it's almost there, I mean there's really nothing that Flash does that you can't do with a little bit of JavaScript, CSS and HTML5, and in fact, Adobe even has a... I forget what they call it, some sort of server package that will actually convert their Flash code into HTML and JavaScript.

So I mean they've really kind of at this point thrown in the towel, and it's kind of nice that... I don't want to say that Flash has gone away, it served a great purpose in the early 2000's when this wasn't possible with JavaScript, but it's nice that it's not going to be around anymore for people to kind of get stuck with having all these, well, I can't go to this site because I'm on my iPhone or iPad and it uses Flash only, and my company doesn't like Flash videos coming through which does happen often.

So it's about time, thanks to Flash for all they've done, but like every technology that we've worked on in the past eventually grows old and needs to be replaced with something else new, it's about time to happen.

So probably another two, three years you're not going to hear Flash mentioned anymore because all the browsers will be HTML 5 and 6 or 7, whichever is out by then, you know, video streaming will be supported natively, JavaScript will just be so rampant everywhere that you can pause and start streams of video and pull in movies, music, move objects around, and Flash has outlived its purpose.

Michael Kimsal: But how do you really feel?

Dino Gambone: I'm going to miss it. I'm going to cry. No. I mean in all reality I mean was this really a shock to anyone?

Michael Kimsal: I'll say it was a shock to me not that it happened but maybe at the time, the timing that it did happen. I always expect things to happen, the things like that that larger companies will hold on a bit longer.

Dino Gambone: Well, I will give Adobe credit for seeing the writing on the wall and not really trying to keep it on life support because there is no way Flash could win in this battle between HTML 5 and Flash, it's just impossible, too many people are gung ho about getting HTML5 and removing Flash.

I'm actually surprised there's not a JavaScript library out there already that converts ActionScript into JavaScript other than what Adobe offers.

Manuel Lemos: Well, what I wonder is that if all that Flash can do can already be done in JavaScript in all browsers, for instance, recording audio, recording video.

Michael Kimsal: All this stuff can't, it's not 100% replaceable at this point.

Manuel Lemos: Yeah. So I sort of agree with Michael it's probably not yet the right time to do that, on the other hand it's also worth noticing that this news from Adobe that they are ceasing the development of the mobile plugin, I mean plugin for mobile browsers.

Dino Gambone: They're ceasing the development of the mobile player correct, it's not just Flash completely, it's the player.

Manuel Lemos: No, it's just for mobile browsers, they'll continue on the desktop. Actually I just received a new version of this for Linux, it appeared in the updates and, well, that's as much as we would like to make Flash obsolete the question is it really totally obsolete already?

Dino Gambone: Let me ask you this question. You mentioned recording the audios and videos in Flash. Do you use Flash to record your audio and video?

Manuel Lemos: I don't work in that area but people that do they complain about that.

Michael Kimsal: Well, yeah, things like Justin.tv there's some others, there's a podcast service that lets people call in and do stuff, it's over the phone but I believe you can also have people contribute over Flash, but the streaming cams, hey, all the sex cams out there, what are they gonna do? I didn't actually bring that up, did I?

Manuel Lemos: Those probably don't use the mobile for recording because playback can be done with other means.

Dino Gambone: You think about the recording piece, if I were someone who needs to record audio/video, you know Flash is one of the last of my choices. Now I've seen I think UStream, no, Livestream has like a studio that, or no, Procaster, that's who it is, Procaster has a studio that it is Flash based and you can kind of do a little bit of video streaming, management, tools, things like that, and that is Flash based, but they also have a native desktop app that does it.  

Michael Kimsal: Yeah, if you can install the native app, but if you want to distribute your recording ability or your streaming ability, anybody on these devices, anybody just install this plugin.

I did streaming stuff a few years ago and we ended up using Windows Media for everything because the Flash stuff, while I could build a Flash thing the native encoder, video encoder, was just not good.

Now, On2 had an awesome Flash based video encoder, a separate codec, but they charged you something like 50 cents a minute to encode or per encoded minute, so we went back to Windows media which is good enough, but that was still you're going to have these Windows controls downloaded through your browser and then you can stream up.

You can say well these are niche uses, but what we've been seeing over the past two, three, four years is that JavaScript and the browser has been largely marginalizing all the purported use cases for Flash.

So every six months or a year there's fewer requirements that this is the only way you can do this is in Flash, but until we see good audio support and good video support for creating, not just consuming but for being a content creator, until we see that from the browsers, Flash and probably Silverlight to some extent will be around for a while.

What I am afraid may happen is that we'll end up with the same level of support for audio and video content creation in the browser as we ended up with with Java on the client which was a completely sorry state of just abandoned crap, and I hope we don't see that, but in some cases I wonder what the incentive for...

In some sense nobody can tell me that between Mozilla, Apple, Google, Opera, whoever, they never understood that anybody has any need to record audio and stream audio up to a server, or video, that just never crossed their mind, the combined engineering power of those companies and the pockets of those companies is massive, massively outweigh Adobe.

And yet none of them have... I won't even say they haven't made it a priority, they haven't even made it anything that they've even talked about as far as I can tell. So as much as Adobe's been the whipping boy for everybody for a long time they still are providing things that no one else even seems ready to touch, there I go, I've said it.

Manuel Lemos: Yeah, well, another related point to this discussion of JavaScript and Flash is that often I listen to people saying that Flash animation applets are heavy, they hog the machines, they consume a lot of resources, but often when I see that happening in practice it's because somebody decided to put complex animation with a lot of effects that do not cease, do not stop consuming resources from the user's machine.

And I wonder if when people switch to same results using JavaScript, will it be as heavy as with Flash or probably worse or not? Because I don't see how JavaScript is going to make it better for complex animations than Flash. Have you thought about this?

Dino Gambone: Complex animation how, though, I mean DOM script already...

Manuel Lemos: For instance those advertising animations that once you know how you see a lot of graphics going around just to grab the attention of the user, and all that is consuming resources because you have to animate all those graphics that are in there.

Sometimes they use heavy images that have to be processed during the animations and all that consumes resources. What I'm afraid is that in the end it will be the same, if you try to do the same complex animations using JavaScript it will still consume a lot of resources.

So what I think is that people are trying to blame Flash for all these problems, but in the end the fault is on the people that create those Flash based movies.

Michael Kimsal: And I think we'll probably go through at least a period where it's harder to get rid of some of those things because right now people can do ad block and say let me just block any Flash, I want a Flash block, I don't want any Flash because I'm just going to see crap.

Are we going to be able to develop a JavaScript block that just blocks all JavaScript, I mean no.

Manuel Lemos: There are solutions for blocking JavaScript. Actually they probably will be able to block specific things that whoever defines what needs to be blocked has already studied to figure what is disturbing the user.

Michael Kimsal: But now we're putting that into somebody else's hands instead of giving the end user control and saying I want this, I don't want this, now you're ceding control of your browsing experience, hey, to Google.

Manuel Lemos: Well, I was talking about ad blocking not exactly the production of those content.

Michael Kimsal: I understand, I understand, but somebody now is going to define what is annoying this JavaScript pattern of code probably as an ad so let me block it instead of just blocking Flash or not. 

Manuel Lemos: Yeah.

Michael Kimsal: And I think it will be harder to disable that sort of stuff, well I want to enable this, there's a lot of pros to Flash going away but it's going to open a whole separate can of worms because the problem is not specifically Flash which I think is what you're trying to say, it's the way that people use it and the way that people are going to use HTML or HTML, JavaScript.

Manuel Lemos: Right.

Michael Kimsal: And that's, in a related note here, an announcement last week, two weeks ago, Flex, Adobe is going to transition Flex over to the Apache Foundation and they're basically washing their hands of Flex and saying we're going to do HTML and JavaScript stuff in the future, here's Flex, and somebody else is going to maintain it, the community will maintain it.

But anybody that's chosen Flex in the past six months or a year and probably still developing stuff, they've tied themselves to a long term loser unfortunately.

Dino Gambone: Is Adobe still supporting Air?

Manuel Lemos: Yes.

Michael Kimsal: I'm suspecting they are for the time being, but it will not surprise me if in the next six months they make an announcement getting... as soon as they have something that will replicate even maybe 50% of what the Air stuff does right now they'll have a converter and they'll say convert all your stuff over to, your air stuff over to JavaScript, and it doesn't do these but we'll work on it, and it's going to be messy for the Adobe stack for the next couple of years.

Manuel Lemos: Actually Air stuff is not solely based on Flash. It's also based in HTML and JavaScript, it's not something specific to Flash.

Michael Kimsal: Right, but untangling that somebody starting with an Adobe stack six months from now and they have some HTML tool and it's all great it's going to be fine for them, but anybody that has current stuff that wants to transition it or keep maintaining it, it's going to get ugly I think, very, very painful.

Dino Gambone: Well, good thing they have Photoshop

Michael Kimsal: Oh, yeah, yes, except for Photoshop.

Google can Execute JavaScript on crawled Web Pages (31:45)

Manuel Lemos: Well, I think there will be a lot more to say about this, and I'm sure it will get back to these Flash versus pure JavaScript solutions in the future shows because there's plenty to say about it, but moving on with our podcast...

Michael Kimsal: Yeah, can I mention the next one on the list?

Manuel Lemos: Okay.

Michael Kimsal: The Google Bot now capable of executing JavaScript and indexing pages that have JavaScript. Now you have a comment here to say to index Facebook comments, and this is a link to a Matt Cutts post, Matt Cutts from Google.

And it's been one of those perennial statements that SEO people have said, well, Google or search engines don't index JavaScript or don't execute JavaScript and therefore they don't know what's on your page if it's all in JavaScript.

And that seems certainly with Google they've been very public now saying that no that is not the case, it can execute JavaScript and the results of that, the text results of those JavaScript can be indexed. Now, how deep they're doing that across the board on all sites probably remains to be seen.

Manuel Lemos: Well, I don't know yet what is the extent of this JavaScript support, what I read is it is somewhat related with Google versus Facebook competition.

Michael Kimsal: Hmm-mm.

Manuel Lemos: And because some time ago Facebook allowed people to sort of use Facebook as comments on blog posts, so it could have those comments embedded in the blog pages, but that embedding would be done in JavaScript.

Actually in the past I have noticed that Google mentioned that could execute some JavaScript in the pages, but that was for quite simple situations, I'm not sure if it could do it to a greater extent.

And now there seems to be this additional motivation because Google also wants to index the comments that are in blog posts using those embedded JavaScript widgets that make the comments appear there.

Michael Kimsal: Discuss, and so on, yeah.  

Manuel Lemos: Yeah, well, we don't know yet other situations on which Google is actually executing the JavaScript on your pages, but I think the important thing to keep in mind is that if you for some reason are using JavaScript in your site pages, assuming that Google or will never index it, you may think again because it may not be true probably already in the present or at least in the future.

And this is something to keep an eye on because I'll just give you a simple case, on which I used JavaScript assuming that Google and other bots will not crawl it. I used JavaScript for instance to check clicks on links that I wanted to take some statistics of visitation.

And what I did is to use JavaScript and I think I need to review that approach and probably use something that does not depart from that assumption that search engines will not crawl your JavaScript. And this is just one thing somehow related with JavaScript.

JavaScript code coverage with ScriptCover extension (35:57)

But now moving on to other more JavaScript specific topics that interest more, I think, our listeners, starting with ScriptCover which is basically a code coverage extension that does code coverage.

Well, I have never seen any code coverage solutions for JavaScript, for me this is news. And for those that are not familiar with code covering concepts this basically is used to determine the extent of the JavaScript code that you maybe using in your web pages to evaluate whether your code has been fully tested or not, so this is related with quality control.

And, well, I develop most of my stuff in PHP, and even in PHP I have not used anything related code coverage despite I reckon its value. Have you guys been using any code coverage tools for any language?

Michael Kimsal: Yeah, I've used some xDebug in PHP, uh, I forget what I used, I've done some in Java before and I've seen other people do it with C# stuff, I haven't seen it for JavaScript, have you seen this in JavaScript before, Dino?

Dino Gambone: I've seen... I'm trying to remember what the name... there's a server side version of a kind of almost a remote debugger that is somewhat like it, but JavaScript on the client it's so tough to build something that no one needs to really have to solve the whole plugin or something test out code coverage.

JavaScript is one of those languages that it's really tough to debug in the client because you're now running inside of a separate process, I'm saying outside of the whole Firefox or Google developer tools, or IE developer tools, there's no real way for a developer to really step through it, and this does seem like it's going to be a nice tool to have to be able to, one, see where is your code being hit, how often it's being hit.

And you know the one thing I have to do with the client side stuff with my company is you know you're going to be hitting, what's the rule, it's like 9% of the time you're running 10% of your code, if you can really optimize that 10%, and this tool seems like it will help narrow down where that 10% is, then you can really develop very responsive and rich front ends.

Michael Kimsal: Yeah. I'm looking forward to doing a bit more with it probably December some time. We have an interview, I'm not sure how extensive the interview will be, but we have an interview with the ScriptCover team such as they are, coming up in next month's JsMag.

So I haven't seen the final thing yet but I'm hoping that there's something interesting in there beyond just what they put in their blog posts so far, because the last blog post I saw for them was the end of October and I don't know how much more progress they've done so far.

Manuel Lemos: Yeah, this is a Google project, right?

Michael Kimsal: Yeah.

Manuel Lemos: Yeah. Well, we'll keep an eye on this because it's certainly very interesting, especially those that are more focused on test driven development.

Michael Kimsal: Sure.

Animation Timeline Editing with Timeline.js (39:48)

Manuel Lemos: But, okay, moving on with our podcast, another JavaScript library that I have found out to be very interesting is Timeline.js which is basically an animation library like many others except that it provides a GUI based timeline editor on which you can see different objects that you are animating and how and when they appear in the whole animation timeline.

This sort of reminds me of the way that web designers use the Flash tools for putting together their animations, and just to give a good idea of how it is going to appear and makes the process of editing animations quite fast to do and very easy to see what you are doing.

Have you guys checked out this library? What do you think about it?

Dino Gambone: I was playing around with the... actually I still am playing around with the demo that they have on the web site, it's very Premiere-like, if anyone's ever done any video management it's got that same kind of feel, and I really love when people put together demos that are just this rich UI.

I've been playing around with it for the past hour, you know, adding new break points, and it looks interesting, I'm not sure exactly where I would use it, but I'm sure there are plenty of people who would look at this and this would fit a specific need, even the author said he had a specific need.

And one of the nice benefits of this which the author does point out is whenever you're doing any JavaScript development you basically have to write it, bring up the browser, see that it doesn't work because it never works right the first time, go back to the editor, change it, hit refresh, go back to the editor, change it and go back and forth.

Where the way he put this together is it's basically all stored on a local storage and you do it all kind of right then and there, it kind of cycles, it loops through the animations and you can see your changes without actually having to go and refresh and going back to an editor and refresh, very, very cool app. 

Manuel Lemos: I think this editor, this GUI based editor, is not meant to be used in production animations, just for editing.

Dino Gambone: No, it is, and on the demo there's a button that you click on it, it actually then gives you all the JavaScript code needed to complete the animation. But really what the tool does is helps you define your animation ahead of time and then pop it into wherever you put it. My only concern about is requirements, is that it requires Canvas, not really a huge deal except for everyone who's running IE8.

Manuel Lemos: Probably just for the editing.

Dino Gambone: Anyone listening to the podcast probably doesn't use IE8.

Michael Kimsal: Yeah, it's a concern but it's probably a somewhat short-lived one, certainly this would be something to use for internal or Internet sort of apps, being able to write something like this and use this, or this is something I'm sure will be improved over time, I'm sure there will be more features at some point, more compatibility, a year from now more people using IE9 and that concern goes away or is lessened, but certainly you can never be 100% compatible, but hopefully we'll start seeing more rapid iteration from the IE team as well too.

Manuel Lemos: But probably it's not that much of a concern because, I didn't check the library, but I assume there's probably a part that is for editing and a part for runtime, I mean to execute the actual animations.

And that part probably does not need Canvas because unless there is some animation effect that relies on the use of a Canvas object I don't know, but that's a reasonable assumption I suppose.

Importing JavaScript packages into JSClasses site from Git repositories (44:25)

Anyway, moving on with our podcast now we are reaching the end, it's time to comment on the latest objects that have published in JS Classes site, but first I would like to comment briefly about a development that was done in JS Classes site and also in PHP Classes site because both sites share the same code base.

And what was just released is the support for importing packages from Git repositories, so this concerns mainly the authors of packages, classes, libraries that are published in these sites. And this year I start adding support for this because some authors have very large packages and using the traditional method of uploading each file one at a time would be quite painful.

I can talk about it myself because I have submitted a lot of packages, I have the patience to submit them one file at a time. And this year it was introduced as a support to import packages from version control repositories. It started with CVS and then Subversion and now Git.

Git and also Subversion are quite popular these days, Git is growing a lot in popularity, I think mainly due to the popularity of GitHub that made it very easy and people, developers, liked it a lot to keep their development in there because it is easy to share and for others to fork thanks to the version control capabilities of Git.

And now with this support to be able to import packages from Git repositories, not just GitHub, any other, they're just a few types of repositories that need some work to make it be able to import from them, but any Git repository will be fully supported.

Anyway, the message I want to give with this is just if you are a developer that has been willing to submit your packages to get greater exposure to your work in JS Classes site and as well PHP Classes site, now you can import your packages if you have them hosted in Git repositories.

Michael Kimsal: Cool.  

Latest Objects Published in the JSClasses site (47:24)

Manuel Lemos: And now actually we'll be talking about the latest classes that we've been seeing on the JS Classes site. What would you guys like to comment about? Oh, I remember, Dino has his own class that he actually mentioned.

Michael Kimsal: Sure. Well, there's two kind of quick that I want to give a shout out to, one is Michele Andreoli from Italy, and he put together a Corners Detector class which will... it's a jQuery plugin so you need jQuery, it just works on top of that, or yeah I guess I'd say on top of that, and this gives you the ability to return coordinates from... or to detect if one element is inside of another, it will tell if the coordinates are inside the boundary of another one or not, also like to move stuff around.

And then also funnily enough Timer which I think... I don't know if we talked about it last month or not, but I'm in the market for a timer class for a particular project and was searching around and came on this one and though I'd mention it, this is Jeff Martin from the United States, always got to give a shout out to people from the U.S., so, carry on.

Manuel Lemos: Well, now it's time for you, Dino, to comment a bit about your class.

Dino Gambone: Very well. This class is from, let me see if I pronounce his name right, Dino Gambone, yep, that's it.

Michael Kimsal: Yep.

Dino Gambone: And from the United States, look at that.

Manuel Lemos: Oh, that's great.

Dino Gambone: But what this Spatial Hash is in typical 2D games you have objects flying around everywhere, thousands of them, and basically when you need to figure out, you know, am I colliding, I the flyer colliding with any other object, you need a quick way of basically iterating through the multitude of objects in the world and figure out, okay, these are the guys I'm actually colliding with if any.

The idea of the Spatial Hash you can basically create these buckets, you know, and the bucket can be a certain size, you pick the size. So let's just per se you have a 1000 x 1000 pixel world and you create buckets of 100 pixels, now basically when an object moves it gets placed into a bucket, if it happens to cross boundaries of one bucket it just gets placed in two buckets.

The idea is that I only now need to worry about buckets that I'm in and not have to check every object in the world. Now a couple people asked for a demo, Michael Shultz and Carl Bailey both asked for demos, I will provide demo, it's actually being used in the next article for JsMag that I'm writing which is a part two, but I'll leave that up to Michael to introduce.

Michael Kimsal: Oh.

Manuel Lemos: A mention to your magazine, right. Well, I think we'll talk ahead a bit about it. On my part I would just like to comment on a few other classes very briefly. As always we keep having great contributions from Arturs Sosins from Latvia.

This time he sent several of them but I would like to highlight in particular this Light source class, actually it was published right at the end of last month but I think we did not comment on it then, but basically what this does is emulate a sort of light that is applied on the elements of a page, so when there is a light on solid elements there is some shadow. So this object uses some CSS properties to make the shadow be projected to a certain distance depending on the position of the light.

And this provides a quite awesome effect that is very impressive to see, and I strongly recommend everybody to take a look, specifically at this object.

We had other objects, there is also Tmatrix also from Arturs Sosins that is basically meant to manipulate transformation matrices of a web page element that basically define how elements in the page can be rotated or skewed or scaled, and this also concerns CSS3 I think, the latest properties that were introduced with that CSS version.

Other than that we also had another object from Arturs Sosins, Texpand, which basically is a very simple way to obtain that effect of automatically expanding the area of text area input while the user is typing stuff inside of it.

Dino Gambone: A very neat feature indeed. If you ever do web, I mean form development and you have a text area you definitely need that kind of functionality.

Manuel Lemos: Well, for those that are used to frequent Facebook, every time you enter a comment, not just Facebook, other social networks and other types of sites, that's the effect that you can see when you type stuff on your comment, and as your comment grow it starts expanding.

And in this case this object that Arturs developed also is able to shrink back when for some reason you delete stuff and your text becomes smaller.

There are also other interesting objects, for instance, we do not have much time to comment about them, but I'll just mention them. There is the Cookie object from Marko Schulz, I hope I'm pronouncing his name right, which is basically to set and get cookie values, and I'm not sure if we have covered all of them.

Michael Kimsal: Emran Ahmed, jQuery on the Fly Form Validator, thank you, Emran.

Manuel Lemos: Yes, I was checking the submission date because there are other form validation components, I was afraid to be confusing them, but that's true Emran also submitted this component this month. And Emran is from Bangladesh, and I think we have covered, at least mentioned, most of the components that were submitted very recently.

Articles in the latest issue of JSMag magazine (54:55)

Manuel Lemos: Now practically at the end of the podcast, Michael can you please comment a bit about your articles of your JsMag Magazine for the upcoming month.

Michael Kimsal: Yeah, December looks like we will have Mike Schwartz is continuing his exploration of server side JavaScript. I mentioned we have an interview with the ScriptCover team which that should be coming up.

Also Trevor Burnham who actually wrote the book on CoffeeScript has contributed a piece on CoffeeScript and testing for us. David Calhoun should have our standard news roundup, and potentially Dino Gambone his part two of his offline web app series. Dino, can I get you to commit on air?

Dino Gambone: Yes, I will have something available for you for December 2011.

Michael Kimsal: Sweet. Kelly will be happy to hear that too.

Dino Gambone: Kelly just loved it when I decided at the last minute, too.

Michael Kimsal: He loves last minute. I shouldn't say that out loud. But that looks like, oh, potentially actually a guy who moved to the Raleigh area, his name is George Gemty, we've been kind of going back and forth while he's pitched an idea, and we've started talking about it, but he's got a... it might be a two-part series on closures in JavaScript, but I'm not sure if we'll have that for December or if that will be 2012, January.

Manuel Lemos: Well, I think you'll have time because the world is only supposed to end in December 2012.

Michael Kimsal: 2012, we got time, yeah, plenty of time.

Manuel Lemos: So you still have time for a dozen issues I suppose.

Michael Kimsal: Thank you so much.

Conclusion (56:36)

Manuel Lemos: Okay, well, unfortunately our time has ended, it was yet another great podcast, we covered very interesting JavaScript related topics. I would like to thank Dino for coming and also adding his insights to the show, as well Michael as always.

Dino Gambone: Thank you very much.

Michael Kimsal: Yes.

Manuel Lemos: And on my part thank you for listening and keep sending your comments to the podcast, and for me that's all for now.

Michael Kimsal: Adios.

Dino Gambone: Good night.

Michael Kimsal: Good night.

Manuel Lemos: Okay, bye.