3rd party control library IE9 support suspiciously absent
-
We're about to release an update to an asp.net web application. We always wait to release until all the 3rd party control library vendors have published their final update releases of the year. This way we get the most stable versions of the controls. Telerik and DevExpress are big ones that we use, Telerik heavily and DevExpress not so much but oddly neither has full support for IE9 yet, in fact it could be said they have very little support for IE9 and are both evasive about it and when it's coming. This is contrary to how both of them normally operate, normally, they are all over any new technology and out of the gate have support as early as possible. I suspect this has something to do with the poor economy right now, both are waiting as late as possible to provide support so that people are forced to buy their latest version rather than getting the benefit in the previous version. It's a new window of opportunity for them because they know everyone will need ie9 support and if they just wait a few months they get to put IE9 support in the first major update of the new year and charge a full upgrade to people who have no subscription or have let it lapse. Microsoft should be kicking their asses any way they can to have early support as possible, it's in their best interest. Timing sucks for us, we're subscribers so we have the new updates anyway but we're loath to install a new major release of components because they're are inevitably dozens of bugs in the initial release and we can't subject our customers to that, on the other hand we've had to force ie8 compatibility mode using a meta tag in all our pages to work with ie9 fully. Kind of a rock and a hard place. No one will probably notice anyway.
There is no failure only feedback
-
We're about to release an update to an asp.net web application. We always wait to release until all the 3rd party control library vendors have published their final update releases of the year. This way we get the most stable versions of the controls. Telerik and DevExpress are big ones that we use, Telerik heavily and DevExpress not so much but oddly neither has full support for IE9 yet, in fact it could be said they have very little support for IE9 and are both evasive about it and when it's coming. This is contrary to how both of them normally operate, normally, they are all over any new technology and out of the gate have support as early as possible. I suspect this has something to do with the poor economy right now, both are waiting as late as possible to provide support so that people are forced to buy their latest version rather than getting the benefit in the previous version. It's a new window of opportunity for them because they know everyone will need ie9 support and if they just wait a few months they get to put IE9 support in the first major update of the new year and charge a full upgrade to people who have no subscription or have let it lapse. Microsoft should be kicking their asses any way they can to have early support as possible, it's in their best interest. Timing sucks for us, we're subscribers so we have the new updates anyway but we're loath to install a new major release of components because they're are inevitably dozens of bugs in the initial release and we can't subject our customers to that, on the other hand we've had to force ie8 compatibility mode using a meta tag in all our pages to work with ie9 fully. Kind of a rock and a hard place. No one will probably notice anyway.
There is no failure only feedback
I can sort of understand the control manufactures reluctance. IE9 is a big change, and it's still in beta. Releasing official support for a beta product can lead to a lot of support problems, since when the beta changes, and then breaks your released product, you now have a lot of customer shouting at you, since your product now doesn't work.
-
I can sort of understand the control manufactures reluctance. IE9 is a big change, and it's still in beta. Releasing official support for a beta product can lead to a lot of support problems, since when the beta changes, and then breaks your released product, you now have a lot of customer shouting at you, since your product now doesn't work.
Except they have a long history of supporting new beta technology with a disclaimer that everyone accepts. It's their job to be on the cutting edge because they have to lead the end user developer by months in order for the system to all work.
There is no failure only feedback
-
We're about to release an update to an asp.net web application. We always wait to release until all the 3rd party control library vendors have published their final update releases of the year. This way we get the most stable versions of the controls. Telerik and DevExpress are big ones that we use, Telerik heavily and DevExpress not so much but oddly neither has full support for IE9 yet, in fact it could be said they have very little support for IE9 and are both evasive about it and when it's coming. This is contrary to how both of them normally operate, normally, they are all over any new technology and out of the gate have support as early as possible. I suspect this has something to do with the poor economy right now, both are waiting as late as possible to provide support so that people are forced to buy their latest version rather than getting the benefit in the previous version. It's a new window of opportunity for them because they know everyone will need ie9 support and if they just wait a few months they get to put IE9 support in the first major update of the new year and charge a full upgrade to people who have no subscription or have let it lapse. Microsoft should be kicking their asses any way they can to have early support as possible, it's in their best interest. Timing sucks for us, we're subscribers so we have the new updates anyway but we're loath to install a new major release of components because they're are inevitably dozens of bugs in the initial release and we can't subject our customers to that, on the other hand we've had to force ie8 compatibility mode using a meta tag in all our pages to work with ie9 fully. Kind of a rock and a hard place. No one will probably notice anyway.
There is no failure only feedback
What exactly do you mean by supporting IE9? Make use of HTML5 features or just run on IE9?
-
We're about to release an update to an asp.net web application. We always wait to release until all the 3rd party control library vendors have published their final update releases of the year. This way we get the most stable versions of the controls. Telerik and DevExpress are big ones that we use, Telerik heavily and DevExpress not so much but oddly neither has full support for IE9 yet, in fact it could be said they have very little support for IE9 and are both evasive about it and when it's coming. This is contrary to how both of them normally operate, normally, they are all over any new technology and out of the gate have support as early as possible. I suspect this has something to do with the poor economy right now, both are waiting as late as possible to provide support so that people are forced to buy their latest version rather than getting the benefit in the previous version. It's a new window of opportunity for them because they know everyone will need ie9 support and if they just wait a few months they get to put IE9 support in the first major update of the new year and charge a full upgrade to people who have no subscription or have let it lapse. Microsoft should be kicking their asses any way they can to have early support as possible, it's in their best interest. Timing sucks for us, we're subscribers so we have the new updates anyway but we're loath to install a new major release of components because they're are inevitably dozens of bugs in the initial release and we can't subject our customers to that, on the other hand we've had to force ie8 compatibility mode using a meta tag in all our pages to work with ie9 fully. Kind of a rock and a hard place. No one will probably notice anyway.
There is no failure only feedback
I don't think IE9 even has a release date yet. I'd be happy right now if Telerik would fix more bugs right now, I think we could buy them out right now we have so many Telerik "points". :-D
-
What exactly do you mean by supporting IE9? Make use of HTML5 features or just run on IE9?
-
I don't think IE9 even has a release date yet. I'd be happy right now if Telerik would fix more bugs right now, I think we could buy them out right now we have so many Telerik "points". :-D
-
Just run on IE9, stuff that works in IE8 doesn't work in IE9, basic stuff.
There is no failure only feedback
Then I think, it is a pretty premature to do that as IE9 has lot of bugs/issues. There are lot of things which are broken in IE9 right now which probably will be resolved by the time of RC. In the ideal case, what is already done to support FireFox and Chrome should work in IE9. But of course, it is not as simple as that.
-
Really? I've had pretty good luck with them, though we're using the asp.net ajax controls, which ones are you using?
There is no failure only feedback
We use the asp.net ajax controls, and ran into a number of things: 1. when you add more rows to an ajax grid the styles set on the server side are not applied. (work around) 2. combo boxes will expand with a random number of rows each time (fixed) 3. all sorts of stuff with the ajax grid filters 4. They use a crazy number of .css and .js files for every control. This kills the performance of high latency connections. 5. The tabs and combo box formatting is messed up whenever the VS2010 testing client is attached even for manual scripts. This is definitely a problem with both products, and we work around it by running the test client by rdping into a box. Those are only the ones that I can remember off the top of my head.
-
We use the asp.net ajax controls, and ran into a number of things: 1. when you add more rows to an ajax grid the styles set on the server side are not applied. (work around) 2. combo boxes will expand with a random number of rows each time (fixed) 3. all sorts of stuff with the ajax grid filters 4. They use a crazy number of .css and .js files for every control. This kills the performance of high latency connections. 5. The tabs and combo box formatting is messed up whenever the VS2010 testing client is attached even for manual scripts. This is definitely a problem with both products, and we work around it by running the test client by rdping into a box. Those are only the ones that I can remember off the top of my head.
Huh, weird, we use all that stuff other than the vs2010 testing client heavily throughout a pretty big asp.net application and so far I've somehow avoided stumbling on any of those though they are all things I work with all the time. I did find a few other things over the years but all worked around or fixed. On the bright side I've found Telerik to provide the best support of the half dozen or so 3rd party component companies we deal with.
There is no failure only feedback
-
Then I think, it is a pretty premature to do that as IE9 has lot of bugs/issues. There are lot of things which are broken in IE9 right now which probably will be resolved by the time of RC. In the ideal case, what is already done to support FireFox and Chrome should work in IE9. But of course, it is not as simple as that.
-
Huh, weird, we use all that stuff other than the vs2010 testing client heavily throughout a pretty big asp.net application and so far I've somehow avoided stumbling on any of those though they are all things I work with all the time. I did find a few other things over the years but all worked around or fixed. On the bright side I've found Telerik to provide the best support of the half dozen or so 3rd party component companies we deal with.
There is no failure only feedback
A lot of the stuff is pretty specific to our organization and the design of the site. The controls are great for what they do, but I just have reservations about the swiss army knife approach to development in general. I can't imagine what their QA should be like to do decent testing of all the different configuration options that their controls offer. Some of the special cases we introduce are having tons of large documents accessed through a web site, an intra net that spans the globe India to Texas with a stop over in South Africa with 50 users, dense screens with somewhere around 10 rich edit controls for those documents, most of them limited to 10,000 characters. :-D One editor page has a couple hundred edit, drop down, and calendar controls on it, etc., which doesn't use the Telerik controls because they generated over 20 Megs of HTML.
John C wrote:
On the bright side I've found Telerik to provide the best support of the half dozen or so 3rd party component companies we deal with.
Wow, the other guys must be horrible. :-D
-
Huh, I had no idea, I thought it was getting pretty much to the done stage lately. Quite a number of people are using it as their main daily browser without issue. If it's that buggy then I can understand completely.
There is no failure only feedback
They had one beta, and have since gone back and done two platform previews. Early last year they were talking about releasing at the end of 2010, early 2011. I think it will still be a while as this is a major re-write.
-
A lot of the stuff is pretty specific to our organization and the design of the site. The controls are great for what they do, but I just have reservations about the swiss army knife approach to development in general. I can't imagine what their QA should be like to do decent testing of all the different configuration options that their controls offer. Some of the special cases we introduce are having tons of large documents accessed through a web site, an intra net that spans the globe India to Texas with a stop over in South Africa with 50 users, dense screens with somewhere around 10 rich edit controls for those documents, most of them limited to 10,000 characters. :-D One editor page has a couple hundred edit, drop down, and calendar controls on it, etc., which doesn't use the Telerik controls because they generated over 20 Megs of HTML.
John C wrote:
On the bright side I've found Telerik to provide the best support of the half dozen or so 3rd party component companies we deal with.
Wow, the other guys must be horrible. :-D
Yeah that's pretty specialized all right. In my experience Telerik have fixed all the speed and size issues with a single assembly now that reuses javascript for multiple controls on a page, maybe you have an old version or are using some controls I don't?
Andy Brummer wrote:
Wow, the other guys must be horrible.
DevExpress is the next best, the rest are extremely horrible. Honestly though I've had nothing but superb service from Telerik, they bend over backwards consistently and go way beyond what I've come to expect from anybody. Unless something has changed in the last few months I'd give them the prize for support over any company I've ever dealt with in decades of needing support for myself or on behalf of others.
There is no failure only feedback
-
They had one beta, and have since gone back and done two platform previews. Early last year they were talking about releasing at the end of 2010, early 2011. I think it will still be a while as this is a major re-write.
-
Yeah that's pretty specialized all right. In my experience Telerik have fixed all the speed and size issues with a single assembly now that reuses javascript for multiple controls on a page, maybe you have an old version or are using some controls I don't?
Andy Brummer wrote:
Wow, the other guys must be horrible.
DevExpress is the next best, the rest are extremely horrible. Honestly though I've had nothing but superb service from Telerik, they bend over backwards consistently and go way beyond what I've come to expect from anybody. Unless something has changed in the last few months I'd give them the prize for support over any company I've ever dealt with in decades of needing support for myself or on behalf of others.
There is no failure only feedback
There are only a few js and css files per type of control and adding multiple of the same type of control isn't an issue. What is getting us are the kitchen sink pages where we use many different types of controls on the same page. Each one of those seems to use 2-3 different files. Plus we have 2-3 files for the wcf services and 4-5 files for various custom controls. It all adds up to 30-40 resources downloaded per page, when in most cases we really could just use jQuery and simple html. Most of the page size is driven by the asp.net ids generated per control and the number of server side controls that were used on these pages. The workaround is a module that sets the expires header to next year, and version flags that we update every release so users only get the extra hit every few weeks.
John C wrote:
Honestly though I've had nothing but superb service from Telerik, they bend over backwards consistently and go way beyond what I've come to expect from anybody. Unless something has changed in the last few months I'd give them the prize for support over any company I've ever dealt with in decades of needing support for myself or on behalf of others.
We've always gotten a response from them, it's just that we ran into a batch of cases where that response was, it's a know issue that we aren't fixing, or that doesn't work with ajax. Have some points.
-
Latest rumour is a release candidate by the end of January.
There is no failure only feedback
cool. I can't wait. I've been messing around with the various 2d canvas contexts for a while now, and starting to dig into the webGL stuff. There will be some really cool and horrible stuff out when that goes mainstream.
-
cool. I can't wait. I've been messing around with the various 2d canvas contexts for a while now, and starting to dig into the webGL stuff. There will be some really cool and horrible stuff out when that goes mainstream.
I've already written a signature control in our app possible because of the canvas element in html5 which works incredibly well on every modern browser even in ie9 in compatibility mode strangely enough. Lot's of possibilities and many ugly sites in our future again I'm sure.
There is no failure only feedback
-
There are only a few js and css files per type of control and adding multiple of the same type of control isn't an issue. What is getting us are the kitchen sink pages where we use many different types of controls on the same page. Each one of those seems to use 2-3 different files. Plus we have 2-3 files for the wcf services and 4-5 files for various custom controls. It all adds up to 30-40 resources downloaded per page, when in most cases we really could just use jQuery and simple html. Most of the page size is driven by the asp.net ids generated per control and the number of server side controls that were used on these pages. The workaround is a module that sets the expires header to next year, and version flags that we update every release so users only get the extra hit every few weeks.
John C wrote:
Honestly though I've had nothing but superb service from Telerik, they bend over backwards consistently and go way beyond what I've come to expect from anybody. Unless something has changed in the last few months I'd give them the prize for support over any company I've ever dealt with in decades of needing support for myself or on behalf of others.
We've always gotten a response from them, it's just that we ran into a batch of cases where that response was, it's a know issue that we aren't fixing, or that doesn't work with ajax. Have some points.
Hi guys, My name is Georgi Tunev and I am Telerik's Technical Support Director. I just wanted to assure you that we are monitoring closely IE9's development and we are testing our controls against the latest BETAs. The upcoming Q1 2011 release (scheduled for this week) will have all fixes for the different issues that we found so far and of course we will do our best to clear any future problems with the official IE9 release as soon as possible. As for the quality of our support service, when we say "we will do our best", we really mean it :) There are cases where we cannot be of much help - due to browsers' bugs, or impossibility to implement certain feature (because the framework does not support it for example), but if the problem is indeed on our side, we will fix it. Of course, fixes have different priorities and some issues are taken care of earlier than others. In any case, if you face a problem with our products, just let us know. I promise you that we will investigate it carefully and try to provide you with an appropriate solution in the shortest time. Have a productive week, Georgi Tunev Telerik