AJAX 2, Microsoft SunSpider cheating? - Lately in JavaScript podcast - Episode 3

By Manuel Lemos

manuellemos.net

<email contact>

Contents

Listen or download the podcast, RSS feed

Read the podcast transcript

Contents

Conclusion (48:49)

Manuel Lemos: Hello, welcome to Lately in JavaScript Podcast. I'm Manuel Lemos the host of this podcast, and as always I have here with me Michael Kimsal. Hello, Michael.

Michael Kimsal: Hello!

Manuel Lemos: It's always great to see you happy probably with the show.

IndieConf event coverage (0:43)

Manuel Lemos: So what have you been up to? Oh, I remember, you have just gone through your event, IndieConf, how did it go?

Michael Kimsal: It went well, thank you. And we probably won't have another episode about this for a bit, but I'll do a quick recap.

Last week we had our IndieConf which is a conference for Web freelancers up in Raleigh or down in Raleigh depending where you're coming from. And we had close to well I think we had a couple of unticketed people who are video people who are video people doing audio and video capture of everything.

We had just over 100 people there on site which was pretty exciting for a first event. I had a lot of speakers from the Raleigh or the North Carolina area, we had some from outside the area from Michigan and Florida. We actually had... and I didn't actually catch his name enough but at the very end I said who came the farthest, who attended from the farthest, we had somebody from Michigan, we had somebody from Atlanta, and there was this rustle in the background and someone said this guy's from Brazil.

Manuel Lemos: Oh, really.

Michael Kimsal: Yeah, so he won a giveaway, a book, The Money Book from two of our speakers, and he had come from Brazil I think just for the conference which was pretty interesting.

Manuel Lemos: All the way or was not already living there?

Michael Kimsal: No, he wasn't already living there, he'd come from Brazil. I don't know if he had other business in the area as well but he'd come from Brazil.

Manuel Lemos: That's great. So now you can call your event international.

Michael Kimsal: Yes, I hadn't thought of that until now but yes that's great.

Manuel Lemos: Okay, that's good to know. Any interesting JavaScript related talks you want to comment on?

Michael Kimsal: We didn't have any specific JavaScript stuff. We will next time. We had Rebecca Murphey who is a JavaScript name, lives in the area, she came and presented on Git which was very well attended. Zoe Gillenwater is fairly well known in the CSS community and she came and presented on CSS3.

I had a couple of people that I was going to bring and have them come on JavaScript, and I decided against it early on but I think the next time we do this event there's gonna be a few more tech tracks that we'll have things probably another CSS or something like that and a JavaScript front-end engineering session.

Manuel Lemos: Right, because the focus is more on soft skills, right, than actual...?

Michael Kimsal: A little bit, yeah, but at the same time there's a lot. The focus is still on web freelancers and some people are copywriters and some people are maybe they're programmers and such but we all have a web focus to us.

And I was initially going to have a track or a whole set of sessions on back-end technologies like PHP and .NET and Ruby and so on, but it felt to me that those would be very divisive. Anybody that's going to the PHP one will by definition not go to the .NET one probably or the Ruby one.

But having a CSS track, or session, having JavaScript's maybe one or two on those I think will be very inclusive because it doesn't matter if you're doing Ruby or if you're doing PHP or whatever you're doing, you're going to be using JavaScript.

Manuel Lemos: Right. Well, I think for a first event you had a great audience. Well, I hope next edition you sort of open more space for JavaScript because I'm sure it is sort of a consensual interest of all the tribes as you mentioned.

Michael Kimsal: It was... I hesitate to say a full mistake to not have it, but in retrospect I wish I had brought in someone specifically for JavaScript. We'll do that next year.

Manuel Lemos: Right. Okay, so moving on.

AJAX 2: XMLHttpRequest Level 2 (4:59)

Manuel Lemos: This month there is a topic I wanted to comment about basically related to an article. Well, by the time we are recording it was not yet published but it will probably be published tomorrow, but once the podcast is on the air the article is already published for anybody to read.

Well, it is basically about XMLHttpRequest specification that recently has recently moved on to a new level. As everybody knows XMLHttpRequest often refers to what powers most AJAX applications, although you don't need to actually use XMLHttpRequest.

Sometimes you can use an iframe based implementation. Actually I just mentioned that because in my PHP applications I use iframes to implement the sort of functionality, AJAX functionality that you have in your Web applications.

And what is relevant now is that this new level of specification that W3C Consortium is organizing adds some new features that overcome limitations of the first version of XMLHttpRequest.

For many years XMLHttpRequest was not under any official specification. For those that are not familiar with the whole story it all started with Microsoft Exchange Server that had a product that allowed it to have web based access to the functionality of the server.

The idea was to make it more..., provide the user interface that is more fluent, more interactive. But that was like I suppose in 1999 and they had this implementation which initially was based on a Java Applet that then later it moved on to ActiveX object that would provide that functionality to Internet Explorer 5.

And that was the sort of beginning of what most of us call AJAX, to have these kinds of applications that are more interactive because they access the server to send or receive data in the background, thus without having to reload the page.

And later in 2002 I think it was when the first Mozilla browser version was released, it already came with the XMLHttpRequest object built in that browser. The Mozilla was actually a suite that consisted of several programs not just browser, but is basically the grandparent of Firefox which many of us use now until today.

And as I said in 2002 it added that functionality of having this XMLHttpRequest object, but I think at least in my opinion what really made this use of this object to implement to the so called AJAX application was Gmail, and I think Google Maps too because those were applications that actually gave great visibility to the object.

And those are released only in 2004, so there was a gap until somebody realized the great potential of this object that could work also in non-Microsoft browsers. And later in 2005 Jesse James Garrett coined the AJAX term to refer to this practice of using XMLHttpRequest or some other technology like hidden iframes, as I mentioned before, to implement the so-called AJAX applications.

And for all this period there was no effort to standardize the specification of the object. The standardization only came in 2006 when finally somebody at the W3 Consortium decided to gather and make it a standard specification.

More recently there is a new effort to standardize the next level, so-called Level 2 of the specification to provide this... better functionality to overcome the limitations of the original XMLHttpRequest object.

And, Michael, I don't know are you familiar with the new specification?

Michael Kimsal: Vaguely, actually I pulled it up here while you've been talking to look at it and see what it gives. The notion of being able to trigger progress events and react to progress events seems probably the most immediately useful aspect of this XHR Level 2, but mentally I'm having a bit of hard time figuring out how that would be integrated into my current code or future code I should say.

Manuel Lemos: Well, this is a new specification and I think there are some browsers like Firefox 4 and Chrome that already implement at least part of the specified functionality. Actually the specification is still in draft, so between now and the final specification things may change, but I think there are a few features that probably will not change.

And from those that I have studied in this version of the specification I like two or three of them. I have to confess that in the whole specification is not clear to me what are some of the features that are described there

But those that got my eye is one of them just like you mentioned the ability to track progress, for instance, if you are submitting a request to the server that probably will take a long time, now it is possible to have callbacks that are invoked when there is new data being sent or received from the server.

So you can somehow use those event callbacks to maybe show to the user how much has gone so far and how much remains to be done. And I think this is very useful and too bad it was not made available before.

So as to your question how would you integrate in your current code I think you probably have to use some conditional code to detect whether the XMLHttpRequest object in the current browser supports it or not.

So it would be something not mandatory, to be an additional feature that you would implement if this support is available and then fall back to something else probably and doing nothing if you realize that it's not available.

But other than that, also regarding tracking progress, one of the most common use cases of tracking progress is to upload files, especially files that are very long. It would be useful to give the user an idea of how much remains to be done.

Michael Kimsal: Yeah. It feels like, well, it is an attempt to standardize, come up with a normal way of doing this because I've seen, I've been on projects where we've had to try to come up with our own protocol for figuring out what the status is and doing separate calls to get progress status on something, and if we're able to do that in a standard way I think that will be interesting.

It will be interesting to see also what libraries like jQuery and Dojo and YUI and all that, what they offer and how they integrate either new functionality or replace old functionality with this Level 2 stuff. That will be an interesting development to see.

Manuel Lemos: Well, and as I was saying, one of the most commonly use cases for this progress tracking support would be for file uploading, but the problem is at least until the first version it was not possible to build upload requests because XMLHttpRequest had no support for building an HTTP request type POST that would attach a file because you would have to have access to the actual contents of the files.

And until recently it was not possible for JavaScript to have access to the data of the files in the user browser machine for security reasons of course. And actually I was trying to study what is now possible, I'm still not sure but from what I understand there is now this File API which is basically a separate specification that from what I understood it allows you some sort of access to the files probably related with some file input in a form or another possibility which I think it's now available on Gmail which is the ability to drag and drop files from your desktop into the browser and then you will be able to upload them.

Michael Kimsal: Yeah, interestingly, well, I was playing around with the drag and drop specifically. I've seen it for a while but I did a small thing probably two months ago and played with it and dragged stuff, and it was kind of cool to get access to the data that is in the file that was dragged in but I've seen it more specifically.

Thinking about it I don't know if it's maybe... I don't know if it's a Flash thing or not but I can drag files into Gmail now when I'm composing a mail. You just drag a file in there and I roll over or mouse over this target with a selected file and drop it and it acts just like it selected the file and it starts doing an upload.

But I can't remember now if that's... because for a while some of their uploading stuff was using Flash.

Manuel Lemos: Yeah. Well, for me I've been using a plugin for this... I have this forms generation validation package that comes with a plugin that allows you to track progress of uploaded files.

What basically it does is that it starts a hidden iframe and that is actually sending a request to the server and it passes a hidden identifier that PHP is able to recognize as a request going on in parallel, and it can retrieve the information of the file being uploaded.

And this plugin works well but it requires parallel connection going on at the same time that the actual form submission request is open. And it works well, it gives all the information, it tells the user how much was uploaded so far and how long it will take, I mean it's an estimation of how long it will take until the end.

But it would be better if all could be done within a single request, and I think so far besides any browser that supports this feature in the XMLHttpRequest Level 2 object I think probably only in Flash it could do it. So this is great, this is one feature that was pretty much in demand.

And other than that another feature that seems to reply to demands of many developers, at least that is my perception, is the ability to do cross domain XMLHttpRequests. Actually I've been talking with the guy from the Opera browser that is leading this specification, his name is Anne. I'm not sure how to pronounce his name.

Michael Kimsal: van Kesteren?

Manuel Lemos: Yeah. You probably would say his name better than me so I will not try. And according to him this is probably the greatest feature of XMLHttpRequest Level 2 which is the ability to send cross domain requests.

Now what happens is when you load a page it will not allow you to send... the JavaScript inside that page is not allowed to send AJAX requests to other domains for security reasons, that could be used to perform cross site scripting exploits, but at the same time there is a demand to allow this type of cross domain request.

So what this version of the specification allows is actually specified in a separate document that describes how cross domain requests should be done. And it basically consists on... the server that generates the current page must send a special header that will tell whether or not you can send AJAX requests to separate domain.

So I think this will address a need that many developers had and had been requesting it. I think for me these are the most important features from those that I learned from the current draft specification.

Michael Kimsal: Well, I think I'd agree with you that cross domain one is probably... I would agree it's important to you, it's important to me as well, and it's probably going to have the biggest impact as this gets rolled out. Though I'm always a little hesitant when these new features come about because there may not be...

Manuel Lemos: available...

Michael Kimsal: the adoption rate, if the adoption rate isn't quick enough we'll find ourselves writing conditional code, well, if you're using this browser or if you're using this functionality then you have this feature, and if you don't you don't.

Really that's the nature of web stuff, I understand that's how it has to be. I just hope that a lot of browsers end up supporting offering this XHR Level 2 quickly. It'd be great to have a huge amount of adoption within say a year so we could just start counting on it.

Manuel Lemos: Yeah. That's always a drag because it does not depend on you and you have to rely on what you get. So if you want to take advantage of it now you will always have to write conditional code.

Well, the recommended way to do it is not doing browser detection but rather feature detection. Having some sort of variable or function call that you can detect whether it is present or not rather than make conditions.

Michael Kimsal: Sure, I agree. Feature detection over browser detection but the reality is that the feature's going to be available in some browsers and it won't for a while, I'm hoping that time period is pretty short.

Manuel Lemos: Well, even if it's short you will always have to put some conditions in there because there will always be people that will not upgrade to the latest browsers.

Michael Kimsal: There's always going to be a few, and this is selfish but my view is that if I can demonstrably point to the majority of a client's audience or a client's users are using a particular browser or set of browsers that have certain features available to them we'll use that.

Because at some point you have to have a cut off because you could say there's five people out there still using Lynx and it doesn't support JavaScript, that doesn't mean that I don't use JavaScript or I don't use AJAX because some people are still using Netscape 2.

The preponderance of people are going to be using something, if the majority of people by 2012 are using a current Chrome, Firefox 4, Safari 5, Opera 11 and IE 8 or higher, for example, or IE 9 or higher that would be fantastic I think in terms of modernity in JavaScript in browsers.

Manuel Lemos: Right. Well, the one thing I have not studied yet is what is the state of that adoption of this specification so far because it's still in draft, and if I'm not mistaken it was started in 2008 and they sort of paused it for a while and then they are resuming it this year, and, well, we'll see.

Michael Kimsal: Just as a point of principle I don't go out of my way to even check if something works in IE 6 or not, I gave up on that probably a year ago.

Manuel Lemos: I no longer have it installed on any machine, so if I wanted to test it too bad, it's not possible. But I think from what I read its adoption is probably lower than 3% by now.

Michael Kimsal: Well, this is an interesting topic, thanks for bringing this up because I was not aware that there was this Level 2 thing actually being specked out. I've heard about some of these ideas floating around but I didn't know what the status of actually bringing it together was, so I'm gonna keep an eye on this.

Internet Explorer cheating on the SunSpider benchmark? (26:25)

Manuel Lemos: Yeah. Well, but moving on with our podcast, the next subject we planned to cover Michael mentioned about this SunSpider benchmark and some discussions regarding Internet Explorer 9 results. What's going on?

Michael Kimsal: Well, I'll introduce this very briefly. I'm not an expert at this at all but David Calhoun who is the news editor for JSMag does a weekly blog post update and I think a couple days ago on Friday he'd done a weekly wrap up and one of the things that had come out in the last week or so was someone had accused Microsoft, or specifically the IE 9 team at Microsoft, of "cheating" or cheating in their JavaScript engine because there was a benchmarking test, there's a number of benchmark tests out there, one is called SunSpider and it's a number, it's a collection of tests that drive and rate different browsers' JavaScript functionality.

And apparently IE 9, whatever the current release version of IE 9 is, did very, very well on a particular test, the numbers were amazingly fast, but when somebody went in and changed one aspect of that SunSpider, that one particular test, they just changed one of the numbers, one of the values in it, IE 9's performance went way, way, way down.

And the accusation was that they had just optimized and basically cheated and just looked for a certain code in the benchmark, or was just looking for certain code, and reacted very, very fastly rather than treating it as normal code supposedly.

There was a bit of a leap I thought to make that accusation, and as we were saying before this recording was happening that I suspect that the IE 9 team was simply not maliciously so but were making sure that their code ran very well in those tests and had simply not gone through and made sure that other scenarios worked just as well.

I may have a very naïve view of this, but I don't view Microsoft really as the evil empire so much as... I wouldn't say they're being attacked but they are being challenged on many, many fronts, browsers and mobile devices and gaming and desktop software, they're challenged all over the place.

And effectively as I'd said before they're damned if they do and damned if they don't. If they had just put out here's our latest version of IE 9 everybody check it out, and they did really, really poor on the benchmarks people would have just said, hey, you still suck, you can't put a browser out now, look at all this other stuff.

So they try to make sure that it's competitive and they're getting taken to task on this. I don't think it was a malicious, hey, we're going to try to cheat on this, it's too easy for people to find out. And I suspect that this wasn't an intentional cheating so much and they're still being accused of it.

So in some case... in some ways if we continually still in 2010 and 2012, 15, whatever, if we keep accusing Microsoft of continuing to play dirty all the time they'll have very little incentive to not do it. Because when you cheat and when you play dirty you get advantages and if you're going to be accused of it anyway you may as well do it. So I was just a little sad to see that such an accusation come out.

Manuel Lemos: I think you're right, there will always be people that will find excuses to blame it on Microsoft for whatever reasons. And I also don't think that they did it on purpose and at the same time I don't think that matters much because in the end in terms of speed it's the overall feeling that the user gets from the browser not specifically on a certain benchmark that just tests a limited number of situations. And I think the subject itself probably will not deserve it.

Michael Kimsal: On the upside, if I remember correctly or if I understand this correctly, IE 9's JavaScript engine is going to much more easily take advantage of multiple processors, a lot more lower level integration, I don't want to say integration in a bad sense, but it's very tied to Windows and I think they're going through a lot of effort to make sure that it can handle as much computational power as Windows itself can rather than arbitrarily segmenting it or keeping it locked at one particular CPU.

My understanding is they they've been trying to make a lot of progress in the multi-core focus, and because they only focus on one platform that's maybe another potential area for them to dominate in, at least initially to lead the way, though I'm not sure anybody would look and say they're going to take their code, they really can't unless they offer it up, but maybe there will be some lessons that people can learn by looking at some of the efforts that they have.

No doubt that Chrome and Safari and Firefox and others are looking at multi-core distribution and all the kind of stuff too, but I suspect that Microsoft may have a little bit of a lead there simply because they get to focus on one platform.

Manuel Lemos: Right, I think it's very positive because I think that is the kind of competition that is healthy because different browser vendors, developers are working hard on surpassing the results achieved by others implementing new techniques that were not implemented before.

And basically we all benefit from that because whatever browser you prefer sooner or later your browser vendor, developer will also catch up or try to do even better with some approach that was not tried before.

And I think this, if I'm not mistaken, this version of IE 9 implements some hardware acceleration using the graphics hardware to render whatever graphics are necessary to appear on the pages, and this is good for many types of applications, for instance, games that may need to render a lot of graphics on screen.

And I also understood that Chrome was already implementing hardware acceleration, and as I said the overall result will be the benefit for all users regardless of the browser that is used because they're trying to keep up with each other.

Michael Kimsal: Yeah.

JavaScript Cookbook book review (34:23)

Manuel Lemos: Okay, but moving on with our podcast now I'd like to bring up a book that I have been reviewing. Actually a published a review just a few days ago, it's JavaScript Cookbook from O'Reilly.

O'Reilly is well known for cookbook book series, if we can call it a series because the books are not related, are for different languages, but this JavaScript Cookbook follows the same pattern and the same quality that O'Reilly already got us used to.

And my overall impression is that it's quite a handy book because frequently when you need to write JavaScript code you find yourself trying to solve common situations that if you are fluent in JavaScript, if you program JavaScript everyday you probably would not need, but many of us are Web developers and our main language is the server side language that you use, being that PHP or Java or C Sharp or Ruby or Python, whatever.

And we are not probably as fluent as we could be if we programmed JavaScript everyday, and sometimes we have a need to find a good proven solution for a common problem. Sometimes it just takes a few lines of code to implement it and you find yourself looking on the Web or whatever to see what is that common solution for the problem that you're having.

And I think having a JavaScript Cookbook on your desk will sort of shortcut many of your problems because this book will not cover all the possible situations that you may encounter, but at least it provides solutions for many, many situations that will be common, and in the end I think most of the time you will find a solution for the common problems that you have. Michael, are you familiar with cookbook type books?

Michael Kimsal: Now is this... who's the author of this book?

Manuel Lemos: Well, as I said, the book is from O'Reilly and the author is Shelley Powers.

Michael Kimsal: Shelley Powers, okay.

Manuel Lemos: I'm afraid I'm not familiar with her name probably because most of the time as I mention I work in PHP, but my impression is that the book itself provides many, many solutions for common problems that would end up being used for the kind of developer like myself and probably yourself as most of the time JavaScript is not the language that you program. You end up programming more in your server side language.

But other than that there are a few sort of unexpected chapters at the end that got my eye besides those that cover common topics. And that chapter in particular covers situations that are not so common but probably sooner or later you have the need to address them in your applications or whatever projects you are having.

In that chapter covers the creation of plugins for browsers like Google Chrome or Firefox and also solutions for creating JavaScript applications for mobile phones. As I mentioned, these solutions are not so common but I think sooner or later you'll have them, so I think that chapter is an interesting bonus.

Michael Kimsal: Well, always interesting timing just like with the regular desktop browsers and all that. For some people writing JavaScript for mobile browsers is already something that they do and they do a lot of, but I think it's still very much a niche thing and it may be by the time particular majority of people are writing JavaScript for mobile devices that there may be a whole other level of functionality available in those devices that might not be covered in a book like this.

It's just the perennial problem of technical publishing in general. One question for you here in terms of the book because when you first mentioned it my mind went to the jQuery Cookbook, but no this is actually the JavaScript Cookbook.

Did you find that it kept a focus just on pure JavaScript or were there references to things like Dojo and YUI and JQuery and stuff like that or was it very just pure JavaScript?

Manuel Lemos: Right. Most of the book is for general JavaScript situations, and actually I think that is probably more useful, at least from my point of view, because most of the time I try to avoid using bloated or at least large JavaScript libraries when I just need something that takes a couple of lines.

Nevertheless there is one chapter, one specific chapter in the book that covers the use of libraries but it talks a bit about JQuery but obviously it does not focus much on that because, as you mentioned, jQuery itself it will be subject to having a whole cookbook just for it.

Michael Kimsal: Yep, and there is one out there which I think was done by a collection of authors. jQuery Cookbook, it says it's by Cody Lindley but my understanding there was a number of contributors. Okay, yeah, Amazon page is saying here Remy Sharp, Jonathan Sharp, Ralph Whitbeck, Rebecca Murphey, Mike Hostetler, and it looks like about 20 different people. And yet the JavaScript Cookbook it looks like Shelley Powers did everything there, a single list of contributors.

Manuel Lemos: It's a general purpose book not all sorts of...

Michael Kimsal: I'm not knocking it all. It's just interesting to see the two different approaches or multiple approaches in the cookbook style of books. Certainly when you have one author you can keep consistency, style consistency, a lot easier than you can if you have 20 contributors.

Manuel Lemos: Right. Well, my impression is that this book regardless of the number of authors would always be useful to have in your desk, so we don't have to research much on figuring what is the proven solution or the most recommended solution for problems that sometimes just take a half a dozen lines of code that much you probably do not need a large library regardless if you are used to always working with a large library or not.

And I think it is recommended for people like myself that do not work with JavaScript everyday, I work with JavaScript often but not everyday. And I have to always switch the context of the language and sometimes when you do that you make syntax confusion, but the use of this book is more to help you find the solutions.

It always presents the problems that try to solve, presents a solution and then there's a discussion because you want to understand why it is being suggested that solution.

Michael Kimsal: Sounds good.

Latest objects in the JSClasses site (43:20)

Manuel Lemos: But moving on with our podcast now towards the end of our show now we have a section on which we review the latest objects published in JSClasses site. Michael, have you been looking at the latest objects which are there or what do you think?

Michael Kimsal: What I was looking at specifically today was one from a contribution from Gianluca Zanferrari, I hope I'm saying his name correctly, and he's created a message box class that has it looks like a little bit of not really animation so much, there's a little bit of that, but it's a class oriented approach to displaying message boxes on the screen.

Very simple from what I can tell, but it is that focus on reusable code and it's very much a stand alone component, certainly there's things like this in the jQuery's and the Dojos and the YUI's and so on, but this is very much just a self contained one file that does that.

But I think that really adheres to the focus that you've had for JS Classes in the first place is the focus of reusable code.

Manuel Lemos: Well, when people just have a need for a simple solution that you don't have to bring all the code of a full class library this is a simple solution that can address that kind of need.

And in this case it is very simple, as you mentioned, it basically displays a message that remains on the browser screen for a while and you can configure it to disappear after a short period. It's very simple but it addresses a need that you often have to implementing your user interface.

Michael Kimsal: One thing that jumped out at me here is that it's small enough that you can look at it and figure out what it's doing and go and modify it for yourself, but from somebody that's trying to get a very quick understandable idea of this whole notion of the reusable code and JavaScript encapsulation, this feels like it kind of hits a mid-ground there between it's showing somebody something visual and you can get in there and play with it pretty quickly, it's not overwhelming code but it's usable at the same time.

Manuel Lemos: Right. And following this spirit of implementing very simple things encapsulated in objects, in small objects that you can handpick just to address your needs, there are several others published there recently and one of them is this JSPoll class that basically also does something simple which is the management of timers and callbacks that you want to invoke after a certain period of time, and with the additional functionality over a simple setTimeout call which is the ability to stop and resume a timer for a given period that you may need to pause for a while and avoid calling the registered callback functions.

And also another object that follows this spirit of simple components, small objects and implement common features that are necessary there is this one from Rafael Lucio to build simple menu items that generate menus with links that will pop up when the user clicks on a certain element on the page and show links, a user can click on links and you can build a very simple menu that you may need in your site very easily.

And as you mentioned the spirit of having simple components that address simple needs that are common is showing up in most of the components, objects that have been published in the site so far, and over time it is expected to have a very nice collection of independent components that you can pick, and eventually most of them do not require you to load a large library that will probably be more complete and address all the needs, but if you use simple components you don't need all that to have loaded in your page.

Conclusion (48:49)

Manuel Lemos: So this is yet another episode of the Lately in JavaScript Podcast. Michael, thank you again for your presence, your insights, and...

Michael Kimsal: My good looks.

Manuel Lemos: Yeah, those that appear on audio.

Michael Kimsal: I've got a face for an audio podcast.

Manuel Lemos: Right. Well, that's all for now.

Michael Kimsal: Well, thanks.