Jan-Klaas,

Great to see some discussion starting on how we might build these types of
applications.


> How is 12,000 lines a problem?
> I am not sure how many lines of script Mozilla has but the
> number is not small. The only problem I can think of is
> managability and maintanence of code and intensive
> calculations that just take too long in JS.

Are you arguing for or against, here? ;) The "only problem" is "managability
and maintenance"? One developer of large web-sites said to us that script
accounts for "90% of their headaches". Change a schema data type, add a
column to your database tables, translate a form into another language ...
and then wait a few weeks -- and more -- whilst your developers add more
spaghetti, and debug.


> Now, for the
> latter there is not much you can do besides optimizing your
> code or get a more performant JS impl.

I guess that depends on what the calculations are, whether they can be
factored out of the script.


> For managing your code
> use clean modularization(packages, ...) so you don't get
> nameing conflicts, can write module test routines, ...

With respect, my guess is that anyone who has a system that runs to 12,000
lines of script has already sorted out their naming conventions and divided
their code into modules!


> But that concept you would apply anyways even using another
> language. Call it packages or whatever. OOP consepts you can
> apply as well.

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. For example, the following
mark-up in XForms does an incredible amount of work:

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

First, it specifies where the value that the user enters should be stored --
in this case in an element called 'name', in the default instance DOM.

Next it says that there is a label for the control, as well as a hint. In a
visual system the hint will probably be rendered when the user mouses over
the control, but it could be triggered by the user pausing for more than a
certain amount of time on the control, etc.

The help text would be rendered to the user on receipt of a request for
help, which on Windows is pressing [F1], but again it could be something
else.

And finally, the alert message is rendered to the user whenever the data
entered goes invalid. The conditions for validity are not defined here, but
they might be that the text is not empty, and less than 200 characters, or
whatever.

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 myself have projects with a few thousand lines of code.
> And had no problem so far.
>
> have a look at:
> http://jsolait.net
>
> It is a JavaScript lib/framework for with package/module
> support, simplified Class construction mechanism and a number
> of modules for handling things like RPC, string formatting,
> HTTP requests, ...

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.
Regards,

Mark


Mark Birbeck
CEO
x-port.net Ltd.

e: Mark.Birbeck@...
t: +44 (0) 20 7689 9232
w: http://www.formsPlayer.com/

Download our XForms processor from
http://www.formsPlayer.com/