jquery vs dojo vs yui etc
in [JavaScript]
|
Prev: Interactive web-based graphs for iPads?
Next: FAQ Topic - How can I disable the back button in a web browser? (2010-06-17)
From: David Mark on 17 Jun 2010 11:23 On Jun 17, 11:04 am, VK <schools_r...(a)yahoo.com> wrote: > On Jun 17, 6:44 pm, Tim Streater <timstrea...(a)waitrose.com> wrote: > > > In article > > <7313e001-78c8-4b17-aa39-72e5a420e...(a)i28g2000yqa.googlegroups.com>, > > Matt Kruse <m...(a)thekrusefamily.com> wrote: > > > [stuff] > > > After all these posts, I'm none the wiser: what is the problem these > > libraries are trying to solve? > > Ever since NN3/IE3 slash, so since it became important to care of more > than one specific platform, the JavaScript libraries are solving these > problem: Huh? > > 1) Provide a reusable subroutines/interfaces for universally frequent > tasks (client-side form pre-validation is the oldest one) Virtually any blob of script is reusable and form validation is not the primary focus of the "major" libraries. > 2) To cover with a top level interface different and traditionally > numerous native DOM interfaces discrepancies and bugs of different UA > producers And as the browser have converged, we are left with library discrepancies and bugs of different library producers. > (layer positioning and viewport size calculations among the > oldest one). LOL. They all botch viewport size. http://www.cinsoft.net/viewport.asp > 3) To add custom methods that was originally considered as non-needed > one by specs producers (getElementsByClassName for a sample). You sure don't need a library for that function. If you can't write (and optimize) such a function in five minutes, a library isn't going to help you. > 4) To add a functionality that otherwise requires many ours of > developments and some particular knowledge not universally presented > even among experienced programmers (3D vector graphics and animated 3D > object matrix transformations for SVG/VML for a sample). Those are specialized "libraries", so off the current topic. > 5) Rather new one and not so common: adjusting the top level > programming paradigm to emulate some non-JavaScript paradigm with is > more traditional for a given target audience (C/C++ class-like in > Prototype.js for a sample). And those are ill-advised of course.
From: Matt Kruse on 17 Jun 2010 11:32 On Jun 17, 9:44 am, Tim Streater <timstrea...(a)waitrose.com> wrote: > After all these posts, I'm none the wiser: what is the problem these > libraries are trying to solve? The goal of any library/framework/layer/abstraction is to simplify the solution to one problem, so it can be used as a foundation for solving a bigger problem. Browser scripting can be complicated, marred by over a decade of browser hacks, quirks, bugs, and non-compliant behavior. If a person is required to understand, solve, and code for all these problems that have been built up for years, they are unable to focus on bigger problems. Imagine if, every time we wanted to make an ajax call in js, we needed to worry about browser threading, the OS we were on, the network stack, handling tcp/ip correctly, handling dns, all the way down to the ethernet layer. It would be an insurmountable problem. Thankfully, all those layers have been abstracted away for us. We have just a few concerns to deal with ajax, since we have to solve for a few different browser conditions and quirks. Along with all those layers of abstraction comes trade-offs. Certainly, performance is reduced by each layer. There may be bugs and quirks in each layer. Our ajax call may fail not because we coded the js incorrectly, but because a DNS bug caused the lookup to fail. But there is no way we would ever think of re-writing all these components to be more technically correct. Even if we knew the faults and knew how to code them better, it would not be practical. Accepting the stack of layers under you - the good and the bad - allows you to focus on higher-level problems. Now, writing applications for the web has developed to a degree that authors no longer want to deal with the lower-level problems of javascript, browsers, the DOM, etc. They may want to just display an in-page dialog that blocks the rest of the UI, for example. It seems like a trivial task, but in reality it's a complex problem. A library simplifies the problem, so instead of having to understand and solve 100 scripting issues, they now just have to understand a few API calls. And they can then afford to combine even more complicated behavior together to create something that would have otherwise been too complex to create. Obviously, the library introduces a layer of complexity that comes with its own problems. It may be less efficient, or may not work in some browsers, or may have other issues. But these are the trade-offs for having a large, unmanageable problem reduced to a smaller, manageable one. Just as there are many trade-offs in the long stack of abstractions between your js scripting environment and the bits in the hardware that is driving it all. Surely, it is up to the developer to decide whether a library is a good layer of abstraction to introduce. If it solves a great number of problems and allows them to focus on bigger issues, then that is good. If it introduces new bugs or incompatibilities or problems, then it's important for the user to be aware of exactly what they are sacrificing, and to decide if it's worth it. Some people are so attached to this specific technology - their ego so caught up in understanding this layer better than anyone else - that it's frustrating for them to see anyone "abstract away" their knowledge. These people fear the day when the js layer is abstracted away, because then their expertise is no longer needed. They can point out the faults in specific libraries all day long, but they lack the vision to see that _every_ layer eventually gets abstracted away. It's how technology advances. JS Libraries, as a way to abstract away the problems with browser scripting, may not be the *best* solution. But it is one solution, and it works very well for many people. I think it's great to argue for different ways to abstract away the problem, and pick the option that is best. But IMO, rejecting the abstraction altogether because of its shortcomings is short-sighted. Web development will move on without these detractors. Libraries will be used and improved, because people don't want to have to deal with the whole nasty, confusing browser scripting layer. They want it solved, at least to a degree that they are comfortable with, and presented in a nicer, easier-to-use form. That's what libraries like jQuery do, and that's why people so overwhelmingly choose to use them. Matt Kruse
From: Jeremy J Starcher on 17 Jun 2010 11:39 On Thu, 17 Jun 2010 07:02:25 -0700, Matt Kruse wrote: > The js that I'm currently working with most is > http://BetterFacebook.net, which is a greasemonkey script/firefox add-on > (which also works in Chrome, Safari, and Opera, I've heard) that adds a > bunch of functionality to Facebook. It's a whole different kind of > challenge, and it's refreshing to not have to deal with IE at all. :) IE7Pro adds a UserScript option to various versions of IE ... and I've got a "compatibility" option that renders the differences mostly transparent.
From: VK on 17 Jun 2010 11:53 On Jun 17, 7:23 pm, David Mark <dmark.cins...(a)gmail.com> wrote: > > 1) Provide a reusable subroutines/interfaces for universally frequent > > tasks (client-side form pre-validation is the oldest one) > > Virtually any blob of script is reusable and form validation is not > the primary focus of the "major" libraries. > > > 2) To cover with a top level interface different and traditionally > > numerous native DOM interfaces discrepancies and bugs of different UA > > producers > > And as the browser have converged, we are left with library > discrepancies and bugs of different library producers. > > > (layer positioning and viewport size calculations among the > > oldest one). > > LOL. They all botch viewport size. > > http://www.cinsoft.net/viewport.asp > > > 3) To add custom methods that was originally considered as non-needed > > one by specs producers (getElementsByClassName for a sample). > > You sure don't need a library for that function. If you can't write > (and optimize) such a function in five minutes, a library isn't going > to help you. > > > 4) To add a functionality that otherwise requires many ours of > > developments and some particular knowledge not universally presented > > even among experienced programmers (3D vector graphics and animated 3D > > object matrix transformations for SVG/VML for a sample). > > Those are specialized "libraries", so off the current topic. > > > 5) Rather new one and not so common: adjusting the top level > > programming paradigm to emulate some non-JavaScript paradigm with is > > more traditional for a given target audience (C/C++ class-like in > > Prototype.js for a sample). > > And those are ill-advised of course. These are what the libraries are (lesser some particular cases). I am not clearly sure what point are you trying to make by your comments. That libraries are not *necessary* for the programming to exist as such? They are not necessary, it is a convenience tool in any language.
From: Garrett Smith on 17 Jun 2010 12:15
On 6/17/2010 3:58 AM, David Mark wrote: > On Jun 16, 11:58 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >> On 6/16/2010 8:11 PM, David Mark wrote: >> >> >> >> >> >>> On Jun 16, 10:32 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>> On 6/16/2010 6:29 PM, David Mark wrote: >> >>>>> On Jun 16, 8:43 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>> On 6/16/2010 4:06 PM, David Mark wrote: >> >>>>>>> On Jun 16, 6:53 pm, Garrett Smith<dhtmlkitc...(a)gmail.com> wrote: >>>>>>>> On 6/16/2010 2:35 PM, David Mark wrote: >> >>>>>>>>> On Jun 16, 2:34 pm, Joe Nine<j...(a)yahoo.com> wrote: >>>>>>>>>> Does anyone have any links to very convincing articles that eloquently >>>>>>>>>> state the major flaws of these libraries? I'm not considering using any >>>>>>>>>> of them, I've heard enough here to know how bad they are. I just want a >>>>>>>>>> few article links to keep in my back pocket that I can fire back when >>>>>>>>>> someone suggests we use one of them. >> >>>> [...] >> >>>>>>> I've done all of the hard work. You yourself were just parroting some >>>>>>> of it recently. >> >>>>>> That is untrue. >> >>>>> History says otherwise. >> >>>>>> I've have never wanted to copy anything of yours. >> >>>>> Then I assume you've done so repeatedly at gunpoint. >> >>>> Lets be very clear on this: There is nothing of yours that I have >>>> copied. Ever. >> >>> Let's be very clear. You have. Perhaps, for whatever reason, you >>> don't even realize it. >> >>>> If you believe otherwise, then it's time for you to get very specific >>>> with an example. >> >>> Haven't we been over *that* enough times? Start with your recent >>> obsession with queries and attributes vis-a-vis jQuery. >> >> So let me get this straight: I reviewed code from jQuery. This bothers >> you because you believe that I copied you. >> >> Did I get that right? > > No, it's one of your usual purposeful oversimplifications. You copied No? You wrote that I copied you by having "obsession with queries and attributes". What exactly did I do? http://www.google.com/search?q="attributes+vs+properties"+jquery http://www.developersdex.com/asp/message.asp?p=2978&r=6837513 I certainly am not going to copy any of the things you wrote there. > the one-off feature test from me too. See, I can generalize too! > IIRC, your comment at the time (as you did this here in public) was > that you were changing your whole library to use it as you previously > just had flags. Go ahead, deny it. I'll dig that one up for > sure. :) > One thing at a time. Back to your first point about jQuery. Garrett |