Seeing as IE7 has only about 10% of the browser market share, I was wondering when Microsoft plans on terminating support for it. We have some browser incompatibilities to work through and we're wondering if it's worth the effort for such a small market share...
Support for internet explorer versions are tied to the support for the OS it shipped with. The most modern OS which shipped with IE7 is Windows server 2008 and support for that isn't slated to end until 2018. Ugh.
However you problem isn't really one of the end of support but rather the end of widespread adoption. That is a complex question and depends on what you define as a significant user base and what your users are like. For instance I work in an industry which is traditionally slow to adopt new technology so I still need to support IE6 and will probably have to for 4 years to come. But if only 2% of my revenue came from customers on IE6 I would likely drop support as it costs me more to support it than I am paid. Is it costing you more to support IE7 than the revenue you're getting from those users?
Old question, but a relevant response...
We follow Google's policy of supporting the most recent 2 versions, and dropping the 3rd oldest when a new one comes out.. So that's IE8 and 9 that we have to support today. :)
Several big sites are following this policy now.. so I think you'll find the old browsers are going to start tapering off faster.
It was recently announced that support for IE 7 and IE 8 will be ending on 12th January 2016.
Related
It's been 10 years since this question was asked and answered here and I'd like to see what current thoughts are.
We have a third party app that we've supported for at least that long. It's an Access runtime application that connects to SQL Server and contains highly confidential data.
Some years ago we moved the database to an SQL Server running on Server Core. More recently we've been asked to run the first upgrade of the database schema in 6 years. The vendor provided upgrade package appears to be built using VB6 and won't run on the server. It also doesn't support running the updates remotely. We have a couple of ways that we can get it done but it has presented me with an opportunity to finally move on from what I think is not an enterprise product.
As part of that I've been asked why I think this product is so bad and, in my estimation, antiquated. My immediate internal response is that it's not a real application, it's Access. That's compounded by the fact that we're paying a pretty good bit for it and I think that there are better, more robust solutions now available that are also cheaper (I think in the end that's all that should matter).
That said I acknowledge that there my be some bias in my opinions on this particular app. Looking back at that old post a few things stand out.
I think there's a big difference between internally developed applications built this way and paid for solutions. Supporting an internally developed app written in Access may still have some positives. I don't think the positives pointed out in the top answer hold up when you're paying someone for it. The disadvantages are precisely what we're running in to.
Reporting isn't being done in Access. It's now mostly being done with outside tools. Most users want to see web based reporting.
A couple of the responses mentioned professional Access developers or this type of application being the COBOL of the 21st century. I think that's an apt description. I'm not sure professional Access developers still exist. How long should we try to maintain this and how long do we think the vendor will be able to?
I think the main mistake about Access is to consider it as a tool made for amateurs to develop applications. It can work this way, but keep in mind that amateur development will give you amateur applications, while professional development will give you professional results
Maybe this is the crux of my problem in particular. I'm not convinced that our application is 'professional'. It feels semi-pro if I'm generous. The VB6 updater is one clue and there are other components that have given me cause for concern over the years.
Fair or not, in my mind, most, if not all Access applications in the enterprise have these same issues. At the end of the day, the question is whether it serves the needs of the department using it.
Where does Access fit in the enterprise in 2019?
Microsoft is discontinuing RoboVM and I am not even trying to figure out the hassle in companies and startups who have invested in this framework.
I see three more JAVA cross platform mobile frameworks sitting out there:
Intel's multi-os-engine https://software.intel.com/en-us/multi-os-engine ,
Oracle's MAF http://www.oracle.com/technetwork/developer-tools/maf/overview/index.html
and https://www.codenameone.com .
Has anybody full knowledges of these frameworks?
What about their project health? Is among them any other candidate that we will see to fall apart the same as it was in the case of ROBOVM?
I'm the co-founder of Codename One so I'm pretty biased. Notice you also missed J2Obj-c which is an important option. Codename One predated RoboVM by a while and unlike it we have a business model/revenue which makes long term support more likely.
I don't want to spread FUD about MAF/MOE so if I got any facts wrong please correct me as I haven't kept up with everything. AFAIK MAF doesn't have much traction, it used to package an interpreted VM and just provide a bridge to Cordova with a few additional plugins. It seems most of Oracles resources are with JET. Back in the day I found a PDF that indicated that MAF has an annual licensing cost of 50K per application, I can't find it now so I don't know if it's applicable but I suggest checking this thoroughly.
MoE isn't a product. It's been a "technology preview" for years and it won't leave that status. Intel stopped all mobile development a few years ago and fired everyone involved, the only reason this wasn't shut down is due to the fact that it isn't a product. It was open sourced but that's just like the open sourcing RoboVM. Both products are over-engineered solutions whose open source code is hard for 3rd party maintenance. It's a full time job to keep up with Apple. Our VM took a far more conservative approach which makes it both easier to maintain/keep up and makes it more efficient. E.g. a hello world in MoE would be over 50mb whereas we support features such as bitcode and can build a release version in under 5mb of size.
Furthermore MOE isn't WORA (Write Once Run Anywhere) which brings me to J2Obj-C which isn't WORA either. If you will sacrifice portability and buy a Mac might as well use J2Obj-C which is more forward compatible than MOE and smaller. It has simpler code and architecture so it won't break if maintenance stops.
If you are a Windows user, using MOE becomes difficult. In fact, you need a Mac available for build reasons or, at least, a cloud hosted mac service.
Moreover, for Windows users, in MOE an iOS simulator is not available (it's only available for OSX users).
Andrea
A developer buddy of mine just recently started at a new company and one of his tasks is to come up with a new web application that allows their users to work offline when their staff are onsite in remote locations and then later to sync with a server side database of which they have not yet determined a server side provider yet (i'm guessing it will be SQL Server).
I've done some looking around and it seems like two viable options are LocalStorage and IndexedDb, with LocalStorage being the more popular technology? They want to go HTML5 and that's all fine and dandy, but long story short my question(s) is/are...
What are their offline data storage options in HTML5?
Are there older solutions that have better support?
are those methods less risky?
less time to implement?
The concept of storing data offline in a web application doesn't seem like a new idea, but doing so in today's newest technologies (html5, asp.net 4.0/4.5) is where you start getting into sparsely explored territory.
what are some things that maybe your company does that works, and what doesn't work?
Any intelligent evidence based replies will more than likely get my upvote so don't just rush to get the first answer and try to score some quick points, I'm looking for some good solid feedback here. Thank you.
There are several possibilities of offline storage in HTML5:
Web Storage
Web SQL Database
IndexedDB
Filesystem API
You have a very good presentation of all these options here:
http://www.html5rocks.com/en/tutorials/offline/whats-offline/#toc-older-storage
Compared to older options (Cookies, Plugin Based Storage, Browser-specific features) , I'll quote from the article:
"The newer storage APIs, what we might call "HTML5 storage", are generally superior in terms of openness and standards compliance. Of course, not all browsers include all of the new APIs, and you may have to support older browsers that don't include any of them at all. So the older techniques are still useful for graceful degradation."
Other useful links:
http://php-html.net/tutorials/html5-local-storage-guide/
http://www.tutorialspoint.com/html5/html5_web_sql.htm
Hope this helps...
I think your best choice is using Local Storage since its the most widely implemented standard of the storage options available under HTML5.
IndexedDB has been over-engineered (in my opinion) and is not widely supported (yet) for all of Mozilla's insistence that its better than sliced bread, and WebSQL's future is looking a bit uncertain as Mozilla is refusing to implement it and it is no longer being worked on due to an impasse between W3C and the browser vendors who have actually implemented it (Chrome/Safari/Opera).
There is currently a bit of a browser explosion happening thanks to smartphone adoption, so its hard to determine how much of the market supports HTML5 LocalStorage features but using statcounter I've been able to calculate that between Chrome (4+), Firefox (3.+), Safari (4+), Opera (10.5+) and IE (8+), including iPhone and Android devices you'll have captured around 80-85% of the market, with this figure going upwards a rate of 1-2% per month. The remainder being IE 6/7 (which stubbornly tends to hang on), older versions of new browsers (with update features that generally kept them current), and some mobile browsers stuck back in the stone age.
As for older options, I would add User Data Persistence for IE6/7 to the list provided by #user998692 but either way you're going to be caught up with lots of browser incompatiblity issues and support for a hodge-podge of technologies, which will complicate your codebase and testing and increase your delivery timelines (and cost) accordingly. If you do want to go down this road, however, I would recommend you take a look at PersistJS as the guys who put it together have done much of the work you would need to already.
These days its worth more looking forward (to what the market will look like in 1-2 years time when your app is propagating and gaining a wide user base) than backwards, so I'd say HTML5 LocalStorage is probably your best option.
I'm not a Silverlight developer (yet) and what is putting me off - and many others, I think - is the relative lack of browser installations of it compared to Flash.
But I'm not clear on why website visitors have to explicitly install Silverlight themselves - which appears to be the major stumbling block.
Since the vast majority of computer users use Windows, is there a reason that Microsoft are not forcing Silverlight onto Windows machines through a Windows update?
They do this (and continue to do so) with the .NET framework runtimes, so why not with Silverlight? Legal issue, perhaps?
Getting sued by all its competitors is what stops this
There are several reasons why not to do it.
Users should have choice over what gets installed. I realize from a developer standpoint we know some users who are clueless about what this software does, so why put the choice in their hands? Fine, MS should make it easy for users to install it if they don't have it when they visit a site that uses it. Then they can make an informed decision. Do I want to use this site or not?
Corporate Approvals. Companies go through software validation procedures and that is why some will still be on XP for some time. If they were forced to validate these pieces because microsoft was forcing them down the pipe, they'd be pissed off. So thus MS gives corporations control over the windows updates that get approved/installed. And corporations are where MS makes their money.
PC Manufactures choosing what software to preinstall. Here the manufacturers have the ability to push silverlight or not.
Competitor's software isn't automatically installed. You actually have to install flash. Some PC manufacturers might bundle it with the PC but if you install yourself or for a corporate deployment, it isn't there by default.
The monopoly power abuse concerns mentioned. But I think this is actually the least important reason.
Silverlight won't hit mainstream adoption till there is that one app that everyone must have that uses it. Like the office online example above.
I think that would be the wrong way to go about trying to gain adoption. The product should merit installation on it's own, not lean on the Windows installation base for support. Writing the free version of Office online (EDIT: I meant the Office Web Applications) in Silverlight, however, is a great way to gain adoption (even with the non-SL version available too http://blogs.msdn.com/officewebapps/archive/2009/08/05/9858563.aspx).
Also, since this is a browser plugin, how would that work? Can a Windows update install plugins for firefox, opera, or whatever browser the user prefers? Doesn't seem feasible to me but I'm really not sure.
They actually suggest it in Windows Update. I politely refuse it.
There may be an anti-trust reason for this also, remember what happened with Java, even when it was from Sun they still had a problem with it.
If you keep waiting for Silverlight to catch on, it never will be enough, start developing now and when there are many great web-apps that support Silverlight then maybe it will get more popular, plus it is very easy to install and you can target Mac and Windows, and some extent Moonlight too as it reaches support for Silverlight 2.0 and some 3.0 there may be Mac-Windows-Linux apps you can write.
I recommend Silverlight to anyone who develops in .NET, I am a little biased as I'm writing an application at the moment in Silverlight.
I suspect that they are waiting for the technology to mature and/or gain more acceptance. Once a critical mass of sites and/or users have it installed they might do.
The other alternative is that they might be waiting until they've completed the "merger" of WPF and Silverlight. I can't see them continuing to keep these two very similar technologies separate.
After all Adobe don't force Flash on everybody.
Can't speak for Microsoft, but I am dismayed by the question. I don't want extra crap pushed to my machine (or into my life in general). I only want extra stuff if I pull it. Stuff like that should always be "opt in" instead of "opt out" or "no option at all."
The european union has filed anti-trust suits against Microsoft which is probably why they don't put it in their updates.
I however don't install it because i don't like unnecessary processor cycles being used up for advertising much in the way that flash is used. Flash I've uninstalled on many of my computers in protest, though i admit it's on my media center in the living room because people use it for you tube.
For all the hype, Silverlight is not all that great to develop in and doesn't bring anything to the user experience that couldn't be better achieved through dhtml/ajax.
I'm only asking this because I'm finding as I get older, it becomes a much more frustrating part of my job.
How do you handle new versions of software, particularly software that coders and DBAs use on a regular basis? It seems that just when I've fleshed out SQL2005, SQL2008 will have come and gone and SQL2010 will be here. I've missed a whole iteration and this isn't endemic to coders and DBAs.
I'm never for upgrading just for the sake of upgrading so unless there is compelling functionality there, I tend to let it go. Somehow though, with software releases becoming more frequent, I can't help but feel that this is the wrong approach.
Edited to add:
I guess part of what I'm saying is that the release of newer versions hardly leaves enough time to become an expert in the previous version.
Rarely do these upgrades require a lot to be relearned. Actually, I would almost argue, that the amount to relearn is proportional to the amount of time between releases. So SQL Server 2000 to 2005 was 5 years, and quite a lot changed. 2005 to 2008, not much changed. 2008 to 2010, I'm guessing that there won't be a lot to learn. I think the trick is to keep on top of things. Because if you fall a few versions back, it can be a nightmare to catch up on things. Even if you just play around with it and don't use it in live projects, you are probably further ahead than a lot of people.
For server based software that needs to be stable, hitting "every release" isn't necessary a good thing. The only benefits you get from a new version are the new features (which if you don't need them, are not a concern) and finding all the incompatibilities now that might bite in the next release as well (on top of those included in the next release).
For this reason, we still support SQL 2000 on our primary product. We have ported and tested it against 2005 and 2008... but we are not using those new features. Too many clients are still running 2000. We are finally looking to cut support for 2000 when 2010 comes out, as 10 years seems a reasonable period, so our newest (not generally released, but in use with some clients) version uses some 2005 features.
As far as our development environment goes, we did move to 2005 and 2008 about a year after each release (when the first service packs were out). That is because the client isn't on the treadmill there, so we are more aggressive. The features in 2005 and 2008 were also compelling (I don't use Linq to SQL, but I love Linq to Objects ). We also do a lot of prototyping on newer versions of software, and keep our internal projects on newer software to keep up with the technologies features for planning and learning.
As far as becoming an expert, I think that with the scope of the technologies in question, nobody is an expert in the entire product. If you know all about the query optimization engine and how to wring the last bit of performance out of it, you are less likely to have spent a lot of time on the replication engine. Personally, I think you should sample everything, but at the end of the day you have to get to work: and your work will rarely require you to be an expert at everything. Just knowing that the features are there are enough so that the day you need them... you can quickly acquire a new skill and move on.