Javascript library development

Discussion in 'Javascript' started by Aaron Gray, Jul 11, 2008.

  1. Aaron Gray

    Aaron Gray Guest

    From what I have been looking at for Javascript library development,
    browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
    base level to pitch at.

    Anyone add anything ?

    Aaron
     
    Aaron Gray, Jul 11, 2008
    #1
    1. Advertising

  2. On Jul 11, 8:54 am, "Aaron Gray" <> wrote:
    > From what I have been looking at for Javascript library development,


    Are you going to be writing your own library?

    > browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like the
    > base level to pitch at.


    Roughly yes. It depends on your targeted user base and the browsers
    they are using. If it is for the general web vs for an intranet where
    everyone is using a single browser.

    > Anyone add anything ?


    If you use feature detection and progressive enhancement your library
    will fail gracefully in older browsers. It is a sustainable approach.
    For example. navigator.userAgent should not appear in your library
    code.

    There is a lure that a single library can cover all possible
    situations. That has never been shown to be true and if such a library
    could be written it would be huge. Determining the position of an
    element on the page is an example of a big problem.

    Identify the requirements for you library and then either find or
    write a library to suit that need.

    Peter
     
    Peter Michaux, Jul 12, 2008
    #2
    1. Advertising

  3. Aaron Gray

    Aaron Gray Guest

    "Peter Michaux" <> wrote in message
    news:...
    > On Jul 11, 8:54 am, "Aaron Gray" <> wrote:
    >> From what I have been looking at for Javascript library development,

    >
    > Are you going to be writing your own library?


    Yes.

    >> browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks like
    >> the
    >> base level to pitch at.

    >
    > Roughly yes. It depends on your targeted user base and the browsers
    > they are using. If it is for the general web vs for an intranet where
    > everyone is using a single browser.


    Yes, it looks like the cutoff point.

    There's the W3C DOM standard introduction and things like
    document.documentElement which I have tried to address.

    >> Anyone add anything ?

    >
    > If you use feature detection and progressive enhancement your library
    > will fail gracefully in older browsers. It is a sustainable approach.
    > For example. navigator.userAgent should not appear in your library
    > code.


    Yes, other than for error reporting :)

    > There is a lure that a single library can cover all possible
    > situations. That has never been shown to be true and if such a library
    > could be written it would be huge.


    Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
    very expensive for commercial usage. I am looking at creating a frame work
    with widget structure a few basic widgets and publish it under the LGPL,
    then hopefully if it is anygood others will contribute, thats the idea
    anyway.

    > Determining the position of an
    > element on the page is an example of a big problem.


    Right. I try to use events attached to elements where ever possible.

    > Identify the requirements for you library and then either find or
    > write a library to suit that need.


    ExtJS is the only contender but as I said it is prohibitorly expensive for
    small scale commercial usage.

    Aaron
     
    Aaron Gray, Jul 12, 2008
    #3
  4. On Jul 12, 12:02 pm, "Aaron Gray" <> wrote:
    > "Peter Michaux" <> wrote in message
    > news:...
    > > On Jul 11, 8:54 am, "Aaron Gray" <> wrote:
    > > > From what I have been looking at for Javascript library development,

    >
    > > Are you going to be writing your own library?

    >
    > Yes.


    With all due respect, if you are new enough to browser scripting to be
    asking the questions that you are, I suggest you write a few libraries
    and really explore the JavaScript language and the browser runtimes
    before you release a library to the world. By explore, I mean spend at
    least a year reading other libraries, writing example libraries,
    reading articles by programmers like Richard Cornford and Douglas
    Crockford. Crockford's "JavaScript: the good parts" book is really the
    only book on JavaScript that attempts to explore the lambda-nature of
    JavaScript and exploit it for maximum gain. Books about Lisp and
    Scheme (especially "Structure and Interpretation of Computer Programs"
    by Abelson and Sussman) which are lambda languages, are generally far
    higher quality than JavaScript books but the ideas translate to
    JavaScript quite readily. Quality books on browser scripting are at
    least hard to find.

    On the web it is already possible to download JavaScript libraries for
    browser scripting with APIs that were published and subsequently
    "fixed" by people with little experience writing browser scripts and
    who seemed to carry a lot of baggage and/or preconceived ideas about
    how to program from whatever language they wrote in before they
    arrived in JavaScript. (Usually they programmed in a class-based, non-
    lambda language which is almost polar opposite to JavaScript.) These
    efforts have resulted in libraries that don't maximize use of the
    things JavaScript does well, don't fully acknowledge the realities of
    the browser environment and use feature detection to deal with them,
    assume they know the right way to do things and end up with an API
    that is really difficult to make work with the techniques they would
    choose with more experience.


    > > If you use feature detection and progressive enhancement your library
    > > will fail gracefully in older browsers. It is a sustainable approach.
    > > For example. navigator.userAgent should not appear in your library
    > > code.

    >
    > Yes, other than for error reporting :)


    What kind of error reporting?


    > > There is a lure that a single library can cover all possible
    > > situations. That has never been shown to be true and if such a library
    > > could be written it would be huge.

    >
    > Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
    > very expensive for commercial usage. I am looking at creating a frame work
    > with widget structure a few basic widgets and publish it under the LGPL,
    > then hopefully if it is anygood others will contribute, thats the idea
    > anyway.
    >
    > > Determining the position of an
    > > element on the page is an example of a big problem.

    >
    > Right. I try to use events attached to elements where ever possible.


    Event target resolution is not what I was referring to in this case.
    That would be a really crazy way to identify what was clicked, for
    example.


    > > Identify the requirements for you library and then either find or
    > > write a library to suit that need.

    >
    > ExtJS is the only contender


    Why? All the regulars on this group write browser scripts and I think
    none uses ExtJS.


    > but as I said it is prohibitorly expensive for
    > small scale commercial usage.


    If the quality of ExtJS is considered acceptable (which would likely
    be highly debated on this newsgroup) then why not fork the last
    version of ExtJS that was free for commercial use?

    Peter
     
    Peter Michaux, Jul 12, 2008
    #4
  5. Aaron Gray

    Aaron Gray Guest

    "Peter Michaux" <> wrote in message
    news:...
    > On Jul 12, 12:02 pm, "Aaron Gray" <> wrote:
    >> "Peter Michaux" <> wrote in message
    >> news:...
    >> > On Jul 11, 8:54 am, "Aaron Gray" <> wrote:
    >> > > From what I have been looking at for Javascript library development,

    >>
    >> > Are you going to be writing your own library?

    >>
    >> Yes.

    >
    > With all due respect, if you are new enough to browser scripting to be
    > asking the questions that you are, I suggest you write a few libraries
    > and really explore the JavaScript language and the browser runtimes
    > before you release a library to the world. By explore, I mean spend at
    > least a year reading other libraries, writing example libraries,
    > reading articles by programmers like Richard Cornford and Douglas
    > Crockford. Crockford's "JavaScript: the good parts" book is really the
    > only book on JavaScript that attempts to explore the lambda-nature of
    > JavaScript and exploit it for maximum gain. Books about Lisp and
    > Scheme (especially "Structure and Interpretation of Computer Programs"
    > by Abelson and Sussman) which are lambda languages, are generally far
    > higher quality than JavaScript books but the ideas translate to
    > JavaScript quite readily. Quality books on browser scripting are at
    > least hard to find.


    Try John Resig's book and site.

    > On the web it is already possible to download JavaScript libraries for
    > browser scripting with APIs that were published and subsequently
    > "fixed" by people with little experience writing browser scripts and
    > who seemed to carry a lot of baggage and/or preconceived ideas about
    > how to program from whatever language they wrote in before they
    > arrived in JavaScript. (Usually they programmed in a class-based, non-
    > lambda language which is almost polar opposite to JavaScript.) These
    > efforts have resulted in libraries that don't maximize use of the
    > things JavaScript does well, don't fully acknowledge the realities of
    > the browser environment and use feature detection to deal with them,
    > assume they know the right way to do things and end up with an API
    > that is really difficult to make work with the techniques they would
    > choose with more experience.


    Yep, I do agree to some degree.

    >> > If you use feature detection and progressive enhancement your library
    >> > will fail gracefully in older browsers. It is a sustainable approach.
    >> > For example. navigator.userAgent should not appear in your library
    >> > code.

    >>
    >> Yes, other than for error reporting :)

    >
    > What kind of error reporting?


    If an error occurs in the Library then it uses AJAX to send home an error
    report with as much information as it can gather, this is then entered into
    a MySQL database app and a report produced and sent by email to me and maybe
    me and the user of the library.

    >> > There is a lure that a single library can cover all possible
    >> > situations. That has never been shown to be true and if such a library
    >> > could be written it would be huge.

    >>
    >> Yes, I am looking at a poormans ExtJS, as ExtJS is a dual licence and is
    >> very expensive for commercial usage. I am looking at creating a frame
    >> work
    >> with widget structure a few basic widgets and publish it under the LGPL,
    >> then hopefully if it is anygood others will contribute, thats the idea
    >> anyway.
    >>
    >> > Determining the position of an
    >> > element on the page is an example of a big problem.

    >>
    >> Right. I try to use events attached to elements where ever possible.

    >
    > Event target resolution is not what I was referring to in this case.
    > That would be a really crazy way to identify what was clicked, for
    > example.


    For most click events the object that is clicked on is where the click event
    is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
    me to other uses if there are some :)
    >
    >> > Identify the requirements for you library and then either find or
    >> > write a library to suit that need.

    >>
    >> ExtJS is the only contender

    >
    > Why? All the regulars on this group write browser scripts and I think
    > none uses ExtJS.


    Then where are the general UI libraries that are any good. Bespoke code is
    good but it is not generally complatible with other bespoke code and making
    libraries is what is interesting to me.

    Laying down the right framework is crucial.

    >> but as I said it is prohibitorly expensive for
    >> small scale commercial usage.

    >
    > If the quality of ExtJS is considered acceptable (which would likely
    > be highly debated on this newsgroup) then why not fork the last
    > version of ExtJS that was free for commercial use?


    I have looked at ExtJS's code and yes its not brilliant if you look at the
    DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
    unless this is due to a bug in FireBug and DebugBar.

    Yahoo's UI is even less self integrated.

    Where are the good libraries ? I am not into making just another wheel, I
    want a good wheel.

    Peter, most of the time I post to newsgroups I am just trying to get
    pragmatics of an issue which UseNet is usually great for.

    Basically I have been programming in Javascript on and off for over three
    years now. And I want my own framework and UI library that works hopefully
    on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.

    Regards,

    Aaron
     
    Aaron Gray, Jul 13, 2008
    #5
  6. Aaron Gray meinte:

    >> Quality books on browser scripting are at
    >> least hard to find.

    >
    > Try John Resig's book and site.


    Er... why? Most regulars here - including Peter - have a much better
    understanding of JS than the "JavaScript Ninja".

    As stated: Crockford's "JS the Good Parts" is definitely worth reading.

    > For most click events the object that is clicked on is where the click event
    > is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
    > me to other uses if there are some :)


    Events bubble. Instead of attaching a listener to every node of my XHR
    tree widget, one attached to the container of the tree does the job. The
    clicked element is identified via its class name.

    >>> ExtJS is the only contender

    >> Why? All the regulars on this group write browser scripts and I think
    >> none uses ExtJS.

    >
    > Then where are the general UI libraries that are any good.


    Because there are no good "general UI library" - and perhaps never will
    be. It's this "general" that causes so much trouble.

    > Where are the good libraries ? I am not into making just another wheel, I
    > want a good wheel.


    Either write your own (that's the most likely suggestion you gonna get
    here), or pick whatever you want and live with the shortcomings.

    Gregor




    --
    http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
    http://web.gregorkofler.com ::: meine JS-Spielwiese
    http://www.image2d.com ::: Bildagentur für den alpinen Raum
     
    Gregor Kofler, Jul 13, 2008
    #6
  7. Aaron Gray

    Aaron Gray Guest

    "Gregor Kofler" <> wrote in message
    news:Jxbek.81$...
    > Aaron Gray meinte:
    >
    >>> Quality books on browser scripting are at
    >>> least hard to find.

    >>
    >> Try John Resig's book and site.

    >
    > Er... why? Most regulars here - including Peter - have a much better
    > understanding of JS than the "JavaScript Ninja".


    Right I have just looked at the contents on Amazon.

    > As stated: Crockford's "JS the Good Parts" is definitely worth reading.


    Right.

    >> For most click events the object that is clicked on is where the click
    >> event is needed. Its only DnD that needs anything smarter AFAICS. Please
    >> enlighten me to other uses if there are some :)

    >
    > Events bubble. Instead of attaching a listener to every node of my XHR
    > tree widget, one attached to the container of the tree does the job. The
    > clicked element is identified via its class name.
    >
    >>>> ExtJS is the only contender
    >>> Why? All the regulars on this group write browser scripts and I think
    >>> none uses ExtJS.

    >>
    >> Then where are the general UI libraries that are any good.

    >
    > Because there are no good "general UI library" - and perhaps never will
    > be. It's this "general" that causes so much trouble.


    I agree, but am taking up the chalenge to try to make one, may probably fail
    but then at least I have tried.

    >> Where are the good libraries ? I am not into making just another wheel, I
    >> want a good wheel.

    >
    > Either write your own (that's the most likely suggestion you gonna get
    > here), or pick whatever you want and live with the shortcomings.


    Writing my own is the best option, then atleast if I want to modify it I
    know how rather than maybe using a hodgepodge of the others and ending in an
    entropic state.

    Aaron
     
    Aaron Gray, Jul 13, 2008
    #7
  8. Aaron Gray wrote:
    > Peter Michaux wrote:
    >> On Jul 12, 12:02 pm, Aaron Gray wrote:
    >>> Peter Michaux wrote:

    <snip>
    >>>> Are you going to be writing your own library?
    >>>
    >>> Yes.

    >>
    >> With all due respect, if you are new enough to browser scripting
    >> to be asking the questions that you are, I suggest you write a
    >> few libraries and really explore the JavaScript language and the
    >> browser runtimes before you release a library to the world.

    <snip>
    >> Books about Lisp and Scheme (especially "Structure and
    >> Interpretation of Computer Programs" by Abelson and Sussman)
    >> which are lambda languages, are generally far higher quality
    >> than JavaScript books but the ideas translate to JavaScript
    >> quite readily. Quality books on browser scripting are at
    >> least hard to find.

    >
    > Try John Resig's book and site.


    That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    that contains:-

    "Since valid HTML is simply a subset of XML, having an efficient way to
    parse and browser DOM documents is an absolutely essential for making
    JavaScript development easier."

    "Even if you're not completely familiar with XML, you will get great
    satisfaction knowing that all HTML documents (which are, in the eyes of
    the browser, XML documents) have a DOM representation that is ready to
    use."

    "Since the use of JavaScript in nonbrowser settings (e.g., server-side
    JavaScript) is still rather experimental, the feature set of JavaScript
    is still very browser-centric. Thus, the features available in
    JavaScript are very closely tied to how browsers evolve and which
    features they (or their users) deem as the most important."

    "Additionally, an object can contain a set of properties, all of which
    are simply references to other objects (such as strings, numbers,
    arrays, etc.)."

    "When performing string concatenation the result is always a new string
    object rather than a modified version of the original string."

    "The this variable will always refer to the object that the code is
    currently inside of."

    "In JavaScript, null, 0, '', false, and undefined are all equal (==) to
    each other, since they all evaluate to false. This means that if you use
    the code test == false, it will evaluate true if test is also undefined
    or equal to null, which may not be what you want."

    "Listing 3-12. Examples of How != and == Differ from !== and ===
    // Both of these are true
    null == false
    0 == undefined"

    "Compression should be used as the final step, just before putting your
    code into production, as your code will frequently become obfuscated
    beyond recognition."

    "This particular naming convention arose due to the fact that words such
    as class, for, float, and text are all reserved words in JavaScript."

    - and many other examples of technical fallacies, misconceptions and bad
    practices.

    Peter's point is, in effect, that if you don't know enough about
    javascript and browser scripting to recognise a bad book when you see
    one then maybe you should be a bit circumspect about rushing into
    designing a library and dumping it on a community who have less
    understanding of what they are doing than you do.

    <snip>
    > Basically I have been programming in Javascript on and off for
    > over three years now. And I want my own framework and UI
    > library that works hopefully on any Javascript 1.6 / ECMA3
    > compilant browser, hence the questions.


    Well, it will make a change for IceBrowser, Konqueror and NetFront to
    get a look-in.

    Richard.
     
    Richard Cornford, Jul 13, 2008
    #8
  9. Aaron Gray

    Aaron Gray Guest

    "Richard Cornford" <> wrote in message
    news:g5bkab$roh$1$...
    > Aaron Gray wrote:
    >> Peter Michaux wrote:
    >>> On Jul 12, 12:02 pm, Aaron Gray wrote:
    >>>> Peter Michaux wrote:

    > <snip>
    >> Try John Resig's book and site.

    >
    > That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    > that contains:-
    >
    > "Since valid HTML is simply a subset of XML, having an efficient way to
    > parse and browser DOM documents is an absolutely essential for making
    > JavaScript development easier."
    >
    > "Even if you're not completely familiar with XML, you will get great
    > satisfaction knowing that all HTML documents (which are, in the eyes of
    > the browser, XML documents) have a DOM representation that is ready to
    > use."
    >
    > "Since the use of JavaScript in nonbrowser settings (e.g., server-side
    > JavaScript) is still rather experimental, the feature set of JavaScript is
    > still very browser-centric. Thus, the features available in JavaScript are
    > very closely tied to how browsers evolve and which features they (or their
    > users) deem as the most important."
    >
    > "Additionally, an object can contain a set of properties, all of which are
    > simply references to other objects (such as strings, numbers, arrays,
    > etc.)."
    >
    > "When performing string concatenation the result is always a new string
    > object rather than a modified version of the original string."
    >
    > "The this variable will always refer to the object that the code is
    > currently inside of."
    >
    > "In JavaScript, null, 0, '', false, and undefined are all equal (==) to
    > each other, since they all evaluate to false. This means that if you use
    > the code test == false, it will evaluate true if test is also undefined or
    > equal to null, which may not be what you want."
    >
    > "Listing 3-12. Examples of How != and == Differ from !== and ===
    > // Both of these are true
    > null == false
    > 0 == undefined"
    >
    > "Compression should be used as the final step, just before putting your
    > code into production, as your code will frequently become obfuscated
    > beyond recognition."
    >
    > "This particular naming convention arose due to the fact that words such
    > as class, for, float, and text are all reserved words in JavaScript."
    >
    > - and many other examples of technical fallacies, misconceptions and bad
    > practices.


    I thought he looked a bit young :)

    You typed in all that ?

    Have not read the book just read his web site which on the whole is pritty
    good.

    Yeah, you only have to look at the second hand price of the "new"ish book on
    Amazon.

    Oh well its probably okay for some people. I will probably still buy the
    book just to see if there are some gems in it, then pass it on as a hand me
    down if I don't then still want to keep it.

    So its back to Douglas then, there's some goodies from him on Yahoo theatre
    :-

    http://developer.yahoo.com/yui/theater/

    > Peter's point is, in effect, that if you don't know enough about
    > javascript and browser scripting to recognise a bad book when you see one
    > then maybe you should be a bit circumspect about rushing into designing a
    > library and dumping it on a community who have less understanding of what
    > they are doing than you do.


    Javascript is a real evolving thing, I have been learning it and relearning
    it looking ahead at Javascript 2.0 and getting a good overview of the lay of
    the land.

    > <snip>
    >> Basically I have been programming in Javascript on and off for
    >> over three years now. And I want my own framework and UI
    >> library that works hopefully on any Javascript 1.6 / ECMA3
    >> compilant browser, hence the questions.


    Sorry that should be Javascript 1.5.

    > Well, it will make a change for IceBrowser, Konqueror and NetFront to get
    > a look-in.


    I want to write the foundations to include as many browsers as possible from
    a reasonable baseline, thats the plan anyway if it is possible then its
    worth doing.

    I am basically putting together a base level "legacy" support library, and
    do a test set for it so that it can be tested on a range of browsers.

    To be clever but not too clever with the level of Javascript coding is the
    name of the game, some of the newer stuff is just too clever for its own
    good, substituting efficiency and readability for technical prowesk.

    Thanks Richard, some of those quotes were quite funny :)

    Aaron
     
    Aaron Gray, Jul 13, 2008
    #9
  10. Aaron Gray wrote:
    > Richard Cornford wrote:
    >> Aaron Gray wrote:
    >>> Peter Michaux wrote:
    >>>> On Jul 12, 12:02 pm, Aaron Gray wrote:
    >>>>> Peter Michaux wrote:

    >> <snip>
    >>> Try John Resig's book and site.

    >>
    >> That "John Resig's book" would be "Pro JavaScript Techniques"?
    >> The book that contains:-

    <snip>
    >> "This particular naming convention arose due to the fact that
    >> words such as class, for, float, and text are all reserved words
    >> in JavaScript."
    >>
    >> - and many other examples of technical fallacies, misconceptions
    >> and bad practices.

    >
    > I thought he looked a bit young :)


    Youth would not, it itself, be a barrier to understanding javascript.
    ES3 is not that complex else it would not be possible for its
    specification to be just 170 odd page (with 10% of that entirely devoted
    to regular expressions).

    > You typed in all that ?


    No, I copied it from a list I have in a document. Though I did type the
    list originally so I cannot promise that it is typo free. I used them as
    humorous signatures for a month or so (john Resig didn't see the joke),
    but have stopped now. The fear was express that my quoting them might be
    taken as an endorsement.

    > Have not read the book just read his web site which on the whole
    > is pritty good.


    YMMV

    > Yeah, you only have to look at the second hand price of the
    > "new"ish book on Amazon.


    Low is it?

    <snip>
    > I want to write the foundations to include as many browsers as
    > possible from a reasonable baseline, thats the plan anyway if
    > it is possible then its worth doing.


    I don't think "possible" == "worth doing" holds.

    > I am basically putting together a base level "legacy" support
    > library, and do a test set for it so that it can be tested on
    > a range of browsers.
    >
    > To be clever but not too clever with the level of Javascript
    > coding is the name of the game, some of the newer stuff is
    > just too clever for its own good, substituting efficiency
    > and readability for technical prowesk.


    Yes, the last couple of years have seen the arrival of "do it this way
    because it is cool". Talking design to people who take that attitude is
    a bit like beating your head against a wall. (What is the best part of
    beating your head against a wall? - Stopping.)

    > Thanks Richard, some of those quotes were quite funny :)


    I thought so. (That or they'd make you cry.)

    Richard.
     
    Richard Cornford, Jul 13, 2008
    #10
  11. On Jul 12, 4:02 pm, "Aaron Gray" <> wrote:

    [snip]

    > If an error occurs in the Library then it uses AJAX to send home an error
    > report with as much information as it can gather, this is then entered into
    > a MySQL database app and a report produced and sent by email to me and maybe
    > me and the user of the library.


    This is a nice idea but don't rely on the navigator.userAgent string
    completely. The message the browser sends to the server could also
    include the results of your feature tests. Then you could determine if
    the navigator.userAgent correlates to the feature test results. Even
    then you might have trouble. Just for IE6 there are many different
    configurations and effectively IE6 could be seen as at least tens of
    different browsers depending on the operating system configuration,
    security options in the browser, etc.

    Probably best to send this message with something very low tech like
    creating an image element and setting the src property. Using
    XMLHttpRequest for this would likely disable many of the browsers from
    which you would like to receive messages from even being able to send
    the message. In fact perhaps you'd want to try sending the message a
    few different ways to make sure the message got through.



    > For most click events the object that is clicked on is where the click event
    > is needed. Its only DnD that needs anything smarter AFAICS. Please enlighten
    > me to other uses if there are some :)


    There are many other situations where event delegation could be handy.
    If you have a list and you are adding and removing elements, it is
    simpler if the list is listening for events rather than having to add
    listeners to each element as it is inserted.


    > >> > Identify the requirements for you library and then either find or
    > >> > write a library to suit that need.

    >
    > >> ExtJS is the only contender

    >
    > > Why? All the regulars on this group write browser scripts and I think
    > > none uses ExtJS.

    >
    > Then where are the general UI libraries that are any good. Bespoke code is
    > good but it is not generally complatible with other bespoke code and making
    > libraries is what is interesting to me.
    >
    > Laying down the right framework is crucial.


    For a foundation, I'd suggest starting with a multi-browser event
    library. That contains plenty of browser bugs and you will need to
    make decisions about how to handle the various problems. For example,
    in versions of Safari up to something like version 2.0.2, there was a
    bug where prevent default didn't work for click and double click
    events when the handler was added with addEventHandler. If the handler
    is added by setting the onclick property of the element then prevent
    default does work. As far as I know there is no feature test to detect
    this issue. However these versions of Safari are getting old. What is
    the right thing to do? The event library problem alone allows for very
    rich exploration into the building of a multi-browser library. It has
    been for me anyway. Building a solution entails feature detection
    techniques, realizing "general" is a problem as Gregor rightly notes,
    API design, knowing how to build a small solution with the JavaScript
    language, etc.


    > >> but as I said it is prohibitorly expensive for
    > >> small scale commercial usage.

    >
    > > If the quality of ExtJS is considered acceptable (which would likely
    > > be highly debated on this newsgroup) then why not fork the last
    > > version of ExtJS that was free for commercial use?

    >
    > I have looked at ExtJS's code and yes its not brilliant if you look at the
    > DOM generated there ar unclosed <div>'s and <ul>'s in the tree control,
    > unless this is due to a bug in FireBug and DebugBar.
    >
    > Yahoo's UI is even less self integrated.
    >
    > Where are the good libraries?


    They seem to be hard to find.


    > I am not into making just another wheel, I
    > want a good wheel.


    The mainstream libraries are certainly not perfectly round wheels. So
    if you need a round one you may have to build your own. First you need
    to decide the requirements for your library.

    > Peter, most of the time I post to newsgroups I am just trying to get
    > pragmatics of an issue which UseNet is usually great for.
    >
    > Basically I have been programming in Javascript on and off for over three
    > years now. And I want my own framework and UI library that works hopefully
    > on any Javascript 1.6 / ECMA3 compilant browser, hence the questions.


    I think learning as much as you can about feature testing techniques
    is the most productive way to start. There is an article in the
    group's FAQ notes which is a probably a very good place to start.

    http://www.jibbering.com/faq/faq_notes/not_browser_detect.html

    Peter
     
    Peter Michaux, Jul 13, 2008
    #11
  12. Aaron Gray meinte:

    > "Gregor Kofler" <> wrote in message
    > news:Jxbek.81$...


    >> Because there are no good "general UI library" - and perhaps never will
    >> be. It's this "general" that causes so much trouble.

    >
    > I agree, but am taking up the chalenge to try to make one, may probably fail
    > but then at least I have tried.


    My "core library" is about 15k: some DOM functions, event handling, some
    small prototype extensions. If I need XHR the according library eats up
    another 8-9k, most of it for Douglas' JSON functions. Another small
    library does drag and drop (5k).

    On top of those small scripts I write my widgets. Works for me.

    Gregor


    --
    http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
    http://web.gregorkofler.com ::: meine JS-Spielwiese
    http://www.image2d.com ::: Bildagentur für den alpinen Raum
     
    Gregor Kofler, Jul 13, 2008
    #12
  13. Aaron Gray

    Jorge Guest

    On Jul 13, 3:04 am, "Richard Cornford" <>
    wrote:
    > That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    > that contains:-
    >
    > (...)
    >
    > "When performing string concatenation the result is always a new string
    > object rather than a modified version of the original string."
    >


    javascript:a= new String("Hola");alert(a === (a+ ""));alert(typeof a);

    --> false, object.

    javascript:a= "Hola";alert(a === (a+ ""));alert(typeof a);

    --> true, string.


    --Jorge.
     
    Jorge, Jul 13, 2008
    #13
  14. Aaron Gray

    Jorge Guest

    On Jul 13, 3:04 am, "Richard Cornford" <>
    wrote:
    > That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    > that contains:-
    > (...)
    > "When performing string concatenation the result is always a new string
    > object rather than a modified version of the original string."



    javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
    ""));alert(typeof a);
    --> object, false, string.

    javascript:a= "Hola";alert(typeof a);alert(a === (a+=
    ""));alert(typeof a);
    --> string, true, string.

    --Jorge.
     
    Jorge, Jul 13, 2008
    #14
  15. Peter Michaux wrote:
    > On Jul 11, 8:54 am, "Aaron Gray" <> wrote:
    >> browsers that support Javascript 1.5/ECMAScript 3/JScript 5.5 looks
    >> like the base level to pitch at.

    >
    > Roughly yes. It depends on your targeted user base and the browsers they
    > are using. If it is for the general web vs for an intranet where

    ^^^^^^^^^^^^^^^^^
    > everyone is using a single browser.

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    This should be understood as an AND-connected condition about the truth of
    the statement. An intranet does _not_ mean everybody using it is using the
    same user agent. And even if that applies *now*, it is very likely _not_ to
    be true in the foreseeable future. Think about employees using mobile
    devices like iPhone, for example.


    PointedEars
    --
    var bugRiddenCrashPronePieceOfJunk = (
    navigator.userAgent.indexOf('MSIE 5') != -1
    && navigator.userAgent.indexOf('Mac') != -1
    ) // Plone, register_function.js:16
     
    Thomas 'PointedEars' Lahn, Jul 13, 2008
    #15
  16. Jorge wrote:
    > "Richard Cornford" wrote:
    >> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    >> that contains:-
    >> (...)
    >> "When performing string concatenation the result is always a new string
    >> object rather than a modified version of the original string."

    >
    > javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
    > ""));alert(typeof a);
    > --> object, false, string.
    >
    > javascript:a= "Hola";alert(typeof a);alert(a === (a+=
    > ""));alert(typeof a);
    > --> string, true, string.


    What exactly is the point you are trying to make here?

    ( ) Your confirming that John Resig does not know what he is writing about.
    ( ) Your not understanding what a String object is.

    (It is a radio button group. Choose one.)


    PointedEars
    --
    realism: HTML 4.01 Strict
    evangelism: XHTML 1.0 Strict
    madness: XHTML 1.1 as application/xhtml+xml
    -- Bjoern Hoehrmann
     
    Thomas 'PointedEars' Lahn, Jul 13, 2008
    #16
  17. Aaron Gray

    Jorge Guest

    On Jul 13, 11:39 pm, Thomas 'PointedEars' Lahn <>
    wrote:
    > Jorge wrote:
    > > "Richard Cornford" wrote:
    > >> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    > >> that contains:-
    > >> (...)
    > >> "When performing string concatenation the result is always a new string
    > >> object rather than a modified version of the original string."

    >
    > > javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
    > > ""));alert(typeof a);
    > > --> object, false, string.

    >
    > > javascript:a= "Hola";alert(typeof a);alert(a === (a+=
    > > ""));alert(typeof a);
    > > --> string, true, string.

    >
    > What exactly is the point you are trying to make here?
    >
    > ( ) Your confirming that John Resig does not know what he is writing about.
    > ( ) Your not understanding what a String object is.
    >
    > (It is a radio button group.  Choose one.)
    >


    (·) Your not understanding what a String object is.

    javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
    a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
    += ""));
    --> object, true, false, string, object, true.


    --Jorge.
     
    Jorge, Jul 14, 2008
    #17
  18. Jorge meinte:

    > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
    > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
    > += ""));
    > --> object, true, false, string, object, true.


    Still, what's your point? Everything works as expected.

    "String objects are created by calling the constructor new String(). The
    String object wraps Javascript's string primitive data type with the
    methods described below. The global function String() can also be called
    without new in front to create a primitive string. String literals in
    JavaScript are primitive strings.

    Because Javascript automatically converts between string primitives and
    String objects, you can call any of the methods of the String object on
    a string primitive. JavaScript automatically converts the string
    primitive to a temporary String object, calls the method, then discards
    the temporary String object." [1]

    Gregor


    [1]
    <http://developer.mozilla.org/en/docs/Core_JavaScript_1.5_Reference:Global_Objects:String>


    --
    http://photo.gregorkofler.at ::: Landschafts- und Reisefotografie
    http://web.gregorkofler.com ::: meine JS-Spielwiese
    http://www.image2d.com ::: Bildagentur für den alpinen Raum
     
    Gregor Kofler, Jul 14, 2008
    #18
  19. Jorge wrote:
    > Thomas 'PointedEars' Lahn wrote:
    >> Jorge wrote:
    >>> "Richard Cornford" wrote:
    >>>> That "John Resig's book" would be "Pro JavaScript Techniques"? The book
    >>>> that contains:-
    >>>> (...)
    >>>> "When performing string concatenation the result is always a new string
    >>>> object rather than a modified version of the original string."
    >>> javascript:a= new String("Hola");alert(typeof a);alert(a === (a+=
    >>> ""));alert(typeof a);
    >>> --> object, false, string.
    >>> javascript:a= "Hola";alert(typeof a);alert(a === (a+=
    >>> ""));alert(typeof a);
    >>> --> string, true, string.

    >> What exactly is the point you are trying to make here?
    >>
    >> ( ) Your confirming that John Resig does not know what he is writing about.
    >> ( ) Your not understanding what a String object is.
    >>
    >> (It is a radio button group. Choose one.)

    >
    > (·) Your not understanding what a String object is.


    I see.

    > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
    > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
    > += ""));
    > --> object, true, false, string, object, true.


    You have not named the implementation that you have tested with. However,
    it works there as specified. Yet you missed the point:

    "foo" is a primitive string value. new String("foo"), on the other hand, is
    a reference to a newly created String object (which is rather bloated, in
    comparison). While the string concatenation operation, be it `+' or `+=',
    works for both values as operands (same "type" and mixed), its result is
    (unsurprisingly) always a primitive string value, _not_ (a reference to) a
    String object (as e.g. the `typeof' operation shows when applied to it).

    IOW, John Resig does not know what he is writing about (there). Hopefully,
    you will begin to as of now.


    HTH

    PointedEars
    --
    Use any version of Microsoft Frontpage to create your site.
    (This won't prevent people from viewing your source, but no one
    will want to steal it.)
    -- from <http://www.vortex-webdesign.com/help/hidesource.htm>
     
    Thomas 'PointedEars' Lahn, Jul 14, 2008
    #19
  20. Aaron Gray

    Jorge Guest

    On Jul 14, 10:07 am, Gregor Kofler <> wrote:
    > Jorge meinte:
    >
    > > javascript:a= b= new String("Hola");alert(typeof a);alert(b ===
    > > a);alert(b === (a+= ""));alert(typeof a);alert(typeof b);alert(a === (b
    > > += ""));
    > > --> object, true, false, string, object, true.

    >
    > Still, what's your point?
    >


    That yes, that string concatenation (even when fed with string
    object(s)) yields string primitive values not string objects.

    Try with "string".concat("string") and ["string"].join("string"), and
    the results are the same :

    javascript:alert(typeof (new String("Hola")).concat(""));
    --> string.

    javascript:alert(typeof [new String("Hola")].join(""));
    --> string.

    Still, Resig is right in the sense that a there's no way to modify a
    string object. Or not ?

    --Jorge.
     
    Jorge, Jul 14, 2008
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kevin Spencer
    Replies:
    2
    Views:
    454
    John Saunders
    Aug 6, 2003
  2. Akhlaq Khan
    Replies:
    4
    Views:
    771
    =?Utf-8?B?Q293Ym95IChHcmVnb3J5IEEuIEJlYW1lcikgLSBN
    Sep 27, 2004
  3. Replies:
    0
    Views:
    486
  4. Replies:
    0
    Views:
    353
  5. tpot
    Replies:
    9
    Views:
    140
    Thomas 'PointedEars' Lahn
    Jan 16, 2010
Loading...

Share This Page