Last week, we launched a Prototype Linkedin group, which, as of this writing, has more than 300 members. This was the occasion to get back in touch with a lot of people from the Prototype community, and to launch a project we’ve had in mind for a long time: regular interviews of developers and designers working with Prototype.

Today’s interviewee is Sergio Pereira.

Your name is familiar to most early adopters of Prototype, but recent passengers on the Prototype bandwagon might not know you. Could you please introduce yourself?

Sergio Pereira: Sure. I’m a software developer that has been paid to do that since 1997. Web development became the majority of my work in 2000 and that’s how things have been ever since. I have done some ASP classic, a ton of ASP.NET, some Ruby on Rails, and a tiny bit of PHP. ASP.NET still pays my bills, but I feel like RoR may be in my future.

When Prototype was still in its infancy, you were the first to document it. What was your motivation? What did you learn from it?

SP: A friend of mine pointed me to the old Protoype page and, after perusing its source code, I asked the obvious two questions: “Is this really JavaScript?” and “What’s in this library?” I decided to take some time to study and understand the code. I knew I was not the only one that had a very superficial understanding of JavaScript, so I decided to take notes while I dissected that code and these notes became two different documents: Developer Notes for prototype.js and Quick guide to somewhat advanced JavaScript. I also helped that I was learning Ruby and RoR at the same time and I benefited a lot from writing those docs. I still get a lot of hits and some emails about the articles. I hope they’ve helped somehow.

Most of your work involves .NET. While we were preparing this interview, you mentioned witnessing a lot of changes in the .NET landscape, notably with the introduction of ASP.NET MVC. Can you tell us a bit more about this and how it affects Prototype?

SP: ASP.NET development, traditionally, involves less HTML and JavaScript manipulation than, say, PHP and RoR. That’s not necessarily bad. It’s actually viewed as a good thing by most ASP.NET developers. Do you want a table with AJAX-ified sorting, pagination, in-place editing, etc? No big deal, just drag one from your toolbox on the design surface of your page and bind it to the data source and there you have it.

As TDD [Test-Driven Development] started to get greater adoption in .NET, the cracks in this style of development became apparent. Testing ASP.NET pages (the so called webforms) in isolation is impossible — or, at least, hard enough to become impractical. The Rails-inspired Castle MonoRail project gave us a glimpse at how to properly structure a web development framework to support separation-of-concerns and inherently enable TDD.

In October of 2007 Microsoft revealed that they would be offering a similar solution in ASP.NET as an alternative to the existing webforms style. This alternative is called ASP.NET MVC. The creation of a view in ASP.NET MVC is closer to that of ERB, where you define your UI much closer to the HTML than in webforms. That implies abandoning a lot of the pre-packaged components that we have in webforms and looking at alternative ways to get the same things done.

That’s where all these new JavaScript client libraries are becoming popular with ASP.NET developers. ASP.NET developers will soon go through the process of picking up a JavaScript library and adopting it as their company standard. Prototype and its surrounding ecosystem will undoubtedly be one of the most popular choices.

You’re mostly building applications for use on corporate intranets. How are you using Prototype in that context?

SP: Coinciding with my interest in Prototype in the last few years, corporate development has also started to demand richer, more productive UIs. I remember seeing the surprise in some of my users’ faces when they saw an InPlaceEditor from script.aculo.us and all the instant feedback provided by the use of Ajax.Request and Ajax.Updater.

For me, what I like the most in Prototype is how well it lends itself to building your own libraries. I was able to create my own business-specific libraries on top of Prototype with a lot of clarity and extensibility. And all that was at least one full year before Microsoft had their own AJAX support for ASP.NET officially available.

Can you elaborate on the libraries you’ve built on top of Prototype? Maybe share some techniques, patterns or concepts?

SP: For example, I was able to create UI classes (presenters if you will) that would bind to DOM elements and extend them with new behaviors, much like Draggables and InPlaceEditor do in script.aculo.us. In my case I created drop-down calendars and Ajax table paginators. I could extend Ajax.Request to detect session expiration and handle its unexpected server redirect.

I also added some more methods to Element.Methods that at the time (v1.4 or v1.5) I thought were useful, like:

Element#findParent('table');
Element#append('a', { href: 'page.html', className: 'navLink' });
Element#purgeChildren();

A lot of what I have written is now obsolete with v1.6 and that’s great. I can’t wait to finish the migration to 1.6 and reduce my code surface.

Any other tips you’d like to share?

SP: I don’t have any earth-shattering tips, but I am an advocate of Sharpening the Saw and becoming proficient in more than one language or platform. Basically try not to become content with the status quo.

You’re also writing training material for JavaScript classes. One of your forthcoming courses will be entitled Advanced JavaScript with Prototype and script.aculo.us. What are the things you emphasize the most in these courses? Which areas are the most troublesome?

SP: The main problem with developers trying to use JavaScript, in my opinion, is the tendency to compare JavaScript to Java or C# just because some of the most trivial constructs are similar. JavaScript is fundamentally different from these two languages. For many developers JavaScript is the only dynamic language and the only prototypal-inheritance language they work with — and most of the time they don’t even know what that means and why they should care. I also try to make sure we talk about treating your JavaScript code with the same attitude as your server-side code: documentation, unit testing, organization, coding standards, etc.

Anything you’d like to add?

SP: I’d like to leave a special message for any .NET developer reading this. Please don’t constrain your development to what comes bundled with Visual Studio or is downloadable from MSDN. Take a look at all the flourishing open-source projects out there. Check out ALT.NET when you have a chance.