Is JavaScript going to replace PHP? - Lately in JavaScript podcast episode 7 - JS Classes blog

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Introduction (00:20)

Interview with Zachary Kessin on Programming HTML 5 Applications book (1:05)

Sources of news to keep you up to date with the JavaScript world (30:55)

Is JavaScript going to replace PHP? (33:31)

Is Firefox better than Chrome for Web developers? (42:52)

Latest JavaScript objects released in the JSClasses site (53:00)

Upcoming JavaScript articles in JSMag magazine (59:33)

Conclusion (1:06:04)

Introduction (00:20)

Manuel Lemos: Hello and welcome to the Lately in JavaScript Podcast.  This is Manuel Lemos. As always I'm here presenting this podcast, bringing what has been happening in the JavaScript world along with my co-host Michael Kimsal, hello Michael.

Michael Kimsal: Hello as usual.

Manuel Lemos: How are you doing, Mike?  What have you been doing good in the JavaScript world?

Michael Kimsal: Well, JavaScript's OK. Personally I've been alright, sort of been bogged down with too much work, not necessarily a bad thing but not a whole lot of breathing room.  But we've got probably some cool JavaScript stuff to talk about as well, so back to you, carry on.

Interview with Zachary Kessin on Programming HTML 5 Applications book (1:05)

Manuel Lemos: Right.  In this episode we have a guest, Zachary Kessin I hope I'm pronouncing your name right. Hello Zach.

Zachary Kessin: Hello from Israel, and yeah, you got it right.

Michael Kimsal: Shalom!

Zachary Kessin: Shalom.

Manuel Lemos: Michael is the expert on foreign languages.

Michael Kimsal: I try to say a few words in each language.

Manuel Lemos: Okay, well, Zach is our guest because he's publishing a new book on JavaScript and HTML5, right?  Zach, can you give us an overview about the interesting points of your book?

Zachary Kessin: So the book is Programming HTML5 Applications, and it's out currently in early release from O'Reilly. It'll be out in a final publication in August or September.

And the theme of the book is that the Web, with HTML5 and JavaScript, has become a really great platform for building applications, the type of thing that five or ten years ago would have been a desktop application but now can be delivered through the Web, sort of the obvious example of this is Google Docs which is one of those things I think we've all used and come to depend on at some level.

But many, many other features have entered into HTML5 that are very useful for building applications for both mobile and non-mobile sources.

So, with HTML5 and the new advances in the last couple years of JavaScript it's possible to build an application into the browser that does stuff that five years ago you just could not have done in a web browser.

You can for example make a web page that will work even if you don't have a connection to the Internet and can cache all the files locally and store data offline and then when you come back online onto the Internet sync itself up with the server, you could not have done that five years ago, it just was impossible, that's sort of one feature.

Then there's Web workers. As you know, JavaScript runs a single thread of execution where you can only have one thing running at a time. So with Web workers you can have a model similar to what you might get in say Scala or Erlang where you have your main thread running in the browser and it accesses the DOM and do all those fun things.

But you can create a second process, or more than one if you like, running off in the background that it has no shared memory, it can't access the DOM, it can't access any of the global objects we're familiar with, you'd expect, but it can send messages back and forth to the main window so you can take some data, send it off to this Web worker which then processes it in some way and sends the data back which can then be displayed to the user.

So you can do some very impressive long running calculations in the background without slogging up the user interface, which if you start a big process in JavaScript without doing this you'll get a user interface just locks up on you.

There's also Web sockets. Web sockets allow you to basically do COMET but do it right where instead of having HTTP calls going back and forth you actually have genuine bidirectional communication. It's also nice because the overhead is much less, you don't have to establish a full HTTP connection to send three characters, you can just send a very minimal envelope.

Michael Kimsal: Zach, how much of the book, I'm looking here at the page of the book, about 300 pages estimated. How much do you devote to the Web sockets and the bi-directional, I've always been a little bi-curious, so I'm wondering how deep you go into that.

Zachary Kessin: Not as deep as I would like, I'm still working, I'm hoping still before the book hits publication to add to that a little because the problem with Web sockets is just what you can find out there is so sparse that...

Michael Kimsal: Hey, just read the source, I'm saying that facetiously of course.  And I think you're probably touching somewhat on the problems of tech publishing in general. I publish monthly tech journals, one on JavaScript, and just trying to keep up month-to-month and make sure that content is relevant and current is difficult enough.

I think a focused book I'm sure this is taking you many months to work on and compile, you're constantly I'm sure dealing with this is changing, this changing, this is changing. How have you dealt with that conundrum?

Zachary Kessin: With difficulty, parts of it I've gone back and rewritten.  I think we started it around September last year, so it's been awhile. 

Michael Kimsal: Certainly a 300 page book for one author you've done quite a lot.

Zachary Kessin: The 300 page count was the initial guess. It actually worked out to about 150.

Michael Kimsal: Oh, okay, well you're slack for that, slacking.

Zachary Kessin: Yeah, slacking, I've been bugging my editor to fix that actually.  This is actually one of a bunch of books on HTML5 that's coming out from O'Reilly.

Michael Kimsal: Just use big fonts, it'll be a 300 page book in no time.  I'd like to if I may steal Manuel's thunder for a moment or two or three, I'd like to go back through the mists of time to Boston, back to your youth, and have you describe for us a little bit about what your background with computers is and how you got into programming, and specifically how you got into JavaScript and what you're doing with it today.

You can probably answer quicker than I asked the question, but I always like to know people's background.

Zachary Kessin: So, let's see, I grew up in Boston. To go back let's just sort of start with the real beginning, my mother when she was in university in about 1970 actually was programming in LISP, and I'll come back to Lisp in a minute, JavaScript is a LISP language.

Anyway, so when I was about seven years old my mother told me if I could get half the money she'd buy me a computer. She didn't expect me to actually do it, I called every relative I could think of and asked for money.  Hey, I was seven, give me a break.  It was a Radio Shack color computer, it had 16 kilobytes of RAM.

Michael Kimsal: You're talking my language, I understand.

Manuel Lemos: And mine too.

Michael Kimsal: You're amongst old people here.

Zachary Kessin: Yeah, no kidding.  And it had you know in those days computers booted up to Basic, so I learned Basic. I'm not permanently scarred by it apparently.  Did some Pascal in high school, played with a few other languages along the way, when I hit university I started a Computer Science major, and at the time Brandeis University for your first class dropped you into a Structure and Interpretation of Computer Programs, one of the great all time books on computer programming, if you've not read it you should do so now!

Michael Kimsal: Well, I'll talk to you guys later then.  No, I'll wait.

Zachary Kessin: I love that book.  I have a copy and 20 years later it's still on my shelf.  And started out as a Computer Science major, discovered I liked physics a lot better, at the Physics Department, dropped out of university around '93, I worked in the .com boom in Boston for a while.

Llived in London, worked in high tech in London for a while because I could. And then when the .com boom crashed in 2001, a week after 9-11 I lost my job, went back to finish my university degree, moved to Israel, and somewhere along the line moved and in terms of professional programming went from Perl in the 90's to PHP, and then really picked up JavaScript over the last four or five years, maybe six.

Michael Kimsal: So you've been over in Israel for a long time, you're coming up on 10 years now.

Zachary Kessin: Seven, I came here... it'll be eight this summer.

Michael Kimsal: Okay, well you're coming up on 10, just don't move for a couple years, okay.

Zachary Kessin: Not going anywhere.

Michael Kimsal: Okay, because I don't know sometimes when we have guests either on this podcast or other times that I interview people I never quite know what their background is, and you don't make me feel old, other people make me feel very old because they start off with, “Well, my first year in high school I took a web programming course and I did this,” and it's insane.

Zachary Kessin: I remember when I was in university, this was about 1993, I was sitting in the apartment I was renting with my roommate, and we figured out how to make an HTML form but I couldn't quite figure out what to do with it, how you submit it.

My first web application was again '93, '94 timeframe, written in Perl, I think Perl 5 had just come out and MySQL didn't exist yet, we were using mSQL.

Michael Kimsal: Yep, from hughes.com.au back then, huh?

Zachary Kessin: Yep.

Michael Kimsal: Yes, all the old-fogies know what we're talking about.

Zachary Kessin: All the young people are going what are they talking about.  Yeah, I can honestly claim that I've been on the Internet programming the World Wide Web since rocks were soft and dirt was a fresh new idea.

Michael Kimsal: There you go.  So certainly I like to understand, to know that background because certainly people that have been programming longer than I have, it sounds like our age and careers are fairly similar, but in truth you've seen a lot of stuff and Manuel's seen it and I've seen it, been doing web stuff, we saw the first iteration mid to late 90's, JavaScript wasn't there then it was there, then it was a joke then it was broken everywhere, incompatible DOMs.

Five, six maybe seven years ago we started to see a coalescence around some standardization and then some of the toolkits like YUI and jQuery started to make abstraction over all the differences a much more palatable approach, those plus certainly faster computers.

Zachary Kessin: And the fact that the JavaScript engines in Chrome, in Firefox, in IE, etcetera, have just gotten so much better.

Manuel Lemos: Right.

Michael Kimsal: Oh, yeah, all of those.  The stars aligned and it's all been getting better over the past several years.  Seems to me one thing builds on another, now faster engines, faster CPU's, multiple cores and some adoption.

I think the big thing to me has been the lessening of Microsoft's dominance.  That's not to say that they haven't... they've certainly done things like introduce AJAX and brought some good ideas, but when you've got multiple competitors all mostly in a friendly way competing with each other.

But adopting the good ideas such that if I'm going to do, take Web workers, initially my understanding was the Google Gears plugin that was one way of doing it, someone else had another way, and everybody over the past few years has adopted 'this is the standard way'.

So if I run it, if I write to that loose spec it's going to work on... maybe it doesn't work on IE7 but it's going to work on some of the rest of the browsers, modern browsers.  So I think Microsoft in some corner still has a majority share in some cases, but I think they're rapidly becoming just the largest minority in most cases, so no one has a dominant thing, and it's in everybody's interest not to accommodate and adopt all of these new technologies so they're not left behind.

Zachary Kessin: And what's really nice is actually the WebKit browsers, which is Chrome and Safari basically, on mobile are really the dominant thing because the Android and iPhone browsers are based on WebKit, so HTML 5 is actually probably getting better penetration on mobile phones than it does on desktops, for a variety of reasons given the fact that most people replace their mobile phones more often than they do their desktops.

Manuel Lemos: Right.  I was just commenting just because earlier you mentioned Google Docs as an example of an application that you use HTML 5.

Zachary Kessin: I'm not actually sure how much HTML 5 they have.

Manuel Lemos: Well, I just read somewhere, I do not recall where, that actual Google Docs is not ready to work offline currently, and they are working on it to make it happen soon probably, a month.

So because I already tried to unplug my network to see what happened, and basically it got stuck, so it was not.  Although it may detect it became offline it still depends on being online to keep saving your changes.

Zachary Kessin: Yeah, taking an application offline is actually fairly challenging to do it well because there's two parts. You need to first of all keep local copies through the offline ability of all of the files that you might have as part of your application, all the JavaScript, all of the CSS, the images, everything else that needs to be cached off through the manifest file.

And then you need to have also be able to deal with storing its data in an offline storage.  The problem with that is you have local storage and indexed storage which just basically appear like a persistent JavaScript object, you put data in them and it stays there, it's kind of nice.

But you also have a SQL standard which was being proposed for a while which seems to be going away, and this has been called indexed DB, which is a No SQL solution sort of similar in idea to CouchDB or MongoDB in broad outline at least, but that seems like it's very inconsistent, Chrome has it, Firefox has it, but they're not compatible with each other near as you can tell.

So, indexed DB I think will be really cool in about 2013, but now in 2011 I would not recommend using it for anything more than just experimentation.

Manuel Lemos: Right.  Well, what I was going to ask regarding your book is, I understand that you have probably one or more chapters on offline work because it is one of the main advantages of the... we keep calling it HTML 5 but in reality just a JavaScript API, it's not exactly HTML.

Zachary Kessin: HTML 5 is one of these great buzz words like AJAX and DHTML that doesn't really mean anything specific. It's a collection of a bunch of new interfaces for JavaScript which is really what my book talks about.

There is some new CSS stuff which is really cool but my book doesn't talk to it, touch it at all. There's some new HTML tags which again I don't really talk, you know, I sort of glance over a few of them but other books will cover that.

In terms of applications really what's interesting is you have a bunch of new interfaces, the offline, the local storage, the Web workers and the Web sockets that allow you to really just build applications.

I don't know if it's possible today but I suspect a year from now you will see some real graphics packages, something of the Illustrator or Photoshop variety dawn in a web browser, which will just be really cool where you can build SVG graphics, again, like you would in a desktop application but in your browser and have all the browser advantages to it, it automatically updates, you can save it to the cloud.

Michael Kimsal: I'll have another program that I can use to be horribly crappy visually at.  You get one more way for me to express the fact that I can't draw or design or illustrate.  In the browser I can be mobile while I do it, sweet!

Zachary Kessin: My other people like my wife who is a graphic designer can do cool things with it.  Yeah, my ability with graphics programs is I can launch Gimp, take a screenshot and crop it to maybe draw an arrow on it to say hey look at this thing if I'm sending somebody a screenshot for a bug report or something, which I do every so often, but that's about my limit.

Yeah, HTML 5 has a whole bunch of different stuff in it, this book just really was intended to cover the application side of things, I think it's a compelling story.

Michael Kimsal: Let me ask maybe a little bit more about the compellingness of some of the sections, and this really speaks to what you do.

How much of what you cover in the book is something that you do on a daily basis, and that's meant to maybe put you in a bad position, but maybe I should rephrase this.

Are there some specific technology that you cover in the book that you find yourself maybe you were already doing before you started the book or you're already doing on a regular basis, things like the offline work, things like Web sockets, things like that, what do you use on a daily basis?

Zachary Kessin: Okay, well I do a lot of JavaScript just in general, a lot of functional JavaScript, I treat JavaScript as a functioning programming language much like say Haskell more than I do as a object oriented language, there's a whole section on that.

There's a section in the book actually which is non-specific HTML 5 on JavaScript testing in Selenium.  I personally feel JavaScript works better in some ways if you treat it like a functional language than if you do as an object oriented language.

The truth of the matter is one of the things that JavaScript got really right is the function, functions in JavaScript are really powerful and really if you know from Lisp what a Lambda is, a JavaScript function is a Lambda really, it doesn't use the word Lambda.

So functions are really the thing JavaScript got right, and then in more recent versions the array operations, things like map and filter, every..., and those are just really nice.  So for Map if you're not familiar with it, Map takes an array, a list and a function and it returns... it applies the function to every element of the array, it returns the array of what the function returned.

So if you want to process a list of elements for some reason, which is a pretty common thing to do, you just create a very small function.  I tend to write a lot of code that tends to have four or five maps sort of chained together each with a one-line function in it or a two-line function that does something really simple, four or five very simple transforms so that when you look at the code you can just sort of obviously see, oh yeah, this is doing what I want it to do which is really nice.

Michael Kimsal: My guess is that the by-product of that, maybe not for JavaScript so much, but the by-product of writing much more smaller chunkable code is testability, either an automated test or from a I just want to make sure this one thing does its thing.

It's also interesting you were talking about the mapping there because we've had this in PHP for donkey's years, as they in England, array walk, but the procedural syntax of PHP is such that I don't think that that style ever really caught on in PHP.

It's there and people use it sometimes but I don't think it's as central to people's program design as mapping and iterative constructs are in other languages, probably partially because just the core syntax and you say the chain-ability and things like that.

Zachary Kessin: I was using array_map in PHP yesterday.

Michael Kimsal: Again, it doesn't happen but you look at most of the PHP books out there it's just not something that is commonly used.

Zachary Kessin: I mean I do it in PHP because I spend 80% of my day in JavaScript doing this kind of stuff, so when I switch to PHP it just makes sense to use the same idea as I've already been using.

OK, so basically the section on power JavaScript I talk about jQuery and then Ext-JS from Sencha which is a really... if you're trying application level stuff in JavaScript and you're willing to deal with a library, it's a little bit on the heavy side in terms of downloads, really one of the best toolkits out there, it's great, I love it, really well documented.

Manuel Lemos: One thing I wanted to ask now that you mention some frameworks is that if in your book you cover any framework support to HTML 5 specific features?

Zachary Kessin: Yeah, I do, actually I talk about a couple of the jQuery extensions to deal with stuff to do some of those things.

Manuel Lemos: Right.  I think that's interesting because even more with jQuery which is usually popular most people would be interested in those aspects because they're already getting used to so much to that framework.

Zachary Kessin: Well, you know one of the things about JavaScript is it is a Lisp language, and if you ever talk to the old-time Lisp guys you'll discover what they do is you can... Lisp is a very dynamic language and will sort of build up Lisp until it gets to the problem domain.

But you can do that with JavaScript as well, I mean jQuery is really this wonderful syntactic extension to JavaScript that really just makes JavaScript much nicer to use.  If you're familiar with functional programming and Haskell and you've read about Monads, jQuery is more or less similar to a Haskell Monad, if you have no idea what that means don't worry about it.

The other thing we talk about in half a chapter on, or a chapter on, is testing both with qUnit which is from the guys that did jQuery and then with Selenium. Selenium is a great tool. I have a huge suite of tests using Selenium at work that I...

I actually wrote the chapter and the test at the same time, so I was literally going home from work writing documentation on how to use Selenium, going to work the next day and printing it out and making sure it made sense as I was trying to write tests.  It was a kind of fun, entertaining experience, you know, I'm writing the documentation I'm using at work in real time.

Michael Kimsal: I'm curious if you're talking about testing... Certainly Selenium's been around for many, many years, I'm wondering if you have tested out or used Zombie and Vows together.

Zombie the fast, headless full stack testing system, and then Vows is a behavior driven for Node.js. We saw a presentation on that at a recent user group and I was impressed, almost impressed enough to actually set something up to run it, but I don't have enough time to get all those tools set up because I'm too busy testing stuff by hand.  Now I sound like everybody else who's ever given me an excuse for not testing.

Zachary Kessin: No, I'm actually not familiar with those, if you could send me a link I'd be willing to check them out.

Michael Kimsal: Sure.  The interesting thing is that Vows and Zombie kind of work hand-in-hand because they're running in Node.js, which itself is JavaScript, you have a lot of the power of JavaScript but it's running out like Selenium might and grabbing a page but it can run all of the JavaScript in a page because it's running in JavaScript, it is JavaScript.

So for those that aren't doing server side JavaScript yet that might be one more reason to take a look at specifically Node just because those are some pretty good tools already put together.

Manuel Lemos: What is the name of it?

Michael Kimsal: One is called Vows, vowsjs.org, that is a behavior driven development tool for Node, and Zombie, zombie.js, that's at zombie.labnodes.org.

Manuel Lemos: So you said before you expect this to go to print in September, right?

Zachary Kessin: It should be August, September time frame, yeah, that's what they're telling me.

Manuel Lemos: So for those that would be interested to purchase the book they can preorder the print version, and if I got it right from the page here, we'll also put the link to the book page on the O'Reilly site in the show notes, but they can already get the digital version?

Zachary Kessin: Yeah, they can get the early release e-Book now.

Manuel Lemos: Does that mean if they get it now they will get an update when it's released?

Zachary Kessin: Yeah, you get an update and that's in ePub, Moby and PDF format, and I believe there is no digital right management on that.  You can also if you have a Safari Books online subscription you can find it there.

Manuel Lemos: Interesting.  I already got some books from the Safari site and O'Reilly has been kind enough to send us review copies for any books.

And let me also remind anybody that would like to review any books from O'Reilly and eventually other publishers, we may even eventually get free review copies, so they can write the reviews, and we have a section in the JS Classes site to publish those reviews.

So, Zach, it was great to know about your book, and I wish you the best of luck with it.  I already published a book many years ago and I know it's hard to succeed somehow, whatever success means to you.

I certainly did not get rich with it, maybe it's not your primary goal for a first book, but I don't know if you have previous books.

Zachary Kessin: No, this is my first, although I am planning a second already.

Manuel Lemos: That's good to know because writing books takes people with dedication, and I hope to hear from you about any future books on JavaScript. We certainly have space in JSClasses site to talk about it and also eventually in a future podcast.

Zachary Kessin: Thanks.  Actually the next book probably won't be on JavaScript but will be definitely on web topics.

Sources of news to keep you up to date with the JavaScript world (30:55)

Manuel Lemos: Okay, moving on with our podcast, now I would like to mention a few subjects of interest of those that are following the latest news in the JavaScript world, I've been meaning to mention this in previous episodes but I ended up not being able to fit it in the schedule, but I will do it now.

One thing that I would like to mention is the sources of where you can get the latest news about JavaScript. So I gathered here an interesting collection of news sources of JavaScript.

First I would like to mention that the JSClasses site blog on which the Lately in JavaScript Podcast is included is aggregated by the Planet JavaScript site which is one of those planet like aggregator sites.

The Planet JavaScript is managed by Michael Girouard, I'm not sure if I'm pronouncing his name correctly, but I'll make sure that on the show notes I'll post a link to the Planet JavaScript and also mention his name correctly.  I think he just aggregates the planet and that's it.  He aggregates several sources, some of the most obvious like the jQuery blog and YUI blog and other blogs.

Michael Kimsal: I think he needs to get a JsMag blog on there too, and I say that because Mike Girouard was a speaker at last year's IndieConf which I'm going slightly off topic, but I knew him in one context, I did not know him in the context of Planet JavaScript, hello Mike!

Manuel Lemos: Yeah, well I think probably it also makes sense for you to contact him and also have an aggregated source of news about JavaScript that you have in your JsMag site which is your JsMag news roundup that David Calhoun, right, is managing it?

Michael Kimsal: Yep.

Is JavaScript going to replace PHP? (33:31)

Zachary Kessin: I have a piece of JavaScript news here that I just saw that came over Twitter today, so it says, Yahoo looking at the possibility of dropping PHP in favor of JavaScript on the server, from Doug Crockford.

Michael Kimsal: Doug Crockford is gleefully rubbing his hands together to try to get rid of PHP, that's how I'm reading it, would you agree?

Zachary Kessin: Oh, I certainly would.  I mean personally if you told me I didn't have to do PHP anymore I'd be pretty happy.  It's a decent language, you can get stuff done in it, but I would not describe PHP as elegant in any way, shape or form.

Manuel Lemos: Everybody agrees I think.

Michael Kimsal: It's functional though, or it's not functional it's pragmatic.

Zachary Kessin: Pragmatic.  The language I got to say, the two languages that I've started looking at recently that have really rocked my world are CoffeeScript is starting to get real interesting, and the language I'm really getting excited about is Erlang.

Michael Kimsal: Hey, 1983 called, they want their hot new technology back.

Zachary Kessin: You know something, it does concurrency right.  It does concurrency as well as anything which isn't saying very much because concurrency's hard, but it's got some pretty cool features in it.

Haskell's also is something that I've been trying to learn although it kind of breaks my brain.  Haskell's type system, I like it but I can tell it's really cool but it breaks my head, I think I need to spend more time on it.

Michael Kimsal: Maybe.  I've gone down the route of, and I've seen other people do this too where they think something is really awesome because other people talk about it and it's got a history and they say, well, if other people like it, it must be awesome, and I'm just not worthy, I'm just not talented enough.

Sometimes that's the case and sometimes it's just, no, those people just have really weird ideas about what's good and maybe they live in academia, maybe they live in a world where they don't actually have to ship stuff, I'm not saying PHP is totally awesome in all respects, but it still holds on partially because it's there, a degree of pragmatism wins out.

And not just PHP, Ruby as well has its place and Python and the standard languages that everybody knows have a benefit in that traditionally if you get hit by a bus tomorrow, not trying to be morbid here, but that notion of could somebody else kind of take over the project, sometimes you want someone else to be able to take over the project, like you don't want to work there anymore.

Zachary Kessin: This is definitely a concern that some of the more obscure languages and some of them are really nice, I mean I think a friend of mine who is probably one of the smartest programmers I know has been ranting about Scala for the last year. I looked at it enough to think, yep, that looks like it's got some pretty cool features in it and played with it for an afternoon once.

The problem with any of these languages is in order to get good at a programming language, and I don't care what language it is, you need to write in my opinion about 2,000 lines of code, and that just takes time.

I mean you've got to just find the time to sit there and write out code and have it not work and fix it and realize you did it in a way that makes... that it's just, yay, it works, that's really stupid and rewrite it, and that just takes time.

Michael Kimsal: I'd say you have to go even further with a framework of some sort, and I will throw out my pitch for Groovy and Grails, which I still occasionally have issues with people saying well I couldn't use that, it's too obscure, it compiles down to JVM, it's pretty standard, it's a JSR standard, it's pretty standard.

That said, I've been working with it for about three years now and it's probably only been in the last year, six months maybe, that I've felt competent with it, I felt comfortable and competent with it, but that's the language and the framework.

You could say I know Scala, but then do you understand Lift, Lift is evolving so you're kind of dealing with am I learning it right, oh they're changing the API's, that's not picking on Lift, it's the nature of tech in general.

Two thousand lines for me, I'd need more than 2,000 lines for me, minimally I would need a year of doing multiple projects to feel comfortable deploying something to production.

Zachary Kessin: I mean the truth of the matter is I had reason the other day to look at code in the project I work in that was written about three years ago back when it was a fairly new project, in JavaScript, and I was cringing, oh my God I wrote that, it was really bad, you know compared to what I write now.

Michael Kimsal: Yeah, I've got stuff like that I've done a year ago that ashamed is too strong a word but certainly not happy with it, because I've discovered, myself, I've discovered a lot more practical ways of doing testing, of doing separation of concerns front and backend, I'm more comfortable with that.

But probably you've faced this, Manuel, you've faced this, do you have time to go back and re-factor stuff, and you have to figure the opportunity cost, is it really worth it to go back and re-factor those six modules only for my convenience and for my peace of mind, is it going to bring anymore money, am I going to get paid for it, all those things we wrestle with.

Zachary Kessin: And the truth of the matter in this case the answer was, no, it really isn't, I mean it's code that works, it may not look pretty but it gets the job done, whatever, whatever job it was, you know, and yeah it looks ugly and I'm going to cringe a little, but I mean that's just life.

I mean I'm sure if I switched tomorrow from JavaScript to doing... or CoffeeScript is probably the best example because it's fairly similar to JavaScript.

Michael Kimsal: If you start doing Scala tomorrow, that's probably a good example, if you did Scala.

Zachary Kessin: Right.  I'm sure I could get to the point in a week where I was getting things done, that doesn't mean getting them done well, but it would compile, it would run, it would do whatever it was supposed to do.

Now six months later I'd come back and look at that code and go oh my God, but it's just if six months later you looked at it, come back and look at the code, and you don't go oh God, something is wrong, it means you haven't learned anything in that six months, and that's a bigger problem.

Michael Kimsal: I'm that way with JavaScript.  I didn't mean to hijack this whole thing about the mettiness of programming, but I'm very similar with a lot of the JavaScript I do, because I do everything I don't do JavaScript full time.

I spend a few weeks on some front end piece and I'm either using YUI which is what I use a lot, or I might try something new, I end up learning something new either by a framework or a new technique or something, so I feel like I've progressed but I don't keep the momentum going, and then I'm back doing database stuff or I'm back doing whatever.

So I understand JavaScript and I know it and I can appreciate a lot of the stuff, I just don't feel like I'm a master at it and I may never be and I have to just learn to content myself with that, but I have masters around me that I can go ask.

Manuel Lemos: Right.  We went a bit away from the original schedule talking about those topics related with languages, but back to the track, I was mentioning the eventual sources of news that the listeners may want to follow.

And besides the Planet JavaScript which aggregates quite a bunch of interesting news sources, as well the JsMag News roundup that David Calhoun puts up in JsMag site that Michael manages, there is also one interesting news letter that I found out recently named JavaScript Weekly.

I was not aware about it, just found it recently, and it publishes quite an interesting bunch of news summary about the latest happenings related with JavaScript. It is put together by Peter Cooper and from what I could gather it is only available if you subscribe to the newsletter, so you will get it via email, there is no web version from what I understood.

And if you are onto these JavaScript related topics that you want very much to follow you may want to also subscribe to this newsletter.  I did not see any commercial motivation for it, it seems to be an effort that Peter puts up weekly to get a summary of news, and it's all that the newsletter has, there is no advertising on it and anything else.

Is Firefox better than Chrome for Web developers? (42:52)

And now moving on to other topics that I was hoping to talk about in this podcast, there is one interesting article that actually I put it together just a few days ago, regarding this eventual browser war that still goes on, but from the point of view of the web developers.

It is an article that I published actually in the PHPClasses site, despite it is not specific to PHP. It talks about browsers. And what I did is actually get some figures of browser adoption of the users of the site.

The site is quite big, recently it reached one million registered users, and there are about I would say probably 40,000 that come to the site at least once a month, and using the statistics of the users that get to the site, at least in the last 30 days.

There is a statistics page that shows the actual share that each browser has.  And basically what it revealed is that there is this trend of growth among PHP developers in this case, but I think we can extend it to developers of other languages for web programming, is that there is this trend of growing of Chrome which practically doubled, it's almost doubled its share since last year, despite Firefox continues to be the dominant browser for web developers with still almost 60% of the share, while Chrome is getting near to 30%.

And practically the rest is Internet Explorer that got below 10%, now is about 9%, and that is an interesting thing to produce some reflections about what these numbers mean.  And for me this article I wrote to vent some frustrations about the Chrome browser because nowadays it's the browser that I use to access the Web in general, not specifically to develop web applications, web sites, but to access any other sites.

But when it turns out to do some web development in specific there are some frustrations that I enumerate in the site, deficiencies, limitations. I thought that some of the things that I sort of complained about were maybe things that I missed, probably there is one extension that implements some aspect that I missed and that Firefox browser provides a good solution.

But after seeing the comments that people have posted there, and this time I got quite a great bunch of comments, over 40 comments, which is not usual for blog posts in the PHPClasses site blog, some people supporting what I was saying regarding the frustrations with Chrome for web development, and other people just supporting Chrome saying that I was not getting the point.

And there is still a minority of people that were not supporting neither Firefox nor Chrome but rather Opera because they probably are longtime fans of that browser.  I don't know if you guys have read that article, what do you think about it?

Zachary Kessin: I liked it.  I got to say you missed my two favorite points in favor of development in Firefox.  I think Firebug is a somewhat better debugger in most respects than Chrome's Dev Tools, but Chrome's Dev Tools are also really good but I just am more used to Firefox, but the tool that I have not found an equivalent for in Chrome.

I use the Selenium IDE not as a test tool but as a macro recorder, so when I'm doing development I'll often be working on something or to get to what I'm working on you have to click five or six different places on the screen.

So to speed that up I'll have the IDE open in a corner with a little script in it that does those click here, type a number there, click this button, you get the picture, and that way when I actually want to reload the page and test it again whatever I've changed, I develop in Linux, I switch to an X term, hit a little shell strip I have that syncs all my code over to the server and then automatically clicks the appropriate button on the Selenium IDE so I then just run the tool and it gets me over to the place I'm working.

So if you're for example working on say a wizard where you have three or four screens, which certainly not a crazy thing to be working in, it clicks you through the first three screens till number four if that's what you happen to be trying to fix the problem in.  I find that saves me oodles of time and work.

Manuel Lemos: Right.  It's an interesting point, I did not think about it.  I knew about Selenium but I never imagined that it probably could be a good thing for recording macros and have it used for repetitive tasks I think, but Michael you were saying something about this article?

Michael Kimsal: Well, I was starting to.  I thought I'd written a comment and I don't see my comment there now, oh, you'd mentioned something about Flash crashing and I'm wondering to some extend if that's... you're more of a Linux guy. I've had Flash crash browsers but it does it on Chrome and Firefox, Safari, it's equal opportunity, I don't know if maybe it's worse in some distros on Linux, others.

Manuel Lemos: Well, the matter is that it doesn't crash in Firefox, it's just a Chrome specific problem, and it's in recent versions, it did not do it in the past versions. I think it's probably something due to the built-in inclusion of Flash support in Chrome's solution. You just don't download Flash or use separate distribution, I think that's probably something Chrome's people are aware of, and maybe it's specific with Chrome on Linux.

It doesn't matter because what matters is it crashes, and when you go to places that you use Flash, not that I like Flash, but somebody that developed those sites decided to use Flash, in this case it was actually Google because I mentioned in Google Analytics and Webmaster Tools. They use Flash and it precisely crashes on the exact pages that I want to see and it becomes really frustrating.

It's not something that was so important because I do not use those applications all the time but when I do it, it crashes.  And just to mention that Firefox does not crash, at least in those situations. I don't know what Chrome did differently but it was just to add yet another frustration with Chrome that I do not have with Firefox.

Michael Kimsal: Well, good for you, because I have crashes in everything, it's equal opportunity for me.

Manuel Lemos: OK.  Well, anyway, this was an interesting article from the point of view that it raised a lot of interest from the community to express their opinions, and since it was mentioned, it was posted in the PHPClasses site, JavaScript developers that are not so much onto the PHP world may be not aware.

It's a way to let them know through this podcast to go and read the article. You may find interesting information, also some solidarity about your frustrations with Chrome.

Latest JavaScript objects released in the JSClasses site (53:00)

Manuel Lemos: But moving on with our podcast now towards the end, we'll get back to the usual sections, first the latest objects published.

Michael Kimsal: Yeah, I'll jump in here first off because recently, one of the more recent contributions looks to be something called GMap 3 which is a plugin for creating and using Google Maps.

And I have to say I've done Google Maps I'm betting a couple of times just using raw sample code and tweaking it a bit, and the GMap 3 object, really set of code here, looks to be a little bit more friendly.

There are some things that it provides, the documentation you can download it from JSClasses.org, but there's also a link to a full page with downloading and documentation and all that as well there, and it's one of the better documented pieces of code I've seen in a while in terms of JavaScript stuff, at least from independent persons, the large teams, jQueries and the toolkits have a lot of documentation, but this in and of itself is pretty nice.

One of the things I really liked about it was the clustering ability to say here's a bunch of points and it will automatically scale the map to include all of them, so if you have everything in one city or one town the map will only be that big, if you have everything going across an entire state or country it will keep the scale of the map accordingly.

And, again, Google does that for you, you can tell it how to do it but the GMap 3 system just makes it easier I found, and that was from Jean-Baptiste Demonte, I hope I said that without hurting Franco-American relations. He's from France, I'm assuming he's a he, Jean-Baptiste sounds like a male name, so merci, Jean-Baptiste.

Manuel Lemos: Right.  It's an interesting object actually, in this case it is a jQuery plugin, and right, just like you mentioned the clustering feature is something that Google Maps leaves out to developers to implement.

They can add an overlay to a Google map object and do whatever they want to, to somehow display markers in a more convenient fashion. In this case the clustering solves the problem of performance when you have too many markers on the map it somehow reduces the time to display them because if many markers are on top of each other they just show a single marker and a number letting the user know how many markers it is aggregating in that space.

Personally I've been using some other JavaScript code to implement clustering because Google does not provide a default clustering solution, you have to implement yourself, and this turns out to be quite useful.

But moving on, Zachary, would you like to mention any objects that you like to highlight?

Zachary Kessin: The Auto-Complete looks kind of neat by Roy Yu, I haven't had a chance to actually play with it yet, but having an easy interface and auto-complete in an input form is one of those things that's just sort of generically useful if it's done well, and like I say I haven't actually played with this yet, but it looks like it could be quite good.  So that would be my choice out of the new entries.

Manuel Lemos: Right.  It's also a jQuery plugin.  I also would like to highlight another auto-complete, well it's not just auto-complete, also jQuery plugin that lets you not only auto-complete selections on forms with select input, but also perform selection of multiple entries.

And it does it in a way that I think it's more user friendly as it displays some entries that get added to the list of selections from possible options that may exist. And it also has the possibility to narrow down the search for options that you want to select when there are too many options and by just reducing the list of options to those that match the initial set of characters that you type in a text input.

And once you've added an option it shows the option that you added below, and if you want to remove it there is a sort of remove button that you can click, and I think it's more user friendly than those... the usual way that select inputs work. If you want to deselect just one option usually you have to hit the control key and point to the option that you have selected, and I think for many users that is not so obvious.

And this solution in this case was provided by Emran Amhed, I hope I'm pronouncing his name right, he's from Bangladesh, it's quite a user friendly solution.  But I think we covered quite a few interesting objects so far.

Upcoming JavaScript articles in JSMag magazine (59:33)

Manuel Lemos: Unfortunately you do not have time to comment more about the others that have been published recently because we have to move on to the next regular section of our podcast on which Michael covers the latest articles in the upcoming issue of the JSMag magazine.

Michael Kimsal: Upcoming JSMag, I will throw this out before I even get to this is constantly always looking for new and good and interesting content, and summertime even sometimes seems to be a little bit more challenging because the Northern hemisphere people with their summer vacations and all that.

We had seven things lined up and I had a bunch of people that through personal circumstance and other obligations have dropped out, so there are a few that I can't mention this month, I'll mention for next month.

But we should have second part in a series from Vincent Goff about writing native Android and IOS phones using JavaScript. We have a piece from Christopher Bergdorf, he's a new author with us, and he's talking about the reactive extensions from Microsoft. And we have Dino Gambone who actually founded JSMag and became an author through this podcast, so thank you very much Manuel, continuing a game development series with Node.js. And there was one other piece which I don't have listed here right now, and then we will have a news highlight from David Calhoun, kind of an overarching wrap-up of what's going on.

So that's what's going on there, we have a couple more things slated hopefully for next month, possibly more with Ringo.js and server side development and possibly some work with RequireJS as well too, and maybe, maybe even a nice little piece from Zach Kessin, maybe something that didn't quite make the book, didn't quite fit but he feels a need to contribute because that would be really awesome.

But as I mentioned before, I mention again, we pay for content, you keep the copyrights, we ask for typically 90 days to be the first publisher of something, but you get to work with one of our editors so you get some professional feedback as to how to make something better, how to get your point across, if English is not your first language don't worry about it, that's a pretty common thing we deal with.

So go to JSMag.com and take a look and if you're interested signup, we'll get you started.

Manuel Lemos: I think from what Zach was telling me I think you have something about CoffeeScript that you may want to contribute.

Zachary Kessin: So for those who don't know, CoffeeScript is a new language that compiles down to JavaScript, it really is almost JavaScript with better syntax and cleaning up some of the really ugly parts of the language, I can't say I know it, I've played with it for about an hour in between other things, but...

Michael Kimsal: This might be a good excuse to dig into it and to write something as either your learning experience about it, things to avoid, things to look out for, things to focus on when you're using it, I'd love a good introduction to CoffeeScript.

Zachary Kessin: Yeah, so would I.  There are a couple books coming out from it, another prags, The Pragmatic Programmer Series is working on one, it's in pre-release now, and I expect there will be others.

Michael Kimsal: There is a cross-platform library called Forplay, you can find it on Google Code, and this is something that will let you take Java and it will compile it into either a desktop Java app or JavaScript and HTML 5 or Android or Flash.

Zachary Kessin: There's another product called Particle Code that's from a company that used to be the parent company of the company I worked for before we got sold, but Particle, I'm not really familiar with the details, but basically it lets applications, HTML 5 and native for a bunch of different phones.

A little background, the company I work for Mytopia, and that company used to be the same company and then basically we had one division that was doing social games, Mytopia, which is who I work for, and another company doing this platform technology, and the social games half got sold about a year ago to 88 Holdings which is an online gaming operation that bought us, so that's what we're part of now, but there's still some relationship there. 

Michael Kimsal: I did not know about Particle Code, that looks pretty cool, I'm going to take a look.

Zachary Kessin: Yeah, it looks cool, I can't honestly say I've used it at all, but yeah, it's got some cool ideas in it.  I know some of the guys who do it.  There's some really cool stuff happening in the world of JavaScript and just the world of programming in general these days, it's a lot of fun.

Manuel Lemos: Right.  We always try to cover as much as possible about the latest that has been introduced in the JavaScript world, unfortunately just recording once a month it seems to not be able to keep up with everything, but we try to mention things that we think are more relevant.

Maybe you can get back in a future show and talk a bit more about CoffeeScript and those other frameworks that you mentioned, but we'll see about it.

Conclusion (1:06:04)

So basically we have covered a lot of interesting subjects but our time has practically ended.  I would just like to think Zachary for coming to this show and giving his input and also interesting information about his book;

I wish you the best of luck with the book, I hope you can publish more books on JavaScript or other related interesting topics, but I think for now it was good to have you here.

Zachary Kessin: It was good to be here, you can find me on Twitter by the way @zkessin.

Manuel Lemos: Yes, that's good to know.  Well, unless you have anything else to add I think that's all for now.

Michael Kimsal: I'm going to do a quick promotion for IndieConf because it's almost that time, we are tentatively planning for November 19th, again in Raleigh, North Carolina as it was last year, but I'm mentioning this right now because we have an open call for presenters, call for speakers, and the focus is web freelancing but we have a number of different focuses.

So we certainly have some legal people, we have some marketing, but we have some tech people as well, so if there are some good presentations, we had a good CSS 3 presenter last year

If there's anybody listening that feels that doing something either directly or indirectly about JavaScript as it pertains directly or indirectly to working as independent web person, as an independent web professional, please go to indieconf.com and submit your paper.  We have the call for presenters open until the end of June at this point, so about four or five weeks from now.

Manuel Lemos: Okay, that's always good to know, and for those that can attend I hope they can make it. It's always interesting to know about conferences that cover not just technology aspects but also other aspects that developers need to handle, to manage their professional lives as businesses, and your IndieConf event seems to aim in that direction.

Michael Kimsal: That's what we're trying to do.  So, Zach, if you happen to be in the States in Mid-November and get to Raleigh there's a ticket and a lu