Dropping IE8 support in useragent-less GWT

[Goktug Gokdogan]

We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations.

Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core).

Let me know if you have any concerns.

 - Goktug

[Colin Alworth]

Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js).

Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/).

If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper.

[Goktug Gokdogan]

On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth <nilo...@gmail.com> wrote:

Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js).

A cross-compiled app is a good example that doesn't need User where you can, for example, use closure to develop the UI.

I specifically pointed IE8 as it is the only supported browser missing Object.create functionality and such apps that just depends on java.emul are paying the price of IE8. On the other hand by just inheriting useragent.UserAgent (not necessarily the User) an app can target older browsers.

 

Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/).

If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper.

Can you be more specific?

 

On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote:

We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations.

Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core).

Let me know if you have any concerns.

 - Goktug

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Colin Alworth]

Sorry for the delay in getting back to you (and to my reviews, got at least one up to date now), finally catching up after a few days off.

I guess I was looking for "We want to use Object.create in Core" in your initial email. If we also wanted any/all of the features I had listed (fast byte[]/int[]/double[] for everyone? rpc-over-ws? cors?), dropping ie9 from Core might have also made sense.

I'm not actually encouraging cutting IE9 (or 8), esp from User, but if we want to move some emulation code off to UserAgent or User, letting go of IE9 may make sense.

My email was written from the perspective of "huh, Goktug wants to drop IE8 because it will make *something* easier - won't also dropping IE9 make more something even more easier?". With the caveat that all you are interested in is Object.create, targeting only IE8 makes sense.

On Tuesday, July 1, 2014 12:02:50 AM UTC-5, Goktug Gokdogan wrote:

On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth <nilo...@gmail.com> wrote:

Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js).

A cross-compiled app is a good example that doesn't need User where you can, for example, use closure to develop the UI.

I specifically pointed IE8 as it is the only supported browser missing Object.create functionality and such apps that just depends on java.emul are paying the price of IE8. On the other hand by just inheriting useragent.UserAgent (not necessarily the User) an app can target older browsers.

 

Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/).

If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper.

Can you be more specific?

 

On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote:

We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations.

Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core).

Let me know if you have any concerns.

 - Goktug

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.

[Goktug Gokdogan]

On Mon, Jul 14, 2014 at 5:02 PM, Colin Alworth <nilo...@gmail.com> wrote:

Sorry for the delay in getting back to you (and to my reviews, got at least one up to date now), finally catching up after a few days off.

I guess I was looking for "We want to use Object.create in Core" in your initial email. If we also wanted any/all of the features I had listed (fast byte[]/int[]/double[] for everyone? rpc-over-ws? cors?), dropping ie9 from Core might have also made sense.

BTW, with Core, I mean literally com.google.gwt.core.Core (which includes the java.lang.emul as well) and we are not really dropping support; just changing the defaults when useragent is not available.

Currently IE8 was good enough to get the benefit I was looking for (i.e Object.create(null)) but I think we can simply bump up the minimum version to IE10 if there are other good benefits. I think it is fair to require UserAgent dependency for anything older.

 

I'm not actually encouraging cutting IE9 (or 8), esp from User, but if we want to move some emulation code off to UserAgent or User, letting go of IE9 may make sense.

My email was written from the perspective of "huh, Goktug wants to drop IE8 because it will make *something* easier - won't also dropping IE9 make more something even more easier?". With the caveat that all you are interested in is Object.create, targeting only IE8 makes sense.

Yep, exactly :)

 

On Tuesday, July 1, 2014 12:02:50 AM UTC-5, Goktug Gokdogan wrote:

On Mon, Jun 30, 2014 at 8:46 PM, Colin Alworth <nilo...@gmail.com> wrote:

Sounds great, but is there a reason that we're now starting at IE9+ and not IE10+, thus giving us typed arrays, web workers, web sockets, etc? I only ask because the kind of case where you are giving up User (and Widget, RPC, Timer, and other fairly high-level apis) seems to suggest that you might not be writing for a browser at all (htmlunit, nashorn, web worker, node.js).

A cross-compiled app is a good example that doesn't need User where you can, for example, use closure to develop the UI.

I specifically pointed IE8 as it is the only supported browser missing Object.create functionality and such apps that just depends on java.emul are paying the price of IE8. On the other hand by just inheriting useragent.UserAgent (not necessarily the User) an app can target older browsers.

 

Dan definitely has a point that if we're supporting modern browsers for a core chunk of functionality, we really shouldn't let 'modern' be 'whatever junk still happens to be running rather tha updating'. And besides, I can't always be That Guy pushing to keep all versions forever, just because IE8 is still 11% of North America's browser usage (really: http://theie8countdown.com/).

If we're cutting a browser for being old/bad/whatever in Core, but leaving support for it still in User, we should consider carefully why we *aren't* cutting deeper.

Can you be more specific?

 

On Monday, June 30, 2014 2:59:12 PM UTC-5, Goktug Gokdogan wrote:

We are planning to drop support for IE8 if the application doesn't inherit c.g.gwt.useragent.UserAgent and hence not have browser permutations.

Nearly all of today's apps inherit User so they will not be affected by this change. In the future more apps will only inherit Core however they shouldn't need to pay price of IE8 support (currently they do because there are no permutations in Core).

Let me know if you have any concerns.

 - Goktug

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-contributors+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/45b68163-0d07-4a6c-9932-412232e2f71d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.

To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/8e78df45-4d71-4dcf-9fea-52d32fc58d65%40googlegroups.com.

[Jens]

BTW, with Core, I mean literally com.google.gwt.core.Core (which includes the java.lang.emul as well) and we are not really dropping support; just changing the defaults when useragent is not available.

Currently IE8 was good enough to get the benefit I was looking for (i.e Object.create(null)) but I think we can simply bump up the minimum version to IE10 if there are other good benefits. I think it is fair to require UserAgent dependency for anything older.

And whats the general usefulness of such a change? Wouldn't any app inherit UserAgent anyways because it gets inherited by basic things like DOM.gwt.xml? I have a hard time imagining an "app" that gets compiled to JS but only depends on Core and does not indirectly pull in UserAgent.

And if I write a library that only inherits Core how does separate compilation behave if that library is not a fileset and the app that uses the library has inherited UserAgent? 

-- J.

[Alain Ekambi]

"I have a hard time imagining an "app" that gets compiled to JS but only depends on Core and does not indirectly pull in UserAgent"

We use GWT to write Titanium applications for example. And we dont necessary need UserAgent there. Only Core. 

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/02a508a8-33b4-4cdd-a9d9-e1037d070566%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Alain Ekambi

Co-Founder

Ahomé Innovation Technologies

http://www.ahome-it.com/

[Thomas Broyer]

On Tuesday, July 15, 2014 10:54:04 AM UTC+2, Jens wrote:

BTW, with Core, I mean literally com.google.gwt.core.Core (which includes the java.lang.emul as well) and we are not really dropping support; just changing the defaults when useragent is not available.

Currently IE8 was good enough to get the benefit I was looking for (i.e Object.create(null)) but I think we can simply bump up the minimum version to IE10 if there are other good benefits. I think it is fair to require UserAgent dependency for anything older.

And whats the general usefulness of such a change? Wouldn't any app inherit UserAgent anyways because it gets inherited by basic things like DOM.gwt.xml? I have a hard time imagining an "app" that gets compiled to JS but only depends on Core and does not indirectly pull in UserAgent.

I believe Google builds applications that use Elemental and/or JsInterop, so they don't use c.g.g.dom.DOM or any other thing that inherits UserAgent.

Goktug also pointed out earlier in this thread "cross-compiled apps" where the UI is built with Closure Library. I suspect this might be the case of Google Drive (Spreadsheets) where GWT is only used to compile to JS those bits of Java that are shared with the server, Android app and iOS app (through J2ObjC); from what I understood, in Spreadsheets that would be the code necessary to parse and evaluate formulas. 

[Jens]

I believe Google builds applications that use Elemental and/or JsInterop, so they don't use c.g.g.dom.DOM or any other thing that inherits UserAgent.

Goktug also pointed out earlier in this thread "cross-compiled apps" where the UI is built with Closure Library. I suspect this might be the case of Google Drive (Spreadsheets) where GWT is only used to compile to JS those bits of Java that are shared with the server, Android app and iOS app (through J2ObjC); from what I understood, in Spreadsheets that would be the code necessary to parse and evaluate formulas. 

Thanks for the examples. Such cross compiled apps probably doesn't have the concept of permutations but they maybe also want to support older browsers. Wouldn't it make sense then to have something like Core.gwt.xml which is strictly modern, and CoreWithLegacySupport.gwt.xml which inherits Core and introduces runtime feature checks here and there? That way such apps don't have to pull in UserAgent at all and its probably more straight forward than saying: "If you need legacy support then inherit core, useragent and possibly collapse all properties if you want a single permutation". 

Also GWT would have the control how it provides legacy support and far in the future if GWT only has a modern and a legacy permutation then Core could provide the modern permutation while CoreWithLegacySupport introduces the legacy permutation and UserAgent maps all the user agents to modern or legacy.

-- J.

[Brian Slesinsky]

It would make sense in principle but we don't know anyone who wants to target older browsers without also using permutations.

--
You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/74f12c72-4e7e-4167-b60e-564448d5d918%40googlegroups.com.

[Colin Alworth]

I think Alain's use case is a legit one, and the SmartGWT product probably also lives in that world to an extent - let the user write Java that mostly interacts with JS libraries, and let them worry about which browser is running, but compile the code to run anywhere. I can't speak to their 'older browser' need though - Alain, what do you guys target?

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/CA%2B%2BRBT_EmOdm%2BCNSSom9-RnBdoio74ure2aELE49kRExgiMnXw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
218.248.6165
nilo...@gmail.com

[James Nelson]

 Just to toss in another use case...

 

I develop a cross-platform java library that exposes generic apis that run on multiple platforms;

each module inherits the minimum possible dependencies, and all platform-specific code is isolated from shared APIs.

I never touch anything in User unless I specifically need to write an implementation that integrates with some other project,

and such dependencies never, ever make it into the shared modules.
Elemental or even just java emul is plenty to create a module of generic functionality,

and I'm very pleased that GWT is keeping its permutations where they belong.

With Elemental being built against webkit's hmtl5 IDLs, it can be the single permutations "standards way" (tm),

with c.g.g.user for all "legacy" code.

If you need to support ancient browsers, do the enterprise thing and bend over backwards to maintain support. 
If you just want to leverage java in a javascript world, then GWT does that too.

Win-win, I'd say. :)

[Alain Ekambi]

@Colin.

We do target Titanium Mobile. Wich dont have any noting of DOM or  UserAgent related stuff. We also have a GWT  binding for DevKit (http://docs.gameclosure.com/).

Right now we have to write some patches just to get rid(override) the the UserAgent/DOM related stuff. And that on each GWT release.

Would be super coool if dont have to

--

You received this message because you are subscribed to the Google Groups "GWT Contributors" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-web-toolkit-co...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-web-toolkit-contributors/bc7863a7-2f63-409c-a6f2-ab2e397e5354%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--