Loading ...
Sorry, an error occurred while loading the content.

Re: Crockford thoughts on JavaScript package systems?

Expand Messages
  • Douglas Crockford
    ... That is an interesting nightmare scenario you paint there. It is hard enough trying to work with 4 browsers, which are all arguably attempting to implement
    Message 1 of 4 , Jun 29, 2007
      --- In ydn-javascript@yahoogroups.com, "traunic" <alektraunic@...> wrote:

      > Imagine a world where tiny JavaScript packages, from infinite sources,
      > can be mixed and matched with each other, as well as your own code. On
      > the fly, through a graphical UI or in source. Use a calendar widget
      > from lib A and a validation set from lib B. The files could be loaded
      > on demand during application usage or all at once at application load
      > depending on how you build it. It is possible, and I don't think
      > that far away.
      > So, I would really like to know, since he seems so very informed on
      > these matters, what is Douglas Crockford's take on JavaScript packages?

      That is an interesting nightmare scenario you paint there. It is hard
      enough trying to work with 4 browsers, which are all arguably
      attempting to implement the same API. Having to work with infinite
      sources, and a combinatorial explosion of mixing and matching, is
      quite frightening indeed.

      The web environment is interesting because there isn't one vendor
      calling the tunes, as is the case with most other application
      platforms. That openness is the web's best features, but it comes at
      a price.

      The web was not designed to be an application platform. As a result,
      there are big gaps in its functionality. Fortunately, JavaScript is so
      powerful that it is possible to fill in a lot of the gaps with
      JavaScript libraries. There are lots of them to choose from. A few of
      them are very good. But they are all trying to fill in the same holes,
      so they don't work well together. Some pairs of libraries can tolerate
      each other, but you are still paying for double the memory and
      bandwidth for no real additional functionality. It is tragic that
      Netscape didn't think through drag and drop. It is tragic that
      Microsoft didn't come up with a encapsulation mechanism. It is tragic
      that W3C is fiddling with HTML's document nature when what it really
      needs to become is an application deliver format. The history of the
      web teaches us that if you pile enough errors high enough, it will
      mostly work anyway. That is the proud legacy of the web.

      The web now has to compete with new proprietary application platforms
      like Air, WPF/Silverlight, and JavaFX. The new platforms, being mostly
      newer, are somewhat less constrained by architectural blunders than
      the web is. Even so, the web's openness is still really attractive,
      and hole filling measures like JavaScript libraries and Gears are
      going a long way toward keeping the web competitive.

      Ultimately, what wins? Will it be the web, or one of the new
      contenders? I don't know, and I don't care. I work for a company that
      will win regardless of who wins the next platform battle. I hope that
      the best platform wins, though history teaches that this isn't always
      the case.
    Your message has been successfully submitted and would be delivered to recipients shortly.