I’m a 24 years old Computer Engineer that used to have my own software start-up, called Solucione. 5 months ago I received a job proposal from Globo.com, the company I’m working on right now. It’s the internet division of one of the biggest media companies in the world. It’s being awesome to work there.

My first contributions started about 2 years ago on lighthouse (here), commenting and creating test cases for tickets. Then I started pushing some code to my Mootools-core and Mootools-more forks and reporting them on lighthouse. The first time my code got merged was an improvement on the isLeapYear function from more’s Date (here). I got really excited when i saw that being merged and, as I was working with it and loved it, I couldn’t stop seeking for something to do for the project.

It’s the framework that fits my needs and philosophy. As it’s all modular and uses it’s Class abstraction on the modules, my code was always better and more extensible than when I used other Javascript libraries (I tried jQuery before). Using Mootools I saw that I could organize my projects better and reuse code easily. Not to mention that when I started studying the code of the frameworks I liked, I really felt in love with Mootools and made it my number one choice

At the moment, I'm working as the Frontend Engineer of Globo.com's main page, and the entertainment page. Can't tell more details, sorry.

At Mootools, I'm one of the developers from the Slick team, which maintains the awesome, super fast selector engine and CSS parser that shipped with Mootools 1.3.

While programing on my free time, I maintain my own open source projects:

• Meio.Mask
• Meio.Autocomplete

I’m mainly a Javascript developer, so I’m involved on some other javascript projects out there, like jQuery that I use on my work. jQuery is a very good tool, is easy to learn and is the number library in use on the web. Of course I prefer Mootools and i’m working on using it at least on the projects I’m working, but it’s not that simple to change the way Javascript is done by a company with 100+ developers.

The 2.0 part of core that is done right now and is being improved is awesome. It includes a better and more reliable implementation of Fx.Morph, reworked and easier to use Request Class, integration of the Element.Dimentions module with the Element.Style module which will simplify the development, builtin event delegation and more!

Besides core, there’s a work in progress demo page by fakedarren, that will decrease even more the time needed for the developers to run the code they need.

An official UI project would be cool too. There are lots of great Mootools UI components out there, but would be nice to see them together, sharing they’re internal architecture. There’s a project heading this way, called mootools-ui, that uses the great A.R.T. SVG/VML abstration library, but it needs a page and documentation.

Hard question. I dunno… really. I really love everything about it, the community, the code, the fun i have while contributing

Maybe i would be doing something related to oil and robotics, as it was what i saw on the university.

Never stop learning, do not stick with the first framework/library you developed with. Check their codes, learn from them and contribute back!
There’s always a way you can contribute:

• Answering questions and giving ideas on the mailing list and IRC;
• Creating tickets and test cases for the existing ones (https://mootools.lighthouseapp.com/dashboard);
• Creating specs for a new feature or an existing one that you think is not well tested (checkout the Specs folder on the project to see examples of specs, they are very easy to do);
• Blogging about Mootools;
• Code/Documentation contributions;
• Telling your friends how awesome Mootools is [:P];
• lots more, etc.

Website – mootools.net. Plugin? Meio.Mask [:P]

1. Mootools.net – http://mootools.net/
2. Ryan Florence’s Blog – http://ryanflorence.com/
3. David Walsh’s Blog – http://davidwalsh.name/
4. Aaron Newton’s Blog – http://www.clientcide.com/
5. Jsfiddle – http://jsfiddle.net/

Visit my blog, it’s a little outdated but there are some great articles out there.

// 1
$$("#someid div.something");
// or 2
document.id("someid").getElements("div.something");

• If the browser has the querySelectorAll method, the Slick Engine will detect it and use it right away, lightning fast
• If the browser does not have it, in short–it will do document.getElementById(‘someid’).getElementsByTagName(‘div’) and for each of the found nodes, it will check for the existence of the class ‘something’.

• For every browser, it will grab the element with id ‘someid’;
• Then, if the browser has querySelectorAll, it will use this method to grab all the divs with the ‘something’ class from the ‘someid’ context;
• if the browser don’t have it will use the getElementsByTagName(‘div’) method from the ‘someid’ context and for each of the found nodes it will check for the existence of the class ‘something’.

So, as seen, first one will be faster for most of the browsers and is recommended.
From the time of this interview Firefox, Safari, Chrome, Opera and IE >= 8, have the querySelectorAll function.

You just gave me an awesome idea for a blog post

I’m a software developer and graphic designer from Manila, Philippines.

MooTools has always been my framework of choice, but I actually got involved with the community later than most of the early adopters. It was mid-2008 when I started hanging out in the official IRC channels, and that was mostly an accident. I was doing early contributions to Appcelerator Titanium back then, and I had the idea of porting Snippely (an old MooTools project from Valerio and Tom) to Titanium. So I went to the IRC channel to ask for permission to port.

Around the same time as my appearance, Jan was working on a project called Fire, which was a MooTools extension framework for Adobe Air. Since I had some experience with Adobe Air, Jan asked me if I would like to contribute to the project, to which I agreed. We worked on the project for a few weeks but we abandoned it at the end due to being too busy with other stuff. However, the project forced me to be constantly online in the channels, and I’ve never been away for more than a few days since then.

Eventually, I got the idea of writing a series of advance MooTools articles for my blog, and that eventually became the Up the MooTools Herd series which really started my community work.

There are two kinds of JavaScript frameworks available today: those that rely on abstraction and those that rely on extension. Frameworks that rely on abstraction are very easy to spot, since they produce code that look nothing like native JavaScript. They stick out like a Java class declaration in the middle of an Erlang source file. Extension frameworks, on the other hand, are subtle; they blend in with the language and appear like part of the standard library.

MooTools is one of those frameworks that fall into the extension category. I really don’t see MooTools as a framework but rather as an extension to the language itself. MooTools is to JavaScript what Objective-C is to C: it’s not a new language per se, but a thin layer that adds features to the language itself. The fact that it implements both a Type and a Class system–both language level features–is a testament to this extension nature of MooTools.

This difference between abstraction-based and extension-based frameworks is important for people who actually love the languages they use. The more you like a language, the more you’ll tend to lean towards frameworks that magnify rather than mask it. You’ll want to work more closely with the language in terms of syntax and philosophy–and burying it under heavy (and often leaky) abstractions would simply be daft.

I’m working on a lot of stuff, most of them related to MooTools and CommonJS. Perhaps the most exciting of them is Meso, which is a cross-engine MooTools library for CommonJS. Another thing that’s keeping me busy is Deck, which is an HTTP Server layer that runs on top of Meso.

I’m quite involved in a lot of things, at varying extents. I used to be very active with Appcelerator’s Titanium platform, but my involvement tappered off a bit because of work. I’m also experimenting a lot with Apache’s CouchDB and Steve Dekorte’s VertexDB, and I plan on hacking the latter in the coming weeks for a project I’m building. And of course there are my own projects that I’m working on together with other MooTools devs.

Depending on when this interview is published, the book would either be coming out in a few days or has already been released. I’m quite happy with it, although I would really like to expand some chapters in the future. Print publishing places very big constraints when it comes to writing time and publishing dates, and that really affected the book. I do think it turned out good, although–like many authors–I do believe that there is a big room for improvement.

Whether or not “less advanced” MooTools users will benefit from reading the book is totally up to them. After all, the MooTools source code has been open-source from the start, and there’s nothing about MooTools in this book that you won’t learn just by reading and examing the source code. If someone really wants to learn MooTools from the inside, all they have to do is look through the source code–they don’t need my book.

It’s also not my intention to promote coding standards and best practices in this book, since it’s not a book about how to develop with MooTools. It’s a JavaScript book that examines MooTools internals to help people understand what’s going on inside the framework. The goal then is to give people a starting point in exploring the capabilities of MooTools. How they apply what they learn from the book is totally up to them.

I believe that things are just gonna get better. Even though HTML5 is uttered like a buzzword these days, the attention its been getting represents a very real acceptance of the technology from the people–not just from the web community. It’s reflective of the excitement everyone has for a better web ecosystem.

JavaScript will remain the de facto language of the web. You might think that I’m happy about this, since I like JavaScript, but it also saddens me a bit. I do want to see something like Native Client to succeed, if only to add some healthy competition on the client-side. But I don’t think that this will happen any time soon, as most browser vendors have disregarded the technology–explicitly and implicitly by not commenting on it.

Server-side JavaScript will continue to grow, but it won’t take over anything. In as much as we JavaScript people would love to think that SSJS would conquer the whole of the server-side, the truth is there are already a lot of established languages that have been offering what SSJS is selling–and a lot of them are way better at this. Fans of the popular SSJS engines like to think that they’re using something novel, but most of the ideas that these new engines are touting are simply JavaScript rehashes of things already included (by default or by extension) in other languages. JavaScript is only playing catch-up.

One advantage of SSJS, though, is the fact that JavaScript reigns supreme (for now) on the client-side, and it’s the only language that can actually claim to be *realistically* usable for both the client-side and server-side. This is why I support CommonJS as a whole rather than individual engines, because CommonJS represents an ideal rather than a solid API. Getting bound to a new-fangled engine’s APIs is dangerous once the hype dies down.

For MooTools Core, I’d personally want to see it split up into two main projects: one for ECMAScript and one for JavaScript. This is needed if MooTools branches out into the CommonJS space in the future, since CommonJS by default is more concerned about the ECMAScript rather than the JavaScript part.

I’d also like to see some additional metaprogramming APIs for Core. The biggest strength of MooTools is its extensibility, and I’d love to see some of the internals exposed via safe APIs. This will benefit those who’d like to extend MooTools without touching Core.

I’d probably be running around the office right now looking for my editor to get him to approve my story for next morning’s paper.

There are a lot of factors, really. For one, it still depends on the people. As more and more developers start building more complex applications, the bigger the need is to use the proper tools for the job. MooTools is a very good framework to work with, since it can actually scale pretty well–but even that depends on the person using it. Not everyone who touches a paint produces a Picasso.

And even if people start flocking towards better frameworks, it does not mean that they’ll automatically choose MooTools. MooTools is awesome, but it’s not the only awesome framework. There are other scalable and well designed JavaScript frameworks competing in the space, and MooTools is simply one of the choices.

Be a scientist. The developers I respect and admire the most are those who always feed their curiosity, are always hungry for new information and are always exploring. They don’t sit around and wait for someone to answer their questions; they find out the answers for themselves. They experiment, they observe, and they share their results to the world.

The official one.

- Google (with proper search keywords).
- Reddit and Hacker News, or basically any site that aggregates a lot of stuff.
- The documentation for the technologies you use, and their source code.
- The documentation for your text editor.
- Your creativity.

All my public code are available on Github (http://github.com/keeto/)

I am 21 years old and I live in the wonderful city of Graz in Austria. I am a student of Software Engineering and Business Administration at the Graz University of Technology. I would define myself as (Mobile) Web (Application) Developer and I am active on the Internet for as long as I have a connection – that’s about ten years now!

When I started with web development I started using JavaScript. I didn’t learn the language at first but when JavaScript and XHR got more widespread adoption later in 2005 I started building my own little animation library. Shortly after I found moo.fx and I became a frequent reader of the mad4milk blog – the place where “moo.dom” and “moo.ajax” were released which eventually lead to MooTools. I was a MooTools user since the famous 0.87 version and I remember bugging Valerio to include “DOMReady” back in the days. I stuck around and got to know the core developers but only a few years later I started to actively contribute and eventually I became a member of the Core Development Team.

The module that got me using MooTools was Class.js. Back in the days we didn’t even have inheritance or mixins but given that I was unaware of the prototype-based nature of JavaScript, Class made me feel like home. Ever since, I love how MooTools works, the abstractions and the clean code, just great. However, at the moment, the most important part about it is our community. I actually got to know and got to meet a lot of the MooTools developers and they have all become great friends.

Right now I am doing lots of probability theory, object oriented analysis, data structures and algorithms, software architecture and information security related stuff. That, of course, doesn’t have anything to do with MooTools but during the semester I don’t have time for anything else really. But fear not, in the web assignments I am of course making use of MooTools (and PowerTools! ). Recently I did some experiments with DeviceOrientation and DeviceMotion on iOS 4.2 (see http://twitter.com/#!/cpojer/status/7485711225716736).

You can usually find me doing work around the JavaScript eco-system. Therefore I am involved in a number of minor projects, nothing similar to MooTools. I am involved with GitHub. It makes the development experience so much better and more fun – it is easy to contribute to almost anything.

The goal of PowerTools! is not to make MooTools mobile compliant – MooTools works great on mobile devices already. One part of PowerTools! is the mootools-mobile project, which brings custom gestures and more for your mobile web app. PowerTools! is about providing low-level MooTools extensions or HTML5 related plugins that help you speed up the development process or to make your code more maintainable. As far as mobile is concerned, yes – mobile browsers have a lot of catching up to do, but we will get there. The mobile web is definitely important. PowerTools! is currently standalone and there are no plans to officially include it with MooTools. I don’t want to bloat our beloved library

Oh well, there are a lot of buzz-words in there. I honestly have no idea, unless you have time to read five different scenarios on how the future might turn out? Haha, I thought so. Seriously speaking, it’s difficult to say. I think its reasonable to say that the amount of abstractions will increase and a lot of things will get easier even though under the hood they become much more complex. It’s just the beginning. And also, it’s just JavaScript.

MooTools 2.0 of course! The whole thing will blow your mind, once its done of course

Well, that would mean I would not be involved with anything related to the Web. I’d probably just go for a BA masters, but that would be the most boring thing… In any case, without MooTools my life would be very different, not nearly as awesome as it is right now and I wouldn’t have made so many great friends – I am really grateful. Also, the word “Ping!” would not make me laugh, Djamil wouldn’t be a funny person and ketchup would just be ketchup.

**editor** [1] to fully appreciate what he’s saying, you really have to see the MooTools core team eat burgers, chips and ketchup, or rather, have some food with their ketchup. Failing that, you can always login to IRC and “ping” cpojer, he loves it!

The numbers vary, I am not so sure about their correctness. MooTools is being used a lot behind the scenes – in huge internal applications. That is where I see MooTools. If you want to do serious web applications, MooTools is the obvious choice. Given that we are moving to a “Web of Apps”, MooTools has a good starting place. Let’s see where the journey will go.

What I have found is that most Web Developers still do not have an idea of what they are really doing. My advice is to learn the core concepts, learn about how the Web works, learn about object oriented languages, learn JavaScript. If you know the basics it only gets easier and a whole new world opens up every time you learn something new. MooTools can help you hide the complexity behind JavaScript and makes it easier to get started. Also, don’t be afraid to ask questions. It is what I do all the time when I want to learn something. Join the #mootools IRC channel on Freenode and ping me (cpojer), I’m happy to help!

I don’t usually have one. If you want to learn MooTools then go to David Walsh’s (FTW) website http://davidwalsh.name/ – also, the site is awesome for using the hover-effect on links which I created Some people claim David stole them, I refuse to believe that.

GitHub. MooTools.net. PowerTools!. NetBeans. Chrome Web Inspector.

I am a father, an aquarist and a web developer. I enjoy designing and maintaining my never too big “nature style” aquarium. I like watching my children grow and learn. I also like free stuff a lot. That’s why I created jsFiddle and didn’t hesitate too long to join Mozilla Team.

I started programming when I was 19. It was Turbo Pascal on XT’s and AT’s. At university I realised I like Gopher, IRC and FTP. Then in our university library someone placed 3 public computers connected to the new thing called World Wide Web. I was usually not consuming the content, but looking at how it was build. Soon I had my own website…

I was hired by Moving Picture Company to create an intranet tool for movie management. They gave 10 working days to find out the best technology for the front-end. On the back-end Django was set from beginning. I was investigating all possible JavaScript frameworks and MooTools was something which I found the best, although I didn’t know anything about it at day 0.

Classes, clean code, ability to shape things in a way developer wants. I found a lot similarities to Python which is good as I write back-end in this language. I think it’s the best tool for someone who writes code, not only uses plugins.

I’d like to make Accordion better. It is considered as a bad UX, but I can’t imagine jsFiddle without it. I also started to rewrite jsFiddle – beta is coming (we aim for January). There is also another launch coming at Mozilla. We would like to have the Addon Builder 1.0 ready for the Firefox 4.0.

FlightDeck is open-source (as whole Mozilla), otherwise nothing I could call “involved”.

I needed it. I would guess it’s the most honest answer for majority of start-ups. I was on #mootools IRC channel and we were helping new users with JavaScript/MooTools issues. We were even playing who will answer first, but the rule was – code has to fit in one line. Soon there was a question which was longer then that – although we do have pastebin I wanted to check if my idea was right before posting. I thought creating file with right DocType, including files and then loading into the browser was too much trouble. The question remained unanswered, but the next day I had a working prototype.

Just as a side note – jsFiddle wouldn’t be as awesome if not help from Oskar Krawczyk who is the “front-end guy” and other members mostly around MooToos community. Thank you all very much.

Back-end is all Django, MySQL and memcache. It still uses Apache, but I think beta will run from within Nginx or something similar. On the front-end we do use MooTools with a bunch of plugins such as ClientCide. CodeMirror is highlighting the code.

Yes – mooShell will be closed when jsFiddle beta will start. It is currently in read only mode. I am still uncertain what type of license should I use for the new jsFiddle. It is a rewrite… I’d like to make it open source, but the business model I have in mind might be against it.

I think the most awaited is user profile with ability to personalize jsFiddle – change editor application (there is a choice now!), the way it displays code, manage the framework drop down, etc. We will also add PRO accounts with many features around private fiddles.

This is a hard question – it’s mostly the community behind the project. We tried to add every framework which is a “must have”. There are few exceptions (like Processing js or Raphael which aren’t even frameworks), which we simply wanted to use. Beta version will be more specified and with the ability to tweak the “hot list” we will be able to implement much more frameworks. Some will be simply hidden by default. I am also adding the “Framework manager” badge. Users with such privileges will be able to maintain the framework – upload/link new versions, add best plugins, etc. More power for the users.

The way the dependencies and frameworks are bond together is wrong – this is invisible for the end-user, but adding new version of the framework is currently a pain.

On the front-end side – it would be fixing the layout for small touch screen devices.

I had a few other ideas in mind, but these needed much more work on the beginning, which is a pain for free projects – not enough hype.

“Jetpack” is a working name for the new Firefox add-ons type. Firefox 4 will have it build in. It allows to install add-ons without restarting and is really easy to write. CommonJS style. SDK currently uses Python (I think it will use NodeJS in the future) and involves some work to be done to install on the developers computer. Mozilla thought it would be good to make this a lot easier and the idea for Addon Builder aka FlightDeck arised. It could be name jsFiddle for Firefox Addons. Users are able to edit and test addons without leaving the browser.

JavaScript developer to me is a person who writes the code – classes, plugins. The knowledge of vanilla JavaScript is essential. So the tip would be – learn vanilla JavaScript. If I would be able to give another it would be: read framework’s code. It is interesting and enlightening.

Github, documentation sites from framework developers, VIM, IRC, Linux, Twitter. I don’t need much

It would be http://webdev.zalewa.info/. It’s a really old site, half of the examples there are from the time when I thought I could be a web designer, but clearly I’m not made for it. I guess you’ll find quite a few 404 on it as well.

My name is David Walsh and I’m a 27 year old Web Developer living in Madison, WI. I’m a self-taught developer that is obsessed with learning everything there is to know about front-end web development. My expertise is in HTML, CSS, JavaScript, and PHP. I work with jQuery, MooTools, and Dojo on a daily basis. I don’t design the websites, I make them work.

My first exposure to MooTools involved a project that required smoothly animated elements. I found jQuery and its animations where laboring to say the least. MooTools’ animations were as smooth, efficient, and the the syntax was logical. From there I was hooked. I started a blog to share my findings and experimentations. I got better MooTools and started getting noticed by the community. A few commits and dozens of blog posts later, I was asked to join the MooTools team. Joining the MooTools team is one of the proudest moments of my career.

MooTools is special for several reasons. The MooTools API is as coherent and logical as you will find in a framework of any language. The code is as well written as you’ll find. MooTools is modular, efficient, and provides an outstanding inheritance pattern. The MooTools team cares about its community. MooTools isn’t about marketing itself and begging for attention – MooTools is about outstanding code to create dynamic, fast websites. MooTools is magic!

Per the framework itself, I always have two goals: making the community aware of new features and strategies, and creating useful, well-coded plugins to display the power of MooTools. I don’t spend much time on committing to the repository other than quick fixes and documentation updates – my strength is spreading the good word Moo.

I work for SitePen so I occasionally commit quick fixes to the Dojo Toolkit. I write exclusively about open source projects on my blog, and give my code away for free.

I work so hard because I love JavaScript, MooTools, and its community. Let’s face it – we’ve all faced a technical problem that we’ve needed to scour the internet to figure out. Most people find their solution and move on. I’ve vowed not to do that – any solution to a complex problem that I find ends up on my blog so that other people don’t need to suffer the same pain that I did.

Per the MooTools project specifically, I strive so hard because I’m so passionate about the project. I love the codebase, respect the hell out of the developers creating the code, and appreciate the MooTools community. I could write a million blog posts about MooTools and not feel I’ve given as much to the project as its given me. MooTools FTW.

The motive behind writing code to accomplish similar tasks with each framework is to show my readers that, in the end, it’s just JavaScript. Dojo, MooTools, and jQuery are very different but in the end, they’re just an abstraction of JavaScript patterns and APIs. I also do it to show developers the different coding patterns available and the differences in syntax.

What’s important, more so than preferring one framework over another, is find the framework that best fits a project. You can love jQuery but what if it’s not a great match for a specific project? You’d be wasting time using it. In the end though, if all things are equal, I’d use MooTools before any other project. Extendible, compact, logical… those are what MooTools is all about.

The future is looking up! Let’s be honest: the reason we create (and use) CSS and JavaScript frameworks is because the tools we need aren’t available at the present time. HTML5′s markup rules bring us back to a more common-sense approach, and its new JavaScript APIs like WebSocket, classList, and storage APIs are outstanding. V8 and server-side JavaScript are also exciting – imagine writing and entire website, front and back-end, in just JavaScript! MooTools works on both the server and client side which is even more exciting! WebKit-based browsers continue to amaze me – the capabilities they provide, especially with CSS animation, are percolating. Using CSS-driven animations instead of JavaScript animation will lead to faster, smoother interfaces. I’m excited to see what’s next!

I would like to see some of the MooTools 2.0 features incorporated ASAP, including CSS animations and the unified Fx timer. These features have been coded but not implemented so as to not create such a jump in upgrading. There are many other features in the 2.0wip branch that I would love to see implemented. Unfortunately, now is not the best time to release these features due to other API changes that would be required.

I owe much of my career advancement to MooTools. MooTools ignited a fire the fire which made me dedicate my career to JavaScript and front-end development. I’d likely be working at an average Web Development shop, waiting for the clock to hit 5:00.

Like other web technologies, MooTools’s future is nothing but up. Our development team continues to grow, as does our loyal, intelligent community. As far as features I’d like to see, I’d love to see a Dijit (Dojo Toolkit) UI competitor created for MooTools. I’m also hopeful that the Forge continues to grow at its current pace – it’s a treasure chest of great MooTools plugins!

My tip would be this: when you create a plugin/class, take a step back and ask yourself:
`Can I make this class more generic so that it could be used for other purposes?`
If so, create that base class and use MooTools’s Extend/Implements methods to create your more specific class. MooTools is founded on flexibility – learn how to properly use its inheritance methods and you’ll be an unstoppable programming force.

This will sound insanely vain but I have to say my own. I refer to my own website often to grab code I’ve posted in the past. I also get user feedback so I can improve my code. I also love the MooTools Forge – its code holds the value of Fort Knox.

A few people you should really be following if you’re into MooTools, jQuery, or just JavaScript in general:

Ryan Florence (http://ryanflorence.com/) – Ryan’s an outstanding JavaScript developer that writes interesting tutorials about jQuery, MooTools, and CSS animation. He’s the creator of MooTools SlideShow, Moo4q, and MooTools’ pub/sub plugin: Channels.

Kris Zyp (http://twitter.com/kriszyp) – Kris is a Dojo committer, author of the JSON Schema spec, and creator of Persevere, a server-side JSON technology. Kris is a JSON guru, server-side expert, and overall JavaScript nut.

There are a billion more plugins left for me to write! I’m hoping to write a Facebook photo-tagging clone soon, as well as anything else I see that tickles my fancy. Wherever there’s an idea there’s a MooTools plugin to write. There are only two limitations to MooTools plugin creation: inspiration and time. I could write MooTools plugins forever!

I’m not big into self-promotion, but a few of my more popular posts and MooTools plugins include:

• ScrollSpy – A MooTools plugin which monitors scrolling to fire events based on page position.
• LightFace – A Facebook Lightbox clone which handles AJAX, IFrames, Images, and more.

If you want to see what I’m all about, visit my blog: http://davidwalsh.name

‘Ninja’ is a lame term to try to make JavaScript development seem exciting to outsiders. In any event, the boom in JavaScript popularity is nothing but exciting. More bright minds to solve client side problems is a boost to JavaScript development and provides more ideas to the development pool. JavaScript is the future of web development.