launchpad-dev team mailing list archive

[Deryck Hodge <deryck.hodge@xxxxxxxxxxxxx>]

On Thu, Nov 18, 2010 at 4:37 AM, Jonathan Lange <jml@xxxxxxxxxxxxx> wrote:
> On Wed, Nov 17, 2010 at 10:12 PM, Ian Booth <ian.m.booth@xxxxxxxxx> wrote:
> ...
>> I guess from my perspective, based on my exposure to date to Launchpad
>> UI development, it's the lack of standardisation that is perhaps one of
>> the biggest barriers to effectively and efficiently jumping on board and
>> getting stuff done. This tends to happen on many large projects.
>
> Lack of standardization is a serious problem.
>
> What should we do about it?
>

We should fix our code to be consistent.  Right now, it's not easy to
look at our code base and work out how to do js.  When you do look,
you see a number of approaches.  When I started writing JavaScript on
lp, no one said "here's how we do js, look at this code, read up on
this style guide," and so on.

We need to make things simpler, too.  Here's a sketch of changes I
would standardize on:

*** stop trying to write JavaScript as if it's Python

    I say this as someone who loves both.  There are certain
    idioms to js that we avoid because they seem odd in Python.
    For example, assigning names that are a couple levels deep
    in the scope chain for performance reasons.

    var foo = Y.lp.foo;

    These type of idioms should be codified in our style guide.
    Clean up the guide and point people at it regularly.  Build
    our style guide on Crockford's style guides, the same way
    we build on PEP 8.

    http://javascript.crockford.com/code.html
    http://javascript.crockford.com/style1.html
    http://javascript.crockford.com/style2.html

*** stop using Python-generated JavaScript (or use only
Python-generated JavaScript)

    Unless we go the whole way of a GWT-like Python-generated
    JavaScript system, I think the times we generate js code from
    Python are not worth the mixed approach.  We should write js
    by hand and get data or structures via the web service.

    Of course, we could also go wholly the other way and write only
    Python that handles the js interactions for us.  I've not seen any
    Python lib do this well, so this seems a huge change, which is why
    I say write js by hand.

*** stop using lazr-js and move all our js work in tree

    I think lazr-js was a great idea initially, but it's an abstraction layer
    that hurts us at this point.  Widgets are over engineered at times, too.
    I suspect to justify their existence in an external lib.  Much of lazr-js
    could be re-written in less lines of code.  I don't think we share that much
    across Canonical projects anyway, and lazr-js is plain unusable by
    anyone outside Canonical.

    We should point to YUI as the standard and share code and
    examples across projects in a lighter-weight fashion.

*** make testing simpler and be explicit about how we test

    I've said much about this in the past.  browser testing is not unit testing.
    Our Windmill tests are terribly written.  And literally no one on Launchpad
    knows why we write them.  And it shows. ;)

    We should understand why we browser test, have a better tool for it,
    and insist on TDD via yui tests over CI browser or integration testing.


I'm sure there are other good ideas, but if we did each of these, the
JavaScript development story on Launchpad would be substantially
better than it is now.

Cheers,
deryck




-- 
Deryck Hodge
https://launchpad.net/~deryck
http://www.devurandom.org/