Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #15097 > unrolled thread

JQuery 2.0 drops support for IE < 9

Back to article view | Back to comp.lang.javascript

Contents

  JQuery 2.0 drops support for IE < 9 perryv@gmail.com - 2012-07-18 20:43 -0700
    Re: JQuery 2.0 drops support for IE < 9 Stefan Weiss <krewecherl@gmail.com> - 2012-07-19 07:18 +0200
      Re: JQuery 2.0 drops support for IE < 9 John G Harris <john@nospam.demon.co.uk> - 2012-07-19 08:53 +0100
      Re: JQuery 2.0 drops support for IE < 9 Matt McDonald <matt@fortybelow.ca> - 2012-07-19 08:18 -0600
        Re: JQuery 2.0 drops support for IE < 9 Stefan Weiss <krewecherl@gmail.com> - 2012-07-19 23:20 +0200
          Thunderbird's posting behaviour (was Re: JQuery 2.0 drops support for IE < 9) Mike Winter <usenet@michael-winter.me.invalid> - 2012-07-19 22:37 +0100
          Re: JQuery 2.0 drops support for IE < 9 Hans-Georg Michna <hans-georgNoEmailPlease@michna.com> - 2012-07-20 15:11 +0200
    Re: JQuery 2.0 drops support for IE < 9 Gregor Kofler <usenet@gregorkofler.com> - 2012-07-19 12:46 +0200
      Re: JQuery 2.0 drops support for IE < 9 Gene Wirchenko <genew@ocis.net> - 2012-07-19 11:01 -0700

#15097 — JQuery 2.0 drops support for IE < 9

JQuery group decides to move forward and drop support for old IE 6, 7 and 8 in version 2.0 of their library.

http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
http://blog.jquery.com/2012/07/01/jquery-1-9-and-2-0-tldr-edition/

[toc] | [next] | [standalone]

#15098

On 2012-07-19 05:43, perryv@gmail.com wrote:
> JQuery group decides to move forward and drop support for old IE 6,
> 7 and 8 in version 2.0 of their library.

Yeah, I read that too. It sounds more drastic than it actually is. From
what I've read, they're creating a version 2 which is targeted at
clients that don't require all the handholding and workarounds that
earlier IE versions needed. It makes certain assumptions (for example,
that methods like document.querySelectorAll are available natively),
which means that a lot of code can be cut. This version can then be
deployed in controlled environments or delivered to certain mobile
devices. It's not meant to be used on the web without a fallback.
Meanwhile, development for the 1.x branch continues in parallel with the
2.x branch.

I think it's a good idea. The collection of tools and methods that I use
(and sometimes call a "library") has dropped support for quirks mode
some years ago. It works because I know where it's deployed - in
websites where I have control over the markup. Supporting quirks mode
would serve no purpose at all, it would only add a lot of unnecessary
code branches. Unfortunately, I don't have the luxury of being able to
ignore older browsers just yet. As soon as the last of those clients is
gone, I'll be removing code and dropping support, too.

The drawback is that the jQuery devs will have to support two different
code bases, likely for a very long time, and that they will have to deal
with the inevitable complaints by people who downloaded the newest
version without bothering to read the instructions.

- stefan

[toc] | [prev] | [next] | [standalone]

#15099

On Thu, 19 Jul 2012 at 07:18:44, in comp.lang.javascript, Stefan Weiss
wrote:
>On 2012-07-19 05:43, perryv@gmail.com wrote:
>> JQuery group decides to move forward and drop support for old IE 6,
>> 7 and 8 in version 2.0 of their library.

  <snip>
>The drawback is that the jQuery devs will have to support two different
>code bases, likely for a very long time, and that they will have to deal
>with the inevitable complaints by people who downloaded the newest
>version without bothering to read the instructions.

It's not the people who downloaded JQuery who will complain. It's the
poor old customers of the companies who allowed the web designer to do
it. And when the customer complains to the webmaster, he will say "It's
your browser setup".

  John
-- 
John Harris

[toc] | [prev] | [next] | [standalone]

#15102

On 12-07-18 11:18 PM, Stefan Weiss wrote:

> Yeah, I read that too. It sounds more drastic than it actually is. From
> what I've read, they're creating a version 2 which is targeted at
> clients that don't require all the handholding and workarounds that
> earlier IE versions needed. It makes certain assumptions (for example,
> that methods like document.querySelectorAll are available natively),
> which means that a lot of code can be cut. This version can then be
> deployed in controlled environments or delivered to certain mobile
> devices. It's not meant to be used on the web without a fallback.
> Meanwhile, development for the 1.x branch continues in parallel with the
> 2.x branch.

And this is because the Zepto project cut into the project's
market on mobile devices. A self-fork is a disastrous move, and
leads one to question the competence of the developers behind
the project.

> I think it's a good idea. The collection of tools and methods that I use
> (and sometimes call a "library") has dropped support for quirks mode
> some years ago. It works because I know where it's deployed - in
> websites where I have control over the markup. Supporting quirks mode
> would serve no purpose at all, it would only add a lot of unnecessary
> code branches. Unfortunately, I don't have the luxury of being able to
> ignore older browsers just yet. As soon as the last of those clients is
> gone, I'll be removing code and dropping support, too.

It's a reflection of a poor design. An API that couples itself to
a certain subset of browsers will always be unstable. Optimally,
the developer should be able to choose what features to support
when implementing the API. This is the design I stick to, and I
know David Mark has implemented something similar.

There are certain cases such as Text Node traversal that need
a fork to function, but deeming such a fork optional nullifies
the potential damage it can cause in the future.

That fork alone underscores the importance of an optional API,
which is something that the jQuery project is beginning to
figure out, but will probably take months to years to implement
because of interspersed dependencies.

> The drawback is that the jQuery devs will have to support two different
> code bases, likely for a very long time, and that they will have to deal
> with the inevitable complaints by people who downloaded the newest
> version without bothering to read the instructions.

Their ignorance does not merit my pity, nor anyone else's.

-- 
Matt McDonald: Web/Flash Developer; Edmonton, Alberta, Canada

[toc] | [prev] | [next] | [standalone]

#15108

On 2012-07-19 16:18, Matt McDonald wrote:
> On 12-07-18 11:18 PM, Stefan Weiss wrote:
>> The collection of tools and methods that I use
>> (and sometimes call a "library") has dropped support for quirks mode
>> some years ago. It works because I know where it's deployed - in
>> websites where I have control over the markup. Supporting quirks mode
>> would serve no purpose at all, it would only add a lot of unnecessary
>> code branches. Unfortunately, I don't have the luxury of being able to
>> ignore older browsers just yet. As soon as the last of those clients is
>> gone, I'll be removing code and dropping support, too.
> 
> It's a reflection of a poor design. An API that couples itself to
> a certain subset of browsers will always be unstable. Optimally,
> the developer should be able to choose what features to support
> when implementing the API.

The developer of a library can decide what features to offer and which
clients to support. The potential users of a library can then decide if
they agree with the developer's choices, and use the library or look
elsewhere.

There is a difference between being reasonably future-proof and
providing backward compatibility for every browser since the dawn of
time*. In my experience, it's inevitable that a line has to be drawn
somewhere. I see no point in offering support for clients which are so
different or so broken that a significant amount of workaround code
would have to be added (and tested and maintained) just for them.
Especially when those clients have all but vanished from the net, and
don't even show up in UA-statistics anymore.

In my case, my "library" is currently not even deployed on the general
Web anymore. It's used in a number of intranet applications, and the
user agents are known. The percentage of unsupported browsers loading
the library is 0.

I think I know where you're coming from with your criticism, and for
general purpose libraries I would agree with you. Where I disagree is
that any library that drops support for obsolete browsers (in its niche)
is inherently unstable.

I don't know enough about jQuery and its development model to comment on
how this decision will affect it. All I'm saying is that making a clean
break can be a healthy choice for a software project. The intended users
of jQuery 2.x will have no use for backward compatibility with IE7. If
anybody outside that target group uses it, they deserve what they get.

>> The drawback is that the jQuery devs will have to support two different
>> code bases, likely for a very long time, and that they will have to deal
>> with the inevitable complaints by people who downloaded the newest
>> version without bothering to read the instructions.
> 
> Their ignorance does not merit my pity, nor anyone else's.

I don't use jQuery myself, so I don't care much one way or the other. I
do kind of envy those working on v2, because they get to rewrite and
streamline their software and focus on modern methods. This is something
most developers dream of, but will rarely get paid to do.


- stefan


*) For the purposes of this discussion, I'm defining the dawn of time as
1995 :)


PS, just as I was about to hit "send", I noticed that your email address
has been added as CC. They *did* change something in the latest
Thunderbird update.

[toc] | [prev] | [next] | [standalone]

#15109 — Thunderbird's posting behaviour (was Re: JQuery 2.0 drops support for IE < 9)

On 19/07/2012 22:20, Stefan Weiss wrote:

[snip]
> PS, just as I was about to hit "send", I noticed that your email address
> has been added as CC. They *did* change something in the latest
> Thunderbird update.

Really? That's not the behaviour I see in 14.0. If I select Followup to 
compose a response, I'll post to the group. If I select Reply, I'll 
e-mail you. If I select Reply All, I'll do both.

Regards,
Mike

-- 
Michael Winter
Replace ".invalid" with ".uk" to reply by e-mail.

[toc] | [prev] | [next] | [standalone]

#15117

On Thu, 19 Jul 2012 23:20:38 +0200, Stefan Weiss wrote:

>The intended users
>of jQuery 2.x will have no use for backward compatibility with IE7.

IE8 has been said. That's strong.

Hans-Georg

[toc] | [prev] | [next] | [standalone]

#15100

Am 2012-07-19 05:43, perryv@gmail.com meinte:
> JQuery group decides to move forward and drop support for old IE 6, 7 and 8 in version 2.0 of their library.
>
> http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
> http://blog.jquery.com/2012/07/01/jquery-1-9-and-2-0-tldr-edition/

So all cross-browser code can be safely removed, right? What do I need a 
cross-browser library then? Ah, to keep the ingenious jQuery style of 
chaining and bizarre overloading.

Gregor

[toc] | [prev] | [next] | [standalone]

#15110

On Thu, 19 Jul 2012 12:46:45 +0200, Gregor Kofler
<usenet@gregorkofler.com> wrote:

>Am 2012-07-19 05:43, perryv@gmail.com meinte:
>> JQuery group decides to move forward and drop support for old IE 6, 7 and 8 in version 2.0 of their library.
>>
>> http://blog.jquery.com/2012/06/28/jquery-core-version-1-9-and-beyond/
>> http://blog.jquery.com/2012/07/01/jquery-1-9-and-2-0-tldr-edition/
>
>So all cross-browser code can be safely removed, right? What do I need a 
>cross-browser library then? Ah, to keep the ingenious jQuery style of 
>chaining and bizarre overloading.

     Stop talking sense, you!

Sincerely,

Gene Wirchenko

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web