Shall we always use semi-colons in JavaScript? - Lately in JavaScript podcast episode 18 - JS Classes blog

By Manuel Lemos
manuellemos.net
<email contact>

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Introduction (00:20)

Google Hangouts API (2:57)

Natural Language Processing in Node.js (5:04)

Porting C/C++ code to JavaScript with Emscripten (9:56)

SQL.js - SQLite port to JavaScript (13:31)

The Nightmare of dealing with JSON encoded Dates (19:29)

The controversy of the use of semi-colons in JavaScript (30:02)

Latest JavaScript Objects published in the JS Classes site (40:08)

Upcoming Articles on the JSMag Magazine (47:11)

Conclusion (49:44)

Introduction (00:20)

Manuel Lemos: Welcome to the Lately in JavaScript podcast. This is an experimental new thing. As you may see, I have here with me Michael Kimsal now live, and for his female fans, they can now faint.

Michael Kimsal: Yeah. I get that a lot.

Manuel Lemos: Yeah, I can imagine.

Michael Kimsal: Oh, yeah.

Manuel Lemos: This is Episode 18, and as I was saying, this is something experimental. We are starting to use this Google Hangouts thing. 

Actually, this is a bit different than the regular Google Hangouts because it allows the recording to be transmitted live and also be recorded on the server side, so I do not have to take care of the actual recording. Just prey that it will work and later the video will be available for minor editing and be published later in the JS Classes site podcast.

Moving on to the actual podcast, I did not say the usual "Hello, Michael! How are you doing?" 

Michael Kimsal: Hello! I am too legit to quit.

Manuel Lemos: Oh. That was cool.

Michael Kimsal: People of a certain age will fervently deny that they have any idea what that's referencing, but I know that they know.

Manuel Lemos: It looks cool. That's what matters.

Michael Kimsal: Oh, yeah! What can I say?

Manuel Lemos: Nothing. You already said it.

Michael Kimsal: I did.

Manuel Lemos: Anyway, let's move on. I have here two computers, one to see the timeline and the other to do the actual recording. As I can see in the timeline, we're going to start talking a bit about this Google Hangouts thing. Not only can we record the video and people can watch it live, eventually whoever is interested can participate.

Actually, I sent some invitations, but then I realized that Google is not sending the invitations out to anybody, so I don't know if they see the invitations by email or in their notifications.

Michael Kimsal: I'm going to try to send out something right now, just trying out the...

Manuel Lemos: Yeah. Your millions of fans will pop up in a moment.  

Also, this is probably not a very good hour of the day for at least part of the world as they're probably already asleep, but OK, this is still very, very beta, but we are going to move on and talk with the regular interesting JavaScript-related topics.

Google Hangouts API (2:57)

Manuel Lemos: And the one that I wanted to talk about first is about precisely the Google Hangouts facility that is well-integrated in Google+. Well Google does not like to call it a social network, but I think that's what it is.

Anyway, they also provide an API that you can use some HTML and JavaScript to integrate in your site. I've never tried it. Michael, did you look into this or even tried it to do something?

Michael Kimsal: I've not tried it yet. The whole thing is kind of neat; it just feels a bit rough, and frankly I've got too much on my plate to mess around with beta APIs. I'm assuming they're beta because there's 'Google' in the name. So it's neat, and I'm going to let somebody else be the early adopter for the most part.

That said, I'm on a public hangout right now, which is, we're not the first people to do this certainly, but it's still a little early, a little rougher on the edges. I do talk about hands a lot sometimes, so you'll notice.

Manuel Lemos: We did a test yesterday and somehow it worked, but there are several things that I wanted to do that I was not able to. 

Anyway, I just wanted to bring up the fact that they provide an API, because an API allows you to probably do things more sophisticated and well-integrated in your sites. I did not look into it with great detail, but that's what it looks like it can be used to do. 

I think there are two options, one to integrate it as a Google gadget, which is probably simpler for most people because it's just a bunch of HTML, and also some control to do it with JavaScript.

Anyway, we will publish the link to the actual hangout's API page, so whoever is interested, you may want to take a look. I think those are the most important things about this API that I can think about and say now.

Michael Kimsal: Sure.

Natural Language Processing in Node.js (5:04)

Manuel Lemos: Moving on with our podcast, the next topic that we'll be talking about is this Node Natural, which is basically a framework for natural language processing. At first, it looked sophisticated, or at least it actually could be some sophisticated thing. 

Michael Kimsal: Let's do a timeout here, because when you say 'natural language processing' my initial thought, though I'm familiar with the term, but my initial thought went to actual sound processing. Like, my dog has fleas and it would parse out, 'My dog has fleas!' and sing it. No. This is a text-processing library, correct?  This hasn't anything to do with sound specifically.

Manuel Lemos: Yeah. We stopped because we have our first guest.

Michael Kimsal: No, goodness. 

Manuel Lemos: Hello?

Michael Kimsal: I just see a black square there right now.

Manuel Lemos: Oh! It seems to be somebody from a well-known family with probably... Is your microphone on mute?

Mark Kimsal: It was. Is it on now?

Michael Kimsal:  Oh, my goodness. That's my brother. Oh, my gosh! Thanks for interrupting, in the dark.

Manuel Lemos: You would not recognize him, Mike.

Michael Kimsal: Yeah. He looks better with the lights off most of the time.

Manuel Lemos: Yeah.

[For whoever is going to do this transcription, just note that we stopped talking because a guest entered into the chat room. I'm not sure if they followed the audio or the video when they did this transcription.]

But I think it worked, Michael. You sent out some invitations to some guests and they are arriving.

Michael Kimsal: Yes, yes. I have that effect. Notice it's all men coming in, there's no women. Whoever has their, Mark, that maybe if you have audio going live, please maybe turn that down or use headphones or something.

So moving back to the natural node language. Wow, that's bad.

[Interruption]

Manuel Lemos: It is showing me a link to deactivate the audio.

Michael Kimsal: I just muted a couple of people. Or I just muted some. Oh, and Jose I think left. Jose, if you're watching later, sorry, you just had a lot of background noise.

Natural node.

Manuel Lemos: OK, back to the topic.

Michael Kimsal: I was mentioning before, it doesn't deal with sound. It's just for natural language text processing. 

And I'm assuming it's primarily English. Most of the libraries that I've seen have to do with... Yeah, it even says here most of these algorithms are English-specific right now.

Manuel Lemos: Yeah. It looked to me it just does the very basic things. It did not seem to do any actual grammar recognition or something like that, just splitting text in words, probably find similar-sounding words and that was it.

But anyway, probably this is just one of the first releases and it will probably evolve into something more sophisticated. Or I hope, because that's what it originally suggested to me to be something, not exactly to recognize words in audio but at least process some written text and maybe reckon some phrase structure or something like that.

Michael Kimsal: Sure. But it does look like there are... I'm trying to see the time element on this, the network graph. It surely didn't show that right away, but there's 46 forks of this and there's 700-something people watching. It looks like this has been going on for at least a year, so definitely a moderately active project. It's had spurts of activity.

Manuel Lemos: But does fork mean actually the people changing the code or they're just checking it out and thought about changing it but they did not necessarily do it?

Michael Kimsal: Well, the hard fork is somebody did an actual hard fork instead of just checking it out. I can check it out without doing a fork. So 46 other people made forks of it, and I'm assuming they did that because they were going to make some changes at some point.

And a lot people do forks. I occasionally fork things and maybe just push one thing back or I don't push anything back. But something that has generated 46 forks on GitHub, to me, it's a moderately large project.

Manuel Lemos: Well, we'll see. If we get more news about any interesting progress about this library, I'm sure we will get back to it.

Michael Kimsal: And I'm watching it, so I should get something in my stream if anything happens.

Manuel Lemos: Yeah.

Porting C/C++ code to JavaScript with Emscripten (9:56)

Manuel Lemos: Moving on with the podcast, the next topic I wanted to comment about is about a new, well, probably it's not new, but it was new to me, which is a way to port code in C and C++ to JavaScript using the Emscripten in language. 

It was actually interesting because I saw an article, I'll post the link in the show notes, that demonstrates it also does some XML parsing that would probably be a processor-heavy operation to do, and they took some C code and converted it to JavaScript.  

Michael, did you check this?  

Michael Kimsal: I read about it, but I'm not a C or C++ person, so the practical implications of it for me aren't all that much.

Manuel Lemos: But probably it would be more useful to people that do not want to deal or even learn C. They can take advantage of the existing C libraries and convert them to...

Michael Kimsal: Yes. It feels academic to me. Again, there may be a lot of potentially great use cases for this, but, I guess, two things strike me. One is that somebody doing doing JavaScript would have to know that a particular C library exists and matches their needs, and secondly, they would have to be aware of this project, and thirdly, the porting would have to be accurate enough that it wouldn't introduce any bugs and that somebody could just take it and convert and drop it in.

And this is less about this particular project and more about just the idea of code reuse so often in 20-something, 30-something years, code reuse, code reuse, code reuse, and people still write something from scratch because, even though there are libraries out there, people still write things from scratch because they don't understand the other stuff or they don't have time to learn it.

Most of the excuses are not valid, but they still do that. So I guess I'm still thinking about what the practical implications of this are.

Now it could be that somebody takes a lot of common C libraries and shepherds the porting of them to JavaScript and ensures that they work properly and does the modifications necessary and maintains them. If there was a person or a group of people that did that and curated them, that would be a great benefit. But that takes a lot of extra work.

Manuel Lemos: Well, maybe not the way I feel this works is that they compile the C and C++ code into LLVM byte code, then they use the Emscripten and other LLVM tools to generate JavaScripts on them from the LLVM assembly, and that's the way it works.

It has shown to be something that works in practice. In the case of the article that I've seen, I'll post the link later, they ported the tool called the xmllint, which is basically to analyze some XML code to figure any syntax problems.

SQL.js - SQLite port to JavaScript (13:31)

Manuel Lemos: This also ties into the next topic that I want to comment about which is the SQL.js, which is basically an implementation of the SQLite library totally in JavaScript. It was ported from C to JavaScript exactly the same way using Enscripten to convert it to LLVM assembly of byte code, or whatever it is called, and then back to JavaScript.

I don't know she still needed some touches to be done manually to finalize the result to make it useful, because if the original code is in C and C is not object-oriented, is not object-based at all, they did end with a JavaScript library that actually works in object-based because of how JavaScript is object-based.

I'm not sure now how it did work. I confess I did not try it. But it seemed an interesting idea. 

Michael Kimsal: Yes, these are interesting, as are a lot of things, and I don't get to play with it as much as I'd like, but if this is the testing ground for the next generation of cool stuff, great, I'm really happy that we'll have people do those sorts of things and be those pioneers, because I'm not good enough to do it.

Manuel Lemos: Well, maybe...

Michael Kimsal: No, thank you. I'm not.

Manuel Lemos: ...you do not have the time or feel the need right now, but at least you can know that there is this process now and it's viable. 

It has been proven to be usable on certain cases, and you can see sometime later if you have a library that you would like very much to have in JavaScript but it is only available in some other language, because I think this is not specifically limited to C or C++, anything that can be compiled to LLVM code can be...

Michael Kimsal: You could translate it. If that's the intermediate step, then you can go one step further and convert it over.

And if you go back to that original article you pointed to, someone pointed out that, yes, this works, but loading all of this stuff into the browser, in his words, "brought Firebug to its knees," and it was apparently not a huge library.

So as with anything, native or something written specifically for your platform versus something converted, you'd have to waive that benefit of, can I convert this? 

That's great that you can do it. I can do this in proof of concept and I can deal with the heaviness or the bulkiness, whatever it may be, if there are cases where that is happening. If you're aware of the tradeoff and you intentionally make it, that's great. If you're not really aware of that tradeoff that's going on and you just do this blindly, you will end up with really slow, bloated stuff.

On top of that, it's stuff that you probably can't go in and easily fix or debug. It may be easier just to build what you need from scratch. And you're getting to be reinventing the wheel.

Manuel Lemos: It could be the beginning or a subsequential effort to optimize the result, maybe rewrite part of the code to make it more efficient when it runs in JavaScript.

Michael Kimsal: But we all know that the first version never gets rewritten, roughly speaking.

Manuel Lemos: Well, it depends. This is basically just one idea that other people may be interested to investigate. 

Michael Kimsal: Yeah.

Manuel Lemos: The project they presented, having a pure JavaScript implementation with the SQLite library, may or may not be interesting. At least you can rely on some code that you provide and you do not depend on the browser to implement any SQL-based interface or something that you want to implement.

Michael Kimsal: Yeah. I think, ultimately, it is a really interesting way of getting the functionality of some of those C libraries without having to compile them into browser extensions and try to distribute things that way, or to write native code and try to distribute it that way.

If you can deal with whatever resulting performance hit there may be and you're focusing more on the functionality, that technique is attractive, I think, to get things into JavaScript, because that becomes the ultimate delivery mechanism for application code is the browser. 

I'm got some old VB app that if I could convert most of that into JavaScript of those libraries, re-glue them together and put it out, I can port old logic code and redistribute it in a new form much, much faster than rebuilding it all from scratch, and it's just one thing that springs to mind.

So discounting some of the 'native versus code first versus rebuild' and all that, the idea of JavaScript being the language of the browser and the browser being the primary way that applications are distributed, app stores notwithstanding, this technique probably can open up a lot of interesting explorations in paths that, again, certainly I wouldn't have thought of. I don't think I would've ever thought specifically of, hey, this C code, I should just port it to JavaScript so that I can have it in the browser. It would not have occurred to me.

Manuel Lemos: Well, it's a tool whoever finds it interesting will figure it out, maybe some very much more interesting purpose than those that we mentioned of these projects, this xmllint and the other one which is SQLite port. We'll see.

The Nightmare of dealing with JSON encoded Dates (19:29)

Manuel Lemos: Now moving on with our podcast, we were talking about actually bringing back one subject.

Michael Kimsal: Oh, yeah.

Manuel Lemos: You, Michael, have shown some concern in the past, and it seems somebody found, well, I'm not sure if this is a solution or just a solidarity article saying, 'I feel your pain', which is dealing with the dates and the different ways different browsers format and then paste them to the server.

Michael Kimsal: Dates in JSON. This was what you're going to post, I guess, with the notes here is a blog post from Scott Hanselman of Hanselminutes in Microsoft. He posted some blog article. I'm not sure what the date was; I saw it probably two months ago when I was looking for date stuff. He'd basically outlined some of the same problems that I talked to you about several months ago, probably January, I think.

Interestingly enough, as kind of a recap of the problem that I had before, we had date values in Grails, and Grails has an option, when you're generating JSON it can convert those into JavaScript Date objects.

So in your JSON, you get a key that says, 'created time' and the value is an expression. The value is 'new Date', open parentheses, and then a Unix timestamp, which gets interpreted by the browser. As soon as the browser gets it and creates a native object from it, it says, 'I'm going to make a date with this timestamp there,' but it's looking at that timestamp and then converting it to the time zone. 

So we had something that was a value that was going up at midnight in one time zone, and then when someone else was looking at it, they would get the JSON and it would actually be 10 o'clock the day before. And when we would just say, 'Give us the date for this,' one date would be January 5th and one date would be January 4th.

We came up, and I say "we," I did a lot of this and some of the other guys in the team I was working on, just beat our heads against this, and partially we were learning the code base and we were learning where all the dead bodies were hidden, so to speak.

We, well, I say "we," a guy named John had, actually I'm trying to give some props here without, because I don't know if they want me to say their names or not, but Jason and John both had some ideas and John's was actually more broadly applicable. 

It's not perfect because we're still not dealing with time zones in our application, but what he did was very high in the stack chain. He actually overwrote part of the JSON serializer that was in our Java stack. I think basically he's overwriting some of either the Grails or the Java JSON writer.

So he takes and he creates a string, creates the actual date string, like 2012-04-07, and then a time, 15:00:00, makes that a string, and sends that down, basically rewriting the JSON expression to say 'new Date' and then give a string.

And all the browsers that we tested on, which are the ones that we say we support, all would interpret that with their own time zone. So if I gave you a string that said 'April 15th, 3pm,' it wouldn't matter what time zone your computer or your browser was in. It would say, 'This is not 3pm in my time zone,' and it would treat it appropriately, more or less.

Yes, it's a hack, but it was a very clever hack, I would say. I actually mean that positively. Sometimes I say "clever" and I'm trying to be rude, but probably it was the fastest way to get around that. 

Now, I don't remember Hanselman's post in terms of how he got around or what his patch was for dealing with his problem. Do you remember offhand? Maybe I should look this up.

Manuel Lemos: No, not really. He did not go into much detail about the solution. I thought it was simpler than that because if you use the date object, it takes a parameter, the UNIX epoch number, which is absolute, it's always relative to the UTC time zone, but I was not aware of these variants that append a time zone offset in front. So I don't even know if this makes sense in JavaScript, the syntax of this appending plus some hours or minus some hours.

Michael Kimsal: Another problem that we've faced, I just want to share this, maybe you said it before, but because I thought the answer is we'll just do everything with time zones and just put zero time zones throughout the whole system and modify our systems, and every time you choose a date in the date picker thing, you'll just have to choose your time zone.

If we were limited to the Web API, that might work, or Web interface I should say, but we also have a moderate amount of data and a growing amount of data that's coming in through rest API calls. To force clients that are paying money to post data in and say, 'You have to give us a time zone now,' it's impossible to do that because some of these people are using old systems they don't have the time zones themselves.

So it's a matter of we can't ever say that we're going to have 100% of these. We need to be able to deal with data that doesn't have time zone associated with it. It's an ugly problem, but it's one that we can't solve on our own because it's bigger than just our software. It's the software that we integrate with and we take data from. So it's a rather humbling experience. 

Technically, I know what the answer is. Practically, there is no good, clean answer. Even after all these years of doing this kind of stuff.

Manuel Lemos: Well, you had to deal with many cases. 

Somehow I had to deal with a similar situation recently, I'm still dealing with it, but it's in a completely different domain, which is the implementations of OAuth 2.0.

Currently I am adding support for users of the JS Classes site to authenticate using their Facebook account or Google account or GitHub account, whatever, and I started adding first OAuth 2.0 support.

But it seems that OAuth 2.0 is not a finished standard and there are differences in the implementation of the parameters that go back and forth and the way that you pass stage to take the information to the authentication servers.

I developed a single class that somehow abstracts that and internally defines some parameters that say, 'In this case, I would have to change it to pass the parameters this way,' and then the responses may come in the form URL-encoded or JSON.

But in that case, it's simple because you can interpret the content type of the response of the server. But even for JSON, some servers return 'Content-type: application/json' or 'text/javascript'.

Since I'm dealing with one OAuth server at a time and I do not intend to support all OAuth servers there are out there in the world, my problem is sort of limited, but I had to figure this and, OK, I see what you mean. I had to deal with it like a pirate, I suppose.

Michael Kimsal: Arr! Yes.

Manuel Lemos: It's somewhat small, but I think it's a smaller problem than you have with the dates. 

Anyway, for those that wanted to investigate how this was solved, there is this article by Scott Hanselman on Microsoft and you can check it out and study. I'm not sure if they provide the definite solution for all cases, but probably it's a solution that covers many cases.

Michael Kimsal: His solution, I think, does work in some cases. It wasn't going to work for our case because we really couldn't deal with time zones at all. But it's still a good read. There's a lot of good stuff in the comments, too.

Manuel Lemos: I think the worst case is you find an unexpected date format that you treat it as something else and then you insert incorrect data in your application on the server.

Michael Kimsal: Oh, yeah.

Manuel Lemos: In that case, maybe it's better to somehow throw an exception when finding some format you do not recognize instead of taking it as some apparently known format.

Michael Kimsal: That was me throwing an exception, by the way. Because when you said it, I was kind of acting out. You said, "throw an exception."

Manuel Lemos: OK.

Michael Kimsal: I don't know if you could see it very well.

Manuel Lemos: It will not appear in the transcription.

Michael Kimsal: It won't, yeah.

Manuel Lemos: Well, people will figure that they have to watch the video because it's more interesting.

Michael Kimsal: They've got to watch it. Earlier, that was my Sarah Palin impersonation, which would only make sense to people of a certain age, again.

Manuel Lemos: Or maybe people that are following American politics.

Michael Kimsal: Who isn't?

Manuel Lemos: Probably not in my case.

[Laughter]

Michael Kimsal: Oh, yeah. We won't transcribe... Don't transcribe that. Don't transcribe the 'L'.

Manuel Lemos: Oh, that's the go to, 'L'.

Michael Kimsal: Hey, hey. I say that sometimes when I get in an elevator. I'll tell the other person, I'll say 'the L', and they get a little offended until I point out I'm meaning the 'L' on the button. They don't really get it. They take umbrage.

Manuel Lemos: In reality, you mean they should go to a place they do not win.

Michael Kimsal: They should go to the lobby. I should just say, 'Go to the lobby,' but I say, "Go to L."

The controversy of the use of semi-colons in JavaScript (30:02)

Manuel Lemos: Yeah. But moving on with our podcast, one last subject of this regular review of the topics I think that are going on in the JavaScript world is the controversy about the semi-colons. 

Michael Kimsal: That damn semi-colon!

Manuel Lemos: Michael, do you want to describe what you have followed? Because I was following some comments on Twitter and everybody's complaining about having or not having semi-colons, so I needed to go back and figure where this came from. But I think you followed it more closely.

Michael Kimsal: Well, it all starts when a nucleoid gets together with a protozoid. 

Manuel Lemos: That's clever.

Michael Kimsal: Oh, the semi-colons. The semi-colons, there we go.

The little that I could grasp from this is that JavaScript, when it's parsing, will insert a semi-colon if you don't have one where one thinks one should be. 

On the link that you'll post, on Brendan Eich's page, there is one particular section or one particular type of expression or a compound expression that you could put together, which is legal syntax with or without the semi-colon, and it creates this confusion. If the parser reads it and puts the semi-colon in, then the expression reads one way. If you have it out, it reads another way. 

In and of itself, it's not that big a deal, except there are minifiers, people want to minify their JavaScript, and the minifiers behave differently than parse that out and minify differently than what someone who is running on the defined JavaScript code would expect it's new.

So in some ways it's kind of a 'much ado about nothing.' I would not write code the way that these structures in question could be interpreted.

It is not quite the same, but you could say, if I write this code and if you have a multiple compound expression that just relies on the order of operators to work a certain way, and then you took that algorithm and put it on the different system that had the order of operations, had your operators evaluate in a somewhat different order, it's not the same but it's similar.

To me, in that when I'm writing code, if there's any possibility of things potentially being confusing, I will just parenthesize them, or in this case, I will just say, 'Put the semi-colon in.'

I like Groovy as a language, there's no secret about that, and semi-colons are optional. I tend not to use semi-colons there. But there are some times where I will put in just to make sure that I am very explicit that this really is the end of the statement. But I don't use them all the time because I get lazy, but if there is a Groovy minifier and this was ever a potential problem, I would probably start doing it more often. Anyhow, that's the real issue.

Manuel Lemos: So basically, who exactly is complaining, those that do not want to use semi-colons or those that want to make them mandatory or something?

Michael Kimsal: Some of this came out because people reported this to JSMin, the very popular JavaScript minifier, and said this is a bug that needed to be fixed. Douglas Crockford, who I think is still a maintainer of that, said, "No, I'm not going to change it," and it's his choice to do that, that's his project, but it's just created this rift and I don't quite know why. 

I would just say, if your code might be minified, just write it in a way that it can be minified or not. And just add the semi-colon. That's just me, but I'm getting old.

Manuel Lemos: Personally, I always use semi-colons at the end of statements, although if you have a line break, I suppose you are not required.

I don't know other circumstances where a semi-colon is not necessary by whatever extenders define the JavaScript language. Other than line breaks, are there any cases that semi-colons are not necessary or optional?

Michael Kimsal: I don't know enough about the syntax to tell you for sure.

The link that you're pointing to actually has a pretty good writeup on it, and I think someplace that, somewhere, I don't know if it was here or someplace else that, it may have been Brendan himself, had said something along the lines of, 'This was a mistake to allow it to do this, to have a JavaScript parser try to insert these for you automatically.' But he also says that if it was up to him, he would just fix JSMin to work with this instead of try to tell everybody insert their parentheses. He would write JSMin.

Manuel Lemos: Is it something that he can fix or is it complicated and there are reasons to not do it? Other than arguing with people?

Michael Kimsal: You can argue that when you write code that can be parsed one of two ways, telling somebody, 'Fix this because my intention was for this code to operate this way,' is not a really good answer. You've written code that happens to parse one way, but when you read it, it could realistically be read one of two ways.

So how do you resolve that? Do you change to match the whims or the demands of a small portion of people that seem to be interested in writing code that isn't very obvious to read in the first place? Or do you say, 'Hey, this tool's been on here for a long time. This is how it works. I'm not changing to accommodate these arguably somewhat fringe/edge cases?'

Manuel Lemos: Yeah. I think this whole discussion has been overblown because you want things to work while you make them unreliable just because you do not want to use semi-colons. What does it get you to not use semi-colons? You are going to save terabytes of memory when you use the semi-colon.

Michael Kimsal: Honestly, the parsing question here, the minification issue, is not the same as what I'm going to say, but I have this argument with people sometimes about parentheses in PHP, or really to some degree other languages as well, but just put the parentheses in. Quit being clever to say, 'Oh, if some bizarre turnery,' and then on the next line just have something indented for one thing, stop it.

I don't want to maintain your crap when you do that. I always and having to go put parentheses in because I have to do something else in that as well. Whether I just need to put some logging-in so I can test your crap because it's not working because you've moved on, not that I harbor any resentment against anybody in particular, because I don't.

This isn't any one thing. This is just, I've seen this for going on 15 years, actually more than that, and it just boggles my mind that anybody would ever do that.

And I think in some cases it's almost a religious argument, the tab versus spaces, except that, and some of this, I think, comes from people, and the maybe younger people, and I'm getting old so this is maybe my perspective, but seriously, because there are people that have made a career out of just writing code and then moving on, they're writing a project, they're writing the first iteration, and then they move on and then they go someplace else and they write another first iteration of something, another Greenfield project in their new popular language or framework of choice, and they generally don't do maintenance work. 

And I'm not saying I do maintenance work because I love it. It's work that I get and I do it. But there is a perspective that you get on how to write maintainable code when you've dealt with disaster after disaster after disaster from other people's code that is not only not maintainable, really, it's not testable, it's not anything.

And the parentheses are in some ways kind of a minor thing, but when they're there, it's just one more thing I have to go do because I have to go put some logging-in in your condition block. 

Manuel Lemos: Yeah. It's not right, an ambiguous code.

Michael Kimsal: Yeah. It's a code block. Just put parentheses in. But that's my little rant.

Manuel Lemos: It surprised me that the topic was sort of overblown because for several days I saw people commenting on Twitter, and I think it did not end already. They're still talking about it.

For me, maybe because I develop most coding in PHP, semi-colons are not optional. You should put them in most places. So I got used to it. And it doesn't bother me. I'm not going to save the world, it will not make a difference in global warming to use more semi-colons here and there, but, OK, it's just so I have something else to comment on in the podcast.

Michael Kimsal: Just real quick here, I think the reason that you were seeing so much in Twitter and Hacker News and Reddit and some other places is because of the names that were involved. 

Manuel Lemos: Oh, I see.

Michael Kimsal: You have Brendan Eich and you have Douglas Crockford both making their case about something, which I find utterly trivial but it has an effect on how some people write, and neither side, neither camp seems to be backing down or seemed to be backing down. I'm not sure of the status of things now.

Manuel Lemos: So the final lesson is, use semi-colons and shut up.

Michael Kimsal: I would say so, but that's just me.

Manuel Lemos: Yeah. OK. 

Michael Kimsal: So on that bombshell...

Manuel Lemos: It just seemed something of stubborn people. Life is short, we need to move on. Also this podcast needs to move on.

Michael Kimsal: Carry on.

Latest JavaScript Objects published in the JS Classes site (40:08)

Manuel Lemos: We are basically at the end of this podcast and we're practically at the moment on which we will comment on the latest classes that were published in the JS Classes site.

Unfortunately, there aren't many classes to comment about, but this is also a good opportunity to remind the listeners and also developers that are contributing or somehow participating in the JS Classes site to keep sending their classes, their objects, JavaScript objects, so not only would we have more subjects to talk about but we can talk about their work and give additional exposure in this podcast.

If you have some components that you're probably reluctant to publish or to announce, or maybe you've published somewhere, in GitHub or some other code repository you are not getting much exposure, if you publish them in the JS Classes site, you will also get additional exposure that may be helpful to get more users, more people getting you feedback and eventually making bug reports or features suggestions and making your project even more useful also to yourself and not just to your users.

On that note, let's just comment on the two classes that were published recently. Basically, there is one, actually it was written by me because I was addressing the need of a friend, but it's also a need that I have once in a while, which is the ability to show progress bars in a way that they appear smoothly. 

The problem that it's trying to solve is the case that sometimes you need to show a progress bar and it updates its lengths in chunks. I think that does not look very nice, and sometimes the user does not notice because he blinked the eye when the bar updated.

Using this smooth progress bar object when the length of the bar is updated, it is not instantaneous. You will go through all the steps between the current position and the next position that it shows and gives a nicer effect, and I think it will be useful. 

People probably want to present progress of tasks that are going on on their sites in a way that it's smooth and more pleasant to see and the users notice more what they are showing.

Michael Kimsal: Well, that's the difference. You write code that takes time to execute. If you were like me and you just wrote code that's just gotten done, you wouldn't even need a progress bar. Just, it's done. It's done. I use indexes on my databases, like that. I use the SSD drive, I'm done.

But for some of you that need progress bars, I guess... I remember those days.

Manuel Lemos: Unfortunately, not all tasks are instantaneous if you are dealing, for instance, with file uploads.

Michael Kimsal: If you're going to be all negative about it, yeah.

Manuel Lemos: If you do not have unlimited bandwidth and things take time to upload, it is always good to give progress information to the user.

But to please you better on that note, one feature that I was about to add is the ability to delay the appearance of the initial progress bar. If the task is too short and if after, let's say, one second the task is already done, it won't even start showing the progress bar.

Michael Kimsal: There you go.

Manuel Lemos: So it won't be necessary. But that's just one of the features that I was adding on. I just did not have the time yet because it's quite recent. 

But there are other suggestions, which is something that's nice about publishing in a site like this that once you publish it and many people get to see your work, some people say, 'Oh, this can be useful to me, but maybe it would be useful if it did something else besides this.'

Michael Kimsal: If it was transparent, maybe.

This is the progress lid. Notice we started the podcast here, and I got it up to here, so we're about here. I'm demonstrating the idea of a progress indicator. Even in this podcast, we've got it.

Manuel Lemos: Oh, you are so visual.

Michael Kimsal: Folks, when you're good-looking.

Manuel Lemos: Yeah. And humble.

Michael Kimsal: I should've been born rich instead of good-looking. My life would've been a lot different. 

Manuel Lemos: Yeah. You can't have it all.

Michael Kimsal: So we're here in the podcast, we're nearly done.

Manuel Lemos: Yeah. We have probably not more than five minutes.

Michael Kimsal: Oh, goodness.

Manuel Lemos: Just enough time to comment on yet another class, which is basically a more generic class. It's basically a wrapper around the different ways to implement AJAX in the different browsers.

Michael Kimsal: Oh, the xhr one. Yes.

Manuel Lemos: Yeah, which is an object published by...I'm trying to spell his name.

Michael Kimsal: I'll say it. I saw it. I'm going to say it.

Manuel Lemos: You are the expert in foreign names.

Michael Kimsal: Archzilon or Arczilon Eshun-Davies. From Ghana. Hello. Hopefully I didn't say your name too poorly. Sometimes people would say that last part is 'Day-vees' and sometimes it's 'Davis'. Let's pretend that the 'e' isn't there altogether. But I'm not sure how you pronounce it.

Oh, whoops, my progress lid has gone away. OK, carry on.

Manuel Lemos: Anyway, just a side note, this is actually interesting to see. We don't see many authors from Africa contributing to this site, so it's good to see this object by Archzilon. He has also contributed to the PHP Classes site and he also sent some classes, some of them, I think at least one, was nominated to the PHP Program Innovation Award. 

Anyway, thanks to Archzilon. I think that's the way it's spelled. I'm not sure. I hope you can keep contributing with more components.

But unfortunately for this month, that's all of the components that we have to comment about. In the past months, there were times that we had too many components to talk about, so I think this month it's in a valley. I hope we get back to the mountains again...

Michael Kimsal: We'll get back to the mountains. Yes.

Manuel Lemos: ...and comment on more interesting components.

Upcoming Articles on the JSMag Magazine (47:11)

Manuel Lemos: But moving on now, our final section is one that Michael has the privilege to announce the upcoming articles on the JsMag magazine.

Michael Kimsal: We've got one, two, three, four, five, six, seven, six or seven things potentially lined up, and we've always got somebody who can't do something and last minute we push some things off, but a couple of things I'm pretty sure we're going to have.

Mike Schwartz is continuing on his series on his SilkJS project. If you go to SilkJS, it's a server side JavaScript project. He's actually got an article on building a GitHub API to integrate GitHub functionality directly into the SilkJS server.

Probably an article from Ku Xiao Lee Ki, who's written for us before, on mobile development with PhoneGap. Probably something from Divya Setia, if not this month then next month, about image manipulation in HTML5 and an overview there. Jeanine Meyer, who wrote for us last month, probably this month or next month an article on doing some livestreaming video rotation using JavaScript. I guess I could do that to demonstrate rotation.

Arturs Sosins, he's doing a, it's probably an ongoing, we talked about this before but I think we're going to get three or four articles out of him about this, he's doing what I had asked someone to help me with and then I ran into too much work, but the Gorodki game that I played when I was in Russia last year, he's doing a mobile version of that using Titanium. That should be in the May issue coming out next week, at least Phase 1 of that. 

So I'm looking forward to some of these, actually I'm looking forward to all of them, but getting some more JsMag out to you next month.

And as always, if you're interested in writing, Arturs and some of the other authors that we have, Dino Gambone, who actually just did a podcast with us recently, has written for JsMag a lot. He was listening, too, to the JS Classes podcast and became an author for us.

If you think you've got something that you want to share with the world about your knowledge of JavaScript or, indeed, you want to learn about something and you want to take some time to research something and write up your research about, 'This is how I learned this and this is how this works,' go to JsMag.com, shoot me an email, or just at michael@jsmag.com, and we can make something happen.

Conclusion (49:44)

Michael Kimsal: Yeah, I'll look at that. I've rolled the thing a little bit more. We're really at it.

Manuel Lemos: Yeah. We're almost at the end!

Michael Kimsal: Oh, we're at the end. I don't know if we're the end, but we'll probably get some.

Manuel Lemos: Well, this was yet another great Lately in Javascript podcast, and this time we tried something new. I think it went pretty well, this recording. Actually, I'll check it later...

Michael Kimsal: We'll see.

Manuel Lemos: ...if it came out well. But so far, it did go well. 

On that note, I would like to thank you everybody that is watching and will be commenting on the podcast.

I hope this Google Hangout On-Air will work better in terms of notification to call people to participate because we've sent invitations to tens of users that joined in the circles of the PHP Classes site, which is the account on Google that is handling this recording. This is a feature that is restricted to some Google accounts, and that's why I'm mentioning that.

So if you want to participate in the next shows, just go on Google+ and add yourself as friend of the PHP Classes site account, which appears or fixed with my name because there cannot be accounts of names of sites, just names of people, so you will see 'Manuel Lemos (PHP Classes)'. Add yourself as friend and you will hopefully be notified next month when Google Hangout On-Air.

Michael Kimsal: You're running out of Pringles lid. We're nearly done.

Manuel Lemos: That's Pringles? Oh, that's cool.

Michael Kimsal: Yeah. You don't get a physique like this not eating Pringles. 

Real quick, my wife will probably never watch this because it's nerdy, but I have to say, I had a birthday last week, woo, and my wife got me a couple of really nice things, but I don't have it yet. 

Manuel Lemos: Happy birthday.

Michael Kimsal: She's buying me a guitar, which I've been wanting for several years, so I'm getting that, and at Sunday, I'm going to the Beach Boys concert in Raleigh, North Carolina. Woo woo!

Manuel Lemos: Oh, was that your birthday present?

Michael Kimsal: Oh, yeah! Beach Boys, baby. They don't go and come around all the time.

Manuel Lemos: You are a very happy boy.

Michael Kimsal: Oh, yeah. Who wouldn't be happy at a Beach Boys concert?

Manuel Lemos: I can tell.

Michael Kimsal: Oh, yeah. I could sing some of it right here, right now.

Manuel Lemos: I'm quite far to go there, so I'm not happy.

Michael Kimsal: Maybe they'll come to Brazil. I'll tell them to go to Brazil.

Manuel Lemos: Well, probably, while they could.

OK, that's all for now on this podcast. Let me just see if I can try to put the animation to end this podcast.

Michael Kimsal: Take us off-air. 

Manuel Lemos: Bye!

Michael Kimsal: Bye-bye.