Faster JavaScript with asm.js - Lately in JavaScript podcast episode 28

Recommend this page to a friend!
  Blog JS Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog Faster JavaScript wit...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)  


Categories: Lately in JavaScript podcast, JavaScript APIs, JavaScript opinions

asm.js is a subset of JavaScript meant to execute code faster, especially for JavaScript converted from C or C++, but can also execute on browsers. This one of the main topics covered by Manuel Lemos, Michael Kimsal and Arturs Sosins in the episode 28 of the Lately in JavaScript podcast.

They also talked about making languages execute faster with alternative memory allocation methods, using IndexedDB and other file storage APIs, better asynchronous programming with Async.js, and the comparison between languages with Lord of the Rings characters.

Listen to the podcast now, or watch the podcast video or read the transcript to learn more about these and other interesting JavaScript related topics.

Loaded Article


Listen or download the podcast, RSS feed

Watch the podcast video

Read the podcast transcript

Click on the Play button to listen now.

Download Size: 29MB Listeners: 1834

Introduction music: Riviera by Ernani Joppert, São Paulo, Brazil

View Podcast in iTunes

RSS 2.0 feed compliant with iTunes:

Watch the podcast video

Note that the timestamps below in the transcript may not match the same positions in the video because they were based on the audio timestamps and the audio was compacted to truncate silence periods.

Show notes

Read the podcast transcript


Introduction (00:20)

File System APIs in Firefox and other browsers (2:34)

Wrapper to Access IndexedDB in Different Browsers (14:30)

Faster JavaScript with asm.js (19:10)

Asynchronous JavaScript Programming with Async.js (24:00)

Is JavaScript also a Hobbit? (31:21)

Making Languages Faster with Alternative Memory Allocation (41:00)

Latest JavaScript Objects release in the JSClasses site (45:50)

Articles in the upcoming JSMag Magazine (54:20)

Michael Kimsal in Russia (56:00)

Upcoming Reputation and Privileges system (57:41)

Conclusion (59:12)

Introduction (00:20)

Manuel Lemos: Hello, welcome to the Lately in JavaScript podcast. Actually, we are still calling it a podcast and it's a video hangout. 

Finally, we have Michael Kimsal back from... Michael, where have you been? It seems you have been very busy.

Michael Kimsal: Hell, partially. Working, and honestly... Whoa, look at that, I can sit up a bit. It's always strange because that's where the camera is, but this is where my main screen is. So, I'm looking at this, to see what's going on. 

Manuel Lemos: OK.

Michael Kimsal: Hello. I was going to try to do a quick screen share of something to show where I've been, at least part of the time. Can you see that? 

Manuel Lemos: It's like a panel.

Michael Kimsal: Yeah. Distance: 3.1 miles, 5 kilometers, in only 37 minutes, 55 seconds. I've been running. That's my treadmill. 

Manuel Lemos: Whoa. 

Michael Kimsal: Whoa, yeah.

Manuel Lemos: Oh, I see. 


Manuel Lemos: I don't use treadmills so I was not recognizing what that would be. 

Michael Kimsal: So, that's my positive. Though I have found out that eating cans of Pringles after you've run for three or four miles does not help weight loss. 

Manuel Lemos: Yeah.

Michael Kimsal: Yeah.

Manuel Lemos: OK, well, last month, we had Arturs Sosins taking your place. But it's never the same. 

Michael Kimsal: Yeah, that I know. If I had a nickel for every...

Manuel Lemos: [Laughter]

I know. We always miss your jokes and your good humor. I hope you are better, now, more relieved from your work as you were.

Michael Kimsal: Now, that's annoying.

Manuel Lemos: In the past month. 

Michael Kimsal: Yeah, that's my Crocodile Dundee moment there. I'm actually, I was telling you, I was starting to tell you, I'm not really recovered all the way. I'm still kind of in the midst of some things, but I'm somewhat back. So, hello! Thank you.   

Manuel Lemos: Yeah, well, I hope you can still make it again as ever. Because it's always great to have your insights.

File System APIs in Firefox and other browsers (2:34)

Manuel Lemos: We are going to move on with our podcast and first, we'll talk a bit about an article... let me screenshare it here... about an article from... Oh, wait, I always miss the right... Because it just moves away.

Michael Kimsal: Which article are we starting at? 

Manuel Lemos: There you go. That's the one from Mozilla...

Let me try to increase the font. Well, there are no miracles with this resolution of Google Hangouts video recording. 

But anyway, this is an article from the Mozilla blog on which they comment about why they do not have the FileSystem API in Firefox.

That is an API that is still being specified. Actually, depending on what are your purposes, it could be either the FileSystem API or FileWriter.

Then, they explained it in the article that, basically, they want to push everybody to use the IndexedDB API to store anything including files. 

So instead of using other APIs, they just support IndexedDB. They give a couple of reasons depending on your purposes. For instance, when people want to store files locally to avoid server accesses, they still recommend to use the IndexedDB because you can store files in there. 

And the other purpose that people may want to use file APIs other than that would be to access documents in the machine of the user, like things they want to share like pictures and music and the other stuff.

Michael Kimsal: But see, that's the problem. Or that's a problem with...

Manuel Lemos: Yeah.

Michael Kimsal: They referenced it here because they're calling it, they're saying, "We're not implementing the FileSystem API." But that is not an API for interacting with the local file system. 

Manuel Lemos: Yeah, they explained... 

Michael Kimsal: It's in the article more than anything else. 

Michael Kimsal: Who's just joined us?

Artur Sosins: Hello, guys. 

Michael Kimsal: Hello, Arturs.

Artur Sosins: Yeah. 

Michael Kimsal: Good morning. 

Manuel Lemos: We're just... I guess, you heard about your name and you could not resist. 

Artur Sosins: Oh, you mentioned me? Already?

Michael Kimsal: Of course. Thank you. 

Manuel Lemos: Yeah. 

Artur Sosins: I just wanted to show you one thing I just got today. 

Manuel Lemos: [Chuckles]

Artur Sosins: Do you see this? 

Michael Kimsal: Oh, look at that, the big...

Manuel Lemos: Oh, it arrived already. 

Artur Sosins: Yeah.

Manuel Lemos: Oh, the Latvian Post Office is working very, very fast. Because it was not supposed to arrived this soon. 

Michael Kimsal: [Applause]

Manuel Lemos: Well, congratulations. You won your deserved...

Michael Kimsal: elePHPant. 

Manuel Lemos: ... elePHPant. Yes, the Post Office here did not give me much hope, that it would not arrive in less than 20 or 30 days, because no other developer that also won the elePHPant got theirs already. At least, they did not report to me, but I am not seeing the tracking...

Well kudos to the Latvian Post Office because they did they're part very quickly.  Well, I hope you are glad about it.

Anyway, just to mention very briefly why you got that elePHant is because you participated in the Innovation Award challenge that was an initiative, actually, you even suggested it to encourage developers to start sending more classes to the JS Classes site.

And it somehow worked to encourage everybody. And the Innovation Award has already started, thanks to that push in the contributions. So that elePHPant is deserved by you and the others that submitted several notable packages. 

Well, anyway, we'll get back to the latest classes more at the end of the show. And now, getting back to the actual topic that we're commenting. 

Michael Kimsal: Yes.

Manuel Lemos: Michael, you're commenting about that to access local files of the user and could not be this API, right?

Michael Kimsal: Yeah, the name of the API is pointed out. They don't actually mention it exactly that it's a bad name. But they say the FileSystem API is not what to use to access local pictures and things on the local filesystem. It's effectively creating a sandbox of area that's only available to that browser that looks like a filesystem.

So, whether or not they implement FileSystem API has no bearing on whether you can drag and drop photos and things like that. 

So, I think, some of this is a naming issue more than anything else. But the other thing I look at is that they could implement the FileSystem API on top of IndexedDB if they felt like it. 

Manuel Lemos: Yeah. 

Michael Kimsal: That's to say...

Manuel Lemos: Well, actually...

Michael Kimsal: Go ahead. I'm pulling that out of thin air.

Manuel Lemos: What I meant...

Michael Kimsal: But there would be no... It might be a performance hit. But there's no technical reason why you couldn't implement that API instead of a sandbox area on the drive, it's translating stuff in the IndexedDB records. 

Manuel Lemos: Yeah. Well, actually, this is to access files that the user may want to share and they say that there is this DeviceStorage API that is more adequate for that purpose. 

Michael Kimsal: Right. 

Manuel Lemos: Because it allows the sites, the applications, to browse the files in those, well, you've called it a sandbox. Probably that's the more accurate term because it would not allow the application to access the whole hard drive of the user computer. It's more restricted to some personal documents, nothing very sensitive in terms of security.

Anyway, they still say that the file API was not for that purpose because the file API is to access files that the user already picked.

So in this case, this DeviceStorage API, I'm not familiar with it but I supposed it is meant to access listings of files without the users explicitly picking a specific file that he may or may not want to share. I have to look more into this. 

Michael Kimsal: Yeah, but it's saying right there, the DeviceStorage API is basically a simple FileSystem API. That is what you would use for storing on your local hard drive, for reading and writing from your local drive. So device storage is what people think of, or they think of FileSystem API..

Manuel Lemos: Right.

Michael Kimsal: They think about, "Oh, I got to get my local pictures from my computer." But you're using DeviceStorage API. They're just not focusing FileSystem API because that's the private sandbox and they want to focus on IndexedDB.

I think they could build a FileSystem API on top of that if they so chose later for compatibility to say, "We support FileSystem API." But it's... I don't know why people are getting so hot and bothered about this. 

Manuel Lemos: I think there are different APIs for different purposes and I think they are trying to say that people make confusion between them and think it's all the same. 

Michael Kimsal: Yup. 

Manuel Lemos: But for each purpose, there is another API for that. And the last purpose that they commented is low-level file manipulation which would be something that I'm not sure if there's an API that can do that, like updating parts of files or reading just small chunks.

Michael Kimsal: Header blocks or something, yeah.

Manuel Lemos: And this is more complicated because to do it right, at least for write access, it would require some locking mechanisms. And anyway, for that purpose, they mentioned FileWriter API which is apparently an API that would allow that, not the file API nor the IndexedDB nor anything.

Well, I don't know. I'll confess then, I'm not familiar with these APIs at least in detail because I did not come across an application that I could use it. 

Anyway, actually, we commented last month about this article, I think it was by Addy Osmani that he was suggesting to use localStorage to cache script on the browser side to avoid server access overhead. That probably would be something that could also be implemented with IndexedDB. I don't know.

Michael, do you use any of these APIs in any applications? 

Michael Kimsal: You know, I looked at testing out something. Not specifically putting like a file in a reporting data, I think it was IndexedDB in Firefox maybe a year or so ago. Maybe a bit like May, 2011. And it was OK, but I was ending up writing something that was very specific to that. It wasn't cross-platformed at that point. 

And really these days, I say these days, maybe the last six months, I'm finding that the work that I'm doing, I have to go back and support things IE8 in Windows XP, even maybe IE7. So, I'm having to write code that has to work on very legacy. In my mind, very legacy browser don't have this.

So I would probably get some benefit by doing some custom stuff to say, "Well, if you're on Chrome, if you're on this, then do this." And I just haven't had the time to optimize for that. 

Manuel Lemos: Yeah. Or the opportunity because there must be some purpose which using those APIs makes some sense.

Michael Kimsal: Well, just...

Manuel Lemos: I think, at least. That's what happens with me.

Michael Kimsal: Well, just keeping large chunks of data down that are essentially already structured or maybe parsed out a bit more, as opposed to just a blob of data that we have to go through again or pre-calculating stuff. 

Manuel Lemos: Yeah.

Michael Kimsal: I can see benefits to it. I'm not working on things, right now, that easily lend themselves to me spending time focusing on it.

Manuel Lemos: Right. 

What about you, Arturs? Have you used much or any of these APIs for accessing files? 

Artur Sosins: No. No, no. Usually, if you need something, you store it in, I don't know, in cookies that's most compatible. If it doesn't fit in cookies, it's too large, then, you use localStorage. 

Manuel Lemos: Right. 

Artur Sosins: And that's probably it. 

Manuel Lemos: Yes, that's also confirmed because applications must run at least in a compatible way in different browsers. And you're right, I think, at least for a good while, cookies are more reliable.

At least, if you want to use just one method and do not have code different for each browser to support some storage mechanism.

Wrapper to Access IndexedDB in Different Browsers (14:30)

Manuel Lemos: Well, anyway, this actually ties to the next topic because it is about wrapper library.

Michael Kimsal: IndexedDB?

Manuel Lemos: Yeah. Let me screen share the article here. There is this article from the Badass JavaScript blog. I like these names that people give to blog, Badass JavaScript, OK. 

Anyway, there is this IDBWrapper which is cross-browser wrapper for offline Web apps. Basically, it's a wrap-around IndexedDB implementations.

Well, I don't know if the available implementations in different browsers are not compatible, but it also mentions LocalStorage here and WebSQL is dead. So we need to move on to something that has a brighter future, which should be IndexedDB.

Well, I don't know. I never tried this. I did not even knew that probably there'd be a need for a wrapper to encapsulate the access to IndexedDB but certainly attempts to address the problem of differences between browsers. 

Are you guys familiar with this library or just started with it? 

Michael Kimsal: I'm not  familiar with this particular library. I'm familiar with the idea of wrapper libraries in general, but that's pretty broad statement to make. 

Manuel Lemos: Yes.

Michael Kimsal: Look at me, I know what a wrapper library is. 

Manuel Lemos: [Laughter] Wow. 

Michael Kimsal: Yeah, I'm the man. I can see why you would want to use it in that there's going to be some minor differences either now or in the future. Just writing to any abstraction layer, unless performance is a huge concern makes a lot more sense.

But I was looking at the initial point and it says "Hey, this works in a... Oh, it's a wrapper for the native stuff that's in Firefox, Chrome and IE 10." 

And just getting back to my... I happen to deal with large amounts of IE8 right now. Interesting, I wonder, the idea of saying IE10, we say Firefox, we say Chrome. Sometimes, we say version numbers, both those are both mostly automatic updated now.

It would be hard for you to find somebody that's using Firefox 16. Because almost everybody has their Firefox auto-update on now. If you're using Firefox, you're probably auto-updating. 

Same thing with Chrome. Not so much with IE, and it's still strange, I think, sometimes to see browser versions in the Microsoft world. To me, this would be easier to see Windows with its browser thing. But from a user standpoint, to say you have to have Windows 8. That's a nice clean, cut-off point. Because you only get IE10 with that.

So, I'm bringing in my current work problem into this. Sorry, go back to IndexedDB.

Manuel Lemos: Well, actually, I don't know, but I think I read some news talking about IE10 being developed for... 

Michael Kimsal: Windows 7. 

Manuel Lemos: For Windows 7, or did I read...

Michael Kimsal: No, I think it's right. But it only recently came out and I'm going to go out on a limb here, OK. I'm going to say that there may be something that doesn't work in IE10 on Windows 7 but it does work on IE10 and Windows 8. Given the history of... The browser is an integral part of the operating system and we can't separate them. And they're the exact same thing. 

Manuel Lemos: Aw, I heard that. But that was like ten years ago.

Michael Kimsal: I know, I know. But 12,15, but if there wasn't anything on the browser that relied so heavily on the operating system, they could have released IE10 six months ago. 

Manuel Lemos: Right. 

Michael Kimsal: I think there's still going to be some anomalies between IE10 Windows 7 and IE10 Windows 8. 

Manuel Lemos: Well, I guess that's really trying...

Michael Kimsal: And that's when you would need the IDBWrapper for that, for example.  

Manuel Lemos: Right. 

Michael Kimsal: There you go, there you go. That would be the IDB wrapper for that. There you tied it around that.

Manuel Lemos: Well, anyway, I think they are trying to push Windows 8 at the expense of IE10 and since it is not working, they're "OK, plan B, let's release it for Windows 7." 

Michael Kimsal: Yeah.

Manuel Lemos: That's what it seems to me, but OK.

Michael Kimsal: You're just cynical. 

Manuel Lemos: No, I have many friends in Microsoft. I would not have reason to be cynical. And they know what they are doing. [Chuckles]

Faster JavaScript with asm.js (19:10)

Manuel Lemos: OK, anyway, basically this topic is covered. We need to move on to the next topic on which we are going to comment on something reasonably recent. Although, it refers to not a topic we haven't covered before.

Let me screen share here. 

Michael Kimsal: What are you sharing? 

Manuel Lemos: The asm.js. 

Michael Kimsal: Woooh, wow.

Manuel Lemos: I don't know if I can increase the font larger. 

Well, basically, this is a project that they... There's even a specification. But basically, this is a subset of JavaScript that is intended to make developers use only code that would translate efficiently... well, would be more efficient to translate from language compilers. 

They even talk about C and C++. I think this has to do with that project that we commented here several times. It's EMScripten, right? That one that converts compiled C++ into LLVM bytecode. And then...

Michael Kimsal: Yeah.

Manuel Lemos: That bytecode can be translated to JavaScript. 

Michael Kimsal: Ladies Love the Virtual Machine, yup. 

Manuel Lemos: Yeah, well, this is a very, I think, it's low level, right? I don't know. 

Michael Kimsal: Ah, whatever, I'm still a child of the 80s. I think LL Cool J and ladies love him. Ladies love him. Hey, what can you do? 

Manuel Lemos: Yeah, it would like to be able to allocate memory manually and deal with memory management meant on all that stuff, right?

Michael Kimsal: Probably the asm.js?

Manuel Lemos: Well, basically, they call it a subset. But I think the purpose is to make it more similar to C and C++. So, the conversion between C and C++ programs would generate more efficient code. That's what I read from this description of the project. They even have a FAQ page here. 

Michael Kimsal: Yeah. I'm looking at it. You bringing it up? Yeah, subset of JavaScript. What kind of performance  benefits? So, this would end up being compiled. It would take the subset and compile it down to C or something else. 

Manuel Lemos: Yeah. 

Michael Kimsal: Is that what I'm hearing. 

Manuel Lemos: Yes. That's the one. Or you're not getting what my screen's sharing? 

Michael Kimsal: I have to go to my screen here. It was just a little too small to see on yours. 

Manuel Lemos: Right. 

Michael Kimsal: It's OK.

Manuel Lemos: I don't know, we can't do miracles because the recording of the video in Google hangouts is limited in size.     

Michael Kimsal: Don't worry about it. I'm not worried.

Manuel Lemos: No, it's just to try to give people something to read while they watch the video but it's hard. Well anyway, this is just to let you know that this project exist.

There are people that have different concerns than the majority of us probably would not be so interested in converting C and C++ programs into JavaScript. 

Arturs, did you ever see this project, EMScript and probably others that compiled to C and C++ tools?

Artur Sosins: No. But what I read from the page that you've just shown, basically, yeah, you can define that you use awesome... I don't know how to... asm.

Michael Kimsal: ASM. 

Artur Sosins: Yeah, ASM. 

Manuel Lemos: Awesome is also an interesting way of reading it. 

Artur Sosins: OK, that basically could make this code more efficient by skipping the type checks and then, stuff like that. But best thing that I've learned, that I've read, it would also run on simple browsers without just resulting in more efficient, but it is compatible.

Manuel Lemos: Yes.

Artur Sosins: So if someone wants to use it, he can do it. 

Michael Kimsal: Simple browsers? Oh, like IE? Ooh, I went there.


Michael Kimsal: I know. I know. I've been there. 


Manuel Lemos: Another IE joke. 

Michael Kimsal: Aww, sorry. 

Manuel Lemos: Well, anyway, it's just more curiosity than something that everybody would be interested. 

Asynchronous JavaScript Programming with Async.js (24:00)

Manuel Lemos: Anyway, now moving on to probably a more interesting topic, which is about async.js library. Let me just screen share it here if I can, if it lets me pick the right screen. OK.

And well, basically, the idea is to try to make asynchronous programming at least less of a hell, as I call it. I don't know what you guys think.

Some people, I notice, complain a lot when I say that asynchronous programming is hell. But all those nested callbacks and things that probably are not very maintainable but... 

Michael Kimsal: You noticed. You notice here, when they are complaining to you, they are using one word after another, single file sequentially. They don't just spew 95 words simultaneously at you. They send one word at a time. They send you one email at a time perhaps, and then, you reply back. That's all I need to say nothing more. 

Manuel Lemos: So your solution would be to use a queue. 

Michael Kimsal: There you go. Or maybe a capital Q, if you wanted to be really emphatic about it. 

Manuel Lemos: Yeah, well...

Michael Kimsal: Yeah. 

Manuel Lemos: Well, what do you suggest using here in async.js, this library provides several resources. One of them is to be able to have callbacks being called in parallel for...

Michael Kimsal: Interestingly, I'm not seeing any promises in here. And I thought I might see promises. 

Manuel Lemos: Right. Well, my problem is that I do not believe promises.  

Michael Kimsal: Well, OK. No commitment then. 

Manuel Lemos: I mean, translating that into  asynchronous JavaScript, it's just a different way to deal with the same hell. But in the end, the hell does not change.

Actually, if you try to change your own programming, just match whatever is being proposed, it's probably a greater hell. I don't know, that's my opinion.

Have you guys tried this async.js library in practice or at least read about it?

Artur Sosins: Well...

Michael Kimsal: [unpronounceable words]

Artur Sosins: [Laughter] No, I have...

Manuel Lemos: [Laughter]

Michael Kimsal: Oh, look at that.

Artur Sosins: You are kidding me. 

Michael Kimsal: Async for this hangout don't work either. Oh, crap. Go ahead. 

Manuel Lemos: Yeah. 

Artur Sosins: Are you promising? 

Manuel Lemos: [Laughter] 

Michael Kimsal: I promise. I promise that you can go first.

Manuel Lemos: We are very metaphoric today. 

Artur Sosins: Yeah, well, the only thing that I've tried to use, as Michael already mentioned, are promises. And well, what I've heard that was the common approach to deal with many callbacks. And this parallel approach, it seems efficient really if you can iterate for all of them and then call them in some ways.

So, it's probably for some specific case, I don't know, it would be generally so useful. But probably, there are more other functions to be inside the async.

Manuel Lemos: Right. Talking about the 80's...

Michael Kimsal: [unpronounceable words]

Manuel Lemos: Michael, did you have an Amiga computer? No?

Michael Kimsal: I had Amiga way back in the day. 

Manuel Lemos: But did you program it?

Michael Kimsal: I didn't much. I played with Deluxe Paint. 


Manuel Lemos: No, that does not count. Well, I've developed a lot in the Amiga computers. And of course, being the desktop operating system, you have to deal with the parallel calls, parallel events, that run asynchronously. And the solution that they have there is to have a message queue. 

And any events that would happen often related with IO and stuff, they would be sent to a queue and you would consume the messages arriving to the queue one at a time.

You would not have to use these callbacks and things like that. And you could put it in a big switch statement and say, "If this message came from here, then reply this way." 

Well, anyway, at least in Amiga operating system, there were synchronous operations. It could access files without having to use a callback to deal with file operations. 

Michael Kimsal: Does this look like a queue? Sorry, kind of an inside joke there. 

Manuel Lemos: Yeah, well.

Michael Kimsal: But many people just wouldn't like that. I think the idea of having a separate message queue is something else that you would have to rely on, if your language structure, your language dynamics, all support the idea of callbacks, your language and all of your asynchronous stuff can happen inside of one engine rather than having a, with that said, some JavaScript engine. I don't know how easy it would be to do this, but you could bundle a built-in message queue. 

We have built-in databases, for goodness sake, in these things. So a built-in message queue that people could subscribe to and push to and things like that. Probably wouldn't be that difficult, but we'd been rather entrenched in the culture of async callbacks over the past few years.

I'm not sure if the majority of people to make these decisions would be able to push the idea of a message queue successfully. 

Manuel Lemos: Well, it's just a way of handling it in a way that you don't have to nest call backs.

Michael Kimsal: Right. Though I...

Manuel Lemos: Nesting callbacks, it's the hell. 

Michael Kimsal: Right. I don't disagree. 

Manuel Lemos: Well, anyway...

Michael Kimsal: But people have a lot of code  already invested in working this way. And yeah, there's just a lot invested in the last several years going this way.

Manuel Lemos: Well...

Michael Kimsal: Changing directions probably wouldn't be very popular. 

Manuel Lemos: Well, I was not proposing to change directions. But I'm just presenting a different way of handling it in a way that is not hell. 

Michael Kimsal: OK. OK. 

Manuel Lemos: Anyway, that part of the topic is related to the fact that at least Amiga operating system had a synchronous file system codes and calls to other things that... When we use, for instance, node.js you have to rely on asynchronous calls. That's what makes it hell, unfortunately.

But well, that's the sort of rule of the game if you want to play with the technology. The way it is, you have to deal with this asynchronous thing. 

Is JavaScript also a Hobbit? (31:21)

Manuel Lemos: And this also ties with the next topic which is basically related with an article that I wrote. It was not specifically about JavaScript but it was related with an eventual war between languages. 

I'm trying to just increase the font here, not too much.

Well, basically, there was a guy that was in the Quora site where they put questions and somebody will try to answer.

Basically, he asked the people if languages would be at war, what part would you take? And there was a guy that provided a very imaginative answer, which compared languages with the characters of the Lord of the Rings story.

And he started comparing The One Ring with C, which would be the entity that has all the power that all the languages want to have. And then, started comparing other languages with some good and some evil characters in the story. And actually, he compared to all the languages here. 

Actually, I wrote an article about it, related to it, explaining why I think PHP would be a Hobbit. Because despite that is not a very strong language or even the fastest language, in the end it's the language that solves all the problems.

And I actually give several points here, explaining why I think that. It's just an amusing article. It's not meant to be taken too seriously. 

Michael Kimsal: I won't. Don't worry about it. 

Manuel Lemos: OK, thank you. 


Michael Kimsal: Yeah, Manuel had asked me about this before and I have to admit... I don't have to. I'm going to admit, I don't really know much of anything about Lord of The Rings, Hobbit, Tolkien, whatever. It's completely beyond me. 

Manuel Lemos: Yeah. But don't worry, because that's the only metaphor that matters for this article is that PHP would be a Hobbit because in the story, the Hobbits are the ones that solvethe problems, even though they had help from other people, from other races.

I don't know if race is the correct term, but I think in the story of the Lord of the Rings, there are different races. 

Anyway, the relation of this with JavaScript is that I said that JavaScript could also be a Hobbit but the asynchronous programming's make it a hell. So it's not so much a very pleasant solution for all the problems. Well, that's just my opinion, of course. And as I said, it's not meant to be taken too seriously.

Well, Michael, did you say that you did not read the article? Or you are not just into the story of the...?

Michael Kimsal: I read the article. It just didn't make a lot of... I wasn't making the connections because...

Manuel Lemos: Oh, I see. 

Michael Kimsal: I don't... It's just... 

Manuel Lemos: Right. 

Michael Kimsal:Yeah. 

Manuel Lemos: Because you...

Michael Kimsal: I don't know the characters. I don't know the premise all that much. 

Manuel Lemos: You don't... Well, actually, I just compared PHP with the one character of the story. 

Michael Kimsal: And I don't know that character. So...

Manuel Lemos: Well, so if you don't know the character and for all that minority that does not know the story, the Hobbits are the eventual heroes. Because in the story, despite that they're not very strong, or very fast, or nor very beautiful, which is a common complaint about PHP. 

Michael Kimsal: Oh, OK, I thought you were talking about me for a moment. 

Manuel Lemos: [Laughter] No, no.

Michael Kimsal: Ooh, then, you're getting a little personal there.

Manuel Lemos: You'll probably be an elf, I think. 

Michael Kimsal: Hey, I'm still here. OK? 

Manuel Lemos: [Verbal Noise]

Michael Kimsal: Dont...

Manuel Lemos: No, but since you don't know the story, being an elf is a compliment. 

Michael Kimsal: Oh, thank you. 

Manuel Lemos: [Chuckles] 

Arturs, do you know the story of the Lord of the Rings? 

Artur Sosins: Unfortunately, I know. 

Michael Kimsal: What?

Artur Sosins: I know, I know. Unfortunately, but I know. 

Manuel Lemos: Why don't you enjoy a good story of many books and movies of more than three hours that you almost fell asleep during the... 


Artur Sosins: Yeah. They even say that it would be faster to read the book than watch the movie. 

Michael Kimsal: [Laughter] 

Probably. Probably. I didn't read the books but I watched the movies. So what is your take on this? 

Artur Sosins: I know. OK, PHP may be a Hobbit because it's a main character. 

Michael Kimsal: Ooh, good one. 

Manuel Lemos: Well, what about the relation with JavaScript? Do you agree with my assertion that JavaScript could be a Hobbit but due the asynchronous programming being hell, it's not as pleasant?

Artur Sosins: As I remember, in the original article I think that JavaScript was the one that was the Hobbit, right?

Manuel Lemos: I don't even remember. I could check but the point was not the original article. Because I disagree with most of the comparisons. They called PHP as an orc. Because PHP teamed with the bad guys. And the bad guys would be C++. 

They are trying to make connections between PHP and Facebook HipHop Compiler, which initially used to be a PHP to C++ translator. But that's not true anymore, so that comparison does not match.

But I bet a lot  of people would like to compare PHP with orcs because orcs are ugly. 


Michael Kimsal: Hey. 

Manuel Lemos: Lots of PHP detractors used the ugliness argument against PHP. Well, in the end, PHP is still the most popular tool for the Web, I think.

Anyway, what you are saying about the comparison? What do you think about JavaScript could also be a Hobbit? 

Artur Sosins: Well, she compared it to PHP, then, I don't know. Yes, I've heard many complaints about PHP but I haven't heard that much complaints over JavaScript. There's not so many Javascript haters, I think. 

Manuel Lemos: Yeah. That's because they do not have a choice. Because JavaScript on the browser, that's their only choice, 

Artur Sosins: Oh, well, yeah, probably. 

Manuel Lemos: Yeah. Well, most of the PHP haters, they just hate it because their favorite language is not preferred. Well, there's no WordPress for Python or Ruby.

Michael Kimsal: Awww. 

Manuel Lemos: Ruby. 


Michael Kimsal: I think it would be a Gollum. JavaScript would be a Gollum.

Artur Sosins: Why?

Michael Kimsal: Driven mad and twisted by a... That's a character. I thought it was a type of character. I'm trying to Google for this best as I can.

Manuel Lemos: Gollum is the...

Michael Kimsal: Yes, a particular character. 

Manuel Lemos: Yeah, it's a character that's full of envy of the others. So probably, it would be some other language whose developers are envious of some other language. 

Michael Kimsal: Yeah, there's no...

Manuel Lemos: I'm not going to name names. 

Artur Sosins: [Chuckles]

You better not. There would be a war. 

Manuel Lemos: All the last three people that's still watching this Hangout will drop it completely. 


Michael Kimsal: Oh, there we go. Orcs, goblins. Maybe, it would be a goblin. Maybe it would be... I'm not good at this. We could move on, because I'm just Googling around and I'm... 

Manuel Lemos: [Laughter]

Artur Sosins: Or maybe watch a movie. 

Manuel Lemos: Right. 

Michael Kimsal: Yeah, I'm going to go. I'll see you guys in just about four hours. 

Manuel Lemos: No, four hours each episode. Because there are a lot like ...

Artur Sosins: Three episodes, I think. 

Michael Kimsal: Yeah, it's going to take me a few hours to torrent it at first. And then ...

Manuel Lemos: Oh!

Michael Kimsal: Oh! I mean, torrent it from my paid account that I pay money for to get things legally.

Manuel Lemos: Yeah, probably.

Michael Kimsal: That's what I meant. 

Manuel Lemos: You are going to torrent it to the Apple TV.

Michael Kimsal: Yeah. But they don't...Oh, don't even get me started. They don't torrent... Brief aside here, I'm not using Safari 6 with JavaScript Engine. There you go, the JavaScript. I upgraded the Mountain Lion. I won't say it's a big, big mistake. It was not all that fun.

Michael Kimsal: But I actually paid for it. Like, "I'm going to pay $20, going to go do my upgrade, pay Apple a little money, try to download this thing." That's like one day and eight hours. Insane. So, I just went and torrented it and installed it. And then, it installed.

So I went to the AppStore because you need updates to get the 10.8.2. So I tried to do that and it was going to be 19 hours, so I went and torrented the  update. 

Manuel Lemos: [Chuckles]

Michael Kimsal: I paid money. That's the whole other thing. I would love them to just build the BitTorrent thing into their App Store. Sign the stuff, cryptographly make it and all that, with all that. But my goodness, I should be able to pay money and get something faster than stealing it.

Manuel Lemos: Yeah, they are so successful that you have to enter in a queue to be served.

Michael Kimsal: It was. Now, if they've been using asynchronous Web serving.

Manuel Lemos: Oh, that would be...

Michael Kimsal: That could have been it. They're probably serving each byte one at a time.

Manuel Lemos: Yeah, probably. They send to a callback function to every byte you got.


Making Languages Faster with Alternative Memory Allocation (41:00)

Michael Kimsal: I got a question. Or I got something I want to mention briefly. It's not on topic but it's a quick point of discussion. Arturs, jump in if you ever played or heard of this. And it's not directly related with JavaScript. Though, it may have an impact on things like Node and Rhino and things like that. 

Last week, I learned about something called... Oh, should my screen be up? How about my screen be up. Come on, make... There you go. Hello, everybody. By the way, can anybody read Russian here? Can you read that?

Manuel Lemos: Maybe Arturs. Arturs...

Arturs Sosins: Make the world cleaner.

Michael Kimsal: Yeah.

Manuel Lemos: Yeah, that's what I thought. 


Michael Kimsal: OK, I stumbled on an article about how GitHub had increased their MySQL query speed by about 30%. And what they're doing is, they're running MySQL with a different malloc, a different memory allocator. Most of us, if we're using Linux, we're using whatever it comes on our standard Linux . Malloc is there, everything semblance against it or does the dynamic loading against a malloc.

Yeah, so there are other memory allocation libraries that perform differently. This was an eye-opener for me. I did not know this.

And they said they tested out... this article had a few different tests on different malloc libraries... and it didn't mean that every single thing ran 30%. But the MySQL Query system, the way it allocates memory and releases, how it deals with that, when it's dealing with Query, when it's dealing with caches, when it's dealing with its execution plan and what-not. Just by having a different malloc library, it was about 30% faster.

Interesting to me, and I haven't seen anybody do benchmarks to keep this on JavScript, do that with any like node.js. Does it run faster if you use a different malloc library. That's kind of just a JS related thing. 

Have you ever heard about using different malloc libraries to speed things up?

Manuel Lemos: Yeah, well, I don't know about... Well, this is no longer JavaScript-related. But for instance...

Michael Kimsal: Not directly.

Manuel Lemos: In PHP, they do not use the standard, the C library malloc function calls. They use their own memory allocation and I'm surprised that they're saying that they discovered something that MySQL developers did not know already... to have their own memory allocation functions so they could optimize at least certain use cases. Well, I don't know.

Michael Kimsal: I mean, if you're kind of just thinking about in general, a subsystem or something, you could have a small number of people that just get very, very , very excited about malloc stuffs and can tune the heck out of that one library. That you can replace one library with another, standard interfaces and all that, they're getting a sizable... Thirty percent's a big change. It varies without having a change of parameters.

Manuel Lemos: I don't know. Well, that would be a very basic optimization. For instance, at least in PHP, that was done, I think, even in PHP 3. They replaced the memory allocation by some more customization that avoided calling so much on the OS memory, freeing a memory allocation calls. They would allocate larger chunks of memory at the time and then use that. 

Well, anyway, to put this more on topic, the last... Well, this is still not related with JavaScript, but since we talked about IndexedDB...

Basically, a key-value store in the MySQL 5.6 that was released not a very long time ago, at least the generally available release, they now provide the memcached interface to access data in InnoDB tables directly without having to execute a SQL query.

And if you just want to check key-value storage for that purpose, it could be faster and would be very similar to what you do in IndexedDB because all key-value store APIs are very similar. And, well, that's the only relation that I found that have anything to do with JavaScript.

Latest JavaScript Objects release in the JSClasses site (45:50)

Manuel Lemos: Well, anyway, back to the actual JavaScript world, we're going to move on now to one when our final regular sections in which we comment about the latest classes published in the JSClasses. This month, again, like last month... 

Let me screen share here. We are going to comment about the latest class, not yet the Innovation Award winners because they were not yet announced. They will start to be announced next month. 

So you're going to comment about any published class that will not be nominated to the Innovation Award so we do not influence the decision of the voters that will vote on the eventual winners of next month. 

Arturs Sosins: So, you already know which ones will be nominated.

Manuel Lemos: I know because I'm the moderator of the site,remember?


Manuel Lemos: Well, anyway, today is 28th and the nominations will be published tomorrow. That would already be a new month. And basically, there are, I think, just about three who will not be nominated. 

Well, I can start from a couple that are very similar because they are for sending AJAX request. Well, this kind of class is not innovative, that's why they are not being nominated because…

Arturs Sosins: Or because they are asynchronous. Or because they are async. 

Michael Kimsal: Ooh.

Manuel Lemos: Well, that would be just a detail. 


Manuel Lemos: Some allow to control the synchronous and asynchronous. But this is just basically wrappers. There is this one from Pierre-Henry Soria. 

I'm trying to fake my French accent. I supposed he's French.

Michael Kimsal: Oh-la-la. 

Manuel Lemos: Well, Michael, you are more...

Michael Kimsal: Worldly? 

Manuel Lemos: Trained in a foreign languages. How about you read his name?

Michael Kimsal: Pierre-Henry Soria.

Manuel Lemos: OK. Well, I tried though.

Michael Kimsal: Yeah, it's okay. 

Manuel Lemos: Well, anyway, Pierre sent several other classes. He has been sending classes both to PHP Classes and JS Classes site. And so far, he has sent two to JSClasses site. I hope he also continues to send more classes besides this one. 

Hopefully, they'll be innovative because starting next month, we will only be commenting about innovative classes. And this one does something that is reasonably common, which is to wrap AJAX request.

And there's another one that also does very something very similar, this JavaScript AJAX request, we call it classes but basically in JavaScript, to be more accurate, we should call them objects because there are always pedantic people that do not like to call classes on at least the current version of JavaScript .

And this one by Ricardo Luiz Rossi from Brazil basically does something very similar, sending AJAX request and having callbacks to handle the responses. And that leaves the last one for you to comment.

Michael Kimsal: Where is... I lost my window. There we go. Screen share. Here we go. This is from... oh, there's four names here. Fabio Elisio Melo Nunes, I hope I'm saying that correctly, Fabio, from Brazil.

Manuel Lemos: Yeah, your Spanish your accent is great.


Michael Kimsal: OK, there's no need to be that sarcastic. And it's not Spanish. It's Portuguese, OK? 

Manuel Lemos: Yeah, you should …

Michael Kimsal: Yeah. You're trying to mess... What did I say wrong? Fabio? Am I saying Fabio right?

Manuel Lemos: No, it's that your accent sounds Spanish, not the name.

Michael Kimsal: How would you say it? How would you say it as a Brazilian?

Manuel Lemos: As a Brazilian, well, there already difference between Portuguese in Portugal and Brazil. But in Brazil, they would say Fabio Elisio Melo Nunes. 

Michael Kimsal: Fabio Elisio Melo Nunes. 

Manuel Lemos: [Laughter]

Artur Sosins: That sounds...

Michael Kimsal: Thank you. Danke.

Manuel Lemos: OK, never mind that.

Michael Kimsal: So, this is a…...


Michael Kimsal: He's contributed a calendar, jQuery calendar plugin using the plugin mechanism and very basic.

Where is the screen? Here's the screenshot of what the calendar looks like. Now, the calendar, it's like what most calendars look like. Though, one of the things I had noticed is that the code itself... you're looking at the JavaScript and we  look here... it is in Portuguese.

Manuel Lemos: Yeah. 

Michael Kimsal: So if you need a Portuguese calendar, that's Portuguese out of the box.

Manuel Lemos: Yeah.

Michael Kimsal:  There you go. It's got the Hoje right there. I know that's Hoya or Hoye. How would you say that, H-O-J-E?

Manuel Lemos: Hojk 

Michael Kimsal: Hosha

Manuel Lemos: Hoj 

Michael Kimsal: Hosh.

Manuel Lemos: [Laughter]  

Well, this is not very uncommon, at least in Brazil. The people are not so acquainted with English and sometimes they prefer to write code even in Portuguese.

Michael Kimsal: And I think it's useful because if you needed a calendar thing that already... 

Manuel Lemos:  Right, right.

Michael Kimsal: Yeah, like even here...  Primeiro dia mês... that's the name of the function. I did notice. Can we say bisexto on the podcast here. Are we allowed? Is this a family friendly show?

Manuel Lemos: [Laughter]

Yeah, we can say that because it's in a foreign language, there is an excuse.

Michael Kimsal: Bisexto, I'm curious now. What does it mean?

Manuel Lemos:  Well, that's…

Michael Kimsal: I don't know can I…


Michael Kimsal: Let's go sequential. We can't do the asynchronous. You're next. 

Manuel Lemos: Yeah, that's when... What is those years that every four years that have the 29th of February.

Artur Sosins: The leap year. 

Michael Kimsal: Leap year. A leap year. 

Manuel Lemos: Leap year. It's totally different. 

Michael Kimsal: Leap, leap.

Manuel Lemos: I remember. Well, that's what bisexto means. Lets...

Michael Kimsal: Let's keep everything clean. Let's keep it clean. No bisexto jokes, OK. 

Manuel Lemos: [Laughter]

OK, yeah, there is an automatic filter on YouTube if you start saying too many...

Michael Kimsal: So if I just started like, just let it ripping, just said " I want to beep," it would just blank it. Wow, how did that... That was awesome.

Manuel Lemos: Don't do that.

Michael Kimsal: How did they do that?

Manuel Lemos: They'd take it down.

Michael Kimsal:  Oh, my God.

Manuel Lemos: They'd take it down, you cannot publish it anymore.

Michael Kimsal: No, it seems like they've got a live filter. Because I was just saying that I really think that you're full of "beep". What? It's like it's tested. Man, Google is so "beep" crazy about this "beep".


Michael Kimsal: It's better on  the non-video podcast.

Manuel Lemos: He's confused. The confusions of mixing foreign language is in the same podcast.

OK, well, basically we covered the latest classes. Well, those that we did not mention are the ones that will be nominated. By the time you see this podcast published, if you're not watching it live, you already know that the others are the ones that were nominated. 

And then, well, for those that we commented, those authors, I hope they feel encouraged next time. They'll try to send more innovative packages so we can comment on them. 

Starting next month, we will be commenting only on innovative packages, starting from those that won the award in... they were nominated in January and were voted in February.

And since we are still in February, at least when we are recording, that's why we are not commenting on them to not influence the voting results.

Well, this is regarding the latest classes. We are done.

Articles in the upcoming JSMag Magazine (54:20)

Manuel Lemos: And I think, now it's time for Michael to tell us more about the upcoming topics in the JSMag magazine.

Michael Kimsal: Well, February is kind of catching us a bit short. Because today is the last day of February already. We got a few  things in the pot and a few things that are slated, though it's getting very down to the wire here.

Jeanine Meyer has contributed for awhile and has a piece on developing a Jigsaw application with front-end JavaScript. 

Callum Macrae who's written for us before also has a piece on kind of diving a little deeper on some under-the-hood jQuery stuff - what's going on in JQuery 1.9 and kind of digging in to what he has found interesting in that. 

Robert Fisher, who has written for us well in the past, many, many moons ago, is contributing a piece on AngularJS and some of his recent work with Angular. I think I've talked about Angular a couple of times and I love to hate it, or I hate to love it... one of the two.

I've tried it a couple of times and I can do the basics but I fall apart when I try to do more complex stuff. So, I actually had a recent project. I had one of this Angular and I ended up moving over to KnockoutJS. 

So, that's kind of a personal thought there. But those are somethings that I know we've got in the pipeline. A couple of things we may have in the next couple of days. Given the shortness of the month, we'll probably will have things out by probably the 4th or so, probably March 3rd. Probably like Monday or Tuesday. So, that's what's going on. 

Manuel Lemos: Yeah.

Michael Kimsal in Russia (56:00)

Michael Kimsal: Oh, and... Hello. 

Manuel Lemos: And? 

Michael Kimsal: Well, not and, let me think about that. But personal here, I'm about 99% certain on this. I actually already bought a ticket and I got a visa. Ooh, I'm heading over to Moscow again for a couple of weeks in April. So, anybody here that's watching this. If you're in Moscow, Russia, and would like to meet up at the second half of April, shoot me an email.

Manuel Lemos: April, OK. 

Michael Kimsal: April.

Manuel Lemos: We'll be there. 

Michael Kimsal: We'll be there. You're going to meet me? 

Manuel Lemos: Well, Arturs is closer.

Michael Kimsal: Yes. 

Manuel Lemos: At least in the map, it's just two fingers. 

Michael Kimsal: Yeah.

Arturs Sosins: [Chuckles]

Michael Kimsal: Here's two fingers for you. 

Manuel Lemos: From Latvia to... 

Arturs Sosins: I'm just afraid it's not a finger. 

Michael Kimsal: [Chuckles]

How far is that actually?

Arturs Sosins: Well, you know, hard to say. I couldn't walk so much so...

Manuel Lemos: [Laughter] 

Michael Kimsal: Yeah. I wouldn't have tried.

Manuel Lemos: You always get tired. 

Michael Kimsal: It's only a two-hour flight. It can't be that far. 

Manuel Lemos: No, maybe not. Talking about Latvia, I had a hard time in the post office because the guy was trying to figure the name of the country in Portuguese. And he's trying to check my mobile phone, what Google Maps would say. Because there are... What are the neighbor country that have similar names?

Arturs Sosins: Lithuania, maybe. Lithuania, Latvia, Estonia.

Michael Kimsal: Belarus?

Manuel Lemos: Lithuania. That's right. It also starts with an L. Imagine if they missed your elePHPant and you would not get it.

Upcoming Reputation and Privileges system (57:41)

Manuel Lemos: Well, anyway, you practically ended this podcast. And just to mention very briefly, I've been working on something very interesting that will be hopefully available in the next maybe months. Not weeks, because I'm not sure if everything will get done already.

It's basically a system that will assign points to the actions that the users on the site, not just authors that publish classes but other users that somehow contribute to the site. And they will be entitled to earn special privileges.

For instance, Arturs has been helping on testing them and also giving some suggestions. And things are building up very quickly and I hope sometime soon, I can announce this.

But the ultimate result of this is that the sites, both JSClasses and PHPClasses, will start to become more engaged and people will be eventually willing to participate more, and hopefully, we'll see more interesting contributions, not just in terms of graphics but other types of content. 


Manuel Lemos: [Laughter]

Who is clapping?


Manuel Lemos: OK. 

Michael Kimsal: I'm just testing out. I'm just testing out. 

Manuel Lemos: Yeah.

Conclusion (59:12)

Manuel Lemos: Well, with this note, I'd like to thank you again, Michael, for returning to the podcast. As we mentioned, the last episode, we missed you. We missed your  jokes. 

Michael Kimsal: Thank you. 

Manuel Lemos: Your good humor, as usual. 

Michael Kimsal: Thank you so much.

Manuel Lemos: And also, thank you to Arturs for coming to the podcast. At least, this time I think sending out the invitations worked. 

And just want to add that anybody else can come to podcast, it's just not us. What you need to do is to go on the page of Google Plus. There is an account that says "Manuel Lemos" and then the JSClasses and PHPClasses in brackets.

And if you add to the circles of that account, you'll get an invitation next time, because you'll be added as friend.  That's the part that was making it harder to invite more people, but this time, I think it worked. At least Arturs came.

Arturs Sosins: Yeah. 

Manuel Lemos: So, thank you for coming. See you next month. Bye. 

Michael Kimsal: Adios. 

Arturs Sosins: Bye. 


You need to be a registered user or login to post a comment

26,081 JavaScript developers registered to the JS Classes site.
Be One of Us!

Login Immediately with your account on:


No comments were submitted yet.

  Blog JS Classes blog   RSS 1.0 feed RSS 2.0 feed   Blog Faster JavaScript wit...   Post a comment Post a comment   See comments See comments (0)   Trackbacks (0)