[
Lists Home |
Date Index |
Thread Index
]
we have our reasons, but for building cross platform, server driven
applications i'm getting a good result from a combination of xul/rdf/html
ie isn't the only game in town and one of the reasons we stopped using
it was that it can be just as frustrating as any other product.
so here's a couple of observations:
1. before the web we could build traditional terminal based, highly
functional applications at the rate of 2-3 complex data
entry/manipulation srceens per day; reports 1+ per hour
2. graphical (ie windows/x) programming we didn't go to because we
couldn't get the functionality of a server based solution
3. we based programming we used to augment the terminal sessions. the
equivalent of a low funtionality screen now takes 3 web documents and
about two days to build. reports, even with our xml report builders,
around a day.
so, since graphical and especially web programming became the norm we
have experienced a reduction in productivity of 5 - 10 times, an
absolute loss of functionality, and significantly increased development
costs.
in high functionality sites we still use terminal sessions for complex
tasks.
20 years ago i observed that any data solution that is client/server
must be slower and less functional. my experience bears that out.
there is a corollorary to this. today's applications have to be simpler
and dumber. we are finding success by building small applications that
do nothing, look good, and make customers happy. this is very
unsatisfying, but maybe it's the future.
i started on this list hoping for a way back to high productivity. i
haven't found it yet, but there is a glimmer of hope.
but really for my money, server based applications that can interact
directly and live with the database, and a thin client solution based on
xul or xaml that work effectively on low bandwidth devices is probably
where real productivity as programmers and users will come from.
i don't know if anyone's measuring productivity against technologies
allowing for complexity of the delivered application (as well as lines
of code) but i would be interested to know if my experience is common,
and i'd be interested in hard facts (not marketing) on the impact of
things like xml on the same problem.
rick
Didier PH Martin wrote:
>Hi Eliotte,
>
>
>
>
>>If a group were to deliver a browser that radically lowered the cost
>>of development and enabled new applications with better user
>>interfaces, it would be adopted widely, despite being incompatible
>>with the existing installed base. No, you wouldn't be able to use
>>these technologies on the public Internet, but it would nonetheless
>>be a huge advantage for any company or organization that provided
>>such a solution. Sadly, the only browser company that seems willing
>>to provide new functionality that goes beyond the past is Microsoft.
>>Opera and Mozilla seem have confused their inability to pass
>>Microsoft on the Information Superhighway with an inability to follow
>>a different road to a different destination. :-(
>>--
>>
>>
>>
>
>yop! very true. In my daily practice I see a lot of intranets using IE
>simply because it offers more then the others. For instance, the other
>browsers still do not allow augmenting the default behavior. To be able to
>separate the code from the declarative statements improve code re-use and
>therefore reduces costs. Moreover, you can transform an XML document on the
>client side into HTML and tag element to be "editable". Hence, only some
>parts of the displayed document are editable. And on and on....
>
>W3C seems like a parliament too far away from practical needs and caught
>into political vested interests or simply jammed into ethereal dialogs.
>
>This said, it seems that Mozilla came back to life and is now improving,
>which is no longer the case for IE. If mozilla brings a good run time
>environment for intranets apps, then things may change and we may have an
>alternative option to XAML/IE/longhorn. Mozilla teams should listen more to
>developers needs and less to W3C in order to succeed.
>
>Cheers
>Didier PH Martin.
>
>
>
>
>-----------------------------------------------------------------
>The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
>initiative of OASIS <http://www.oasis-open.org>
>
>The list archives are at http://lists.xml.org/archives/xml-dev/
>
>To subscribe or unsubscribe from this list use the subscription
>manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
>
begin:vcard
fn:Rick Marshall
n:Marshall;Rick
email;internet:rjm@zenucom.com
tel;cell:+61 411 287 530
x-mozilla-html:TRUE
version:2.1
end:vcard
|
