JavaScript development, design, and consulting.
Developing JavaScript: Kangax
Wednesday 03 February, 2010 by moschel
For this edition of developing JavaScript, I was lucky enough to get a response from a rising young star in JavaScript, Juriy Zaystev - a.k.a Kangax. He is a prototype contributor and his work is often discussed on Ajaxian.
Living in Russia for most of his life and dropping out of college, he has an interesting background. Even more suprising, he's only 23. I asked him to share how he got into JavaScript:
About 2 years ago, me and my friend were making our first website for a local high school hiking club. My friend somehow bought a Professional AJAX book by N. Zakas, but eventually ended up doing back-end in PHP. AJAX was kind of a new big thing back then and I decided to see what it is. Since I had zero experience with Javascript, AJAX book was pretty confusing, and so I started digging more into the Javascript language itself. Short after that, I read an article by Sitepoint about Javascript frameworks where author recommended Prototype.js as the best option at that moment and so I started digging into Prototype.js. About a year after, me and that very same friend hakunin decided to make a little website that would serve as a repository of all Prototype.js-based extensions. That's how Scripteka was born. I also started writing Prototype.js tutorials on my blog. A couple of months ago I became a core member of Prototype.js and still serve my daily duty through the numerous tickets on Lighthouse : )
Here's a taste of what he works on:
Scripteka (scripteka.com) was one of the first app-like websites that we have built. Then there was a Wehike (wehike.net), but that wasn't an application - just a plain, very minimal, website. I recently worked for Aptana (aptana.com) together with Ryan Johnson (livepipe.net/), implementing front end of some of their redesigned sections. Other than that, my full time job involves intranet-based apps, and none of them are publicly available : (
His most visible work is prototype's changlog.
Question 1: What programming paradigms do you use - Class / Prototype based inheritance, AOP, Functional Programming, etc?
I'm a bit of a performance freak and this, of course, reflects on the way I design applications. I try to stay away from patterns that provide real private members, since memory consumption is usually more important. Pseudo private members (i.e. those that begin with underscore and are documented as being private) work pretty well for us even in large applications.
Functional programming is definitely handy and often makes for quite elegant solutions. I absolutely enjoy it once in a while.
Other than that, proper class/object hierarchy and overall architecture definitely needs to be thought through. In my experience, any kind of inheritance emulation usually makes application simpler to understand and maintain.
I asked him to elaborate where functional programming has been useful:
Prototype extends `Function.prototype` with plethora of useful additions - `bind`, `curry` and `wrap` are one of the most helpful. Both `bind` and `curry` allow for a partial application - when different functions can be made out of one - by currying original with different arguments. Bind, of course, allows to specify within which context function should be called. `wrap`, on the other hand, allows to program in AOP style - wrapping functions with before and after behavior. `wrap` is also useful for monkey-patching core methods without ever touching library source. I'm always cautious when using these helpers - additional level of abstraction is useful but deceiving, and can easily kill performance pretty badly.
Question 2: What architectural patterns do you employ - MVC, SOA, Layers, Components / Widgets?
Service oriented architecture works out quite nicely for us. I wouldn't say it affects client-side design much, though. I haven't tried MVC approach on client-side either. Perhaps our systems are not large enough to fully take advantage of all aspects of MVC. Widgets, on the other hand, are a great way to encapsulate distinct pieces of functionality. I think DOM would be a great foundation for widget-based systems if it wasn't designed and implemented so poorly; Instead of taking advantage of it, DOM usually needs to be thought of as a quite hostile and unpredictable environment - all for achieving maximum compatibility.
I asked him to follow up on what is implemented poorly in the DOM and how he would improve it:
- Careless resolution of named elements via document or global objects (i.e. when `form` with name=getElementsByTagName shadows native `document.getElementsByTagName` method, etc. I'm still not sure how they managed to f*ck-up like this. )
- Verbose API, lack of relatively basic functionality (which HTML5 is trying to fulfill now), methods are not chainable
- Gaps in specification (and vague explanations here and there)
Question 3: How to you manage event handlers and responding to them?
I use event delegation where appropriate, of course. Also, having some kind of way of simulating mouseenter/mouseleave is a must.
Question 4: Dom Building - how do you build HTML?
I use templates often - chunks of markup presented as strings - which are then interpolated with proper values at runtime. I find this to be the most maintainable way to deal with DOM creation/modification.
Question 6: Testing - what level of testing do you do? What tools do you use?
I should definitely be doing more testing : ) I find it hard to test applications that change often and usually resort to just unit-testing separate widgets/scripts.
Question 7: Compression & Build - Do you compress your JS files, what do you use?
All assets are pretty much always gziped; I don't see a reason not to do so. Everything else depends on a project. Rails, for example, concatenates all .js files when set up properly so we take advantage of that. Minification, on the other hand, is usually not much of a high priority.
Question 8: What development methods do you use - Waterfall, Agile, V, Story based, Requirement based?
I work in a very small team where we have a very transparent and flexible communication process. We try to stay more on a side of agile than that of a waterfall.
Question 9: Documentation - Do you document your code? What tools do you use?
I try to document as much as I can. jsdoc is a perfect tool for that. I'm looking forward to using PDoc in the future (developed by one of Prototype.js members - Tobie Langel)
Question 10: File Structure - Do you have a standard file structure? What does it look like?
No standards really. Usually depends on the server-side framework in use.
Question 11: Performance - How do you tackle performance issues?
I constantly experiment - try to test alternative methods of doing things - finding more efficient solutions. It's a lot of fun. I try to build apps with performance in mind right from the scratch. I'm not a big fan of build first - optimize later way of thinking. While it certainly has its advantages in building something fast, I think there's a danger of designing a system with poor core components - something that could be really hard to optimize in the future. Oh, and reading ECMA specs are an absolute must and gives an amazing understanding of what kind of beast Javascript really is!
Subscribe to:
- Jupiter
- Open Source