> and then wait a few weeks -- and more -- whilst your developers add
more spaghetti, and debug.

That is bad development.


> I think this is where we get to the nub of it; is it just a case of
using modules and objects? My suggestion was to use declarative
mark-up like XForms which decreases maintenance and increases
development speeds by an order of magnitude, way past OO techniques.

Oh, I am not at all against declarative development.
I think concepts/techniques should be used according to their
aplicability.
And if that means to write a class then I will write a class.
If it means to use XFORMS I will use XFROMS, if it is XBL then let it
be XBL. Whatever is the better choice.

But that does not change anything about JavaScript.
Not that I am a fan of JavaScript as a language, but one can still
write clean code with it and also build large apps using it.


> <xf:input ref="name">
> <xf:label>Name:</xf:label>
> <xf:hint>Enter your name here</xf:hint>
> <xf:help>This is where you would enter your name</xf:help>
> <xf:alert>You must enter your name</xf:alert>
> </xf:input>
>

You still need an XFORMs impl. and something that renders it.

BTW in script the above decl. would be
inp = new Input("name");
inp.label = "Name:"
inp.hint = "..."
...

It's just a different way to declare it, you still need something that
can handle the inp. obj. As you need something that can handle the XML .


> Now, we might want to render this using SVG, in which case we need
to write
> a 'hint' object, a 'help' object, a 'label' object, and of course an
'input'
> object for our system. But they're pretty easy, and once they are
done, you
> can then concentrate on using your declarative mark-up to build
complex UIs
> that are far easier to maintain.

I agree with that very much.
I used this approach in a couple of projects, e.g.:
http://jan.kollhof.net/projects/svg/playground/superformula.svg

it uses namespaced custom elements which are transforemd to some path
data after the document is loaded.
In some projects I use JS to do the transformation and in others a
combination of templates written in XML and some JS to take care of
the bindings. It works realy well.

We will get sXBL, so we will have a standard way of taking care of
those binding and transformation issues.

> It's very impressive, and none of what I am saying says that
libraries such as this aren't useful. But to build large
industrial-strength applications, rather than web-sites, I think we
need to move to a new generation, and a new approach.

So your problem is not that you have 12,000 LOC to manage but that
it would have not been 12,000 lines of code if using a different
approach, for example using techniques like XFORMS or sXBL or ... ?

Maybe I misunderstood your initial post.
I thought it had something to do with wether large
projects can be developed with JS or not.
I am sure one can but should use whatever is most apropriate.



Jan