[Web-SIG] JavaScript libraries

[Donovan Preston]

On May 2, 2005, at 2:29 PM, Carlos Ribeiro wrote:

> On 5/2/05, Shannon -jj Behrens <jjinux at gmail.com> wrote:
>
>> It sure would be nice to have a common JavaScript library that we
>> could all share.  People are wanting this for Aquarium, but I really
>> don't want Aquarium to have its own JavaScript library.  It's too  
>> much
>> of a niche within a niche.  Do you guys think it'd be possible to use
>> the RoR one?  I've often talked with Donnovan about using LivePage
>> from Nevow.  Do you guys know of any other really solid JavaScript
>> libraries?
>>
>
> Just for the record.
>
> I have spent six months writing a web-based workflow framework using
> CherryPy on my own time. I experimented a little bit with several
> templating systems, and one of the main problems that I had was with
> the integration of JavaScript code. I thought, "I want to code in one
> language as much as possible, and that's Python". So I wanted to have
> a templating system that allowed me to forget about writing custom
> Javascript code.
>
> After lots of painful experiments, I wrote a simple form-based library
> drawing on my experience with Delphi and other event-based toolsets.
> Forms are composed of components; each component has associated
> events. Event handlers are split in two parts: the form library itself
> generates a Javascript callback using an IFrame (the code was borrowed
> almost line-by-line from the example in the Apple's Developers site,
> and worked off the shelf!). This callback in turn is automatically
> associated with the even handler that is written in Python. The system
> was amazingly simple and intuitive. The best part, I didn't had to
> write custom Javascript code; I could rely on Python to handle events
> that were fired into the web browser, using my two-way glue code.

You just described what LivePage in both Woven and Nevow has been  
doing for 4 years now.

I'm not saying you should have discovered or used LivePage instead,  
I'm glad other people are finally starting to realize what my vision  
was, and realize that I'm not crazy!

> All of this was prior to Ajax. I heard about it and it seemed to be
> something along the same lines of the work that I was doing, but at
> that time, I was hired for another project (I am a network architect
> by profession, not a programmer!), and I had to spend the last two
> months reading the latest Cisco manuals :-(

Ajax is just a re-branding of things that have been possible cross- 
browser for a long time; it's just that nobody's boss believed them  
(including mine). DHTML is too 1998 for it to be a good boss- 
convincing tool, so Ajax was born.

It took a company that was seriously dedicated to the web (Google)  
and some apps that were willing to throw the rules out the window and  
keep the scope small so they could succeed (gmail, Google Suggest and  
Google Maps), but finally bosses around the world are able to point  
at something and say "I want that!" Ajax is just a convenient way to  
talk about it.

> Now I am beginning to find some time for my happy workflow hacking...
> and things have changed a lot, it seems. I think it's about time for
> it to happen. It may seem a little bit simplistic of my part, but I
> truly believe that the programmer's nirvana can only be attained when
> we manage to hide the dozen different tools that are necessary today
> behind a single & comprehensive framework. It makes no sense to me
> that we have to learn Python, JavaScript, HTML, CSS & SQL -- at a
> minimum! -- to become productive in this profession.

I agree it would be nice, but I am convinced it is currently  
unrealistic. The only reason for the current renaissance in rich  
browser UI is that people are willing to actually dig in and write  
lots of JavaScript. There is a Nirvana out there, but you are not  
going to get there through a modern web browser. Too many bugs remain  
on both sides of the fence and too many old browsers must be supported.

I had this dream when I first started writing Woven. I finally had to  
admit to myself that there were too many corner cases, and a  
framework which doesn't let you work around a bug in a browser is  
just a straightjacket, not a framework. With Nevow I have tried to  
take things more slowly, starting from the bottom, trying to build a  
thin, simple, sane way to get HTML into a browser which tries as much  
as possible to get out of your way and let you do your work.

Someday I hope we can get to a place where you write an app entirely  
in Python and deploy it in a Python, JavaScript, HTML, CSS, and SQL  
environment... but it'll be a while.

> The situation reminds me something about the beginnings of Windows
> programming; one had to know C, the Windows API, the format of
> resource files, the internals of event handling, memory models... just
> to write a simple application. Tools like VB & Delphi managed to hide
> all this complexity. I just feels that it's about time for it to
> happen for Web programming.

The problem is that there are good abstractions, and leaky  
abstractions. Good abstractions are built on top of solid  
foundations, which the current browser bug mess is not. Leaky  
abstractions are when the guts of the implementation of the browsers  
leak through, and a leaky abstraction is worse than no abstraction  
because it is harder to debug.

I have a dream that something better will arise and replace the  
browser, but I'm not holding my breath there, either.

I hope I don't sound too pessimistic... I'm still optimistic that web  
programming can become enjoyable. I'm just being realistic after  
being beaten down too many times before :-)

Donovan