Can Apache 2.4 Match Node.js Event processing efficiency? - Lately in JavaScript podcast - Episode 16

Listen or download the podcast, RSS feed

Listen or download the podcast and RSS feed

Click on the Play button to listen now.

Download Size: 24MB Listeners: 1442

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

RSS 2.0 feed compliant with iTunes:

http://www.jsclasses.org/blog/category/podcast/post/latest.rss

Show notes

Seriously.js: Video compositing JavaScript library
PSD.js: Photoshop File Format parser library
PHP PSD Reader: PHP class to open images in Photoshop PSD files
Apache 2.4 supports event processing mode
Textualizer.js: Text animation effects library
Basecamp Next UI sheets
Twitter to drop the hash bang convention for URLs
Friends of the Site initiative enhancements
Top Friends of the Site ranking
Top Friends that led more authors ranking
Top Friends that led authors that submitted more packages

Manuel Lemos: Hello. Welcome to the Lately In JavaScript podcast. I'm Manuel Lemos, the host of the podcast. This is episode 16. And as always, I have Michael Kimsal here with me to comment on some of the latest happenings in the JavaScript world. Hello, Michael.

Michael Kimsal: Hello.

Episode diez y seis!

So that's Spanish. That's Spanish. Hola. Hello.

Manuel Lemos: Yeah. I noticed that you were trying to say anything in foreign language, as always. Well, it's always good to. Right. It's always good to hear. We have a few... actually, this month, we don't have many, many interesting topics there as probably in past episodes. But we are going to move on now to comment on a few that we found more interesting.

Seriously.js Video Compositing library (1:14)

Manuel Lemos: Maybe you could start from seriously.js library for video compositing using WebGL. Michael, did you...

Michael Kimsal: You're asking me to start. Are you asking me start, is that what you're saying?

Manuel Lemos: Yeah, because somehow you had better luck in trying this.

Michael Kimsal: Well, it's just could be because I'm better looking. That might be what it is.

Manuel Lemos: Yeah.

Michael Kimsal: But, and speaking of good looking, seriouslyjs.org is what we're referring to. Now, I saw this, Manuel actually sent me this a couple of days from today. It sounds like it'd be pretty neat. I think you've seen a few weeks ago when they first announced it.

And it is a video compositing library, a JavaScript library that uses WebGL. But you have to have a WebGL-capable browser that is sitting on top of something that actually has the right graphics chips to use it. I did get it to work at some point but I can't get it to work now. So I'm going on memory for a month.

There were a couple of different live, or is it live, streaming videos and there were a series of buttons at the bottom. As the video was playing, you could change those, click the buttons and it would apply different effects to that video stream on the fly, whether it was color changes.

There were a couple different colors and tinting changes, if I remember correctly. There at least one that would do some spatial perspective changes on the video as it was happening.

It was really interesting. But partially because it's one of these that I'm thinking, it's going to be probably for another couple of years until we have most browsers supporting the WebGL stuff out the box. It's still though just kind of a neat hack for public stuff.

Manuel Lemos: Well, I tried it here on computer that has a graphics card with 3D capabilities but probably I need to install something. I could not figure what it was but...

Michael Kimsal: It might be that you need a nightly of a browser. I seem to remember at some point that I had tried with a much more current, like a bleeding edge of Firefox or something.

Manuel Lemos: Yeah. It's something browser-related, definitely, because when I'm on Linux, there are those 3D desktop effects that I can use regularly and I do not have to enable anything on the OS. So I supposed OpenGL or something compatible is enabled in the desktop.

Michael Kimsal: Yes, this is part of it.

Manuel Lemos: Yeah.

Michael Kimsal: Here it is. I just go it to work. I had to use a Firefox nightly. And I think there was a config setting that I had to set, about:config. But I do have this working now.

OK, yeah, if you can see this. Maybe, I can make a video of it and send it to you. It's pretty slick.

Manuel Lemos: Well, I supposed it would be interesting for the developers to provide the video showing how it would look, but I think that it did not cross their minds to do it.

Michael Kimsal: I don't think they care all that much.

Manuel Lemos: Right.

Michael Kimsal: If you got the hardware and software to run, it runs. And if not, well, showing you a video just make you say, "Oh, I don't have that."

Manuel Lemos: Just a teaser.

Michael Kimsal: Yeah. Maybe just shouldn't show some people some things because they'd just get jealous.

Manuel Lemos: Just to motivate you to bother to figure what is the setting that you need to enable your browser. Well, anyway...

Michael Kimsal: I've been using the... I think it's using the... This is Firefox Nightly 12.0a1 from January 11. As I've checked it, it's actually downloading me a new version. But the version from January 11 didn't work. So Firefox 12 works, but Firefox 10 doesn't. There you go.

Manuel Lemos: Yeah, I think maybe that's what I'm using.

Well, anyway, we're just talking about it. We'll not be showing anything at least because it's just recording audio for now. Maybe in the future, we can do a video podcast with all these resources and hangouts on Google +1.

Just to give an idea, anybody that is interested on this kind of effects can go to seriouslyjs.org and they can try it there to see if it works on their browsers or figure what it needs to be enabled.

Michael Kimsal: Sure.

PSD.js: Photoshop File Format Parser (5:49)

Manuel Lemos: Anyway, moving on, another interesting library that I found. At least because it's not usual. It is a Photoshop file parser library.

It basically parses a Photoshop file, the so called PSD files. They can actually extract some metadata from the files, I think. I'm not sure if they can actually the extract graphics, the image data from the file, but at least some information about what it contains, seems to be what this library does for now. Probably it will do more in the future, but it's all interesting.

Sometime ago, there was a developer that submitted something similar for PHP but it actually could extract the images. Well here, we are talking about JavaScript but for those PHP developers that may be listening, they might also want to take a look at such libraries.

The only difference is that since PHP runs essentially on Web server side, anything that you could do on the browser side, you won't be able to do like what you can using this library.

But from what I can see, they have to have a goals to be able to actually show the images that are in the files, the PSD files, eventually separating the layers and show them usually in HTML canvas.

Michael Kimsal: That's a very audacious goal. I hope they get to it.

Manuel Lemos: Well, I think they did it in PHP, so probably in JavaScript, it would not be a big deal. Although PHP has the GD Library that can do many things with graphics that may...

Michael Kimsal: I did a little bit of image stuff last year with JavaScript and taking data out of a file. In some measures, I guess you could do some things with a data resource and I think it Base64 encoded everything. Some of the browsers can do some of these stuff already but it's still very largely dependent on your JavaScript engine and your browser.

So I have a suspicion that some browsers might always be falling back or performing behind on this. But if they could say, "Hey, this works in Firefox 11 and Chrome and Safari," that's still going to hit a very large portion of the type of people that don't want to use this effect or something.

Manuel Lemos: Right. And short of saying, "Oh, nobody's using IE anymore." It's amazing that all IE share is decreasing. I don't know if it is something related with the lack of love that Microsoft is getting, but it's not getting it much love...

Michael Kimsal: That's another... It's actually a discussion that maybe we should have next time because I had one of the listeners to this podcast wrote me and asked about .NET developers and why .NET developers don't get more love or get more, I can't get what the exact word is, I guess 'respect' in the design, from a front-end designer, front-end developer standpoint.

I meant to more clarify if he meant design or developer, but that may be an interesting topic to explore. Or maybe have him on at some point, too. Because he's a .NET guy and I think he feels a bit marginalized. Sometimes, we see a lot of podcasts that...

Manuel Lemos: I think it's cool. Well, my theory is Microsoft-related. Although I'm not going to extend this but just as a side comment, did you notice that the Nginx browser... Nginx, right?

Michael Kimsal: Server. The Nginx server?

Manuel Lemos: Yeah, the server, the share has surpassed the IIS, Microsoft Internet Information Server.

Michael Kimsal: Yeah, I have heard about that , yeah.

Manuel Lemos: And decreasing over the years. So whatever is happening in the Microsoft world, it's not as it was in the past. Remember when Internet Explorer used to have a much larger share.

Michael Kimsal: Oh yeah, I remember when it mattered.

Manuel Lemos: Well, we don't know what...

Michael Kimsal: It's not that it doesn't matter at all now. But cross-platform functionality matters a lot more, if only because of mobile devices.

You can write stuff and then if it works right in multiple browsers in desktops and multiple mobile browsers, if it doesn't work in IE6, I think few people would even care.

IE6 is almost a dead horse, but IE7 - it's just not the focus I think that it used to be. But another topic for another day probably.

Manuel Lemos: Right.

Michael Kimsal: I got one more curve. I have a curve ball that I want to throw you in a bit that we didn't talk about. And you could...

Manuel Lemos: I just wanted to...

Michael Kimsal: You could choose to do it or not, but we'll carry on on the scheduled stuff for a bit.

Manuel Lemos: We'll do it.

Apache 2.4 to match Node.js event driven Web server capabilities (11:04)

Manuel Lemos: I just wanted to complement something that is somewhat related to JavaScript which is the fact that just these days, Apache 2.4 was finally released. It somewhat implements event... Although they call it... It's not exactly... Well, it's somewhat the way that Node.js work. It's all based on events and the goal is to some how save memory.

So there is a new mode for Apache servers to work that end up being as efficient in terms of memory usage and probably response feed that is similar to what you would achieve on using Node.js.

Well, I don't know if that is going to make any difference to any of the listeners, because whoever, was already going through that train of using Node.js - for using it as a Web server as well, using these HTTP server object, at least, there are some focus.

I wanted to mention this because since I mentioned before Nginx server. This is somewhat related because there is an effort to make the Web servers more efficient. And that is the reason why Nginx has been getting attraction, inclusively surpassed the Microsoft IIS.

And this is probably a topic that we'll get back in the future. But moving on, I don't know if you wanted to bring up that topic or just follow the schedule.

Michael Kimsal: Follow the schedule for a bit. I'm used to that schedule.

Manuel Lemos: Well, we are covering several libraries that we've been looking into lately. And there is just one more and you'll get back to your surprise topic.

Michael Kimsal: Woooh!

Textualizer.js text animation effects (13:14)

Manuel Lemos: Actually, I'll just comment a bit about a... There is a library named Textualizer.js, basically just to present text with nice animation effects. Not exactly a big deal but it's always good to sometimes show pages with certain effects and in this case, with this Textualizer library, it applies some effects to the letters and make them fade and appear in a different order and move them to the final positions.

And probably it's better understood if our listeners go to the page of this project. It's kiro.me/textualizer. I'll post the link in the show notes and whoever found this interesting can go there.

We have many general purpose animation libraries but this one is specific for text. And if you want to show some text with nice effects in your pages, you might want to take a look into this library.

Well, this was...

Michael Kimsal: Well, I just like it a lot.

Manuel Lemos: This was the plan.

Michael Kimsal: Sure. Well, I'm just looking at Textualizer. I'm just watching the animations go by and it's... If not hypnotic, it's still pretty slick. I just keep watching. And yet, I probably say this almost every show, I feel like I'm getting old.

If we'd seen animation like this ten years ago, certainly 20 years ago, on a computer, this would have cost thousands and thousands of dollars or it would have taken days to render something this smooth.

And I'm looking at it here on effectively commodity hardware that you can go to the mall and buy. I'm just looking and say, "Oh, girl, it's neat.". I'm continually amazed at how far we've come with...

Manuel Lemos: Yeah.

Making AJAX pages load faster using UI sheets (15:13)

Michael Kimsal: Let me take my old man hat off for a moment.

Manuel Lemos: OK. And I'll put the hipster hat.

Michael Kimsal: Yes, and then angle it. It's jointly placed to one side.

And I was actually looking for a hacker news discussion because I saw this. I remember what it was, it was a discussion last week. It's 37signals said, "Hey, we got the new Basecamp coming out and here's what we did to make it really, really fast."

And there's a big discussion on it because apparently, if I read this right, a lot of what they were doing is: they got a lot of AJAX and they got a lot of caching. But most of the AJAX calls are hitting the server and the server's rendering HTML. And they're getting HTML snippets back rather than sending back data structures that are then parsed and processed into new DOM elements or modifying local DOM elements.

And that seems to just kick off a whole discussion thread about where should, server-side or client-side... It touched a nerve with me because I have recently, in the past month or so, started to work a lot more on a client project that has an extreme amount of front-end JavaScript. And almost everything you do is reaching back to the server with a JSON request and is getting a JSON object back.

At one level,"Hey, that's really slick. That's cool. That's separated. That's SOA. That's whatever." In another level, it's extremely hard to figure out what is going on. Some of it is the way the code is written. Some of it is the libraries that had been used. Some of it's just... If you're trying to figure why something went wrong, when you don't have...

Manuel Lemos: When you said that it renders HTML...

Michael Kimsal: Go ahead.

Manuel Lemos: Sorry. When you said that it renders HTML on the server, what do you mean? Does it return images? Graphics?

Michael Kimsal: Well, I think with that 37signals article, they're returning just a block of HTML, like an open <p> tag with some text and a close </p> tag, something like that, or an actual DIV with the contents on it, rather than a JSON object that is then parsed and then a DIV object just created and inserted some place instead of saying, "Here's the DIV. Here's the HTML for the DIV. Just put it in wherever you want to put it." In that case, that was where the discussion was but it really hit me.

Dealing with timezone differences between the browser and server sides (17:44)

One of the things that we're actually wrestling with right now, and I'll throw this out because I think we may have a couple of solutions coming up. But this has taken far longer than it should have for a number for a number of reasons. But these are open plea for some help.

The framework that we're using, the server-side and client-side framework talking together, deal with anything on the server-side which is listed as a date or a time is automatically converted when the JSON objects are created.

They are created as date. Right now, they are created as date objects in JavaScript. So you get a JSON object that says, "Oh, your start date is..." and then actually it's an expression of new date with a timestamp in it.

So that is evaluated in the browser as this is this moment in time. Well, we hear the snag because initially, everything was just dates. And the dates were stored as... they were stored as day time but the time was always midnight.

So what was happening is, you will get this date object in JavaScript that looks fine in North Carolina and then when somebody in Kansas look at it, their browser was interpreting that same new date object as two hours earlier but it was only rendering the date. So my date would say February 9th, meaning midnight and their date would say February 8th which is really February 8th, 10pm, their time.

Michael Kimsal: ... So it's another aspect of... the client-side.

Manuel Lemos: The difference in time zones, right?

Michael Kimsal: Yes, exactly. Because the creation of what it actually needs to be the date or the time is happening in the person's browser respecting their time zones or language and all that kind of stuff.

So we've actually been wrestling with this a lot. And compounding that is the fact that this particular project has a need to store dates, just dates. Because there is some moment in time during the ordering processing when we don't have an associated time with it.

So just saying it's this date at midnight doesn't make sense because it doesn't actually give midnight. We need a null in there for the time which means we have to keep these... At least seems right now, we have to keep these in separate fields.

This is kind of getting into non-Javascripty stuff but the lot of this was kicked off by... There's a lot of processing going on at the client that we don't have ultimate control over. Or to the extent, we have control, it's just very hard.

I upgraded to IntelliJ several months ago. So I'm now used to doing breakpoints all over the place and stopping and doing all these stuff. And thank goodness for Firebug. I'm getting really good at using Firebug but it's still not as friendly a full-pledged IDE that lets me do all the things.

So I don't know if you have any maybe project experience or experience with heavy front-end stuff. I actually don't write. I guess I can say, my friend, Rebecca Murphy, well-known for the yayQuery Podcast on amongst other things, I worked at one project with her almost two years ago now. And she did a fantastic job setting up a Dojo project, full unit tests just in a Dojo. That was great.

That's not what I have right now. I've inherited something that feels largely untestable. Trying to still get my arms around it but it has made me want to retreat back to the safety of the server-side and the completeness of server-side.

I don't know if either you, yourself or if you've worked...

Manuel Lemos: Well, dates, I don't think I ever have a problem dealing with dates. But usually, it's like you said, I usually deal with that on the server-side. And I try to use the ISO format. I don't use... I'm not sure what you mean with the problems you had.

You said you had a problem dealing with dates because they are represented differently on the browser and the server because of the time zone differences, right?

Michael Kimsal: Yes.

Manuel Lemos: And what was exactly the problem? When you sent the date back to the server, it was not on the same time zone?

Michael Kimsal: The date comes up but it would come up as a string and that would get parsed out. But when it would be returned, it was being returned as... When it was being sent from the server to the client, it was... and I'd say, I think even right now, today... it's still is being sent as a JavaScript object. Not a string that says 02092001 or 2001-02-09. It's being sent as an expression that says "new date (16594327000)", something like that.

Manuel Lemos: So the value that is in there, what is it? Is it a timestamp?

Michael Kimsal: I guess it is a UNIX timestamp. I think it's a UNIX timestamp. I'm still getting my head around this, and I...

Manuel Lemos: Well, timestamps... you mean... Because probably it's serialized in the format that the browser machine uses, right? I don't know, because there are UNIX timestamps which are not the same in Windows for instance.

Michael Kimsal: Right. I think JavaScript engines all associate that in the same... I think they all deal with them the same way.

Manuel Lemos: Yeah. Well, I never had to deal with that directly. But if it is an epoch value which is relative to January 1st of 1970, that value is always in the UTC time zone. So you have to format it on the server-side assuming it is on UTC not on the server time zone which isn't likely to be UTC.

And that's probably why you have two hours difference. Because the UNIX epoch values are always relative to the UTC time zone. It doesn't matter where you are.

And well, if you are using PHP on the server-side there, for instance, functions like strftime which formats a time stamp as text and then you have several marks to use the time, the day, the year, or the month in whatever format you want.

And there is also the function which is similar to that one which is called gmstrftime.

Michael Kimsal: Yeah.

Manuel Lemos: Which formats the same date but in the UTC time zone. But I don't know, it depends what you do on those dates.

Ideally, even if you are in a different time zone, I always recommend that you store in your database in UTC because it won't matter where your server is, what is the daylight savings and stuff like that.

But that is something that is to be planned from the beginning or else, you'll probably have a big headache later to deal with dates in the future. But as long as you use everything relative to UTC, I think it's all right.

I was not familiar, what would be the serialization format that JavaScript would use? But now that you've mentioned, it's probably something that is platform-independent. Probably it's epoch which is an integer value relative to January 1st, 1970 but always in UTC.

Well, I don't know, I think you have to try to figure to compare...

Michael Kimsal: It's been an insane mess, actually, I have to say, for a bunch of reasons. And we're actually been working on this for more than a month. I'm almost ashamed to say that because anybody listening would say, "What an idiot! You just do blah."

Manuel Lemos: Yeah.

Michael Kimsal: But I had some other people working with me too. And there's a couple of things that come out with that. One is that A, we're dealing with thousands of files that we didn't write. And I say we, none of us on the team wrote it because we've been part of this all brand new.

Manuel Lemos: Right. Legacy.

Michael Kimsal: And you got code on the server and now you got a lot of code also in the client. So even to figure out where these things are.

And there's a load of assumptions that have been in the code, they're just "Oh, I'm getting a... " There's probably two dozen places I can think of, just not on the top of my head, in the JavaScript code that say, "Oh go grab me this and do Date.parse on it." Well, all of that, all of that code is assuming... No, it's a dull doing it with native Date.parse stuff in JavaScript.

It's assuming that everything coming down is in one format. And now, when you change that format, every place that uses it now has to... They'll be changed. Or what we need to really do is put in some sort of a middle abstraction layer, which I was kind of fighting against. I didn't want to do that.

I thought we could just fix this. And then it turned into, "Just fix this, just fix this, just fix this." And one of the guys of the team kind of verbally sat me down last week and said, "You know, maybe we should try something different."

Michael Kimsal: I said, "Yeah." I think, like in the back of my head, you know there's a right way to do it but... And this isn't really just JavaScript, this is engineering software in general. You know that there's a correct way to do it and I constantly struggle with "Do we do it the right way?"

In some ways, I don't know how long the right way's going to take but if I say I can address this one problem in front of me in six hours. That's known. OK, I can do that. But then you find out whether there's something else. "Oh, there's one more thing, " and it turns into... At some point it becomes an unknown.

Now, all of you out there listening would say, "Well, just run all of your unit tests and that will find out your problems."

Manuel Lemos: Oh, right.

Michael Kimsal: To all of you says I say ha ha ha ha ha ha.

Manuel Lemos: It doesn't work that way.

Michael Kimsal: Well, if we had, say, 400 unit tests written all over this, then it would be much more easy. We'll have the confidence to make these changes and experiment and we don't have that confidence.

Anyway, that's a little bit of a side topic. If anybody here has maybe strong thoughts one way or the other about server-side versus client-side, do you do full apps in the browser? Or do you use things like jQuery, Dojo and YUI? Do you use them more for just enhancements?

I know you and I have talked about that a couple of times in the past year.

Manuel Lemos: Yeah.

Michael Kimsal: So I'd like to hear from more people that had wrestled with that.

Twitter abandoning the hash bang convention for single page AJAX apps (28:25)

Manuel Lemos: I think it's a bit complicated. Now people seem to be tempted to use the browser side of template engines and things like that. But if you need to generate pages that need to be indexed by search engines because they are public, they have content, you can use that convention that we mentioned before, the hash bang convention that use the hash character followed by the exclamation mark and is... search engines... .

Michael Kimsal: Interestingly enough, that was just the topic the other day that Twitter themselves are... I think were the first big proponent of hash bang syntax and they're deprecating that. They're going away from having that be their standard default now.

Manuel Lemos: Yeah, well, I don't know. I don't know why they used it in the first place. They probably did not really need to use it at least in every case they are trying to handle. That's more when you have AJAX-based user interface... something that is updated without reloading the page completely as when you click on a link that goes to the server and fetch the content.

Well, but anyway, even when you used that hashbang convention, what happens is that the search engine bot will access your server to fetch a page that removes the hashbang from the URL. Your server needs to be ready to serve the actual content of that page.

So if you rely on the browser to render everything, that won't do because the server will still need to be able to generate the page regardless where usually the page is rendered. So it won't do for that purpose.

Michael Kimsal: Interesting.

Manuel Lemos: Bottom line is, that you always have to be able to generate the page on the server-side. Even if in practice for human users, the browser will render the page.

Michael Kimsal: Sure.

Manuel Lemos: This means that if you use a template engine in JavaScript on the browser side, you probably need to have an equivalent in the server-side to render the page exactly the same way. So I don't know if it is worth this duplication of effort.

Well, I actually never tried to do that because I always try to render everything on the server, even when it's all part of content is served via AJAX request, I still render it on the server and then send the HTML to update whatever the places of the pages that need to be updated. So the server always knows how to render the page, even if it's splitting in many parts.

Anyway, that's probably yet another challenge for those that want to implement fast user interfaces. The question is, is it really worth to render everything on the browser side or you still have to be concerned with the server-side?

Michael Kimsal: Yeah. We'll bring it up again at some point. Reach out to me or Manuel if you have any strong opinions one way or the other. We would love to hear your thoughts.

Manuel Lemos: Yeah, everybody can comment on this podcast comment section to show what are the criteria that each one is using for their own projects.

Friends of the Site incentive enhancements (31:57)

Manuel Lemos: But moving on with our podcast, we are going to carry on with one of the regular sections of the podcast, which is the one on which we comment about the latest classes that were released in JSClasses site.

This month, there is a great increase in the number of the classes that had been submitted.

Michael Kimsal: Yeah.

Manuel Lemos: As I mentioned before, there is now sort of an incentive or at least a feedback mechanism that the site is using which is to send as part of the report by email telling each author how they are doing, if their classes are having more users, or if they are rising or not in their ranking of authors and stuff.

And this has been encouraging authors to send more classes to the site and this seems to be working very well. I hope it continues to be that way. We still need to encourage more authors to come to the site and take advantage of the fact that the site will give you even more exposure to new projects.

And this also leads to something that I wanted to comment. By the time we are recording, it was not yet announced but this month, I've been working on something that is about to be announced which is sort of an enhancement of that report that goes by email, that is also giving feedback to users, that are bringing other users to the site.

So now, there is something that was started actually in the PHPClasses site in 2002, which is the Friends of the Site initiative. It's basically meant to encourage every user, not just authors, to send more users to the site... eventually, to become contributors.

So there is now a page, I'll mention more explicitly in the Show Notes, that shows a ranking of the users that led more users to the site. And to make this referral mechanism simpler, which requires to just append a few parameters to any URL of site. So when the users come to the site, the site realizes that it was you that referred.

If you click on those buttons that are on almost every page of the site, the +1 or the Facebook likes or the tweets, they pass a slightly changed URL to those social networks. So when they appear in your timeline or whatever it is that you use in your preferred social network, the URL contains some parameters that identify that it was you that was referring.

So this is practically to say that the site is encouraging you to tweet and like and +1 your pages of the site that you think that are interesting, eventually have some comments of your own telling why you think the pages that you interesting. And any users that follow your links and come to site and register, you get a sort of a credit. And you'll be rising in the Friends of The Site ranking.

Additionally, I already mentioned that this report that goes by email to the top of the site contributors tells you how you are doing, how many users that you have led to the site and registered and also, if any of those users have submitted a new class. So if you know anybody that did not submit a class to the site but you think could submit a class and benefit the whole community, you can just pass the URL.

It will be explained in more detail how it is formatted. When the person comes to the site and she registers and submit the class, you'll be credited for that. And this is just a way to give an incentive for more and better classes to be submitted to the site.

Well, anyway, there will be an article talking more about this. By the time we are recording, it was not yet published but it will be until this broadcast is live.

Latest Objects Published on the JSClasses site (36:42)

Manuel Lemos: So now, getting back to what we are going to do, Michael, which are the classes, objects, that you'd like to mention.

Michael Kimsal: Well, first, we'll look at simTaco. Hope I'm saying that correctly, SimTaco. This is from Hensel Hartmann from Switzerland. I wish I could say something in Swiss. I don't know anything. Hello. Pretend I was an Englishman in Switzerland. I would say, "Hello!" That's as good as a foreign language that I can do right now.

Manuel Lemos: Right. They know English in Switzerland.

Michael Kimsal: OK.

Michael Kimsal: But this project is interesting. It's actually, that's where the Taco comes from. This is a port of Taconite. That's Taconite plugin. And this actually kind of touches on what we're talking about before.

This is a way of doing fast AJAX calls back and forth from client to server. The notes that Hensel mentions here, this could be used as an unlimited option to the server and it can also bind, works on demand and not by listener.

Anyway, you can read a little bit more about that. But it looks like Hensel's one of those guys that is using heavy AJAX to build very strong client-side UIs and very complex interactions.

Exactly what's causing me a lot of problems right now. So I can respect the work that going into something like this, more so because I've been recently having to deal with a lot of the pain of dealing with something.

And it's not to say that what I'm dealing with... I'm not saying, "Oh, it's bad, it's garbage." It's just that it's very large and it's foreign to me. I just want to get that out. I'm not trying to bash the guys that came before me on the project. They'd accomplished quite a lot.

But anyway, back to simTaco, I didn't quite get what the Taco name came from first. But it's a port of the Taconite plugin. That was the first one. Now, there are couple of others I can mention but if you want to chime in, if you want to go back and forth, we can do that.

Manuel Lemos: Well, I think I did not test this in practice. I usually review most of the code to figure what it does. But the idea is to provide that effect that we see on Facebook that updates pages. Well, they gradually...

Michael Kimsal: The Taconite plugin itself is a way of coordinating. In fact, it's kind of registering multiple callbacks, multiple events that happen based on one AJAX call. So you can do one AJAX, say, "Get me this status." But from that, this is what simTaco does so well, too.

You can configure, "Here are three things that should happen based on this update." Or five things, rather than tying each one, each thing that you need updated to its own AJAX call. You can bundle them together. That's the really the core of it.

Manuel Lemos: Right. Well, the idea is for that to be able to update different parts of the page just like what you see on Facebook and other sites.

And for now, that's all I can say. But you were going to mention other objects that you want to comment on.

Michael Kimsal: Well, another one is from our good friend Arturs Sosins from Latvia. Good morning, Arturs. Or good afternoon or good evening.

I mentioned something that he'd done in the last podcast and he did it again. This class is actually something that's built specifically for the Titanium Appcelerator framework.

And this is a timer countdown that you can apply to labels in Titanium. You can make a label and throw this countdown object on it and it will do a timer of the countdown for you.

In and out of itself, nothing overly complex, not like the simTaco before it. But just the fact that it's a plugin that's designed around the Titanium framework is I think, at this point, still worthy of note.

Manuel Lemos: Right. Well, it's one more object, like we mentioned in the past episode, that one of the snowflakes, it's basically to demonstrate what you can do in JavaScript and then using the Titanium framework to generate applications for mobile devices and whatever are the platforms supported by the Titanium project.

This is interesting. Actually, I've been talking with Arturs, considering the development of an eventual application for the site. In this case, it's JSClasses but will be practically the same for PHPClasses, which they share the same code base.

Actually, I was trying to figure out how much work would be involved because looking at this objects, it seems simple. But then, there are details which are device-specific that do not work the same way.

And from what I could gather, Titanium provides different APIs for different devices even though the purpose of those APIs are somewhat overlapping.

And basically this means you'd need to write device-specific code depending on the platform you are targeting. So despite that, it is all simple, it's all in JavaScript, you still have to make some device-specific effort to take advantage of specific features of the devices.

I was also asked him about PhoneGap, if he have tried it. Basically, he told me that is very slow because it runs on top of a proxy. So the actual calls to the system are to communicate with a proxy, which is in the device. I don't know, I understood that it was to render the user interface and things like that.

So he was not very amused by PhoneGap. Probably, Titanium is more efficient but you might need to perform more device-specific development.

I haven't tried this. I would like to have more time to do it but right now, I'm already really buried in many other things that I want to develop first. Although it would be nice, I don't know if I'm going to go ahead and develop an actual application. Well, it depends on the purpose. Maybe I will consider it later. But for now, just to give an idea.

Carrying on, what are other...

Michael Kimsal: Well, I had one more that I was thinking about mentioning. I mentioned it by name but there's another one that's actually caught my attention a little more, the first one is by just Jason, jQuery handleStorage. So again, he's written to do the handleStorage but, and this is not to knock handleStorage, there's one that has struck me as... I'm going to try this out on a project, that's Reflect Object.

This is a pretty minimal class that lets you reflect. In a way kind of like var_dump or print_r on PHP but it's actually, with var_dump and print_r in PHP, it typically just get the values. This Reflect Object will give you all of the properties, with all the methods as well on an object.

And as useful as I find Firebug to do a lot of that for me, sometimes, even just finding all of the values that I'm looking for in the Firebug tree gets a little convoluted. And I'm going to play with this and see if this would be a good thing to help. Because at times when I know, when I get to this point in the code, I want to be able to see what's going on here.

Manuel Lemos: Yeah. You mean the reflect-object, right?

Michael Kimsal: Yes, Reflect Object, yes. And that is, I forget to mention his name. Who's that from. That's from Tom Schaefer in Germany. Our fielder's named Tom.

Manuel Lemos: Yeah. Tom has been a regular contributor to both to JSClasses and PHPClasses.

Michael Kimsal: Awesome, professor.

Manuel Lemos: Yeah. He always send his nice classes to the site. I hope he can continue to do it as well. Any other class or is this last you wanted to comment on?

Michael Kimsal: Well that's the last I want to go. I wanted to hear what you're going to talk about a bit.

Manuel Lemos: Well, I also picked a few because since this month, we have more than usual. And also, we have more time to talk about these classes. I also picked three of them.

One of them is also from Arturs Sosins, this Lightning Effect which was quite impressive. Did you see this in practice or the...

Michael Kimsal: I didn't see it run. I saw the demo.

Manuel Lemos: Not if you go to the Related Links section, there is a link that says Class Documentation but you can also see live examples. And it's quite impressive because it renders sort of a lightning bolt, a ray that... It's very similar.

And it use canvas to render that bolt, all the randomness of the lightning and it is very interesting because it gives a very impressive effect. It can help to capture the attention of your users if you use this in a page that you have in any of your sites. And this is very interesting.

Manuel Lemos: And again...

Michael Kimsal: I like the mouse one. When you move the mouse around, that's pretty cool.

Manuel Lemos: All, it seems that it's kind of killing somebody with the electricity. If you drag the mouse around while you click.

Michael Kimsal: Yes.

Manuel Lemos: Well, this is one of the few that I wanted to comment. This month, we are already at 10 and we're practically doubling the rate of contributions of the past month. But we don't have time to comment on all of them. We just comment on a few.

Other than this one of the Lightning Effect, I also want to comment on this one, the File Drop from Pavel from Russia. Basically, he developed a way to handle file drag and drop from your desktop to your browser. So you can drag files by their icons into your browser and have them uploaded.

So this object allows you to register all sorts of callbacks to figure the progress of all events, since you to start dragging and dropping and then starting upload and then when it finish the upload. So it's quite complete for those that are interested on things like this, dragging and dropping files from the desktop into the browser for uploading purposes.

And the other one that I also want to comment, another one. This is one is from Daniel Martinez from Spain. It's actually a nice example of implementing a very simple image, basically a puzzle. It takes an image and splits it in several parts and shuffles those parts. So you need to click on the mouse to make the parts move until the puzzle is all sorted.

It's very interesting because you can use this to learn how to implement a very simple game of dragging all the images around in a canvass. And this could be used as an example of how to implement all sorts of games that requires to move graphics around.

Michael Kimsal: He is using a Simpsons picture.

Manuel Lemos: He is.

Michael Kimsal: Yes. Are you going to get shut down by SOPA down in Brazil?

Manuel Lemos: Not yet. But I think, at least, I can get DMCA take down request. But I always comply, so anyway, maybe I should ask the author to please change the picture before whoever owns the rights to Simpsons knocks.

Michael Kimsal: Fox is going to come knocking at your door.

Manuel Lemos: I'm going to be foxed.

Michael Kimsal: Can you say that? Are you... OK.

Manuel Lemos: Foxed, foxed.

Michael Kimsal: Oh, foxed, OK. Yes, yes, OK.

Manuel Lemos: Well, I think this is all for now. We have many other classes that we could comment on but we don't have time to comment on all of them. Some are more interesting than others but we covered quite a few. I hope the authors continue to send more of these nice classes so we can keep talking about them.

Articles of the latest issue of the JSMag magazine (50:20)

Manuel Lemos: And now, moving on to our final section, I'm not sure. Michael do you have it ready to comment on the upcoming topics of the JSMag magazine.

Michael Kimsal: Well, hopefully, yes. We have something last month that had to get... We had some technical issues but we got local chap Matthew Bass has a piece for us on using eJS templating, JavaScript templating in Rails. So it's going to be a Rails-JavaScript combo.

Mike Schwartz is continuing his series on server-side JavaScript with SilkJS . He's been running this series for awhile. SilkJS is a project he's been working on and he details different aspects of that every month.

We got an article on specific jQuery plugin, development and projects of the prompt menu plugin that's out there for jQuery.

And there's a couple of other things we may be having as well, but I haven't got confirmation on those yet.

Manuel Lemos: Yeah.

Michael Kimsal: And as usual. I will throw out... I'm going to be a bit more specific this time because I've said, "Hey, we're looking for somebody. If you want to write something, if you're interested in this and that... "

Oh, I should also say David Calhoun every month does our news. He does a great news roundup and he does a somewhat sporadic... He's turned it into a podcast as well. He does usually a JavaScript news roundup for us every couple of weeks on the blog, JSMag blog. And he often does an audio reading of all that as well.

So if you want even more JavaScript news, you can listen to David Calhoun at jsmag.com/blog. Want to give him a shoutout because he does a great job on that.

Manuel Lemos: Right.

Michael Kimsal: But one thing I was going to ask for is, rather than just saying, "Hey, if you want to write about something, let me know." That's always there because I've met some great people through this podcast, people reaching out, saying, "Hey, I'd like to contribute. I got this, I got that."

I specifically would like to hear from people that would like to do some longer ongoing columns of some sort, whether it's mobile developments with JavaScript or perhaps even JavaScript optimization, JavaScript security, apps security to JavaScript. Or things like a Titanium column, something like that.

Something that would be more than just, "Here's one article," and give you something. But where you could explore different angles on that topic every month, a regular column. I would like to hear from anybody who's interested in doing that. Because I think some people...

Actually, I was talking to somebody last month about writing and he had a topic. And he called me after a couple of weeks and said, "Well, there's too much here. I don't know where to stop. I don't know what I should put in and what I shouldn't put in." And that was actually probably a better candidate for a series or a column on mobile JavaScript stuff.

Manuel Lemos: Yeah.

Michael Kimsal: We do pay, if that's on your mind. And you'd like to talk to me about that, reach out to me, michael at jsmag.com and we can make that happen.

Manuel Lemos: Right. By the way, talking about mobile, did you already start with the articles of Arturs Sosins on Titanium? He was asking me about topics on that.

Michael Kimsal: He and I have not... We talked kind of on and off but we haven't formalized anything yet but that would be certainly a good use of his brainpower if he has the time commitment. I'd love to get an ongoing Titanium series from him, or anybody else that would like to contribute. Doesn't have to be Arturs.

Manuel Lemos: Right. Actually, he was asking me about what kind of thing I would be needing to develop an eventual JS classes or PHP classes, app for mobile using Titanium.

What I was almost trying to figure out is how to,for instance, get notifications into the device the more efficient way. I think there are push notifications but what would be the way to implement them because it will probably be different between platforms. There are more efficient ways to do using platform-specific code.

That would be one thing. Another thing is to have an application that is actually a background service that is listening to something and it is not showing anything to the user; but it may trigger some device notification so the user knows when something of his interest is happening.

And I was telling him about this. But nothing specific, just to get notifications from the site things that may be relevant to the actual user that is accessing it. It seems it can be done with Titanium but it's not so obvious because you may require platform-specific code as I mentioned.

And I think if he or somebody else starts it from there, it would be really useful to have a series of articles on that.

Michael Kimsal: I think it would too. So we should reach out to Arturs and say, "Write this."

Manuel Lemos: Yeah. If he has time, right? I understand he's very busy with his own startup but he's very willing also to contribute in this. That is always great.

Conclusion (55:49)

Manuel Lemos: Well, basically, this concludes our podcast. I hope we can continue to have much more of these to talk about in the upcoming episodes. Other than that, Michael, thank you again for coming. Your insights are always helpful and give people a lot to think about.

Michael Kimsal: I know.

Manuel Lemos: You are very humble but you know.

Michael Kimsal: I know that, too, yeah.

Manuel Lemos: OK, on my part, that is all for now. Bye.

Michael Kimsal: Thank you very much. I will talk to you later then. Bye-bye.

Can Apache 2.4 Match Node.js Event processing efficiency? - Lately in JavaScript podcast - Episode 16

Contents

Listen or download the podcast, RSS feed

Show notes

Read the podcast transcript

Listen or download the podcast and RSS feed

Show notes

Read the podcast transcript

Contents

Introduction (00:20)

Seriously.js Video Compositing library (1:14)

PSD.js: Photoshop File Format Parser (5:49)

Apache 2.4 to match Node.js event driven Web server capabilities (11:04)

Textualizer.js text animation effects (13:14)

Making AJAX pages load faster using UI sheets (15:13)

Dealing with timezone differences between the browser and server sides (17:44)

Twitter abandoning the hash bang convention for single page AJAX apps (28:25)

Friends of the Site incentive enhancements (31:57)

Latest Objects Published on the JSClasses site (36:42)

Articles of the latest issue of the JSMag magazine (50:20)

Conclusion (55:49)

Introduction (00:20)

Seriously.js Video Compositing library (1:14)

PSD.js: Photoshop File Format Parser (5:49)

Apache 2.4 to match Node.js event driven Web server capabilities (11:04)

Textualizer.js text animation effects (13:14)

Making AJAX pages load faster using UI sheets (15:13)

Dealing with timezone differences between the browser and server sides (17:44)

Twitter abandoning the hash bang convention for single page AJAX apps (28:25)

Friends of the Site incentive enhancements (31:57)

Latest Objects Published on the JSClasses site (36:42)

Articles of the latest issue of the JSMag magazine (50:20)

Conclusion (55:49)

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

Login Immediately with your account on: