Developing JavaScript – Kangax

by Brian Moschel

Developing JavaScript – Kangax

Brian 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.

posted in Development on February 3, 2010 by Brian 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
on Ajaxian.

Living in Russia for most of his life and dropping out of college, he
has an interesting background. Even more surpising, 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 ( was one of
the first app-like websites that we have built. Then there was a
Wehike (, but that wasn’t an
application – just a plain, very minimal, website. I recently worked
for Aptana ( together with
Ryan Johnson (,
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:

  1. 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. )
  2. Verbose API, lack of relatively basic functionality (which HTML5
    is trying to fulfill now), methods are not chainable?
  3. 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

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!

CanJS 2.2 Release

Justin Meyerposted in Development, Open Source, Uncategorized on April 5, 2015 by Justin MeyerCanJS 2.2 is out. It's awesome. This article covers the top 10 enhancements added since 2.1. Some of the improvements include Browserify and StealJS support, can-EVENT arguments, observable promises, and in-page automatically rendered templates. The article includes a lot of good JSBins to learn from too.

Getting Started with Cordova

Brian Moschelposted in Development on March 26, 2015 by Brian MoschelAt Bitovi, we’re big fans of building applications with web technologies and using build tools to target other platforms like iOS, Android, and desktop. This article will provide a quick guide to getting up and running quickly with Cordova.

Contact Us
(312) 620-0386 |
 or cancel