I think we are all missing the "features detection" point as well. As
example, you'll never know until you try if the browser has a correct
implementation of querySelectorAll, getElementsByClassName, or other
features such Array.prototype.slice compatible with live collections, etc
etc ... the Apache or PHP trick for example is based on userAgent and we all
know how not reliable it is to understand browser features ( patches or
different SP over same browser version, an updated JScript dll over IE6 for
Windows Mobile, others )
I think the best approach is to understand runtime what the browser can do
and what it cannot then call right pieces of the puzzle in order to create
the "perfect library".
This will mean a sort of nightmare for each created ticket, but if we are
talking about performances, I have to insist I do not want Opera 9 problems
in "my jQuery for Firefox"
I cannot see concrete benefits with just 2 version of jQuery since non IE
browsers are already 10 times faster than IE and IE is the most problematic
with all its workarounds.
The dojo approach is in my opinion one of the best one, but jQuery design is
totally different.
An alternative could be a full lazy library which auto build itself during
execution time in order to guarantee best performances for each browser,
still one single file rather than 2 or more, but a lot of duplicated code
because of the possible single if inside "that method"
So, at the end of the day, what seems to be that simple to do, requires a
lot of work, a lot of tests to understand if it is worth, and a deep
analysis about side-effects, best approach, server load, file serving
strategy, method serving strategy, etc etc
Just my 2 cents
On Wed, Sep 2, 2009 at 10:25 AM, Thijs Houtenbos <
th...@thijshoutenbosdesign.nl> wrote:
> Step 1: Comment jQuery code with some standard scheme describing each
> section of code as a workaround for browser X version Y.Step 2: Create a
> parsing script that 'compiles' the different browser versions.
> Step 3: Design a foolproof method to get the right script loaded in the
> right browsers.
>
> You are now at step 3, and while this is a very interesting discussion, the
> first step is a very big and essential job for the jQuery team.
> When you decide this optimization is worth it you should start working on
> step 1 for the next mayor jQuery release.
> Steps 2 and 3 can be perfected separately, and the different browser
> versions will probably be ready in a day after the code with proper comments
> is available. ;)
>
> As I understand it you might need some help with step one, so what
> mechanism would best suit our need to let the community help re-comment
> jQuery?
> It might be a little far out but isn't it an option to let a semi-automated
> script leave out different pieces of uncommented code and test in various
> browsers with the new testswarm. Kind of like reverse-feature-detection! :)
>
> Regards,
> THD
>
>
> On Wed, Sep 2, 2009 at 10:39 AM, DBJDBJ <dbj...@gmail.com> wrote:
>
>>
>>
>> Are we (or am I ) solving/discussing a non existend problem? I think
>> no and I think there actually is a problem. Not very big, and not a
>> "show stopper", but a visible one. Which makes this issues (or
>> problem) worth solving.
>>
>> jQuery (as it is ) code is i sprinkeld with IE related comments. I do
>> not need any hard data, to convince myself (and others who agree) that
>> something has to be done to rectify the situation where core library
>> has active/runtime workarounds arround IE issues. I am extrapolating
>> (not just mine) concepts, knowledge and experience from other
>> programing developments, into the realm of browser hosted javascript
>> environment. I do not need any kind of tests to be convinced that
>> having different jQ for IE and other browsers is a good thing. And
>> that it must bring measurable benefits, in terms of speed and
>> stability, of future jQuery releases (if adopted).
>>
>> There are people here who agree and even want to extend this idea into
>> having different jQ for each of the browsers that matter. Someone even
>> suggested PHP based solution which will make (compose) jQ "on-
>> fly" (aka dynamicaly) by looking into the HTTP client descriptors. Or
>> one can imagine a solution using server-side-includes :
>>
>> <!-- jquery_composer example running on Apache -->
>> <!--#if expr="${Mac} && ${InternetExplorer}" -->
>> IE on OS-X solution
>> <!--#else -->
>> Every other solution code goes here
>> <!--#endif -->
>>
>> I think, have suggested much less dramatic, solution vs. above ;o)
>>
>> I would gladly do the jQery code changes (and spliting into two),
>> myself, but I am not sure I am capable of matching each IE related
>> comment in jQ to actual code, even less capable of understanding few
>> uncommented IE workarounds.
>>
>> --DBJ
>>
>> On Sep 1, 5:20 pm, David Zhou <da...@nodnod.net> wrote:
>> > On Tue, Sep 1, 2009 at 11:45 AM, DBJDBJ<dbj...@gmail.com> wrote:
>> >
>> > > @dz No offence, but why are you taking part in this "pointless
>> > > discussion" ?
>> >
>> > Because if there *is* a significant speed increase, it's valid and
>> > therefore interesting. There's a lot of sound and fury, but not a lot
>> > of data.
>> >
>> > > I am really puzzled on what arises a certain ammount of confusion
>> > > here? JScript conditional comments, IE html conditional comments, etc
>> > > are nothing new. People have been using them for years. And the whole
>> > > "conditional compilation" concept is decades old.
>> >
>> > People have been using them for years -- but not blindly. jQuery just
>> > recently made a move towards feature detection rather than browser
>> > detection. Separating out non-IE code is a step backwards towards
>> > browser detection. If that step is to be taken, you need to show
>> > measurable gains beyond screams of "it's better!" and beyond generic
>> > appeals to tradition and authority.
>> >
>> > This isn't cargo cult mysticism. If there are gains, create some test
>> > cases and show them.
>> >
>> > > (one very relevant and recent example :
>> http://dean.edwards.name/weblog/2008/01/ie7-2/)
>> >
>> > How in the world is that relevant? His javascript does not use:
>> >
>> > 1. Jscript conditionals
>> > 2. conditional compilation
>> >
>> > His front-end code uses HTML conditional comments, but that's a
>> > completely tangential issue, and has no parallel to what is being
>> > discussed in this thread.
>> >
>> > > One good example of a measurable benefit. Not in speed but in
>> > > stability would be jQ UI. They would benefit even more from separating
>> > > IE vs NON-IE code. The amount of greef (it seems to me) they are
>> > > getting because of IE, is v.large. Most of the discussions in jQ UI
>> > > forum are formed arround IE 6,7,8 issues ...
>> >
>> > Then take it to the jQuery UI forum. You do realize you're on the
>> > jQuery mailing list?
>> >
>> > Although, I'd wager a fairly large sum of money that after all the
>> > work in separating it out, you'll not help those people with IE6/7/8
>> > issues one bit. Most, if not all, of the issues are not because the
>> > IE branches are together with non-IE branches.
>> >
>> > > Ah, yes, and yet another no-brainer is CSS. CSS comunity has solved
>> > > (is solving) many difficult issues by separating IE vs NON-IE CSS ,
>> > > mostly through conditional HTML inclusion. I think this is very
>> > > measurable benefit in the context of web apps stability. I do not know
>> > > what was before, but it seems no one "over there" is confused with the
>> > > beenefits of using
>> >
>> > You're conflating problem domains. It muddles your point and confuses
>> > the hell out of everyone.
>> >
>> > HTML conditional comments were used because it was the *only* way to
>> > properly ascertain browser version without resorting to CSS hacks,
>> > which could change with each new browser.
>> >
>> > This isn't analogous to the code branching inside jQuery, especially
>> > after it switched to feature detection.
>> >
>> > > Lastly. Of course tests need to be done. What makes you think I do not
>> > > think so? But please understand the conceptual advancement here which
>> > > is not going to be measurable just in the terms of raw-speed.
>> >
>> > Then stop saying, and I quote, "This kind of delivery, would show
>> > measurable benefits (in spead increase and stability)."
>> >
>> > -- dz
>>
>>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"jQuery Development" group.
To post to this group, send email to jquery-dev@googlegroups.com
To unsubscribe from this group, send email to
jquery-dev+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/jquery-dev?hl=en
-~----------~----~----~----~------~----~------~--~---
