Developing JavaScript Applications using PHP functions - Lately in JavaScript podcast - Episode 5 - JS Classes blog

Manuel Lemos: Hello, welcome to the Lately in JavaScript podcast.  This is episode number 5 of our podcast and I am Manuel Lemos the regular host, and as always I have here Michael Kimsal.

Michael Kimsal: Good morning!

Manuel Lemos: Hello Michael, how are you doing?

Michael Kimsal: Buenas noches, I'm doing great.

Interview with Brett Zamir on PHP.js (0:44)

Manuel Lemos: You better say Buenas noches again because today we have a guest on our podcast. Brett is over there in China joining us from there, hello Brett, how are you doing?

Brett Zamir: I'm great, how about you guys?

Michael Kimsal:  Fantastico.

Manuel Lemos: From what you told us before you are in China, right?

Brett Zamir: Yeah, in Shenzhen China, right across from Hong Kong.

Manuel Lemos: But you are originally from?

Brett Zamir: No, I'm from Chicago, originally, in the U.S.  I came here to teach English about a decade ago and I got hooked here and my wife is Chinese, I'm living here with my family.

Manuel Lemos: It's interesting, somehow I also changed countries more or less ten years ago, just went another direction.

But in today's podcast, actually the reason why I invited Brett over this podcast is to talk about an interesting project. Actually we commented a bit about it in I think it was the first episode when we had Mário Valente to talk about several JavaScript related subjects. And that project is PHP.JS which is somehow a port of PHP functions and API's to JavaScript.  Is that correct, Brett, the description of this project?

Brett Zamir: Yeah, basically just porting the PHP functions and some classes into JavaScript. Sometimes some people maybe confused, they think we're parsing PHP or some server side library, but it's all pure JavaScript.

Manuel Lemos: Well, that's an interesting project. Actually I've never seen something like that. What exactly motivated you to develop this project with that goal?

Brett Zamir: Sure, well first I should mention the founder of the project is Kevin Van Zonneveld, and he started the site in 2008.

I had also had the idea for this at a similar time, but he ended up I think building the momentum up first and on his blog initially, and then eventually it became a separate site, and when I saw what he was doing and the license of the code was very open and just decided I'd start contributing and that's how I got involved.

So, anyway, as far as the motivation basically I think many of us had come from PHP backgrounds and we found the many hundreds of functions that you use in PHP to be pretty useful, but when you go to a JavaScript environment it's kind of sparse as far as the built-in functionality that you get, as great a language as JavaScript is.

 And we were looking to sort of replicate that core functionality but also leveraging the functions, the API's and so forth that we were already pretty familiar with.

Michael Kimsal: This seems to me, and I don't think I didn't get this from reading the site, I didn't get this from... actually I'd known about this project for a while, and I don't think the motivation was this, was to reverse things, but we see a lot of the argument for server side JavaScript is because people have cut their teeth over many years using things like jQuery and whatnot on the browser, and the argument for server side JavaScript is use the skills that you already have in the browser and then you can take them to the server and you can have one language to use in both contexts.

And again, I didn't hear this as a motivation but you're kind of going the other way, you're saying hey we got people maybe a decade of PHP experience, maybe you can even remember haystack needle or needle haystack, but you've got a lot of that experience, take that to the browser so you don't have to rewrite and not even just rewrite but rethink how you work.  Is that maybe a safe benefit, have you found that to be a benefit yourself?

Brett Zamir: Absolutely.  I'm actually kind of new to it, I'm just getting into like Node.js and server side JavaScript, but yeah absolutely, I've wanted for such a long time just to be able to whether it's for code reuse and even very bright people, I know a guy who basically could write assembly language comfortably and even he was telling me that when you learn enough languages you start confusing them or it's just helpful sometimes, you don't need a thousand different ways to say apple, and I think the same is true with coding.

So it's nice to be able to go full circle and take what's useful from PHP as far as some built-in functionality, but then also whether you bring it to the server, whether you bring it to a browser extension, client-side JavaScript or whatever, it's got a lot of... the great thing about JavaScript I think it's got so many... a lot of environments it's becoming like a world language in a way.

Michael Kimsal: Oh, yeah, without a doubt.

Manuel Lemos: I think it's very interesting, and I think that point that Brett mentioned regarding the fact that many of us came from a PHP background it certainly will be helpful to at least us. I am from a PHP background, Michael is also from a PHP background, so I think now that more and more we use JavaScript for complementary functionality on the browser, or maybe some of us already tried things like Node.js on the server, it certainly will be helpful because we are so used to doing things in PHP that sometimes we wonder how can we do this in JavaScript.

And basically what this PHP.JS project allows is to quickly learn at least a way to implement certain functionality in JavaScript that we are used to benefit when developing in PHP.

But, sorry, you already mentioned the founder Kevin Van Zonneveld, right?  I'm not sure if I'm pronouncing his name correctly.  I also did not mention your surname, Brett Zamir, right?  And there is a long list of authors here in the site. I did not count all of them. I'm not sure if this is a sort of ranking of who has contributed more because as a number in the front is this the number of functions or what is it?

Brett Zamir: I'm not sure, I don't remember off hand about how the license lists the people, but there's an author's page which lists the number of contributions.

And I think one interesting thing about this project from a management point of view is Kevin was very generous I think in just encouraging people to contribute no matter the initial level he would give credit to somebody even if they just reported a bug, and I think that really invited participation and made a really nice environment.

So for people who want to know contributions there's a... I mean we have it in source control now, we've moved it form subversion, we've got it in GitHub now, but I mean you can look at the repository but he's also still, we're also still keeping track of it inside the functions.

And yeah, so we've got a lot of people on the periphery who are making reports and we're including them, and then we've got a few core people some of whom come and go or are still around, but for example recently a person has come, Ratheous, if I'm pronouncing his name right, I'm not even sure myself, but he's made some really sharp contributions, and we've had other people over time like Onno Marsman and some others who have helped shape its development.

Manuel Lemos: Right, it's a lot of people. And I think this idea, it's in this author's page, seems like a ranking who has more contributions. And it seems like a good idea because somehow it acts as a teaser for contributors to contribute more so they can raise in the rankings.

I know that works well because both in the JSClasses site and PHPClasses site I also have somewhat similar rankings based on number of users. It's a different count, but the goal of using rankings is somewhat similar.And it's quite amazing, a lot of contributors.

And what exactly is the main goal of the project, is it to cover all functions and extensions of PHP or a more modest goal?

Brett Zamir: Yeah, especially the more core libraries and whatnot. We've covered, we've kind of just tended to pick and choose what seemed relevant.  I'd say that most of the functionality right now is limited to client-side JavaScript, so for example, file_get_contents which is a pretty handy PHP function, we use that, it's pretty much just for AJAX right now, but there's the potential to adapt it as an adapter for server side JavaScript.

So yeah, it's pretty much limited to that but we haven't narrowed down the scope arbitrarily. So if there's anything that's possible to be implemented we've kind of tried to find ways to do it, and for those few cases where it kind of deviates, it has to deviate from PHP because just of the nature of JavaScript, we put those functions in the experimental section.  If you go to the functions page there's a link leading to our experimental section or some other sections.

Manuel Lemos: Right.  I imagine that just like you said there are differences in the usual environment on which the languages usually run, like the fact that you don't have access to the machine files when you are on the browser side, at least directly. So you focus that for solving the access to remote files via AJAX, right?

Brett Zamir: Right.  We just implement that, but I think I added a little bit of an API, for example, I've done some work in Firefox extensions so in that particular function I put some, I think I might have an API for accessing if you're in a privileged context you can use it for getting content on the client side, but unfortunately I think HTML 5 seems to be... I've seen mention about a file system object, and so it seems like maybe there will the potential in the future to see some of this on the client side too.

Michael Kimsal: Cool.  Manuel, I had a question that I had sent to Brett just a moment ago I'd like to throw in here, because I'm looking at the PHP.JS site.

I'm looking at the implementations of the functions, and at least some of the ones I looked at it doesn't look like there's a lot of necessarily a lot of reuse between the functions. And I'm wondering if I'm interpreting that correctly, if there is and maybe I'm just not looking at it, or if there's not, because it seems like most of the functions that are implemented are implemented more or less stand alone.

And then from that there's actually a couple things, if that's correct I'm thinking that might encourage people to just be able to put their own implementation in or submit their own one function in JavaScript rather than having to learn a whole framework.

But the flipside of that might be that the actual PHP.JS environment when it's running might be larger than it needs to be.  Could you talk about some of those internals for a little bit Brett?

Brett Zamir: Sure.  Interesting questions, good questions.  Yes, you're correct.

Michael Kimsal: So, internal architecture, code reuse, non-code reuse, performance, size, all those things, can you talk about those?

Brett Zamir: Sure.  OK, as far as reuse you're correct, that was a design decision by Kevin and I think it was a good one. We basically wanted for the most part people to be able to just come to the site, pick up the function they wanted or two, and then just run with that.

And also the compiler which Kevin built allows you to select just the functions you want, and I think it also handles the dependencies for you because in some cases there are some dependencies when there was really a good need, when there was a very significant amount of code that could have benefitted from that.

So, yeah, we've tried to make it independent and, in fact, using a little trick appending the this object, we just this object to refer to our functions internally so that if you're using, if you're copying a function and pasting it into an object like our name-spaced object it will work there in a name-spaced way, but it will also work as a global since this is interpreted as a global when it's not in an object, when it's not called with new or whatnot.

So, yeah, we do reuse code when it's compelling, but we try to keep it more... that's maybe different as you say from other frameworks, there's not really a framework strictly speaking.

However, there is a way that some items work in sort of a framework way, for example, the INI settings, just like in PHP, PHP.JS you can use functions like ini_set which coordinates configurability using a pseudo-global, it's global if you're in the non-name space version, if you're in the name space version it's just the instance object.

And anyway, yeah, so that is something for example that you can coordinate behaviors between functions or it also allows us to track states in some cases like the string token, strtok function needs to know about the state, there are other cases like that where it does work in sort of a framework way, but usually it's just pick and choose whatever you want, whatever you want out of the library.

Michael Kimsal: Cool.

Manuel Lemos: Personally I think this project is amazing if not to use it as a compiler to convert your PHP code to JavaScript at least to borrow some code or at least learn how certain things would be implemented in JavaScript when you have no idea but you have a good PHP background and know how you would do it in PHP.

Brett, what were or continue to be the greatest technical challenges that you guys encountered while trying to map functionality between PHP and JavaScript?

I'm thinking for instance did the nature of JavaScript be mainly asynchronous, at least implement certain aspects, did it interfere or pose any challenges to accomplish anything that you do, for instance, in a more synchronous way in PHP? What can you tell us about regarding your challenges?

Brett Zamir: Sure, let me just if I could just first mention I think one of the issues that maybe I don't know if you're interested to get into it, but just in general there's a little bit of some of the bigger objections were actually not as much technical ones as they were people have something against PHP for some reason or another, and a lot of times it's because of a misunderstanding of either PHP or of our library, in some cases it's because people just didn't happen to like the API.

I think it was Michael mentioned that haystack needle or needle haystack, some inconsistencies in the API, but I think overall it's recognizing the audience here, that if people like PHP and like working with it it's good for those of us in that position, and those who don't like the API also free to adapt it, I mean this is JavaScript after all so that can be adapted.

But sorry, I just thought I should mention that point because that's one of the more significant things that comes up for us.  But as far as technical challenges, yeah, there are some major and minor differences, as you mentioned, synchronous or asynchronous.

For example, in let's say echo where that's a function that I still would like to do quite a bit more work on, but the question is for example if we implemented let's say output buffering code by we have the ability to store whatever strings the user's adding into echo, and if they've turned output buffering on we can kind of allow them to selectively store those strings, and then later on we can actually echo them whether it's to the document body or whatnot, so it does provide some interesting challenges.

And as you mentioned with asynchronous connections, for example, file_get_contents, which is synchronous in PHP, and if people are expecting a return object right away then of course it has to be synchronous.

So that's the default way we implemented it, but we do allow and thankfully PHP made it easy for us to allow configuration, sometimes we can do the configuration in a more PHP way, and sometimes we use INI settings.

So, for example, in PHP file_get_contents you can do a add a stream context to the arguments, so we added our own configuration item so that you can specify that you want file_get_contents to work asynchronously, and it's just kind of fun in some ways to find all the ways where we can leverage what PHP already does to make it work.

Manuel Lemos: What I was wondering, because I browsed the code superficially, I saw that in certain cases you call somewhat what seemed to be private objects to implement things. They do not belong to the PHP space. They are some objects that you used to implement certain functionalities.

So I could not figure exactly how do you provide synchronous functionality, but now that you mention it may work asynchronously I wonder if you actually can make it work synchronously somehow with some trick that I'm not able to figure what it could be.

Brett Zamir: When you say synchronously you're talking about getting file data?

Manuel Lemos: Right.  For instance, when you call file_get_contents it will retrieve something and will it only return when it gets to complete contents or did you make it asynchronous?  What did you do?

Brett Zamir: We filed the default way of PHP which is synchronous, so we make synchronous AJAX connection just because especially if somebody is just coming to this library the library is intended to be useful whether you're an advanced user who wants to adapt it, you know, take the parts you want and adapt it to your needs, or whether you're a beginner who just happens to know file_get_contents and they just want it to work.

So if we didn't do it as the return object and added our own callbacks in a non-standard way it might not be able to leverage what the user already knew.  So we do do it synchronously by default but we allow the user to pass in a stream context which I think is a callback that will be invoked when it returns.

Another way we do it is I mentioned INI settings which ini_set is a PHP function which lets you configure things, and what we did was basically when you want to configure something there is no PHP setting for it, we just add a prefix just like PHP JavaScript, PHP.JS, at the beginning of the configuration item.

For example, let's say you want PHP JavaScript to treat objects as though they are arrays or you don't want them to treat them as though they are arrays.

We have a configuration setting so that when you use let's say the is array function whether it's going to actually treat them as associative arrays or not there are some issues with that I'm trying to work on because, I don't know if you want to get into that, but so basically we deal with differences by either putting functions in the experimental section or using INI functions or by taking advantage of arguments that PHP already has like stream context.

Manuel Lemos: Right.  Well, it seems to be quite a challenging project.  I was looking here it says 81% complete. What that translates to is if the number of functions that were finished or does it involve more complex extensions that usually in PHP are optional?

Brett Zamir: Yeah, I mean there are actually I think if you included all of the possible extensions and libraries, there would be several thousands of these. What we've basically included is if we've actually started a function from a given extension, if we at least implemented one of them and we've included that in the total. So if there are other functions in the category that is possible for us to implement we include those in the totals.

Manuel Lemos: Right.  So it seems if you say that you're including all possible extensions 81% seems to be quite a lot already.

Are you looking for more contributors? If so, what should any interested listeners or other people that know about this project can do to approach and contribute somehow?

Brett Zamir: Yeah, we absolutely welcome anyone whether it's submitting, you know, if it's a bug fix, they find a problem, if they find something they can optimize it or a new function, we do have a good number of... for example, we've got 84 listed as unported that we'd like to port, and that's not even including the other extension libraries out there that could be possible to port, including for server side JavaScript.

So yeah, contributors most welcome, like I said, it's on GitHub but also the web site has a simple comment system so if you just want to leave a comment for a particular function it's really easy to offer feedback, or if somebody has questions if they think something might not be right they're welcome to send those kinds of comments too.

Manuel Lemos: Great.  Well, I will add a link to the show notes, but the address of the site is quite easy, it's PHPJS.org. Anyone interested to contribute just go to that page and follow the instructions that you find that either download the project or get it from GitHub and start contributing with whatever functions there are missing.  So congratulations for this project.

Brett Zamir: Thank you.

Latest browser releases: IE 9, Firefox 4, Chrome 10, Opera 11 (32:09)

Manuel Lemos: Well, moving on to the next section of our podcast, lately several new releases of the different Web browsers have been launched. And I thought it would be a good idea to comment on the new features of those browsers and somehow how can we take advantage of those features to improve our sites even if it takes advantage of certain browser specific features.

Well, now specifically talking about browser specific features that I have noticed in these latest browser releases, starting with IE 9, there are certain features that are not related exactly with JavaScript but you can take advantage of them to enhance your applications.

One of them is the ability to pin down your site pages, so the user can drag the current page tab to the desktop bar and it leaves it there with an icon so you can start with that page very quickly the next time you want to use it.

And the icon that shows the desktop bar is taken from the favicon.ico , it usually is very small, 16x16 pixels, it will probably look nicer if you had a better resolution picture, and now IE 9 also uses a 64x64 pixel image if it is present in the favicon image, but still that is not related with JavaScript.

What is related with JavaScript are some interesting features that you can take advantage of regarding a sort of menu that opens when you click on the icon of the pinned down Web page. They are some menu entries that you can define and add to the menu for that pinned down application.

Michael Kimsal: This is IE 9 you're talking about, right?

Manuel Lemos: Right.  I'm not sure if you can control those with JavaScript because I saw that there are some meta tags that you can define those menu entries. But one thing that I found that is interesting and directly related with JavaScript API added with HTML 5 which is the ability to show somehow notifications, Web notifications, in the desktop bar.

Actually there is an API defined by the standards body for desktop notifications. And it seems that IE 9 provides that API, so you can somehow notify your desktop in case you have your browser window minimized so the user knows that there are some notifications on that web page. I think is particularly useful, for instance, for chat applications like gTalk, Web based chat applications.

Michael Kimsal: Convore.com is a fairly new one as well, too.  I don't know if they take advantage of IE 9 notification because it's so new, but that would make sense.

Manuel Lemos: Right.  Actually this is not specific to IE 9. I suppose that WebKit based browsers also support that API or at least something similar because the specification of this API goes back to 2006.

And in the case of IE 9 there is a demo application that Microsoft put up to show a Twitter feed for a certain keyword, let's say you want to know what are people saying about JavaScript in Twitter, you can just enter a JavaScript word in a page that they provide just for that demo application, and every time there is a new mention about JavaScript it shows in the page the mention of the Tweet that came out.

And if you minimize the window, the desktop bar shows over the icon of that application that is pinned down, shows a count of new web notifications that have been added since you minimized I think. And that is interesting because it somehow provides a feature that until now it was only available to non-Web applications.

Michael Kimsal: Things like Growl notifications on the Mac and I think there are Windows and Linux equivalents. I haven't seen any, personally I haven't seen any unified approach to that yet, but with a standard and maybe IE's now supporting this as well, maybe there will be a standard to allow notifications from the Web to be picked up by client side, totally client side notification systems like Growl and integrate them, that's the word I was looking for, integrate.

Manuel Lemos: Right.  I think Chrome and probably Safari already provide support to desktop notifications, but I don't know in practice how it does translate if they provide similar features to IE 9 like this ability to show the count of new notifications pending for you to see for each application because this is directly related with the ability to pinning the pages, so the notifications appear on the pinned page, the notification count.

Well, this web notification thing seems interesting with good potential to enhance applications that provide updated states on the pages, and once the user minimizes the window these notifications can get his attention back to the browser window again.

Other than that, other features that I also found interesting in IE 9 were more or less things that they already had before like their built in debugger that is now a permanent part of the browser, I think it was already there since IE 8, but is now enhanced with benchmark tools for those that want to determine how they can improve the performance of their scripts, including networking traffic.

There are other features, I did not try to go much in depth on those features, but basically now they tried to follow more the standards for API's to do many things like they already provided in the past but now since there are standard API's to implement those things they are providing those API's, this is more or less common to other browsers.  I don't know if you guys also tried IE 9 or have anything to comment on about it.

Michael Kimsal: I've not tried it yet personally. I'm glad to hear that there's an enhanced debugger, but I have to say Chrome, Safari, Opera, IE, I've tried the bundle developer tools/debuggers that come with them, and it could just be because I started with Firebug, all of these seem really complicated and confusing, convoluted and lacking all at the same time. And I find myself sticking with Firefox and continue operating Firefox just to get Firebug because everything else feels really clunky.

I don't know if anybody else has that experience, but maybe IE 9 will be good but that's still only going to help me in a small amount of cases.

Manuel Lemos: Right.  Well, for me I've tried Firefox debugger because it's not just Firebug that matters, and you have to single step over the code, you have to use debugger, and there is that Venkman extension.

Michael Kimsal: For me Firebug is it.  We'll have to agree to disagree here.  Brett, are you going to defend me or are you going to side with the enemy?

Brett Zamir: Actually I kind of do my debugging the old fashioned way. I haven't got as much into debuggers, but I have to say although I think anytime there's something new it can be intimidating, to me what's interesting the functionality I think of Chrome's debugger looks like it would be worth learning because it seems it can do some things that, you know, monitoring and tracking things that Firefox doesn't have that capability at the moment, at least as it appears to me, but yeah I'm a huge fan of Firebug for sure, that's what I know best.

Michael Kimsal: Whoo!  I win.  I won!  I won!  He agreed with me, I won.

Manuel Lemos: Right.  Actually I did not ended what I was talking about.  Basically when I need to single step over code to figure...

Michael Kimsal: Yeah, I use Firebug.  When you need to single step over code, JavaScript code, in the Firefox you use Firebug, and if I need to single step over it in Opera I still go back to Firebug and Firefox and just keep doing it there until I get it right, and it works in Opera and Chrome and whatever.

Manuel Lemos: The truth is that I have not been using Firefox for a long time because I've switched to Chrome, it's much faster.  Actually, talking about speed, it's good to know that finally Firefox has caught up on speed because it was practically unbearable, and for the time that I was using Firefox I used to use Venkman, so I was not really familiar with the ability to single step code on Firebug, that's why.

Michael Kimsal: There you go.  Well now you've learned, you've learned something and I learned something.

Manuel Lemos: Right, that's always good to know.  And anyway I think the debugger on IE is quite good in terms of user interface, I also agree that Chrome's debugger user interface is quite confusing, they tried to cram a lot of things in a small space and it's hard to figure what each button is that you want to use to single step and it's back to variable.

Michael Kimsal: Given Brett's endorsement I will have another look at Chrome, but not this week, it will have to be next week.  I got too much going on. I don't have time to learn something new.

Manuel Lemos: Right.  And I also looked into Dragonfly which is the Opera debugger, it is also not exactly new, but personally I don't like Opera very much because it tries to overdo optimization including caching, it does aggressive caching of pages, so whenever I try Opera it's just to see if everything works well on that browser because sometimes I want to flush the cache and I cannot figure where it is there, but I actually tried their debugger and it seems almost all debuggers sort of copy each other, so it's even hard to figure which one started the trend to look this way, but somehow that's my impression that I got from how all these debuggers work nowadays, they're pretty much very similar.

Other than that, I don't know much about Safari because I'm not on the Mac and in spite there is a Windows version I'm not a Windows user, so I don't know much about its state.

Michael Kimsal: You're not missing much. 

Manuel Lemos: Right.  And basically what I think it seems is that probably it's very on par with Chrome because it was all based on WebKit.

I think for me that's all that I could figure. There are probably more interesting features on these new browser versions for web developers, JavaScript in particular, but I could not figure much more than this.  Anything else you guys would like to add on this topic?

Brett Zamir:  Maybe just on HTML 5 itself, I think specific to the browsers I don't have anything in particular.

Manuel Lemos: Right.  Well, on HTML 5 I think that most browsers are adopting the standard specifications. And the only thing that I actually missed that none of the browsers seemed to have implemented, probably because the specifications are a bit immature, is the ability to capture audio and video which is something that traditionally is done in Web application using Flash.

And we can get rid of that dependency capturing audio and video, there is already a standard defining how that can be done using API's, but so far I did not see any good implementation on any browser. I noticed there are some patches but that's all that I could figure.

Latest most interesting JavaScript objects in JSClasses (49:56)

Manuel Lemos: So moving on with our podcast now reaching the end, we have a regular section on which we try to comment on the latest objects of the JS Classes site.

Lately there are quite a few interesting objects, and not as many as I would hope, also because this time we tried to record earlier in the month so it did not leave much time. But there are still a few objects that I think to be worth mentioning.

Would either of you guys like to comment on any objects that you have noticed, Brett or Michael?

Michael Kimsal: Well, I was going to throw out one first, one of the more recent ones, and I got to grab this and play with it a bit before we recorded, from Arturs Sosins, I hope I'm saying that correctly, from Latvia, the Keyboard, the JavaScript Keyboard class, and it gives you a nice on-screen keyboard and gives you ways to just click around and accept stuff through that.

Now, it's an interesting implementation from a code standpoint and it looks nice, it still strikes me that the majority of people that would need an on-screen keyboard are probably people on mobile devices, maybe using a Samsung Galaxy Tab or an iPhone or some other Android device which generally come with their own onscreen keyboards anyway, if it's an input field the device will know to put one on there.

So, from a practical standpoint I don't see many day-to-day uses for this personally, but I thought the code itself was pretty slick.

Manuel Lemos: Right.  I also noticed that object is quite good and sort of complete in the sense that not only can it display on-screen keyboard that makes it useful for users that need to type something on a page using a device only that they do not have a keyboard, but I was saying it is quite complete because one of the things that it provides is the ability to switch the key map.

So if you want to use a key map, for instance if you want to type Chinese letters, you have a key map you can switch to it and obviously I'm not acquainted with Chinese.

Brett Zamir: I don't know if you want to make a keyboard with several thousand or tens of thousands of characters, that might be pretty big.

Manuel Lemos: Right.  I know it's possible, I don't know if it's feasible or interesting at all, but this is somehow just to show the flexibility that this object provides.

Michael Kimsal: Actually, let me throw this out real quick because I did come across, I actually came across a situation where something like this would have been useful, and it was a kiosk situation, it was a kiosk I think it was in a hotel, and they had a screen up and it wasn't really a touch screen but something was there, and they actually had a popup keyboard.

I don't think it was anything built into Windows, it looked like it was sort of a custom control, but for stand alone, sort of stand alone kiosk mode apps where you don't necessarily have a physical touch screen, you don't want to buy the Elo touch, or whatever it's called to get the touch, this would be a good thing to put on there, so there you go, I thought of one.

Brett Zamir:  I do think it has its uses too for other languages, yeah, including Chinese or others, Arabic or Hebrew or others that have the more limited set of characters, or even symbols and whatnot.

I worked on an extension for Firefox called Unicode Input Tool Converter which lets you input, but it's not an on-screen keyboard and it's not in HTML, which would be I think really pretty handy, I think it could be useful for that kind of app where you can define your own key set too, it might be interesting.

Manuel Lemos: Right.  And other than that, any other objects that you found interesting?

Brett Zamir: I noticed that Fabian Vogelsteller from Germany made one on jsGET, which actually kind of parallels one of our PHP JavaScript functions. It looks to be similar where you can get from the URL a hash and get the variables that are included on the URL which can be pretty convenient, a lot of times people don't think of the fact that a JavaScript application can utilize that information, in fact, one of the HTML 5 API's is going to deal with that, for example, AJAX applications can be bookmarked and whatnot in a more regular way.

Manuel Lemos: Using the hash, right?

Brett Zamir: Hmm-mm.

Manuel Lemos: Actually there is also an interesting API that is now standard, it is the history API, but it's one of those API's that even if it is present in a browser, I think it will be hard for many of us to use it, not because of any technical difficulties, but because we need to somehow figure how to make it work in older browsers.

So it's great we can use these API's but we still have to catch up all the older browsers.  OK, any other objects?

Michael Kimsal: The most recent one, it looks like it's from Daniel Martinez, while we've got Brett here talking about PHP.JS, this looks like it's... what's the name of this one? It's the JSON converter, array to JSON converter.

And it just seems like that's probably something that PHP.JS handles in it's own way as well, I think it's just 1500 bytes so it's pretty compact JavaScript class that handles that.  It's just interesting for me to see different people's approaches to effectively the same kind of problem.  I think I said his name, Daniel Martinez from Spain, Hola, Daniel.

Manuel Lemos: Well, other than that I'd just like to comment that several other interesting objects were published like Arturs Sosins, like Michael mentioned before from Latvia, and he's becoming quite a regular contributor, not just for the quantity but also for the quality.

He's also a regular contributor on the PHPClasses site. Kudos to him for continuing to contribute to JSClasses site, as you mentioned he contributed this class for emulating keyboards, but there are others also interesting.

The one that I would like to mention is this Content Slider object. What it does is not exactly new but the effect that it provides is the ability to slide content like you can see using many libraries like jQuery and others that provide animation effects.

And what I notice that is interesting is not only can slide the content but you can sort of drag the pages as if it was handling touch events of dragging some content on the page, and it can do it in any direction, right, left or vertically, whatever you want.

And despite it's not exactly a new thing it's always interesting to see this in a stand alone component. You don't have to download a large JavaScript library to benefit from this effect.

Well, basically these are the objects that I would like to comment more this time.

Upcoming articles in JSMag magazine (59:45)

Manuel Lemos: Now moving toward the end of our podcast, Michael, I don't know if you already have ready your comments on the upcoming articles of your JSMag magazine.

Michael Kimsal: We got a few things. Just a couple of things I'll say about JSMag, I mentioned this in our last podcast. Just like you, Manuel, are always on the lookout for more classes, for stand alone classes for JS Classes, we are always on the lookout for new and interesting content for JavaScript Magazine.

And I mentioned this in the last podcast and I had somebody reach out specifically, Dino Gambone contacted me and said hey I heard you on the Lately in JavaScript podcast and he had an idea for a series, so we talked about this and he's going to be developing a series of pieces for JSMag on game development.

He's really into games, we go back to some classic 80's games, and he's really into game development, so he's going to be doing a series doing game development using server side stuff, so initially probably a piece or two on using server side JavaScript to create some multi-player like MMO RPG, I forget what they're called, like MMO type games, large virtual world sort of games is what we're getting at.

But it's going to focus largely on the server side JavaScript aspect and then we may get into some other ones, some other types of games later on, but I'm excited to have him doing this for us for a couple of reasons, one, it came from this Lately in JavaScript podcast, so you've got some listeners and they have a lot of good stuff to contribute, and two, I like talking to people about old games, we had a lot of stuff about Zork and Infocom games, we had a good discussion on that.

We've got some other pieces coming up, a friend of mine named Robert Cameron who wrote for us years ago is doing a series on another server side JavaScript piece talking about using Spring, Spring components from the SpringSource company, using those in client side JVM, so using JavaScript things, using Java libraries, Spring Java Library in Rhino on the server.

And Mike Schwartz is going to be starting off, he'd done a large series for us on server side JavaScript developing a whole application and using Helma as a server side JavaScript component. Now he's going to be revisiting similar topics but using a new, not Helma but something else, and I'll leave that up to everybody to go pick up next month's issue.

Nick Carter's going to join us and he's going to be doing a piece on require JavaScript or requireJS as a toolkit for helping deal with dependencies, we're looking forward to that, and we're also going to be starting a series on testing probably in the next month or two reviewing multiple testing tools for JavaScript

So we've got a lot of server side stuff coming up in the next month, and potentially if Brett has time he may be doing another piece for us on PHP.JS for JsMag as well too.  So that's kind of the JsMag plug, reach out to me, Michael at jsmag.com if you're interested in learning more about it, and thank you.

Manuel Lemos: Great, that's good to know.  I'm glad that you are getting some new contributors that are somewhat led from listening to the Lately in JavaScript podcast.  I hope you get more, and as you said, Brett is also... Brett or any other PHP.JS contributor is welcome to write on topics, on articles for JsMag.

I would also like to extend that invitation, if any of you would like to write an article for the JSClasses site blog you are also welcome, and hopefully it will also help you to get more contributors.

Michael Kimsal: As an addition to this, in our outreach for content I can say this for JSMag and I assume that you can offer something similar, some help as well. One of the biggest issues that people have that I've found when I talk to them about content is they say sometimes I'm not a good writer, English isn't my first language and so on. I would still encourage people whether it's JSClasses or PHPClasses or JsMag, don't worry about that.

If you're writing software already and you're good at what you do the English will come, or we have editors that help you work through phrasing and wording and they'll say here's a better way of saying that, you forgot this and so on, but just get your content out there and however don't worry if you make a spelling mistake or whatever, people can help you with that.

So don't let that hold you back from contributing to anything, don't let it hold you back in life, let's be broader about that.  There's always someone out there like Brett who can help you learn English, right Brett?

Participate in Open Source technology groups in China (1:05:17)

Manuel Lemos: Okay, well this was a great show and we covered some interesting aspects, news in the JavaScript world.  As final remarks, Brett, I wonder if you would like to comment on anything else that we did not cover on this podcast.

Brett Zamir: Well, I just thought I'd mention one thing that we're doing over here.  In coming to China we follow whatever other news in technology and China comes up quite a bit on issues about intellectual proprety or whatnot.

Basically my feeling is that it's great to bridge cultural divides and try to improve relations between people.  One of the issues that I found over here in China specifically was that people don't tend to know a lot about open standards, open source tools that might be able to help them.

On the other side because of that and kind of interrelated with this is people tend to disrespect intellectual property sometimes, although I know some guys for example, one guy here that refuses to watch anything that's been copied or do anything, you know, very principled, but in general I think if there's more awareness, then hey, there's stuff out there you can use legitimately and have self respect in developing code ourselves which is open, you can feel good about that, and also by learning these technologies we get a chance to open ourselves to new markets too because there are a lot of users who are not using free software.

So basically I decided to work with some local guys here, some of the guys I work with, and just others that is open to anyone who basically every three weeks we cover a new topic, each person is welcome to present something where we introduce, for example, one week I introduced a pencil, a mockup program for Firefox, an open source tool that programmers could use, and they in turn offer classes on new techniques in JavaScript they were learning or HTML 5, and we've basically been trying to promote that.

So hopefully we're hoping that out of this comes more familiarity with these kinds of technologies. And I think it's kind of fun also to meet with local people, and we're going to be contributing with wiki for them to learn about, try to improve the awareness of these things so we can see for example China contributing a lot more to open source and we all benefit from it as they get into these things and of course it helps their own plans locally to be aware of more tools you can use.

So that's something I've been getting into and enjoying, but we want to kind of expand it and maybe branch off once we get more than a good number of people, so hopefully we can kind of get a self-sustained movement here and keep it going.

Michael Kimsal: Well, it's interesting from my part to hear that you're doing what you can as a, I want to say as a westerner, over there sort of from the inside from a software perspective.

My limited experience was in Shanghai a few years ago, I went over and my role was that of a software auditor and I was reviewing code that was going into a cell phone, and they had done the initial draft they had used the initial engineers had just copied code right and left and their initial audit had caught a lot of stuff that legally they can't use.

And we found a couple of potential minor violations in terms of code linking and stuff like that which they shouldn't have been doing, or if they do they need to release code, but it was kind of surprising to me to learn, this was four years ago, how I guess cavalier the attitude was, and hopefully with efforts like yours you'll be doing more to let people know that you really shouldn't be copying that, but you can use this, and it would be great also if you contribute back, but some things BSD even if you don't, that's fine.

So good luck on that, it's good to hear that you're able to bring that sort of perspective and it sounds like a guiding hand in the right direction.

Manuel Lemos: Basically are you running a local user group?

Brett Zamir: Basically it's like that, we're not focused on... I'd say the closest we've come to a focus is particularly Web stuff, although last week I think I presented something on Scala, but usually I think we're more focused on web standards and then also open source.

And the guys really bring a lot of energy to this, you know, when you just filter everything through the media you might get this impression that they're just trying to steal everything, but it's just kind of habits and when people, like you said, they see what's available they contribute back too.

The guys are enthusiastic, I think really pleased to get involved, they've made bug reports and got a lot of skills that we don't learn even in the U.S maybe in computer school, whether it's using Subversion version control, that kind of stuff that takes a little bit of time to learn in order to contribute or try to help each other with that kind of stuff.

Michael Kimsal: I want to throw out one more thing here.  I was not meaning to imply that Chinese engineers are more prone to IP violations. I've worked in Western organizations where people, they would find code, Google for something, find it, and they would copy it and didn't even care, didn't even understand in some cases that there was any sort of a copyright or IP associated with it.

What I saw though in China was that, at least the project that we were involved in, one code violation was going to mean that half a million devices or more were going to be infected or have that problem with them, whereas that sort of scale of violation doesn't often happen if somebody's just sitting building a bug tracker for their own office the violation is more theoretical than practical.

And when you've got a large company, which I will not name, that's going to be redistributing these things in the U.S. and Canada, anybody that wants to sue them for a violation there's very deep pockets involved.

So the potential for one small violation over there given the manufacturing-ness of China and where they reach from a global scale has a much bigger potential for harm. And that's something that I think a lot of in my experience a lot of Western developers in the U.S. anyway, most of what they're working on doesn't have that potential in the first place, maybe that's another reason why they don't care either.

Manuel Lemos: Brett, do you have a URL that you would like to pass for people to get in touch for those listeners that are based in China?  I don't know if your group is specific to a certain region or is nationwide, I'm not sure, how do you operate?

Brett Zamir: Right now we're just in the city where I'm living here in Shenzhen in China.  We don't have a website but I can give my email address if anybody wants to get in touch and coordinate or give ideas or share or whatever, it's Brettz9 at yahoo.com.

Manuel Lemos: Well, any listeners interested in participating and benefitting from whatever your activities now you know how to contact Brett and contribute more to the local community.

Conclusion (1:15:22)

Manuel Lemos: So basically we are all done with this episode, I would like to thank Brett for coming and taking the time to talk to us about PHP.JS project and also his insight and his opinions about other aspects, and I think that's all for now.

Michael Kimsal: Cool.  Well, thank you Brett for staying up so late over in China and thank you Manuel for putting this together.

Brett Zamir: My pleasure, it was an interesting program, thank you guys.

Michael Kimsal: Adios. I forget how you say goodbye in Chinese.

Brett Zamir: Bye, bye.