Is NodeJS going to be the PHP of JavaScript - Lately in JavaScript podcast episode 1 - JS Classes blog

By Manuel Lemos
manuellemos.net
<email contact>

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Introduction of Mário Valente (03:33)

JavaScript versus Flash (05:43)

Is NodeJS going to be the PHP of JavaScript? (16:40)

Object Oriented JavaScript book review (35:11)

The latest JavaScript objects in JSClasses site (44:19)

The latest interesting articles on JSMag magazine (49:22)

Getting seed funding for JavaScript oriented startups (51:22)

Conclusion (57:34)

Manuel Lemos: Hello, welcome to the Lately in JavaScript Podcast.  I am Manuel Lemos the host of this podcast. This is the first episode. Just a brief introduction about myself.

I have created many years ago a site named PHPClasses.org that is basically a repository for components that are written in an object oriented fashion. And that was meant to make the components more usable and useful for other developers.

The site was created in 1999 and it has grown up to near one million registered users, thousands of components were contributed, and just recently I started a similar site for JavaScript components based on the same principle.

So, like in the PHP Classes site I have a podcast there that talks about the latest happenings in the PHP world, and I decided to also start a podcast about JavaScript in the same format.

And following the same format I also have a co-host; in this case it is Michael Kimsal.Michael Kimsal: It would, wouldn't it?  Let's give them a little ear candy.  Hello everybody, my name is Michael Kimsal, I do many things.

Recently, past couple of years I have been the publisher at Webdev Publishing, we put out GroovyMag which is a monthly PDF technology journal for the Groovy Language, and JSMag, a monthly PDF technical journal for the JavaScript language covering browser JavaScript, server side JavaScript and all those sorts of things many branching out in a CSS and front-end engineering now and then.

When I'm not busy putting those together I do things like do some custom PHP and development, I do some training for the Zend Company on PHP, and I'm trying my hand at conference organizing.

Indieconf is a freelance web conference coming up in Raleigh, North Carolina November 13th, so that's a little bit about who I am, what I do and what's coming up, thank you.

Manuel Lemos: Well, that's interesting to know.  Just to give an advance to our listeners, more or less by the end of this podcast it would be interesting to have a regular section on which you talk about the latest articles that were published in your JSMag magazine. 

Michael Kimsal: Sure!

Introduction of Mário Valente (03:33)

Manuel Lemos: Okay, but let's move, starting right in this episode we also have a guest, in this case Mário Valente. Hello, Mário, how are you doing?

Mário Valente: Hi there, hi everyone.

Manuel Lemos: Well, Mário is Portuguese like myself. Despite I moved to Brazil many years ago I am still Portuguese.  I know Mário from the Portuguese Internet scene and for many years ago. He was a co-founder of one of the independent ISP's in the early days of the commercial Internet.

But it would probably be more interesting if Mário you could give a brief overview of what you have been doing and hopefully put in context why I have invited you to this podcast.

Mário Valente:  Okay.  I graduated from computer science back in ‘92. I started the first Portuguese private ISP, Internet Service Provider, back in '94. And I've been basically an entrepreneur for I mean not all my life but for all of my short life.

And in 2002 I got my MBA from the Portuguese Catholic University, and after a brief stint as the CIO for the Portuguese Ministry of Justice from 2005 until 2008 I left to finish my Master Thesis and start up a new startup. And in this case this new startup can be called the mother of all startups since it is a micro-venture capital company, we are following the Y-Combinator model to invest in technology startups here in Portugal.

I guess that you have invited me to this podcast because I've been very, very vocal about JavaScript being the future since 2005 or 2006, and I think that's it.

JavaScript versus Flash (05:43)

Manuel Lemos: Yeah, I think we may pick up on that last point, you have been very vocal. Anybody that follows Mário on Twitter can get an early dose of irony, sort of have some fun. Usually you make some comments about things that in the past would be claimed that could not be done in JavaScript, it would have to be Flash or something else.

I'm not a detractor of Flash as you seem to be, but I would rather not use it because it was sort of a patch that was implemented in the 90's to overcome some browser limitations which nowadays are not present with the latest developments in JavaScript and HTML5.

Would you like to expand a bit more on that Mário?

Mário Valente: Yeah, sure.  I hated JavaScript until I'd say 2005 maybe, probably for the same reasons that everyone hated JavaScript: it was browser-side, it was very slow, prone to security problems, I mean the whole lots of reasons that other people also hated JavaScript.

In about 2005 I started looking, for professional reasons, I started looking into... I mean I was a pro PHP man myself from 1994 up until 1999, and I switched to Python and worked with, and still do lots of work with Python, but in 2005 I had to look for professional reasons as I was saying into language choices and language trends and taking into account lots of stuff that was going on, and especially the trend towards functional languages like Haskell or Erlang.

I started thinking about the several language trends and I came to the conclusion that JavaScript would be the language of the future for several reasons: it's the most deployed language on the planet, it's not only on browsers but also on mobile phones, in every browser whether it's based in PCs or in personal computers or in mobile phones, there's lots of people programming in JavaScript.

And at the time JavaScript as a service language started to get some traction namely with the Rhino implementation of JavaScript that runs on top of the Java virtual machine, but there are also some other technologies going on, namely the Spider Monkey version that was being developed by the Mozilla Foundation, and so I started looking into that.

There were also some server side engines sort of proprietary or little known engines for JavaScript that were server side, and so I started looking into that and doing some research and some evangelism, and so I was one of the first, an early participant in the ServerJS group under the Mozilla Foundation wing.

That group eventually has turned into and is a current working group on something that is called CommonJS, if you go to commonjs.org you can find lots of stuff there.

And so I have been convinced since 2005, 2006 that JavaScript is the way to go not only in terms of client side and browser side but also in terms of server side, and I've been accompanying all that development and trying out things and think that this recent phenomenon of NodeJS coming up and getting very good traction is indeed a very good thing, so that's it.

Manuel Lemos: Well, but you've also been a detractor of Flash. Do you think Flash can be seen as something evil or just something wrong for the current context?

Mário Valente: Yeah, it's not that Flash is wrong, actually ActionScript, the language that you program Flash with, it's called ActionScript which is a very close, it's a derivative of JavaScript or ECMAScript as we should call it.

So what I think was absurd and is absurd was that having three virtual machines running browser side it was a bit and it's still a bit stupid. So you have a virtual machine for running Flash bytecode, you have a virtual machine to running JavaScript code, and in most cases you have a virtual machine to run Java byte code, so that doesn't make very much sense.

I mean the Java virtual machine has been practically unused by now, there's lots of people who have Flash installed, 99% I think that have Flash installed, but that's a separate virtual machine, I don't think that makes too much sense, I mean why program in ActionScript and have a separate virtual machine if you can do the same things in JavaScript and with modern technologies embedded in the browser.

So I mean that's my take on it, it's not that I hate Flash but Flash is proprietary, doesn't allow you to look at the source code, and has huge penalties in CPU performance since it starts inside its own virtual machine, and so I think that like you said before Flash made sense ten years ago since web browsers didn't have the certain capabilities. Nowadays Flash doesn't make sense anymore.

Michael Kimsal: Can I throw out two points?  Maybe one in support of the JavaScript and one in support of Flash approach.  One of the interesting things to me is as a developer, from the developer side of things I can test my JavaScript, I can write JavaScript, load it in browser like that, and it's fine.

To try to do the equivalent in the ActionScript VM Flash world or in the Java VM world, I need to take this extra compilation step which may be problematic, may not be problematic, but it certainly adds on to the development time, JavaScript is that quick action dynamic language.

I will say maybe in defense of the Flash approach, Flash/Silverlight, I would say JavaFX but not at this point, when there's a new iteration of things I don't have to change my browser, I can get the latest Flash runtime, I can get the latest Silverlight runtime, I actually just hit a site today that said oh you need to update your Silverlight do you want to do it; I said no but I can do that whereas right now we're still stuck in this notion of, oh well, the next version of this browser is going to have a better JavaScript runtime and it's going to have a much faster JavaScript runtime.

And I do software development, I'm not a low-level C assembly bitwise hacker kind of guy, but I guess I'm just not quite sure why we don't have a replaceable JavaScript runtimes yet, maybe not across all browsers but it sort of surprises me that Chrome doesn't have that, but if the Chrome and Safari and Firefox suddenly said you can update your JavaScript just like you could update your Flash or update Silverlight I think we would see even probably more innovation in that space.

Manuel Lemos: Well, you both have good points.  In this case Mário pointed out the problem of resource consumption when you have too many virtual machines, probably one slowing the other, and also the portability use of JavaScript is I think important, although nowadays we have many libraries that try to abstract the differences between the versions and sometimes between the browsers and the implementations of JavaScript.

Other than that one thing that annoys me about Flash is for instance it is not well integrated in the browser. For instance if you have some tags in a Java applet, if you can call it so, you cannot do a select all in the whole page and include the text that is in the Flash because it is not well integrated.

And other things like for instance I tend to use a lot the mouse wheel to scroll up and down, and then when you hit a Flash movie often it does not react as it was a single thing not just a square in the middle of a page.

And that is probably the annoyances of Flash, not just Flash, also Java and whatever gets inserted in the page as a plug-in.

Michael Kimsal: I'm seeing similar behavior though if there's a JavaScript app on a page, some of the maps is a good example, I can be on a page scrolling down, but if my mouse suddenly if the bottom content, if a map scrolls up into the area where my mouse is suddenly my scrolling is now zooming in on the map.  So there's still some problems there, just saying HTML5 or client side JavaScript it gets rid of those problems, it just changes them a little bit.

Manuel Lemos: It's probably an iframe, that's a different offset on the page. Well, anyway, I'm just expressing a concern from the non-technical user point of view.

Is NodeJS going to be the PHP of JavaScript (16:40)

But moving on in our podcast, another thing that I would like to discuss a bit continuing what Mário already mentioned regarding JavaScript on the server side, he already mentioned NodeJS. I have to confess that I have not been looking into JavaScript on server side until very recently.

Michael Kimsal: That was a shock!

Manuel Lemos: Well, you program a site during 11 years all in PHP and then you start a derivative for JavaScript, that's when you get more interested in the JavaScript world.

Anyway, I have just tried in the latest days to actually do something in practice with NodeJS. And for those that are not very familiar with NodeJS it is basically a framework that works on top of Google V8 JavaScript engine, that provides many modules that implement common functionality that you need in server side applications.

So we are already talking a different context not just the browser, it's also the server side and what happens on that side.  And basically it provides many modules that are often available by typical server side development languages.

And I thought that I read somewhere that NodeJS would be the PHP of JavaScript, but I just talked with Michael a few minutes ago, he actually said JQuery was the PHP of JavaScript but in a totally different meaning.

Michael Kimsal: Totally different, yeah.

Manuel Lemos: Anyway, I thought it would be interesting to discuss the possibility that NodeJS becomes a sort of PHP implementation of JavaScript. And in this sense what I mean is that PHP already provides many built-in modules that provide functionality that is very useful, it makes writing server side applications very quickly.

And I think NodeJS, despite it's very recent, it sort of took off last year if I'm not mistaken, it already has many interesting modules and it is very quickly getting close to the level of support of server side programming like PHP.  What do you think about this perspective Mário?

Mário Valente: Me? My turn?

Michael Kimsal: Yes, your turn.

Mário Valente: Okay.  Well, NodeJS bring the PHP of JavaScript, that doesn't translate quite right, I mean NodeJS is a virtual machine for running JavaScript and PHP is a language and it has a single virtual machine, a single engine to run it.

What I think was meant by that quote is that NodeJS can make JavaScript as popular as PHP became in the middle 90's and with that I do agree.

The biggest problem with people adopting JavaScript as an engine was that up until very recently it didn't have a few functions, namely IO functions, file access sockets access, hardware access, it didn't have those capabilities because of security concerns since it was thought that JavaScript would only run on the browser side, and there you would have some security issues.

But, once you think that you can use, once you're aware that you can use JavaScript not within the browser but within a specific virtual machine or a specific engine you start to understand that you can run it server side as well, and there you won't have the security problems that you have browser side.

And you can actually run JavaScript on server side and add to it all the functionalities that are missing, namely input/output functions.

And so that was what was basically happening since the early 2000's up until 2005. There were several custom versions of JavaScript, virtual machines of JavaScript engines, namely the SpiderMonkey engine from the Mozilla Foundation, and what happened was that then Google Chrome came out with its own virtual JavaScript virtual machine named V8, and that was also adopted as a server side JavaScript engine and some people added to it some input/output functionality, and I mean that's what the ServerJS or the CommonJS groups were doing, only I think that they started on the wrong side of things.

They started by defining standards and API calls and the definitions, and what's interesting with NodeJS is that Ryan Dahl when he came up with it about a year or year and a half ago was that he said, well, screw all those standards and all those committee meetings and I'm coming up with my own extensions to the V8 JavaScript engine.

And so that's what I think is interesting. NodeJS is a bytecode engine for JavaScript, there are several, whereas in PHP there's only one, well, actually I think that Zend, write, they have their own byte code engine, but I mean it's pretty monolithic whereas you have several bytecode engines for JavaScript, but NodeJS has gained huge traction and in that by doing that it might just be able to get JavaScript to a point where PHP is nowadays one of the most popular server side languages to program.

And let me tell you, Manuel, one thing, if you go to phpjs.org you have some guys who have ported all the functions from PHP into JavaScript, so you just include phpjs.js, I think, single file and you have all the functionality, all the functions and methods of PHP available in JavaScript.

Manuel Lemos:  Actually I noticed that site some time ago although it did not go into detail how exactly they do implement things like asynchronous calls.  Are you saying that they implemented with NodeJS?

Mário Valente: Yeah.  You can just include PHPJS in your JavaScript code server side and you have all the functionality of PHP available from the JavaScript side.  I mean you will still have to use some braces and semi-colons to terminate the statements, it's still JavaScript, but you will have access to all the PHP functions that you're used to.

Manuel Lemos: Is it something feature complete or maybe it's still part of...?

Mário Valente: I think it's practically complete, yeah, I think there's a huge list of functions that have been ported and I mean I haven't looked hard at PHP lately or for the last few years, but from what I see and from what I understand there's a progress bar here on the site and it's 83% of the PHP functions are ported already.

Manuel Lemos: Yeah, that could be interesting to share with our listeners, I'm sure many of them are PHP developers.  And actually I will also take a look because I wonder how they implement for instance networking IO synchronously as it happens in PHP because I could not figure how to do it with NodeJS.

Mário Valente: Yeah, but NodeJS is completely asynchronous, it's philosophy is asynchronous.  There are several things that you can do to make it synchronous, but it's basic philosophy is being asynchronous.  What happens is that in PHPJS you have the IO functions which basically call the synchronous versions, the synchronous APIs of NodeJS.

Manuel Lemos: Right, that's what I was wondering because I know there are synchronous versions for file I/O but I did not find at least in the latest version that I tried, which is 0.2.2, and networking.

Let me give you more details why I'm thinking about this because just as an exercise I tried to port one of my oldest and successful components that I wrote in PHP many years ago which basically did some email address validation.

It did not just validate the format of the email address, and check the MX records, it also simulated SMTP connection to the destination server to see if it would accept the message almost to the point of sending the actual message body

And it was an hell to implement it without synchronous calls because we have to do all with callbacks. And if you have to iterate over several MX servers to see if one accepts the message in case one, for instance, rejects the connection, you have to skip to the other, it's even more complicated.

Actually I succeeded with it but it took me practically two days to write a few hundred lines of code, which of course that's my fault, that's my limitation, it's for me I think with everybody else, when you are so used to programming with synchronous function calls, switching to a synchronous mode you have to think a lot what your strategy is.

Mário Valente: It's hell, you just have to get into it.

Manuel Lemos: Now imagine SMTP protocol dialog, you have to send the request and then wait for the response and depending on the response you move on to one action or another. And that done a dozen of times in the same protocol connection.

And, well, I will upload that email validation component that I ported.

Michael Kimsal: JavaScript?

Manuel Lemos: Yeah, using NodeJS, but if not fully done. There are a few things that I do not handle already because I did not have the time to check how to handle timeouts of connection receiving and sending data, but most of the functionality is already there.

I will upload it in the next days. But by the time this podcast is live on the site it will be already there so I'll have a link to that component.

But basically, like you said, it was an hell, but that's just because we are not used to it. So that's why I wondered why PHPJS would handle those calls that in PHP there is only the synchronous version and in JavaScript there are no synchronous versions available.

Mário Valente: Well, you could say that in JavaScript there's no I/O operations at all, and you have to embed them into the engine, the virtual machine.

Now, when you embed those into a virtual machine you can then use them either to synchronous I/O or asynchronous I/O.

What happened was that NodeJS chose deliberately to use them in an asynchronous way because that's the context of functional programming and of JavaScript.  Now, that doesn't mean that you cannot call the synchronous versions of file I/O, and that is being discussed within the NodeJS mailing list to have the two versions, so you can have file open synchronous and you can have file open asynchronous.

Manuel Lemos: Yes, for file I/O that is already present. I just think that at least for networking I/O if it is already available it is not there in the documentation, but I suspect that for getting a better acceptance of NodeJS they will have to concede and provide synchronous implementations as well just so people do not get nuts when trying to do things like I did simulating protocol.

Michael Kimsal: I would disagree slightly. I think just briefly here the one thing that will really, really, really help adoption is to have some of the major Linux distros provide out of the box apt get yum packages and to have some of those adopted by some of the major hosting companies.

If when I got a Linode virtual machine if it just came with some moderately recent version of NodeJS or something that had some built-in way like pre-defined proxies and things like that, so I could just point a domain name at it, maybe this is a control panel sort of thing, it took a while for the rails stuff to get integrated into web hosting control panels, but it's there now and hopefully we'll see some of that adoption by mainstream hosting providers.

To me that's going to be the thing that breaks it into the mainstream.  And it's one of the things that has kept PHP there for so long, not that it doesn't have its other ups and downs or other pros, but it's just there because it's there, and it's so easy, you can build it into Apache, there's a lot of utilities, I can point and click, and the hosting providers and the control panel companies have that nailed down for years.

Is there enough demand for them to go out and say, okay, we're going to provide something for Helma or we're going to provide a point and click or NodeJS, it'd be awesome if they did.

Mário Valente: Yeah, I agree, I totally agree.  And that has started to happen. I agree with you when you say Ruby On Rails took some time to come out, the Ruby language has existed for a few years. And it's the Rails framework that really pushed the adoption of Ruby as a popular language.

In a presentation that I made a couple of years ago I said that if Ruby on Rails became really, really popular we could also come up with a framework called drugs and then we could have something like JavaScript on drugs, and that would push for the adoption of JavaScript in a big way.

Manuel Lemos: Right.  Well, personally I see a great future for JavaScript and NodeJS in particular precisely because it is addressing the needs of many server side developers, and as well provide interesting functionality that makes server side applications more efficient in terms of resources precisely because of that support of synchronous I/O calls that make resources consumption more efficient, and we'll see.

Object Oriented JavaScript book review (35:11)

Well, moving on towards the end of this podcast I would just like to comment a bit about the latest content published in JSClasses.

And starting with a review that I just published a few days ago on a book from Packt Publishing named Object Oriented JavaScript which basically gives a good introduction of how to implement an object oriented programming concept that most people are used to in other languages but in the way JavaScript is done.

JavaScript does not have support to classes. You have to instanciate objects. There are a few ways to do it and the book covers that well.  I think it is important to have books like this to enforce the importance of doing object Oriented Programming the right way because it provokes...

Mário Valente: I totally disagree with doing Object Oriented the right way.

Manuel Lemos: I meant in the sense of doing Object Oriented Programming in the way that promotes reuse of the code.

Most people that have just arrived to the JavaScript world tend to clutter all the variables and functions in the global scope, and that compromises the possibilities of making reusable modules because you may end up colliding names of functions and variables, and then if you encapsulate them in objects in JavaScript or any equivalent in other languages it just makes it better. That's what I meant in that sense. 

Michael Kimsal: I was going to throw out a couple things, one, Rebecca Murphy who does a little bit of work for JSMag, she writes sometimes and helps out in other ways, also runs the yayQuery Podcast for JQuery stuff, some people know her name.

She had an article in JSMag about a year ago, a year and a half ago, but it's also on her blog. It's Using Objects to Organize Your Code, and I've seen her give this presentation a couple of times too, she talks about the object literal pattern and she gives some very good reasons and gives some very good examples in that, not saying this is necessarily a replacement for that book but it's sort of a taste of why you should do this and what problems it solves.

Manuel Lemos: Right.  Well, that's what I meant but Mário won't agree.

Mário Valente: Well, you used the words 'the right way' to do Object Oriented.  There are actually two ways of doing Object Oriented, one is the class-based way which is probably what you are referring to as 'the right way' to do it, but there's another way of doing Object Oriented Programming which is called prototype oriented way.

Where as in the class based way of doing Object Oriented you have classes as abstract types.  In prototype object oriented languages or model you have objects and you don't need abstract classes, so you instanciate other objects not from classes but from previous objects.

And of course that once again just like the functional nature of JavaScript needs a different way of thinking, the prototype way of doing Object Oriented-ness also means that you have to adapt to it.

So I have programmed for a long time in class based Object Oriented-ness, I still have some difficulties going into the prototype way of doing things, but what I have been finding out for the last couple of years is that the prototype way of doing Object Oriented-ness is much better.

All these different libraries that try to throw up or do throw up a class based way of thinking on top of JavaScript I think they're great, perfect for the people who are used to doing that, but people who go into JavaScript and fall into that way of doing things will probably lose a lot, miss a lot of the nice things that JavaScript has by using the prototype oriented way of doing Object Oriented.

Manuel Lemos: Right.  Well, so I think we do not disagree after all.  What I mean the right way, as I mentioned, is that people encapsulate the functionality inside the object functions rather than put them in the global scope which is something actually Michael commented on in the podcast that we did about the JSClasses site that people, for instance, they use JQuery which is all Object Oriented, but in the end they clutter many global variables and functions to use it and it makes it very messy and hard to maintain and that was my sense of what wouldn't be the right way.

Michael Kimsal: I think in the broad sense we're all sort of saying the same thing.  Mário, I think what you're getting at is take advantage of what the language allows, and JavaScript is a lot more oriented towards giving you the benefits of that prototype stuff.

I do Groovy work and I came to it from PHP, very class oriented. There's a lot of parody, a lot of things that I would do in PHP I can mimic almost entirely in Groovy, but Groovy, as Ruby, offers a lot of meta programming stuff that's very slick, very easy, and very integral to the language.

So I can do Groovy or I can do Groovy as I think about it or I can do Groovy as it was intended to be and really take advantage of the language. And whether people come into JavaScript it may take them a while to get into the prototype way of doing something, it's really just a learning curve.

And I think that the more languages that we use as developers the easier it is for us to adapt to the nuance and the features of each language but it does take some time.

Manuel Lemos: Right.  Yeah, I think for people that come from other languages it's just a matter of adapting to things that are a little different.

Michael Kimsal: Well, functional programming, for example, does kind of take some people off guard; it takes a while. Closures just came to PHP5.3 a year ago, it's taking people a while to figure out how can I use this, what's the benefits, what's the drawbacks, what do I gain from this, oh, I get this, let me try this.

Manuel Lemos: Yes, that's true, in PHP 5.3 finally they implemented closures or anonymous functions you can do the same as you do in JavaScript.

Mário Valente: Yeah, but see all this stuff is closely related. Closures, prototype based programming, synchronous functions, this is all interconnected, you can only do asynchronous program, namely asynchronous I/O or asynchronous programming in general, if you understand the concept of closures.

And if you understand to use closures not in 'the right way', I don't want to say that, but you do need to change your mind from class based objects oriented to prototype based objects oriented. So I totally agree with Mike, it's something that takes time with it; I, myself, am still trying to adapt myself to this way of thinking, but you do get lots of benefits from these features.

Michael Kimsal: Yeah.

Manuel Lemos: Right, well, anyway this was mentioned just in the scope of this book review that I published.  There are several other books that cover object oriented JavaScript programming, this is just one, basically it is nicely written. It was not thought to have in mind developers of other languages but it's still a good recommendation.

The latest JavaScript objects in JSClasses site (44:19)

But moving on now practically in the end of this podcast I just would like to comment on a few classes that... actually a few objects, I just got so used to the name classes that I tend to forget that there are not exactly the same concept of classes that you have in other languages, but let me just comment on a few.

Well, there are several interesting classes, actually objects, that were published here. I have published a few just to get the site started, one about making page animations to easily script them to provide very simple basic but useful effects.

I also have written a wrapper around HTML editors that several browsers support, but adding special support for templates which basically consist of marks that appear in the middle of HTML, and you can visually insert them in the HTML editor. This is very useful for implementing documents that have placeholders to insert complex, more complex HTML.

And other than that I would like to mention just a few submitted by other developers.  One which is very interesting which is an object that cuts HTML when the text acts as a certain length of words. And this is very useful when you want to paste, want to present a text in an HTML page that visually it would be better to cut it or make it shorter until the user wants to click a button to expand and at the same time keep the original HTML text in there in the page, so the search engine is Google or others can fully index the pages and you do not have to apply some server side tricks to cut the HTML to make it shorter.

Michael Kimsal: There's one other that jumped out at me, can I jump in here?

Manuel Lemos: Sure.

Michael Kimsal: I'm seeing here a JavaScript class from Sergei Selihov, I hope I'm saying the right name, over in the Ukraine, he's got a class here to allow you to access SQLite databases from AIR applications.

And given that we were talking about Adobe and Flash before this was a tie-in to the AIR world, but in general I've been seeing more interest in doing JavaScript accessing of SQLite because that's a thing that's built into a lot of the browsers now, client side persistence, so that looks like it might be a good class for people to look at and figure out how to build their own or to build on top of this class.

Manuel Lemos: Right, it's curious that after all you can use JavaScript in air applications, well, it makes sense because that's what they propose, but I wonder if people would not prefer to use ActionScript since it's all an Adobe thing.

Michael Kimsal: They prefer whatever Adobe tells them to prefer, so.

Manuel Lemos: Yeah, they obey.

Michael Kimsal: Yes.

Manuel Lemos: Okay, other than that there are several other objects here, but other than this one that is able to retrieve Twitter statuses of a certain Twitter user using JavaScript, I wonder what other classes, objects, have you found interesting?

Michael Kimsal: Well, the one I found most interesting is the one that I'm writing myself which I plan to upload probably in the next week or so which does client side resizing of images before you upload an image. So instead of uploading a 4MB image that's gigantically huge if you only need a thumbnail of it to be like 400 pixels across this will do that.

So I'm working on how to package that up into something more reusable, that's my focus right now, but I should have that up probably in the next couple of weeks.

Manuel Lemos: That's interesting, what is your approach, do you use canvas or something like that?

Michael Kimsal: Hey! That would be telling. You'll find out soon enough.

Manuel Lemos: Oh, okay, that will be a surprise, as if we couldn't guess.

Michael Kimsal: I have more error checking to put in and I have to make it more reusable but I'll let you know when that's ready.

Manuel Lemos: Right.  Well, there are a few other classes but we don't have much more time to go through them.

The latest interesting articles on JSMag magazine (49:22)

Manuel Lemos: Other than that Michael already mentioned an article that would be worth looking at in your magazine. What about the latest issues? What articles would be worth taking a look at?

Michael Kimsal: I'll throw out just a little bit of JSMag stuff here, don't want to hog the light here, but, the current issue, September, we had a review of some of the smaller code contests, there was kind of a smattering of how much JavaScript can you put in 1K or 5K or 10K..

We had an article on performance testing with Boomerang which is a performance testing tool for JavaScript, but we're almost at the end of the month and I'm more focusing on what's coming up.

We've got a new series starting from Jason Gilmore, a well known name in the PHP community, he's starting a series on client side mapping, integrating mapping functionality with JavaScript.

And we have an ongoing series from a guy named Mike Schwartz on server side JavaScript, pretty much what we were talking about today. I think there's probably going to be five or six installments, but he's going through server side development with JavaScript but he's using Helma instead of Node JS.

We did have Ben Dowling gave an article in February on getting set up with NodeJS, although I'm not sure how out of date, it's been seven or eight months, it might be a little out of date now, but we've got this ongoing series right now about server side development with Helma, so I'm looking forward to the next edition of that which will be out this coming Friday, October 1st.

And to kind of throw this out to tie it in with JSClasses, if you use the coupon code JS Classes, jsclasses at jsmag.com you can register with that and use that coupon to grab any issue of your choice.

Manuel Lemos: Oh, that's interesting.

Michael Kimsal: If you want to check out Ben's article from February 2010 on Node JS just redeem that coupon jsclasses and it's yours.

Manuel Lemos: Yeah, that's nice, I think that will be an opportunity that many listeners will take.

Getting seed funding for JavaScript oriented startups (51:22)

Manuel Lemos: And I think we are almost done with this podcast, I'd just like to thank Mário for coming and I have just one last question to Mário.

Mário you are basically nowadays you work as a seed fund investor, do you have any interest or preference for people who have projects or products that need funding based on JavaScript or related technologies?

Mário Valente: Well, I have for a long time been writing on my blog about the future web development framework, I mean if you go to my personal blog which is at mvalente.eu you can find if you search for web development framework you can find a few articles about it, and if you search for server side JavaScript you can also find some of my articles there.

And it's one thing I've been thinking about for a long time, it's about a server side JavaScript web framework, something similar to Rails like we were talking about a while ago.  So if I could convince someone something to build me up my dream web development framework out of JavaScript on top of NodeJS or whatever JavaScript engine it would be, I would definitely invest in one of those ideas.

Manuel Lemos: That's great but what would be the business model or you're just funding because you like it?

Mário Valente: Well, I mean several other development frameworks exist and they do make money, so there would just be some thinking about what the business model could be, but that was something that I would be interested in.

Manuel Lemos: Right, so just to give some more detail for people that would be interested to consider your offer, do you have any restrictions in terms of projects that you would fund or not?

Mário Valente: No, we would or we will fund any idea that we find interesting from the business point of view not from the technology point of view.  I mean of course we do prefer a couple or a few technologies just for the reason that they might be able to lower costs and from that I mean open source and free access technologies.

We would tend not to choose projects based on technologies for example like .NET or ASP or Microsoft languages or infrastructure, not because it's Microsoft, and I don't like them, I can state that, but it would mostly be due to cost reasons because if the right project came up for investment and we found out it was a good possibility for investment we wouldn't, we couldn't care less about what technologies they are using.

So from the investment point of view we are technology agnostic.  Then I have my personal preferences but that's it.

Manuel Lemos: Okay, so anybody could approach and propose a project for investment or do you have things like geographic restrictions, or would the funded teams have to maybe be in Europe or they could be elsewhere?

Mário Valente: I mean we are just starting up ourselves, so we don't have that many resources, so we do prefer that the projects are for now based in Portugal, but we're looking towards Europe as well.

We are investing right now in a company from, in a startup from Lithuania, and where we would like to do some traveling back and forth and some distributed team coordination but we intend to do it.

The rest of the world I mean it would be a little bit more difficult, for example, Brazil would be easier basically due to the language, I mean right now we are focusing on our geographic area.

Later on if we grow up a little more I mean then we can start looking at wider possibilities, but I mean once again if a good idea comes up I don't know from Pakistan or from Australia what we would try to do is convince people to come spend six months or a year here in sunny Portugal.

We are better than San Francisco, we have a better bridge, better wine, better food, better trams, and so we would try to convince the team of that project, that interesting project, we will try to convince them to come to Portugal for six months to a year, that's what we would try to do.

Manuel Lemos: Yeah, sounds good.  Well, so what would be the way to contact you is there a site that they can visit?

Mário Valente: If you go to my personal blog, that's mvalente.eu, or if you search for me on Google, Mário Valente, you can find my personal blog, there's a contact form there. Or if you go to the company's, to our company's investment site, seedcapital.pt, there's a project submission form there and you can submit your projects there.

Manuel Lemos: Okay, sounds good.

Conclusion (57:34)

Manuel Lemos: Just let me thank you, Mário, for coming, it was great to have you here, you have your insights, as well Michael. And if you don't have anything else to comment on that's the end.

Michael Kimsal: Just, hey, Mário it was great to meet you, thank you very much for your time.  And, Manuel, thank you for putting this together again.

Mário Valente: Thank you Michael and thank you Manuel as well.

Manuel Lemos: Okay, bye, bye.

Michael Kimsal: Adios.

Mário Valente: Bye.