|
Chris Maunder wrote: I'm back on a Mac.
The irony here is... I'm the Mac fanboy but yet I'm on a PC. What is this world coming to? You hear about Apple Silicon? They're switching back to RISC (via ARM this time) processors like in the olden days. Except now Windows will still run on ARM so we're still good on the dual boot front. Never thought we'd see the day.
Chris Maunder wrote: Know anyone who would love nothing better than to convert a WebForms site with roughly 300 web controls over to something better? Blazor and .NET 5? I mean: how hard could it be, really?
Hah... sure man. Just ask any rookie PM... all you need to do is press that shiny magic button to fix everything. That's what the sales pitch said.
Jeremy Falcon
|
|
|
|
|
Last I heard was no more bootcamp. Craig Federighi said pure virtualization is the path forward from here on in. "These hypervisors can be very efficient, so the need to direct boot shouldn’t really be the concern.”
If they can truly make virtual Windows as fast as native then that's a huge win.
If.
cheers
Chris Maunder
|
|
|
|
|
Chris Maunder wrote: If.
Dun dun dun.
Jeremy Falcon
|
|
|
|
|
You do have an advantage if you do support IE, and that is that you are more likely to get that business since others may not be supporting that browser. And there is also how much will it impact you to include ie support. It if is easy, just as well support IE. Depends on the tools you are using too.
|
|
|
|
|
Agreed. The biggest impact I'll have is JS code that's a bit bloated. It's not the end of the world, but say for instance... I use Babel a lot a lot. It runs and transpiles my TS and ESNext back down to ES5. For instance, to get something like a default parameter in IE11...
function test(x = "hello") {
}
Would end up like this...
function test(x) {
var x = arguments.length > 0 && arguments[0] !== undefined ? arguments[0] : "hello";
}
It's not the end of the world, but the more you do that and more stuff ads up. So, the site will be a bit slower for everyone because of IE... that 3% who won't upgrade.
Jeremy Falcon
|
|
|
|
|
40% of our customers are still on different versions of IE. They're a slow moving bunch. Apparently the average age of their computers are 7 years.
Luckily I don't do front end stuff.
|
|
|
|
|
Do you mind saying what your target audience is? For me, this is a retail site... which means I don't think I can drop IE11... but I want to.
Jeremy Falcon
|
|
|
|
|
Car retailers and workshops make up the bulk..
IT knowledge varies quite a bit I have to say. Half the customers are using the newest and best, and the other half buys a new computer when the old one breaks.
|
|
|
|
|
Gotcha. I appreciate the info. I may just have to let it ride for a couple of years to figure out the stats for my customers then. Thanks.
Jeremy Falcon
|
|
|
|
|
See it this way: every web site looking broken in IE11 is another nail in it's coffin. If it's a pain to support, help kill it.
|
|
|
|
|
I really, really want to. It's already done for the most part (the site), but I do think this will be the last time I support it.
Jeremy Falcon
|
|
|
|
|
The relevant statistic is not the percentage of people using IE11 on the 'net, but the percentage of people using IE11 that visit your site(s). How about maintaining counter for the different browsers used to visit your site, and seeing whether IE11 is worth the effort to support?
On future professional (== for pay) projects, I would quote two prices - one not including IE11 support, and one including it. I would also give the prospective client the latest IE11 usage statistics, and let them decide whether it is worth it.
Freedom is the freedom to say that two plus two make four. If that is granted, all else follows.
-- 6079 Smith W.
|
|
|
|
|
Agree 1,000% on that. I don't have those stats yet though as this site is brand new. Since the site is done for the most part, I may just let it run for a year or two and find that number out and then drop support for it if need be.
Jeremy Falcon
|
|
|
|
|
I've never specifically targeted IE, in any of its bastardized forms.
".45 ACP - because shooting twice is just silly" - JSOP, 2010 ----- You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010 ----- When you pry the gun from my cold dead hands, be careful - the barrel will be very hot. - JSOP, 2013
|
|
|
|
|
Dun dun dun.
Jeremy Falcon
|
|
|
|
|
I have a client whose internal, country-wide web app is implemented using Java Server Pages and applets which interact with local hardware through JNIs.
So, guess what I'll be stuck supporting until the dust buildup shorts out a vacuum tube at some point?
Oy!
Cheers,
Mike Fidler
"I intend to live forever - so far, so good." Steven Wright
"I almost had a psychic girlfriend but she left me before we met." Also Steven Wright
"I'm addicted to placebos. I could quit, but it wouldn't matter." Steven Wright yet again.
|
|
|
|
|
Jeremy Falcon
|
|
|
|
|
This is a more complex question that it may appear to be.
What is the projected user base? Desktop, mobile, or both? Where are customers located? Industrial nations? Mobile will be using a "modern" OS -- what desktop OS are in play?
Does your client have other commercial sites? If so, look at their stats for browser and OS. I found several stats sites that put IE as ~1.4% of the overall browser market, and ~5% for the desktop market. But that's overall -- these figures may not be accurate for YOUR market.
What is the projected budget to develop and maintain the site for IE? If the budget is 10% of the total and the expected revenue from IE customers is 3%, supporting IE is counter-productive.
My group made the decision to support the last 3 revs of the top 5 browsers + Edge. Costs are the driving factor, not only development time to support quirky browsers, but testing time to test that plethora of quirky browsers. We write current JavaScript and use Babble to transpile to support our planned user base, which also helps reduce dev & test costs.
Why Edge? It's built into Windows so it's present for most of our user base. [Granted, the change to Chromium has eliminated a lot of testing.]
That said, our site works on most modern browsers ... excepting IE (which is far from modern).
YMMV
|
|
|
|
|
Well, it's not for a client per se... it's for my own company so I'd be the client. So, there are no other sites demanding the requirement. It's just 25 years of web development has taught me... people don't always upgrade. So, I need at least a base stat to start with.
BryanFazekas wrote: these figures may not be accurate for YOUR market.
That's a good point. I have no idea what the figures are yet. Since the site is made to support IE11 I may just let it run for a couple years to find this info out... and drop support in two years if I get no customers using it.
BryanFazekas wrote: What is the projected budget to develop and maintain the site for IE? If the budget is 10% of the total and the expected revenue from IE customers is 3%, supporting IE is counter-productive.
Very good point.
BryanFazekas wrote: Why Edge? It's built into Windows so it's present for most of our user base. [Granted, the change to Chromium has eliminated a lot of testing.]
Agreed. Which is also the reason I'm still targeting IE11.
BryanFazekas wrote: which is far from modern
I think we should all switch back to VBScript.
Jeremy Falcon
|
|
|
|
|
On the plus side, if you determine that the costs of supporting IE are too high, convincing the client should be fairly easy!
I suggest you track the OS & browser usage of those who purchase from your site. Ignore the visitor statistics, as this will include bots, people who navigated accidentally, etc. The people who actually buy are your target audience.
Since the site is built (or mostly), the cost of developing for IE is already expended. Keep an accounting of the costs to maintain IE and contrast that with your overall support costs and number of buyers who use IE. With the site built, if the support cost is low, it probably doesn't matter.
However, when you eventually rebuild the site or if you build another, the statistics will help you decide go/no-go for supporting IE.
Six months after you go live, please post statistics (OS and browser) on your customer base. I'm interested in seeing what the reality is.
|
|
|
|
|
Jeremy Falcon
|
|
|
|
|
Two things, my friend.
- If they are using IE-something, it means this is a public machine nobody has cared to give maintenance, so it's always slow and people don't expect otherwise
- Using polyfills was supposed to be an interim solution, since as it's author suggested "if you removed the polyfill script, your code would continue to work, without any changes required in spite of the polyfill being removed" which, of course, is impossible in modern context. So most normal polyfillers like core-js and CSS3 PIE use lots of convolution to make this work.
With that in mind, the appropriate way to go is to avoid polyfills altogether and start creating more basic "shims", that will actually break the site if not found.
Since nobody has the time to do those, I would suggest you use a "critical path" approach.
Since you want your WEBSITE TO BE BROWSED BY EVERYONE, BUT NOT EVERYWHERE, just consider this. Target IE11 for essential pages that give an overview of your company and its services. Any deeper links are safe Chrome only, as they will be visited by the stakeholders on their own devices, including iOS and Android.
Remember that if a page is just tooo slow on the common machine, anybody can fire up a browser on its phone and get the missing content.
|
|
|
|
|
Member 2896020 wrote: If they are using IE-something, it means this is a public machine nobody has cared to give maintenance, so it's always slow and people don't expect otherwise That's a good point.
Member 2896020 wrote: Using polyfills was supposed to be an interim solution, since as it's author suggested "if you removed the polyfill script, your code would continue to work, without any changes required in spite of the polyfill being removed" which, of course, is impossible in modern context. So most normal polyfillers like core-js and CSS3 PIE use lots of convolution to make this work. I get the technical pros and cons. Polyfills aren't 100% perfect though. It's just one example of many. Autoprefixer isn't perfect, etc. For instance, in some versions of IE11 flex shorthand can't be parsed but in other versions of IE11 it can be. Autoprefixer won't catch this. The issue I'm addressing is more from a "should I bother" perspective rather than the technical side. As in, if I support it... it needs to be included with testing, etc.
Member 2896020 wrote: Since nobody has the time to do those, I would suggest you use a "critical path" approach. I disagree. If you know how to make a cross browser site for one-page you know how to do it for two pages. Like I said, the site is almost done and works with IE11. So I know what I'm doing... the question is... should I bother.
Member 2896020 wrote: Remember that if a page is just tooo slow on the common machine, anybody can fire up a browser on its phone and get the missing content. That's a good point, but my target audience isn't technical. I can't assume they'll do that and it makes me look unprofessional, which I'm not.
Jeremy Falcon
|
|
|
|
|
Member 2896020 wrote: If they are using IE-something, it means this is a public machine nobody has cared to give maintenance, so it's always slow and people don't expect otherwise This is incorrect. A lot of folks continue to use IE, some for the simple reason it's the icon on their desktop. I know a few who use IE because it has (in their opinion) always worked best and they simply don't see a reason to change.
|
|
|
|
|
Read this, and I think it will answer your question...
https://www.zdnet.com/article/microsoft-security-chief-ie-is-not-a-browser-so-stop-using-it-as-your-default/
|
|
|
|
|