Rewarding JavaScript Developers - Lately in JavaScript podcast episode 19

By Manuel Lemos

manuellemos.net

<email contact>

Contents

Listen or download the podcast, RSS feed

Watch the podcast video

Read the podcast transcript

• Adobe Brackets editor

• PhysiJS library

• JSCheck library

• JavaScript Innovation Award page

• Article on the JavaScript Innovation Award Challenge

Contents

Introduction (00:20)

Introduction (00:20)

Manuel Lemos: Hello. Welcome to the Lately in JavaScript podcast. This is episode 19 and this is the second time that we record this on video, which is great because now you can see both our regular co-host, Michael Kimsal, and Arturs Sosins.

Michael Kimsal: N-n-n-n-nineteen. Yes, good morning, Arturs, or sveiki.

Arturs Sosins: It's already 'Good evening' here.

Michael Kimsal: Labvakar.

Arturs Sosins: Yeah, that's right.

Michael Kimsal: I know. I know. OK!

Manuel Lemos: Hello, Arturs. It seems to be still daylight where you live. You are in Riga, right?

Arturs Sosins: Almost.

Manuel Lemos: OK. Do you have a long day over there?

Arturs Sosins: Yeah. It gets dark only about 11pm, I guess.

Michael Kimsal: Wow.

Manuel Lemos: Well, today we are going to have a new thing to talk about related with the JavaScript Innovation Award that is going to get started, that's why we have Arturs Sosins today to comment about because what is being implemented is an idea that is inspired on something that Arturs suggested.

But we will get back to that later on the podcast because first we are going to start with the regular batch of topics, things that are going on in the JavaScript world.

LLJS: Low Level JavaScript (1:56)

Manuel Lemos: I'm going to start talking a bit about LLJS, which is Low-Level JavaScript library.

Michael Kimsal: I think it's 'Lady's Love JavaScript'. Yeah, LLJS. That's a little '80s reference for you guys. I don't know, you're probably not old enough, sorry. And you're not American enough, because that's the other thing.

Manuel Lemos: No. I have that limitation. I am not American enough, sorry.

Michael Kimsal: LLCoolJ! You guys don't remember LLCoolJ? No, you probably don't.

Manuel Lemos: Oh, that's old. I remember, but that's ancient. 

Well, anyway, back to the topic of LLJS library, this sounds a bit hard to me, but the idea is to offer C features, or should I say limitations...

Michael Kimsal: You should.

Manuel Lemos: ...because it makes you do things in JavaScript as if you are programming in C like declaring variables and memory allocation, and I suppose you also are forced to free all the allocated memory.

I'm not sure what is the purpose of this, maybe to gain some speed in terms of execution, because if memory allocations are managed by the program, as opposed with the usual managed memory systems that use garbage collections and stuff, I'm just wondering if this is a good idea or not.

Michael, did you check into this? What were your impressions?

Michael Kimsal: Well, anything that brings the fun of C-level programming and anything else gets a 'thumb up' in my book. Specifically, I have not actually tested this, so unfortunately I don't have a lot to contribute on this.

Manuel Lemos: Oh, you did not enjoy the fun of C programming again.

Michael Kimsal: No. Really, for as much stuff as I've done, I've never done any production C stuff. I've messed around with Hello world, and actually I've messed around with the PHP internals a little bit to try to make some modifications, but very, very minor. Just C is not my thing.

Manuel Lemos: Yeah. Well, I developed a lot of C code in like 20 years ago. No more. Or more.

Michael Kimsal: Twenty-one. That's more.

Manuel Lemos: About that. I cannot see if this is being anything close to fun.

Michael Kimsal: This programming in C gives me this. [Guitar chord] It's kind of a sad chord. [Guitar chord] Yeah, very sad. I feel sad when I think about C programming. I'd like to get back to something where I can do a major chord and be happy again, which PHP and JavaScript both give that to me, so I get happy there.

Manuel Lemos: Well, I don't know if this is going to be any fun for anybody, but I suppose it has its reasons.

Arturs, did you program in C at least in the past?

Arturs Sosins: Yeah. The first and second year in computer science university, we were learning only C, basically. I haven't used it in production also, but I know the basics. But I completely agree with Michael that I would never change JavaScript or PHP for C++.

Actually, I've read an article from authors of LLJS what was the reason behind the LLJS. It was more like an experiment to see what people could do with low-level types in high abstraction language, what would be possible, how would it be used and stuff like that. It was more like a research, like an experiment. I don't know how well it's working, but that was their main intention.

Manuel Lemos: Well, I think when they force people to declare variable types, that is an opportunity for optimizers that compile code, good compilers to generate more optimized code.

Michael Kimsal: Maybe we'll get that in PHP at some point. I know it's not a PHP podcast here, but maybe we'll get that in PHP one day, optional declaring types.

Manuel Lemos: Well, when I started to program in PHP, I was quite happy that finally we had a sort of interpreted PHP, because at least in the beginning most of the commands looked very much like C.

Actually, many PHP functions have the same names as in the C libraries, standard libraries, and I was quite happy that you don't have to go through the draft to have to declare all the variables. But probably this will make it possible to gain a few milliseconds for whatever it is executing, at least for CPU-intensive tasks.

Well, I don't know if this is going to be any useful to anybody else, but we'll see if somebody probably comes with some real-time applications for JavaScript that really require all the CPU power that the machine can provide.

NodeObjC: Node.js on Mac OS (8:00)

Manuel Lemos: Well, moving on with the next topic, which is basically to comment about a library named NodeObjC which was a case Objective-C bridge for Node.js.

Michael, you are...

Michael Kimsal: I have a Mac, so I have to talk about this one. Paldies.

Manuel Lemos: That was the agreement, so you can get paid.

Michael Kimsal: You're just going to pay me in elephants, though, that I don't need.

Manuel Lemos: You'll get a few more if you will be enthusiastic.

Michael Kimsal: Just looking over here, it looks to me like this... I am not an Objective-C person. My understanding was that people only did Objective-C on Macs. That's probably not true, but from a technical standpoint you probably can write in multiple places, but from a practical standpoint this is largely something I would imagine is only going to be used by people running Node.js on Mac that also want to bridge over and reuse some of their Objective-C stuff.

The reading here is saying that it's similar to other bridges like JSCocoa, which I would guess would go from Node.js to Cocoa bindings, which I'm assuming there are people that need this, but it strikes me as niche.

I mean, not an experiment so much like the LLJS, but even though I have a Mac, not all Mac people do Objective-C. Maybe it should be the lesson that we take away from this.

Manuel Lemos: Well, I'm not sure why this could be useful in practice. Not that I have anything against whoever uses Macs, but...

Michael Kimsal: Yeah, you do.

Manuel Lemos: No.

Michael Kimsal: Your anti-Mac bias has been obvious for 19 episodes.

Manuel Lemos: Oh, sure. I'm just against expensive computers, and over here they are so expensive because they have to be imported.

Michael Kimsal: But they're going to start making them in Brazil. So?

Manuel Lemos: iPads, I think.

Michael Kimsal: I think they might start making Macs there at some point, too. Just a thought.

Manuel Lemos: Well, that would be good because the taxes over here has to be really high and I'm sure there's plenty of demand.

Anyway, what I was going to say is that Macs are not the typical environment on which you run servers, which is one of the most common environments on which Node.js is used. 

Michael Kimsal: Yeah.

Manuel Lemos: And since this Objective-C bridge is probably to make it easier to interface with native Mac resources, I was wondering if this will be anything useful.

Michael Kimsal: Which is, the thing in the back of my head is that Apple right now has seemed to pull out of the server market, and certainly there are people who use Macs for servers, public servers, heavy-volume servers.

This may be something that we see as people start to do hobbyist home automation stuff with their Mac minis to be able to run code that I can do 'evented' Node stuff but tie it together with other Mac-specific things.

It's a solution that's in search of a problem that I don't have, but that doesn't mean that other people don't have it. It does feel very much, though, that it is somewhat experimental, that it would be hobbyist. I can't think of a production use for this, like a mass commercial market sort of a thing.

Manuel Lemos: Well, it seems to be more for desktop application that for some reason the person that developed them would like to use Node.js. That's what I suppose it is good for, because they say that you can write an entire application with Cocoa or iOS libraries.

So other than that, I do not see this being much useful for real-world applications being on the desktop or on the mobile or on the server site. Because as you said, I don't know if it was Apple that dropped the server market. I think it was the server market that dropped Apple.

Michael Kimsal: No.

Manuel Lemos: I think it would be more accurate to say that Linux prevailed on that market, because even Windows is kind of struggling to be relevant on the public web server market probably.

Michael Kimsal: Yeah. I knew people years ago that got Mac stuff and they got Mac servers specifically because they were already a Mac shop. They could manage it, there were nice interfaces to manage things, and Apple has good profit margins on this stuff.

I don't see any major reason why they would say, 'Let's drop this,' other than they decided they just didn't want to deal with what was for them a small market. And yes, they didn't have a huge market share in the public market, either, but...

Manuel Lemos: No.

Michael Kimsal: I mean, this is semantics, your point of, 'Well, the market dropped Apple.' There's always going to be a passionate subculture of Apple people that would get everything that they make and there were people that were running their businesses on Mac servers. But Apple really seems to want to get out of that market right now. Maybe they'll come back with better offering in the future.

Manuel Lemos: Yeah. Well, I think the market sort of said that you cannot beat the price of free, which is the cost of licenses for Linux machines, I mean, in terms of the operating system. Somehow that also justifies why Microsoft Windows server share has also seemed to be dropping. I think we commented in the past that nginx, the web server, its share has already risen above the Microsoft IS server.

Fans of Apple and Macs, do not take my comment personally; I just meant that in practice that is what happened, sort of Linux prevailed over there. Anyway, that was just a side comment.

Adobe Brackets Web Editor (14:52)

Manuel Lemos: We're going to move on with another topic which is somehow related to JavaScript, which is basically this Adobe Brackets Web editor that allows you to, I'll say, edit files or the usual pack of files that you need in web projects like HTML, JavaScript and CSS.

Did you guys take a look at this project by Adobe?

Michael Kimsal: Arturs, why don't you take it first?

Arturs Sosins: Well, actually I was pretty interested in it. I liked the idea of, well, you guys covered this topic in one of the podcasts that was about editors where you can interact physical, so I thought it might be something similar. I want to check it out, but I couldn't manage to install and run it. I tried to download it but still didn't make it to really check out what it does.

Michael Kimsal: Unfortunately, right now it says, 'Hey, this isn't ready for general use,' so I guess their announcement is, 'Hey, we're working on this,' and 'Developers come help us.' But it doesn't seem to be quite ready for general use.

Manuel Lemos: Yeah.

Michael Kimsal: The screenshots look neat, but I'm not sure if they're getting, I didn't get the impression that this would be a competitor for, what was that, Cloud9, which was hosted in the cloud sort of thing?

Manuel Lemos: Yeah. That's something that I also recall there is this web-based editor, although I'm not sure if it is more than JavaScript. I'm not sure if this is all the file type that it can edit. I do not recall. I remember, I think it was a great idea to have a sort of web-based editor.

I think it was by Dion Almaer, right? I remember I read an article that they are expanding by rendering this kind of editors on the Canvas objects would be more efficient than trying to render it with DOM elements.

Michael Kimsal: Efficient? Are you saying efficient as in just speed or a better experience?

Manuel Lemos: Speed. They meant speed, but I do not recall the exact details. It was sort of a long time ago when I read that article. 

Well, anyway, the idea here of Adobe seems to be the same approach, but I had the impression that it covers more types of web types of files like HTML and CSS.

Well, this is a brand-new project, so it's not a surprise it is probably not mature enough for use in production. But I think it is interesting anyway. Also interesting is the fact that they are open-sourcing the project, so they made it available on GitHub.

Michael Kimsal: I'll tell you what's interesting to me is that it's from Adobe. 

Manuel Lemos: Right.

Michael Kimsal: There's been loads of people that have worked on editors, worked on these sorts of things, but for Adobe to be as publicly experimenting with something like this as they are really, from my view, sends a signal about where they think they are and where they think they need to go to remain relevant as a tools company.

And I may be getting a little over-dramatic there, but that's...because certainly, they could do all this stuff internally and give trials to select users and what not, but for them to be going public with this and saying it's open, 'Here you go,' to me really signifies that they are thinking longer-term that this is what they're probably going to have to do, at least in the web tools market.

Manuel Lemos: Right. I agree. Maybe they have plans to offer cloud-based development environment on which, rather than buying a package to install in your machine, you use cloud-based solution on which your projects are hosted somewhere, and they offer things like version control tools and some other things they may want to provide on a sort of freemium model on which the base plan is free and if you want some add-ons you would need to pay extra. That's my suspicion of it. They want to move on to the cloud.

Michael Kimsal: The cloud.

Manuel Lemos: If we can call it that. I hate calling everything the cloud because everybody's talking about that as if it is a new thing. Actually, to the cloud they mean to the Web, and the Web is old.

Anyway, I think they did this because they are probably planning on it. I'm not sure. I have not been following what Adobe is doing. Maybe they are doing this already and I did not notice. Maybe they already have a cloud-editing project management stuff being offered. But since I do not use Adobe tools, I don't know.

I have nothing against Adobe. I think Adobe did a lot of good things for the Web in general. Some are sort of dying like...

Michael Kimsal: Just not Linux. Just not Linux.

Manuel Lemos: No, Linux is not their league. It's hard to compete with free. 

Anyway, we'll see if this is part of a greater plan from Adobe to offer cloud editing. I think that's all I can remember. But I think it was a good point to bring the fact that what's more relevant on this is that Adobe is doing it.

PhysiJS: Adding physics to Three 3D generated scenes (21:21)

Manuel Lemos: Anyway, moving on with the podcast. Now we're going to talk a bit about a library that is interesting because it does something that looks fancy, at least on screen.

Michael Kimsal: It is fancy. This is the PhysiJS library.

Manuel Lemos: It's even hard to spell it, right?

Michael Kimsal: Arturs, did you get a chance to try this? Does it work on your system?

Arturs Sosins: Actually I'm an Opera user, and Opera doesn't support WebGL yet. 

Michael Kimsal: Oh.

Manuel Lemos: You are from the elite that uses Opera.

Arturs Sosins: Yeah, I guess I'm falling behind on this topic.

Michael Kimsal: Well, maybe they'll catch up. It's a shame you can't afford Firefox over there in Latvia. That's too bad. The exchange rate just must not be very good.

For those of you who can shell out and afford to upgrade to the Firefox browser, if you look at the PhysiJS demos, I am not one to understand all the complex math stuff.

Some of the libraries that Arturs has done over the years, the shadows and all that, and the Gorodki thing, all that, I'm learning as I get older. I'm not an algorithm or a math kind of guy; anything that has more than a plus or a minus in it kind of confuses me.

But looking at the demos for PhysJS, they're pretty awesome. Now that said, let me come over here and let me reload this and do a screen share so you guys can see it, do some screen share.

Manuel Lemos: Yeah, I was trying to do that, but...

Michael Kimsal: Here we go.

Manuel Lemos: ...it's so slow on my machine.

Michael Kimsal: Can you see this? Now tell me when you see this.

Manuel Lemos: Yes.

Michael Kimsal: OK. This is a click-and-drag blocks, so I can click that and move it over. I can click this and move it over. Now, not much is happening there, but I can click that and move it over. Now they drop.

Bear in mind, I'm running a Firefox Nightly. You can see this window has probably 25 tabs open, plus also in this Nightly I'm doing my share Hangout with you. So I am pegged at, I'm using a couple CPUs where I'm using a lot of stuff, but as I pull things out the bottom, you can slowly see that it's going to start to fall with real physics.

They have a couple other demos which, they weren't as impressive to me. This has the...I can make stuff break. Yeah. There we go. I like breaking things. But that in and of itself, for me, is enough to say, "That's really cool." And if you need to do 3D physical stuff, this would certainly be something to look at.

Now, unlike the Unity engine and some of the other 3D libraries out there have physics stuff in them, this is certainly not the first one out there, but just having good...

Manuel Lemos: This is on the browser...

Michael Kimsal: Yeah. But just having good cool demos that can let you break stuff, to me, is enough to say, "Hey, give it a look." That was pretty from the screenshot right to me.

Manuel Lemos: Yeah. That was a fancy physics animation to fade a few bricks into Michael Kimsal. Anyway, I think this just shows the maturity of the 3D capabilities of the browsers.

Michael Kimsal: Except Opera.

Manuel Lemos: Yeah. I tried to run it here on Chrome. I'm not sure which revision this one is, but it was still very slow, which means there is plenty of room for optimization.

Anyway, this is a library that is already on top of the Three library on generating 3D scenes. It just adds some physics to apply in physics laws to the 3D blocks, and ahead, Arturs will also comment on something else that he added some physics, but we'll get back to that.

Anyway, this library PhysiJS, it's just a demo of something interesting that we'll probably be looking more and more in the future. Maybe soon we have a full version of Wolfstein 3D in the browser just to catch up the 20 years of delay of the browsers relative to the desktop applications games.

We'll see where this is going. More and more I suspect that we will be getting back to these 3D-based applications.

JSCheck: Testing JavaScript code with random tests (26:27)

Manuel Lemos: Now moving on with our podcast, it seems that Douglas Crockford, now that he left Yahoo, right? He was at Yahoo before PayPal?

Michael Kimsal: Yahoo-oo! Yeah. He is now at PayPal.

Manuel Lemos: Maybe he is no longer under the Yahoo stress and focus on new interesting tools for JavaScript as opposed to wasting time on semicolon discussions and release this JSCheck library.

Michael, did you try this library?

Michael Kimsal: I have not tried it. I've been waiting on this gets to JsMag. We have a piece, the timing is such that we may not get it for June, we may get it for July, but something that's going to go into JSCheck a little bit more in-depth in a tutorialized way.

I was kind of hoping I'd have it for the podcast today and I didn't have it. I was almost wondering, the idea behind JSCheck here, reading it, and I'll do a screen share. How's that? Oh, you've got it up, too. OK. 

Manuel Lemos: Yeah, but when we talk to you, it only shows your screen.

Michael Kimsal: Well, we'll just leave yours up for now, then. JSCheck, they tested for JavaScript. You want me to bring mine up?

Manuel Lemos: If you can share it, it would be better.

Michael Kimsal: OK. I didn't want to say that, but that's how it goes. "Testing tool for JavaScript, inspired by QuickCheck. Specification-driven testing tool."

I had first thought that this was more a case of testing more like a lint tool, and my first thought was, 'Oh, this is a linting sort of thing that was a reaction to the whole semicolon thing from a month ago.' It doesn't seem to be that that's what it is. It looks like it's more of a generalized testing tool.

And the interesting thing here is that it talks about, you give predicates and makes claims to say, 'This is going to do something,' which is really at the heart of a lot of the X unit, PHP unit, JS unit and so on, but inspired from J unit from a decade-plus ago, those have always been oriented around class and object manipulation and testing, 'Let me test this class,' and my interpretation here is that this is basically a way of letting you test things that aren't classes.

Now, I may be misreading this or reading it at too basic a level, but was that your interpretation, either of you, Arturs or Manuel?

Manuel Lemos: Well, I did not try this. I just read what is described, and for me it also suggests you to be at another lint tool, which would not make sense because Douglas Crockford already had his JS lint tool and it would be sort of redundant.

Then, looking closer at the page of the project, it seems that it's actually generating random random test cases to figure if things are working as expected. 

I don't know how this would work in practice, but it seems interesting. It seems different, a different approach of the usual testing methods, which are usually based on known cases. 

Actually, in practice, a lot of people say that they do testing, but they will only do after the fact the testing, which is they only produce tests after they figure they have bugs. So they create tests to figure if the bugs are still there or not.

Michael Kimsal: Yeah.

Manuel Lemos: This is not very proactive because you want to prevent bugs rather than just fixing them. Fixing this is important, it's necessary, but it would be even better if you could prevent bugs before they can happen.

Now, how this happens in practice, how useful this can be, I'm not sure, and my bad for not having had time to test this in practice. But I think it looks interesting.

Arturs, do you have an opinion on this?

Arturs Sosins: Well, I guess, in my opinion, these kinds of tools are more like it could be suitable for aggression testing when you are creating a code. OK, you write some test cases and every time you make a change, you can retest them again, but I don't know if the JSCheck is suitable for it or not.

Manuel Lemos: Yeah. I think we need the tests to reach a conclusion, so we don't wonder too much about what these things are.

Anyway, I think it is interesting. I confess that doing tests, I think for me it's not the funnest thing in the world, but I think we all reckon it is necessary, even if it's just after-the-fact testing, which is the building tests to demonstrate if the bugs are there or not. But I also reckon that is not ideal.

Anyway, maybe we can get back to this new testing JavaScript checking tool later. Maybe we invite a person that is more of a fan of testing. As I said, I'm not probably the best person on that.

Rewarding JavaScript developers with the Innovation Award (32:10)

Manuel Lemos: Anyway, moving on with our podcast, we are almost getting close to our regular section on which we comment on the latest classes on the site, but first I would like to comment on actually an important topic of JS Classes and hopefully to the JavaScript community as a whole, which is the plan to start the JavaScript Innovation Award initiative.

For those not familiar, this is basically the JavaScript counterpart of the PHP Programming Innovation Award that was started in the PHP Classes site in 2004 and basically the idea was to encourage developers to share components that do more useful things by addressing problems that need specific solutions, as opposed to yet another component to solve the same problems that everybody else has solved, like yet another MVC framework or yet another forms validation framework or something else.

So in 2004, in the PHP Classes site, I started this initiative which basically consists in organizing monthly contests on which all the packages, all the classes published in the previous month in the PHP Classes site that do something innovative which can be either implementing something that was never done before or at least an innovative approach to an old problem that has been solved with different approaches. 

And what I can say is that given all these years during which the Innovation Award has been running on the PHP Classes site, it gave great results. Many, many innovative components were submitted, and for that, the authors that submitted those components got additional recognition and attention for their work as well as some nice prizes.

The idea of the initiative is to provide a sort of reward also, prizes from sponsors, which are usually companies that develop the tools on products that are of the interest of the PHP developers in general. 

And now, the idea here is to start that initiative also in the JavaScript world, actually in the JS Classes site, by also distinguishing packages, objects, JavaScript components that do something innovative in the same sense as the PHP Programming Innovation Award but focusing on JavaScript components.

Well, this initiative was not started from the beginning of the site because the site had to, in the beginning, since it had not much components, practically everything that was submitted to the site would be innovative. In that case, the components submitted to the site would not be distinguished for whatever they do different because everything would be innovative, and the idea is to distinguish this.

So actually, sometime ago I commented about this problem with Arturs of not being able to distinguish work of developers that submit to the site because everything would be innovative. But at a certain point, the initiative with that would be started.

It's not easy to determine a good point when it would be ideal to start, but talking with Arturs, we figured that maybe we could set a goal like reaching 200 components. And once we get there, probably not all components will be so innovative, and those that are innovative, we could get those that are innovative a good distinction and recognition to their authors.

That's how this initiative got started in the JS Classes site. Arturs also gave a suggestion which would be to show a sort of a progress bar on which we would, I would say, give the users an idea of how many packages are remaining to reach the goal on which we would start the actual Innovation Award. 

This means that what was defined that until the site gets 200 packages, 200 components, the Innovation Award will not start. But if the Innovation Award did not start, probably some authors would be holding back their contributions and that will lead to a certain 'chicken and egg' problem.

So talking with Arturs, it was decided it would be good to show a progress bar that I think you can see it all on the screen which basically shows a percentage of how many packages are submitted relatively to the goal of 200 packages and how many packages are remaining to reach that goal.

This was announced early this week, and we already have some packages, namely from also Arturs that after a brief period of rest during which he was not submitting much packages, probably he had some work. There are some new packages and I think things are ramping up, although it did not pass a lot of time since it was started. 

Arturs, is this coming how you would expect? What are your thoughts about this?

Arturs Sosins: Yeah. Well, you've heard Manuel's side of the story. From my side, I could tell this contest is a result of like a compromise of me trying to persuade Manuel to start an Innovation Awards for JS Classes, like how many more components should I write. There are already 30-plus there.

So yeah, I hope there will be a competition. I already started making more components; there are two prototypes and at least five, 10 more ideas what can I do. So hopefully others will join and we could push this milestone to 200 packages and finally start JS Classes Innovation Awards like it is on the PHP Classes.

Manuel Lemos: Yeah, that is the expectation. 

Well, other than that, all this initiative is intended to be a sort of stimulus for authors to contribute in a fun way because they can see how far they are from reaching the goal, and at the same time this will be a collective goal because if each developer submits an interesting package to the site, it's one step closer to reach the goal. 

And for authors obviously reaching this goal, which probably is not too high, hopefully. Currently there are 64 remaining packages to reach the goal.

Even for Arturs that is a very frequent contributor, that is probably a very high goal, but if people join forces and submit enough components from each other, they will be able to reach the goal collectively thanks to the effort of everybody.

I also would like to make clear that when people participate in a site like this, they are not doing a favor to the site. They are actually contributing, actually going through a way that gets them more exposure to their work. 

But the suggestion of Arturs to make this to work even better did not stop there. Actually, I was afraid that if I encourage authors to send packages in quantity, I will probably start getting a lot of rubbish packages, packages that do very simple things that are not so useful.

So to sort of preventing that from happening, there is an additional prize that is given to authors that submit more notable packages until the award goal is reached. And as you probably may see on the screen, now on the award page, below the progress bar, there is a ranking of the top authors that have submitted more notable packages.

Michael Kimsal: And look who's Number 1. Yeah.

Arturs Sosins: Probably because this isn't alphabet.

Manuel Lemos: Yeah. Well, actually this is even not sorted by the author name.

Anyway, the idea here is to distinguish authors that submit more notable packages. And notable packages are not necessarily innovative. They are just packages that do something that is not too trivial, not too simple. And even though for purposes of reaching the goal, any new package will count for getting the additional recognition and prize. Only the notable packages count.

Notable packages are packages that I will be nominating and the authors will get an email when their packages are distinguished as notable. So they also feel the encouragement to keep contributing more notable packages.

Other than that, as I mentioned, there will be a prize, which is a bit odd for those that are just from the JavaScript world. But for now, that is all that I could come out. 

Actually, this was an idea of Arturs' to provide an additional prize for those that submit more innovative packages, and the prize will be an elephant mascot of the PHP Classes site, which is somehow based on the original, well, it's not based, but it is very similar to the original elePHPant from Vincent Pontier, which is commonly used as a mascot of PHP. 

This is the odd part is that being this a JavaScript site, not everybody will necessarily also be a PHP developer or be interested, but the problem that I had to face is that as far as I know, there is no JavaScript mascot, right?

Arturs Sosins: I guess not.

Michael Kimsal: I'm not aware of one. I mean, I can be one, if you'd like.

Manuel Lemos: Well, that would be a cool idea.

Anyway, this prize, it is a plush toy that is actually still being produced. We are still in tests. You can see on the screen that this is just an idea of a final version. It's getting closer. It has been iterating to make it more faithful to the PHP Classes site logo designed by Ifat Amit, and the idea is to hopefully provide these prizes or reward to the authors that contribute more notable packages and help reaching the goal of this award.

Actually, the goal of the award itself is to distinguish innovative packages, but as I explained, it will only be started, well, I don't know exactly when, hopefully if we start getting new contributions at a good pace, we probably will get there sooner rather than later. Eventually still in 2011 before the world ends, whatever that means.

Michael Kimsal: 2012. End of 2012.

Manuel Lemos: Right. 

Well, other than that, just a quick question to Michael, because he had not yet a time to contribute to the JS Classes site. I wonder what is your opinion about this initiative in terms of do you think it will work somehow, it will encourage developers to submit more interesting JavaScript components? What do you think?

Michael Kimsal: That broke up. Was that for Arturs or was that for me?

Manuel Lemos: Yes, it was for you, because you sort of...

Michael Kimsal: Well, I think the elephant will get people, maybe. But it's a neat initiative. The elephant is a neat initiative just to say, 'Let's try to make something that is a bit unique to the JavaScript community,' if not the JS Classes community. I mean, it's kind of both right now.

I certainly don't think it will hurt, and really, with 64 more to go, you can get the pace that you've had, you've had some up and down months over the past few months, but I think realistically you could get that before the end of this year. And the elephpant may help to get that maybe by September.

Manuel Lemos: Yeah. I also would like to emphasize that I think at least I will give away five elephants. It's not going just to that main winner, or else somebody probably upset because I suspect it will be hard to compete with Arturs, which is already the top contributor, although in the recent weeks, at least in the weekly chart, you have been lagging, somebody already passed you.

But now with this initiative, we hope you can get back. But it also encourages others to contribute, and I'm sure there are several other people that are pretty capable coming with many components, not just a few.

Arturs Sosins: Can I jump in?

Michael Kimsal: Please.

Manuel Lemos: Yeah, sure.

Arturs Sosins: Well, I just wanted to emphasize that, I don't know if everyone knows, but in PHP Classes, you need to submit more innovative classes or earn points as the top, and then at the end of the year, if you collected enough points and you're the first one, only then you get that elePHPant. So it's exclusive really.

Manuel Lemos: Yeah.

Arturs Sosins: And as I understand, this is a new design that none of the PHP developers have them yet, right?

Manuel Lemos: Yeah, that's true. That's a good point. I don't think I have mentioned it here in this podcast, but because it's not related with PHP but since many PHP developers are also JavaScript developers and would be interested to participate, what I would like to mention is that the original elephpant, it used to be produced by a company in France, but I think they were sold to another company and the people that were left in the company are not able to justify the time they used to spend on producing.

I think they took care of all the process of producing the elePHPants and shipping them, because I think it's not the focus of the company. Originally, Damien Seguy used to be the person in charge, but he moved to another company, I think in China or something, and it used to be sort of, well, if Vincent Pontier was to be the father of the elePHPant, maybe it would be fair to call Damien Seguy the mother, because he really tried hard to dedicate a lot of time to produce these elePHPants.

And I know it's not easy because I've been trying to produce them myself, finding companies that actually do this stuff and do it well, and as I think I did not mention that this drawing of the elephant is actually the fourth attempt to do a test, something that is close enough to the original drawing of Ifat Amit. 

It takes a lot of time and patience to tell people that are working on, producing these plush toys to do it right. It takes a lot of time and dedication. Hopefully in the end it will pay with return, the encouragement that we will provide to other authors to earn this prize.

Well, I don't know, this is the fourth iteration. Arturs, do you think that is already faithful enough to the original?

Arturs Sosins: Yeah. Well, I guess it looks pretty great. Too bad we can't see it in real life so you can rotate it around the camera or something, but from the image, yeah, it looks good. Yeah.

Manuel Lemos: I did not see it either because it is produced by a company that is a bit far away. Although it's still in Brazil, it's still a bit far away from where I live, so they only send me pictures like those that I have shown. But I think you can get a good idea.

Well, this is the basic message that I wanted to give with this section here on which we, just trying to encourage more authors to send more contributions.

Latest JavaScript objects published in the JSClasses site (52:31)

Manuel Lemos: Other than that, I think it's time to move on to one of our final regular sections on which we comment on the latest JavaScript packages published in the JS Classes site.

I think we can start precisely by, we have a few, about five, since the last ones that we commented, and I don't know if you can get to see these. I'm trying to share the right screen.

Michael Kimsal: Should I go?

Manuel Lemos: Actually, I was thinking about starting with Arturs because he is our guest.

Michael Kimsal: OK. That's fine.

Manuel Lemos: I don't know if you can share your own screen because I was having a hard time here to share the right window.

Arturs, do you want to go ahead?

Arturs Sosins: Yes. I don't know if you see anything. I just showed the screen.

Manuel Lemos: Oh, it's the demo of the same component.

Arturs Sosins: For this, this is just a simple demo.

Michael Kimsal: Yeah, there you go.

Manuel Lemos: This is the Gravity one, right? 

Arturs Sosins: Michael, are you up to breaking some more stuff?

Michael Kimsal: I'll watch you break stuff.

Arturs Sosins: I don't know how good it will run. This is a pretty slow machine where I'm sitting now, but the basic idea is that you apply physics to HTML elements and... Well, that goes really bad. You might have seen a Google Gravity example. Have you seen it?

Michael Kimsal: Yes. "...animate HTML page using the..." OK, I get it. I get it.

Arturs Sosins: Yeah. So it's something similar, just uses a Box2DWeb library, and I wrote a wrapper for it just to apply to HTML using CSS transformation and matrix transformation, matrix for Internet Explorer, and this is how it goes.

You can also...and now it's pretty slow here. I don't know if you can get it straight, but as you can see?

Michael Kimsal: I bet if we all use Opera, it will be better.

Arturs Sosins: Well, it's on Chrome right now. I just downloaded Chrome just to try PhysiJS. Oh, it runs OK, but it seems it's slow for this one. I guess my machine is pretty slow.

Michael Kimsal: It's OK, it's OK. I bet it's fine on Opera. 

Arturs Sosins: Well, actually it may not, but it's manageable.

Manuel Lemos: Yeah. Well, this is based on a Box2DWeb version of the JavaScript library, right?

Arturs Sosins: Yes.

Manuel Lemos: So you basically use that library to apply some physics to the elements?

Arturs Sosins: Yeah. I did an article before for JSMag that was about drawing animations on Canvas. Well, that is actually what Box2DWeb is meant for, for drawing animations on Canvas. I just created a wrapper, did some calculations to try to apply them to HTML elements and, well...

Michael Kimsal: It worked.

Arturs Sosins: Well, I thought I could submit it.

Michael Kimsal: Cool.

Manuel Lemos: And this one is from Arturs Sosins from Latvia, right?

Arturs Sosins: Yeah.

Manuel Lemos: Well, that's quite an interesting effect. 

But moving on. Michael, now it's your turn. Which packages would you like to highlight this month?

Michael Kimsal: I'll need about 10 seconds, so please hold.

Manuel Lemos: You need it to...?

Michael Kimsal: Because I can't shut off the phone.

Manuel Lemos: There's a countdown? Let me see so I can share the screen. This time for some reason mine came out blank.

Michael Kimsal: OK. Hello, I'm back. It was a case of, I can't reach the phone and it blasts out whoever is leaving a message. So I had to just shut my mic off for a moment so that you didn't hear that rather personal diatribe from somebody.

So, there was two things that are related that I was going to screen share. Not gravity.

These are two different classes, LZF and then the other one is SCSU. These are sort of two sides of the same coin, but I've actually played with the LZF one. These are ways of compressing and decompressing data with the LZF algorithm and SCSU is to encode and decode Unicode strings with SCSU.

But what's interesting here is if we actually go look at... Oh, where did it go? Where did it go? Readme. I think it was in the Readme. There was an example of using this over at JavaScript Archiver so you don't necessarily have to go install the whole thing. You can choose here, choose a file, and it will... This is actually kind of interesting, if I can find it. Where is...of course, I can't find what I wanted to do.

Manuel Lemos: Yeah, Murphy's Law.

Michael Kimsal: Impress.js, yeah. OK.

So I wanted to take impress.js. If we look here...oh, where is it? Of course, it's not actually going to show me how big it is. This is somewhere around a 35K file or so impress.js.

Well, I can put this up, 99493, make archive, and it will give me, it's compressed this whole thing down into a 19K file from a 32. So it's done it. But what we see here... And actually I don't need to download it because I already have it here. Let me share my other window, screen share, let me share this.

What this gave me is, downloads impress, it gives me impress.jsa, which does an eval and extracts with the jsa, this is using the LZF algorithm that's part of the class that was uploaded, so it's given me impress.js self-compacted in base 64, but I'm still getting whatever, 30%, 40% reduction in the actual size of the file.

Manuel Lemos: Yeah.

Michael Kimsal: So I thought it was kind of interesting because it's a way to compress and then automatically uncompress or self-uncompress files, actual JavaScript-executable files.

Arturs Sosins: So it's like a packer?

Michael Kimsal: Yeah, that's the word I was looking for, 'packer'. Yes. 

The SCSU is a similar thing, just reading the code strings, but those are both from...let me get the name right. That is, that both of these are from...

Manuel Lemos: Alexey.

Michael Kimsal: Alexey Znaev. Zdravstvuyte, Alexey. There you go.

Manuel Lemos: Maybe Arturs can spell the name more closer to the original.

Arturs Sosins: Alexey Znaev.

Michael Kimsal: Znaev, OK. That's what I said.

Manuel Lemos: With the proper accent.

Michael Kimsal: I said it pretty close, I have to say. I, thank you. Spasibo.

Manuel Lemos: Yeah, yeah, because you are an expert in foreign languages.

Michael Kimsal: Ah, si. No, not C the language. Nyet.

Manuel Lemos: [Laughter] Yeah.

Michael Kimsal: OK, so those are the two side-by-side from Alexey that I thought were interesting.

Manuel Lemos: Yeah. The other one, SCSU, is more, well, it's not so much specifically about the compression but rather to make the...

Michael Kimsal: Encoding.

Manuel Lemos: ...encoding more suitable, more compressible, from what I could get, which is, these kinds of components are those that would be considered innovative in the JS Classes site once the JavaScript Innovation Award is started, because they do something that is innovative and also in practice it would also be notable because it does something that is useful other than being unusual.

As you can see, and you demonstrated it quite well, it reduces the size of the packages. Let me see, it's my turn now. I wanted to comment on a couple of classes. Let's see if my screen sharing is working now. No. I think so. I think you can see it now. 

Basically this is...I'm looking now at jQuery.pidCrypt. This is also an interesting component by Jason Gerfen from United States. He already contributed a component before, I'm not sure if we could comment about it.

Basically to store data from form values on the browser side eventually to use them later, for instance, in offline applications on which maybe without internet connectivity we wouldn't be able to save the data to the server, so it uses browser storage containers, all sorts of containers like sessions, I mean, browser side sessions or cookies or local storage.

This component, this new... he made it a jQuery plug-in, but I think it did not even need to be a jQuery plug-in because it seems to only use jQuery just to traverse the forms inputs and get their values.

But the actual functionality of this class is to use public key encryption, RSA, to encrypt data from the form values. I think the idea is to provide additional protection, because if you store values of the forms in the browser side in some browser container, browser storage container, if somebody steals your machine, you will be able probably to access sensitive information.

So with this possibility to use encryption, I think the data will be better protected. I think this shows yet another very mature use of the JavaScript code to do something that is not trivial, which is to apply RSA public key encryption algorithms to encrypt, decrypt, sign and verify data that we used to see in the old days we would only see it in programs written in C because it would be a CPU-intensive task to encrypt all the data.

Well, later we've also seen it in PHP, but PHP, all that, is done with an extension which uses C library as well. So it's still all in C. But in this case, it is all done in JavaScript, and given the advances of the current browsers, it certainly gives you a new useful way to take advantage of JavaScript without being too slow to implement this kind of functionality.

So kudos to Jason for also yet another great component. This component was just submitted right after the Innovation Award challenge was started, so his package was already considered notable. That's why Jason is also featuring in the top notable package authors ranking.

Another component that I also want to comment, I'm trying to open the right window here, I think you all can see, if you are not distracted with Michael's glasses, this is another component from Hensel Hartmann, which is already a regular contributor.

Actually, I also would like to mention as a side comment that Hensel has been submitting a few articles to the blog. In this case, they will be featured in the JS Classes site blog. They need to be reviewed, but once they are reviewed, they will be published soon.

And Hensel in this case contributed a component, in this case named CDA Cross Domain AJAX, which basically allows you to send, well, not exactly AJAX requests, I mean, XMLHttpRequests, but rather requests to the server to retrieve certain resources on the background without reloading the page, so the effect would be similar to using AJAX requests.

Basically this can be useful to send requests to a server that may be in a different domain, that's why it's called 'Cross Domain AJAX'.

So without requiring all those permissions that are now supported in the latest standards of the APIs in the... I think it's XMLHttpRequest 2 that provides support to sending some headers to allow cross domain AJAX requests, but in this case it is not necessary because what it does is basically to create a script element on the page and use that to send a request to a given server to retrieve some JavaScript code that will be executed and will probably return some data or do something useful. So again, kudos to Hensel for his contribution.

Michael Kimsal: And I'd like to say something to Hensel, too: 'Gripsi.' Yeah, he'll know what that means. He'll know.

Manuel Lemos: Is that German?

Michael Kimsal: He'll know. It's just between me and him.

Manuel Lemos: OK. [Laughter] OK.

Michael Kimsal: 'Gripsi.'

Manuel Lemos: Maybe he can come to the podcast in a later edition and reply to you personally, whatever that means.

OK, and with this, we conclude this section of the podcast on which we comment on the latest components. Now with the Innovation Award initiative, at least this challenge phase which is not already the actual Innovation Award initiative, we can encourage more and more authors to submit more new components that we will certainly comment on future episodes of the podcast.

Upcoming articles on the JSMag magazine (1:07:59)

Manuel Lemos: And finally moving on to our last section on which our special rock star co-host, Michael Kimsal, will exhibit his cool glasses and...is that a mustache here? 

Michael Kimsal: Maybe. I just had some chocolate milk.

Manuel Lemos: Oh, sorry.

Michael Kimsal: Yeah.

Manuel Lemos: You did not find a napkin to get rid of that.

Michael Kimsal: No. It won't come off.

Manuel Lemos: Are you ready to comment on the upcoming topics of JSMag?

Michael Kimsal: Well, we've got a few things, and as always, things are always kind of up in the air.

Mike Schwartz is going to continue talking about his development of SilkJS, a server side JavaScript server that he's been working on. This month he's going to talk about session handling.

We may have something from Callum Macrae this month specifically on JSCheck. That's what I was talking about before. We have a piece on Phone Gap coming up.

We possibly have a couple of pieces on, or should I say a piece, on timers and creating timers and doing timing work in JavaScript, and likely we're going to have a piece on dynamic interfaces with images that move around.

All these are in the works right now or in the pipeline, depending on the writers and the editors. Some of these may be this month, some of these may be next month. It's just that if we were doing this a week from now, I would have a much better idea of exactly what we'd have, but we're kind of early in the month this month.

Manuel Lemos: Yeah, that's true.

Michael Kimsal: We may have something from Arturs in the next month or two continuing on Titanium, perhaps.

Arturs Sosins: Yeah, sure.

Michael Kimsal: Maybe.

Arturs Sosins: You know what? It would have sounded better with guitar accompaniment.

Manuel Lemos: Oh, yeah.

Michael Kimsal: OK. 'We're going to have some [Guitar Strum] JavaScript, some C programming, some PHP, and some JavaScript, back to JavaScript again. Then we're going to get a little sad, and back to happy.' Like that?

Arturs Sosins: Yeah.

Michael Kimsal: OK.

Manuel Lemos: Oh, man.

Michael Kimsal: That's going to be the bonus disk in the printed issues of JSMag next month.

Manuel Lemos: Oh, that's cool.

Michael Kimsal: I'm lying.

Manuel Lemos: For all that want to subscribe to the magazine, they can go to JSMag.com as usual.

Man, you almost poked yourself in the eye.

Michael Kimsal: Well, I've got the glasses to protect me. The glasses took care of that. No problem, though.

Manuel Lemos: Well, that's the problem because those glasses always appear in the front. [Laughter] But it looks like you've been poking yourself.

Michael Kimsal: Yeah, no. Yeah. It will get better.

Manuel Lemos: Yeah.

Michael Kimsal: So on that note, yes, that's what's potentially coming up. Anybody that would care to contribute, as Arturs and others have done, reach out to me at michael at jsmag.com or just go to the website and click 'Contact'.

Manuel Lemos: And obviously those that want to become rich, that's also a way to go because you pay for your...

Michael Kimsal: Well, I think Arturs would say you're not going to get rich doing this, but hopefully it helps.

Manuel Lemos: Less poor.

Arturs Sosins: Well, I could tell you one thing, Michael, that you don't know yet.

Michael Kimsal: What?

Arturs Sosins: Well, practically you have bought me a Mac.

Michael Kimsal: There you go. Really? OK.

Arturs Sosins: Yeah.

Michael Kimsal: How many pieces have you done? [Laughter]

Manuel Lemos: [Laughter] You don't remember?

Michael Kimsal: Goodness, OK. Well, look at that. You write for JSMag and you can buy yourself a Mac. That's awesome.

Arturs Sosins: That should be your slogan, you know.

Michael Kimsal: Yes.

Arturs Sosins: Motto, yeah.

Manuel Lemos: Is that a Mac from China?

Arturs Sosins: No. Hopefully from USA.

Michael Kimsal: Look at that. You don't have that import in Brazil.

Manuel Lemos: Oh. I need to go to Latvia to get a cheaper one.

Michael Kimsal: Yeah.

Manuel Lemos: Over here it's like double the price.

Arturs Sosins: No, exactly. Here in Latvia it's also double the price that they pay in the USA, so it doesn't matter.

Conclusion (1:12:04)

Michael Kimsal: Well, I'm going to play us out. I think we're at the end of the podcast.

Arturs Sosins: Yeah.

Manuel Lemos: Right.

Michael Kimsal: OK. What should I play?

Manuel Lemos: Well, play something while I finish the podcast just commenting that other than contributing more and sending articles to JSMag as well, if you have an interesting JavaScript project, now that we can benefit of these sophisticated resources of Google Hangouts, we can have you on screen and you'll be famous and you can wave to your mother, "Mommy, I'm on TV!" and you can show your JavaScript projects here.

Just write to the site address and we can schedule your presence in upcoming podcasts. Your projects do not necessarily have to be some package published in the JS Classes site. It can be something else, as long as it is JavaScript-related.

Other than that, I hope to see you all next month and comment more interesting stuff on JavaScript. So on my part, that is all for now. Bye.

Michael Kimsal: [Guitar Strum] Yeah! That sucked. That's horrible.

Manuel Lemos: Imagine if you did not suck.

Michael Kimsal: Yeah. I think I'm still better than you, though. I'm pointing at Manuel, not you, Arturs.

Manuel Lemos: That's for sure.

Michael Kimsal: Yes.

Manuel Lemos: That's for sure. OK, that's all for now.

Arturs Sosins: OK, bye-bye, you guys.

Michael Kimsal: Bye-bye.