The Evergreen Web
Sponsored By
I visited a website on my company's Intranet today using Microsoft Edge (the new "evergreen" browser in Windows 10*) and got an interesting warning. "This website needs Internet Explorer." At first I was taken aback, but then I got to thinking about it and it made sense.
Let me back up. I was talking with awesome Web Developer Catt Small today and she mentioned how sometimes Chrome will update silently and break some little piece of the web in order to move the larger web forward. This means that Catt would have to then update her website to support this new feature or tweak the way she uses a feature in order for Random Visitor to have a Good Experience. This is life on the Evergreen Web and we techies are generally cool with it.
In a world where we all write our websites with feature detection and (generally) gracefully degrade when features aren't around, things just work. But at the same time, it does make the Web itself a moving target.
Flash, Silverlight, and Java are on the way out and JavaScript is the web's assembly (it's true and happening, you can't deny it anymore) so we should always be able to emulate what we need with JavaScript's Virtual Machine, even arcade games amazingly frozen in amber by Jason Scott. As the web moves it WILL be important to have browsers that can render yesterday's web as well as tomorrow's.
However, a few important aspects need to be called out in my opinion.
With an Evergreen Web comes Great Responsibility
Firefox, Edge, Chrome are all Evergreen browsers now. They really need to make smart decisions - hopefully as a collective when appropriate - to not Break Everything.
We also need to realize that we will have to leave some folks behind. Some older operating systems won't be able to run the latest browser. Some browsers come with the operating system or phone and don't upgrade often.
If we're gonna do this, we all need to do it
Everyone needs to get on board (*cough*Safari) and move forward.
An Evergreen Web is a kind of privilege
This is an interesting one that Catt and I talked about (podcast coming soon!) Again, not every company has the money, resources, or patience to keep their sites Evergreen. Things will break. Not every non-technical relative will have an Evergreen browser. These may seem like edge cases, but they aren't.
My wife has been in university these last few years and I swear it's like browsing the web in 2003. She's got a collection of browsers, literally, and bookmarked the school's sites that work in specific browsers. I'll find her running IE, Edge, Chrome, and Firefox on her own, and when I ask what's up, I'm told that "this blackboard site only works in Firefox" or "this testing app only works in IE."
This kind of haves-and-have-nots split will continue for the foreseeable future while mission-critical (everything mission critical to someone) apps continue to be used.
Compatibility Modes (however they are implemented) will be important
While your startup or agile team can likely fix little issues that pop up on your websites, that super-old web-based Expense reporting system that your company use DOES WORK in the right browser. It works. It's OK that it works and it should be allowed to work. While I was shaken by the error message I saw above for a moment, I understood it and I was able to get my "nevergreen" copy of IE to open that old-but-functional website quite nicely. I've found myself wishing, on occasion, that my copy of Chrome 44 could just act like Chrome 38 for a site or two.
Additionally, there will be Enterprises that won't (for whatever reason) want to be as Evergreen as we'd like them to be. There concerns are usually around compatibility. For many giant companies, changing stuff means breaking stuff.
* Evergreen browsers are always fresh, always updated. Chrome and Edge are "evergreen" browsers that support the latest Web Technologies and most importantly you shouldn't have to think about version numbers.
Do you welcome our Evergreen Overlords? Sound off in the comments.
Related Reading
SOCIAL: Hey folks, please do follow me on Facebook https://fb.me/scott.hanselman or Twitter! https://twitter.com/shanselman
* Photo "Road Work" by Grempz used under CC BY 2.0
Sponsor: Big thanks to Infragistics for sponsoring the feed this week! Responsive web design on any browser, any platform and any device with Infragistics jQuery/HTML5 Controls. Get super-charged performance with the world’s fastest HTML5 Grid - Download for free now!
About Scott
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. He is a failed stand-up comic, a cornrower, and a book author.
About Newsletter
Hosting By
I'm not sure compatibility modes are a good idea, they just encourage lazy and poor behavior from developers.
We probably should be more willing to break old stuff, if you really need your app to be stable for a long time then keep it simple, don't fill it with faddish JavaScript frameworks.
We probably should be more willing to break old stuff, if you really need your app to be stable for a long time then keep it simple, don't fill it with faddish JavaScript frameworks.
We need browsers to:
Sadly, web tech is pulling in a hundred directions at once and getting rewarded for it. Salaries are higher to work with fragile technologies though they require more maintenance. Web app UX is relatively terrible. If we could get web tech culture to rally around much fewer, less sloppy tech stacks, we would have millions more person-hours each year to do things that matter. How do you think we can make that happen?
- Provide versioned contracts for each feature (kind of like UAP does).
- Have automated compliance certification by a single third party (no more differences in standards interpretation)
- Have unacceptable consequences to browser authors who don't comply.
- Provide a client language that's less of a "foot gun" than JavaScript. Libraries don't cut it.
Sadly, web tech is pulling in a hundred directions at once and getting rewarded for it. Salaries are higher to work with fragile technologies though they require more maintenance. Web app UX is relatively terrible. If we could get web tech culture to rally around much fewer, less sloppy tech stacks, we would have millions more person-hours each year to do things that matter. How do you think we can make that happen?
Re: "JavaScript is the Web's Assembly" quote.
Actually, WebAssembly provides a byte code more similar to assembly than JavaScript that could easily be targetted by other languages. This, in my opinion, comes some way towards realising the potential of the Web.
Actually, WebAssembly provides a byte code more similar to assembly than JavaScript that could easily be targetted by other languages. This, in my opinion, comes some way towards realising the potential of the Web.
Since the IE monopoly was broken on the web, the apps that still cause problems are the type that were installed on a server years ago and left to just work, often without any maintenance agreement from the vendor. Thankfully many of these apps are also becoming evergreen, usually by being replaced by SaaS solutions.
Welcome back to the Browser wars of the 90's for anyone who missed them. It was a joy. A good time had by all.
What's that old adage? Client asks, "Why don't you support this internet standard?"
"The problem with stardards is that, there are just so many of them"
What's that old adage? Client asks, "Why don't you support this internet standard?"
"The problem with stardards is that, there are just so many of them"
There needs to be more projects like Mozilla's Shumway. Too much of the web is at risk of being lost forever as browser vendors render old technologies like Flash and Silverlight obsolete.
@Ian - I find plenty of modern apps that cause problems. Go to Google Analytics using the Edge browser and you will find that the site won't render the charts, and will tell you that the browser doesn't support charts. Oddly, if I open dev tools and change the User-Agent string to Chrome or Firefox, the charts work just fine. This is an example of a site that is both modern and broken in an evergreen world. A normal user would attribute that to Edge being broken in some way, and like Scott's wife, would open a different browser that "works".
The developer in me loves the idea of browsers keeping up with technology changes at a steady pace, so I can use tools that solve my problems with less effort, like CSS3 layout rules, vector graphics, HTML5 form inputs - stuff that makes the browser work harder so I don't have to.
Except in reality we have to keep in our mind that whilst many browsers may be evergreen, there are those which are not. I believe the real strength of the web as a platform comes from our ability to assume little about the capabilities of the consuming client, and instead write to a standard (W3C or de facto) which works with the intended audience.
This kind of design usually comes with the extra challenge of graceful degradation|enhancement, and it's where the vast majority of the pain is with web development. So much pain that we have to lean on libraries like jQuery and polyfills to attempt to give the appearance of an even playing-field, and to try to nail down the moving target to a known feature-set.
The problem is compounded in that browsers don't always get the implementation of the spec right, so we end up with the same instruction producing different outcomes depending on where it runs. CSS has always been a minefield of inconsistent behaviours, one that can only be seemingly hacked around using various browser quirks.
And so, the problem with the web is that it's still a Wild West. There's no formal testing procedure or sign-off that a browser is compliant with standards; compatibility is just good intentions on the part of the implementer. When the page we have authored doesn't work with this morning's release of Edge or Chrome, nobody is going to accept a response that "the latest update has a bug in it" - they want it fixed now and we are always the ones who pick up that work.
The continuous delivery model for browsers only works until a bug is introduced. Once the bug is out there, we're being forced to developer workarounds for it. Once the bug is fixed, the workarounds now cause the the page to be wrong and we have to make a fix to correct that. We're completely exposed to the fallout from the vendor's QA process.
Continuous delivery for browsers is continuous pain for developers.
Except in reality we have to keep in our mind that whilst many browsers may be evergreen, there are those which are not. I believe the real strength of the web as a platform comes from our ability to assume little about the capabilities of the consuming client, and instead write to a standard (W3C or de facto) which works with the intended audience.
This kind of design usually comes with the extra challenge of graceful degradation|enhancement, and it's where the vast majority of the pain is with web development. So much pain that we have to lean on libraries like jQuery and polyfills to attempt to give the appearance of an even playing-field, and to try to nail down the moving target to a known feature-set.
The problem is compounded in that browsers don't always get the implementation of the spec right, so we end up with the same instruction producing different outcomes depending on where it runs. CSS has always been a minefield of inconsistent behaviours, one that can only be seemingly hacked around using various browser quirks.
And so, the problem with the web is that it's still a Wild West. There's no formal testing procedure or sign-off that a browser is compliant with standards; compatibility is just good intentions on the part of the implementer. When the page we have authored doesn't work with this morning's release of Edge or Chrome, nobody is going to accept a response that "the latest update has a bug in it" - they want it fixed now and we are always the ones who pick up that work.
The continuous delivery model for browsers only works until a bug is introduced. Once the bug is out there, we're being forced to developer workarounds for it. Once the bug is fixed, the workarounds now cause the the page to be wrong and we have to make a fix to correct that. We're completely exposed to the fallout from the vendor's QA process.
Continuous delivery for browsers is continuous pain for developers.
I've been thinking a lot about this lately, the state of the web is a scary place! Especially if you're working on something public and not within the nice warm confines of an Intranet where IT can control what you need to support.
My team recently switched to Angular. It makes sense for our site and what we deliver. Except that our users in Japan are having a tough time migrating from IE8, and are important enough that we need to support them until IE8 is officially unsupported. Some modules break in IE9 because HTML5Mode isn't completely compatible with our ancient servers.
My other web devs are trying to stay on the bleeding edge, pushing to adopt the latest and greatest...which is a weekly meeting. Being the most seasoned of us all I know enough to let frameworks, features, and tech freeze for a year or two until gauging adoption, but I come from the from the Full-Stack side of things with a PhD in enterprise where change is slow and steady.
My RSS feed is full of "If you aren't using Flex-Box you're a dummy" and all I can think of is our incompatible user base and until things simmer down I can't even take these into consideration. "Why React is the future of the web!" is immediately met with "React sucks at mobile speed, watch out!".
I don't dream of an evergreen web. I dream of a web where ideas are toyed around with, speced out, and have a firm "go live" date. I dream of the web being like client-side delivery, ES 6.0 is ready to go, include it in your package and we'll compile it for you. Maybe we'll get there with this new WebAssembly chatter, but until the web -- both users and browsers -- can agree upon what can and can't be used yet, we're stuck in this same old loop of "Yes Eric, only 5% of our users are on IE9, but we need to support them because they pay the most". Wasting time and money on compatibility needs to be budgeted into any web project, and it's sad.
My team recently switched to Angular. It makes sense for our site and what we deliver. Except that our users in Japan are having a tough time migrating from IE8, and are important enough that we need to support them until IE8 is officially unsupported. Some modules break in IE9 because HTML5Mode isn't completely compatible with our ancient servers.
My other web devs are trying to stay on the bleeding edge, pushing to adopt the latest and greatest...which is a weekly meeting. Being the most seasoned of us all I know enough to let frameworks, features, and tech freeze for a year or two until gauging adoption, but I come from the from the Full-Stack side of things with a PhD in enterprise where change is slow and steady.
My RSS feed is full of "If you aren't using Flex-Box you're a dummy" and all I can think of is our incompatible user base and until things simmer down I can't even take these into consideration. "Why React is the future of the web!" is immediately met with "React sucks at mobile speed, watch out!".
I don't dream of an evergreen web. I dream of a web where ideas are toyed around with, speced out, and have a firm "go live" date. I dream of the web being like client-side delivery, ES 6.0 is ready to go, include it in your package and we'll compile it for you. Maybe we'll get there with this new WebAssembly chatter, but until the web -- both users and browsers -- can agree upon what can and can't be used yet, we're stuck in this same old loop of "Yes Eric, only 5% of our users are on IE9, but we need to support them because they pay the most". Wasting time and money on compatibility needs to be budgeted into any web project, and it's sad.
Interesting timing of this article, given that the opposite opinion also has supporters.
The problem is that zero developers (and fewer companies) have proven they can actually be trusted with compatibility modes.
This is why including IE11 in Win10 was a stupid idea. Edge isn't going to gain traction, because the existing developers who are too lazy to fix their IE7-compatibility-mode-required sites don't have to -- IE11 is the "latest version of Internet Explorer" and, according to the MS lifecycle, will be supported for the life of Win10.
This is why including IE11 in Win10 was a stupid idea. Edge isn't going to gain traction, because the existing developers who are too lazy to fix their IE7-compatibility-mode-required sites don't have to -- IE11 is the "latest version of Internet Explorer" and, according to the MS lifecycle, will be supported for the life of Win10.
So, if your boss says to you that you have to build a greenfield app for your company/division that has to work for at least 8 years before the money will be available to rewrite or refactor it, what technology would you use?
It has to have a user friendly UI, server side business logic, a decent size database, and have server side interactions with web services from other firms or divisions within your company. Mostly it will be internal, but it may have some customer facing parts.
Regardless of the OS, language, or platform used, are we now in such an era of throw away code and ever changing libraries that planning for a large long lived application is impossible? Long lived used to mean in 10's of years at least. Today, long lived may only mean weeks, or until the author of the library you based your app on graduates high school and no longer has the bandwidth to support it. :)
As you talked about in the article, the concept of Evergreen can be bad from some points of view. If the technologies and tools that help to build both Evergreen and long lived applications don't stay compatible or usable in both stacks, i.e. Visual Studio, the developers of applications that cant be Evergreen are screwed.
pmont
It has to have a user friendly UI, server side business logic, a decent size database, and have server side interactions with web services from other firms or divisions within your company. Mostly it will be internal, but it may have some customer facing parts.
Regardless of the OS, language, or platform used, are we now in such an era of throw away code and ever changing libraries that planning for a large long lived application is impossible? Long lived used to mean in 10's of years at least. Today, long lived may only mean weeks, or until the author of the library you based your app on graduates high school and no longer has the bandwidth to support it. :)
As you talked about in the article, the concept of Evergreen can be bad from some points of view. If the technologies and tools that help to build both Evergreen and long lived applications don't stay compatible or usable in both stacks, i.e. Visual Studio, the developers of applications that cant be Evergreen are screwed.
pmont
@PMONT
"Long-lived" is already a mistake.
What happens next year when there's a new security hole discovered in your libraries that requires a rewrite?
And two years after that?
And six months after THAT?
If a company is unwilling or unable to maintain software and rebuild it as needed, they have no business producing it in the first place.
The good news is that we'll never run out of black hats who punish companies -- hard -- for failing to do basic maintenance.
"Long-lived" is already a mistake.
What happens next year when there's a new security hole discovered in your libraries that requires a rewrite?
And two years after that?
And six months after THAT?
If a company is unwilling or unable to maintain software and rebuild it as needed, they have no business producing it in the first place.
The good news is that we'll never run out of black hats who punish companies -- hard -- for failing to do basic maintenance.
ok, put a maintenance/support budget in there. But not a rewrite budget.
What technologies do you choose if the basic system needs to last years?
Must companies increase their software budget to provide for potential full re-writes of major internal software efforts at any time? That is exactly the problem I am talking about. Not every company can do that with all of their internal applications. Not every company is a software company, most have a primary business to run and software is a necessary but expensive and usually neglected part.
pmont
What technologies do you choose if the basic system needs to last years?
Must companies increase their software budget to provide for potential full re-writes of major internal software efforts at any time? That is exactly the problem I am talking about. Not every company can do that with all of their internal applications. Not every company is a software company, most have a primary business to run and software is a necessary but expensive and usually neglected part.
pmont
For me evergreen browsers are a bit love and hate.
I love that I can require Chrome/Firefox (and now Edge) for my business clients whose IT departments typically keep them a decade behind on Windows versions. That means that essentially my app's "platform" of sorts stays up-to-date with modern features. Less work, better product - what's not to like.
The rapid pace at which updates are released does pose problems, especially when things are inadvertently broken. For example, Firefox v36 decided to change something about how it prints, causing a problem in my app which relies heavily on browser-based printing. I managed to get a fix out which lasted through version 37 and when 38 came out Firefox reverted back to pre-36 functionality. There's no real way to feature-detect that sort of thing.
I've since remedied my printing woes with SVG, which incidentally is something that has benefited from the greenfield updates.
I love that I can require Chrome/Firefox (and now Edge) for my business clients whose IT departments typically keep them a decade behind on Windows versions. That means that essentially my app's "platform" of sorts stays up-to-date with modern features. Less work, better product - what's not to like.
The rapid pace at which updates are released does pose problems, especially when things are inadvertently broken. For example, Firefox v36 decided to change something about how it prints, causing a problem in my app which relies heavily on browser-based printing. I managed to get a fix out which lasted through version 37 and when 38 came out Firefox reverted back to pre-36 functionality. There's no real way to feature-detect that sort of thing.
I've since remedied my printing woes with SVG, which incidentally is something that has benefited from the greenfield updates.
@PMONT
Companies that aren't in the software business have no business writing software that will affect the external ecosystem -- no one truly cares if your company rots from the inside, of course.
They can hire a web design firm to do the development and maintenance, which will be substantially cheaper long-term.
Companies that aren't in the software business have no business writing software that will affect the external ecosystem -- no one truly cares if your company rots from the inside, of course.
They can hire a web design firm to do the development and maintenance, which will be substantially cheaper long-term.
@PMONT You are right on the money! There are far too many bleeding-edge developers who are keen to break and deprecate entire technology stacks with no regard to the cost of re-writes. What business can cough up the hundred of thousands (or millions) of dollars every 3-5 years to re-write each project they have?
PMONT's "8-year" question is a good one.
PMONT's "8-year" question is a good one.
@Ian W
Any large application written today has to be able adapt to change. They must be designed to isolate the areas that must change weekly to allow the use of current fad technology or UX paradigm or whatever is currently hot in the customer facing market. But there has to be core parts of the system that can exist through those fads and into the next seminal change in technology that the core has to adopt. Design for change. But the tools have to be able to support the parts of the system that cant change with the wind.
I am NOT denigrating the people who have to live in the ephemeral world of the current web fad / Evergreen Web. It is an extremely complicated and competitive challenge to keep a web site up to date and relevant. The people and teams that can do that have to be VERY good, work at a fast pace and be able to adopt the latest trends at a moments notice. But I don't want those people writing the software that controls the pace maker in my fathers chest.
Any large application written today has to be able adapt to change. They must be designed to isolate the areas that must change weekly to allow the use of current fad technology or UX paradigm or whatever is currently hot in the customer facing market. But there has to be core parts of the system that can exist through those fads and into the next seminal change in technology that the core has to adopt. Design for change. But the tools have to be able to support the parts of the system that cant change with the wind.
I am NOT denigrating the people who have to live in the ephemeral world of the current web fad / Evergreen Web. It is an extremely complicated and competitive challenge to keep a web site up to date and relevant. The people and teams that can do that have to be VERY good, work at a fast pace and be able to adopt the latest trends at a moments notice. But I don't want those people writing the software that controls the pace maker in my fathers chest.
Scott, you should totally have a conversation (ideally on a podcast) with Aaron Gustafson about progressive enhancement. He now works at Microsoft and has written THE canonical book on the subject called Adaptive Web Design. The first edition is available for free.
It's a super-important topic, especially in light of the ever expanding universe of devices and user agents. We all need to start building a Future Friendly web. We shouldn't have to rely on browsers to ensure future compatibility - It's something we should take responsibility for. It's just good design and engineering. We must play to the web's strengths. Start with HTML, layer on CSS for style, then layer on JavaScript for behaviour.
See also Jeremy Keith's blog for lots more good thinking on the subject of PE. Continuum and Baseline are two particularly good ones. Actually, get on a podcast with Jeremy too!
It's a super-important topic, especially in light of the ever expanding universe of devices and user agents. We all need to start building a Future Friendly web. We shouldn't have to rely on browsers to ensure future compatibility - It's something we should take responsibility for. It's just good design and engineering. We must play to the web's strengths. Start with HTML, layer on CSS for style, then layer on JavaScript for behaviour.
See also Jeremy Keith's blog for lots more good thinking on the subject of PE. Continuum and Baseline are two particularly good ones. Actually, get on a podcast with Jeremy too!
If you have a big piece of software that needs to last, then you too need to adopt evergreen software. If your response to that is, "but that's added cost". Yes. Yes it is. But you will be left behind otherwise and you will look down the barrel of a big rewrite at some point in the future. That's the reality of the web, no matter how many people go "please stop".
The web is still a pain to write software for. There is a lot of innovation that still needs to happen. There are going to be lots of disruptive frameworks that will come out / have come out.
Things like meteor are game changers which lower the cost of development, if you get stuck on older frameworks like asp.net or mvc, your time to produce features or adapt is going to be a lot higher. But it won't stop there, there will always be new disruptive tech that changes how fast we can develop. It's always going to be a problem for existing software. You either adapt or die.
It's easier to accept these realities and go with the flow.
Keep pushing forward and stay evergreen!
The web is still a pain to write software for. There is a lot of innovation that still needs to happen. There are going to be lots of disruptive frameworks that will come out / have come out.
Things like meteor are game changers which lower the cost of development, if you get stuck on older frameworks like asp.net or mvc, your time to produce features or adapt is going to be a lot higher. But it won't stop there, there will always be new disruptive tech that changes how fast we can develop. It's always going to be a problem for existing software. You either adapt or die.
It's easier to accept these realities and go with the flow.
Keep pushing forward and stay evergreen!
I work in an agency. We have lots of very old large projects. Some go back to 2001. Some are even installed on several instances, in different branches. Those projects are still used and maintained. But customers pay for content maintenance and new features. Most don't care for browser compatibility. They use IE-X, so they think the rest of the world does that too. Modernizing costs money and evergreen browsers require modernizing.
Anyway since IE8 is not used that much anymore it's getting easier to keep sites running in the modern evergreen browsers and IE10+.
But I am afraid that the browser vendors will soon start to break websites as google for example seams to be a big fan of breaking changes. This causes budget issues. So I am not sure if evergreen is the best way to go.
Anyway since IE8 is not used that much anymore it's getting easier to keep sites running in the modern evergreen browsers and IE10+.
But I am afraid that the browser vendors will soon start to break websites as google for example seams to be a big fan of breaking changes. This causes budget issues. So I am not sure if evergreen is the best way to go.
If the browser does not accept the page and refers to another browser I'm leaving that browser.
Anyhow this is the reason why I don't like web gui dev. Luckely the future is here with web.api and native mobile apps with cross platform tools (dont mean VS icm xamarin or cordova web )
Anyhow this is the reason why I don't like web gui dev. Luckely the future is here with web.api and native mobile apps with cross platform tools (dont mean VS icm xamarin or cordova web )
@Keith: I agree that for new sites/enterprise software you have to do this. However as other people already stated: When I created my first Geocities web site nobody had heard of responsivee design, tablets and mobile devices.
So if i create a new site for a company I know that in 2/3 years the frameworks is completely outdated and can be replaced by something better. The company isn't going to pay me again to update the site every time a new version of a framework is released/ or a better framework is available. They probably want to use it till it falls apart at some point in time and maybe ask me then. The reason for this is simply the cost they invested in the site and the amount of money it would cost to replace/update a framework.
Say i have a site with knockoutjs, and a js MVC framework. Now I want to replace the knockoutjs with angular (for example). This is really hard, i cannot just use the binding part of Angular. I also need to use their MVC solution.
That is in my personal opinion the problem with modern web frameworks. They all do everything on their own (Databinding, MVC, Dependency injection etcetera.). Nobody ever looks at other frameworks that do the same job (sometimes even better) and integrate that in their own framework. I quess that's a software developer thing or something. We all feel comforabler if we tear down everything an start over from scratch because we are better/smarter/know more etc. than the other guy.
If a web lego 'framework' existed where I can choose whichs blocks i wants to use and build my site then i would be a lot easier to remove one block and replace it with another. This would also cut down on cost because all the blocks are loosely coupled together. Then making a site more modern only means adding/replacing/changing a block with a new block. Then maybe a more evergreen web can be created a little bit easier.
So if i create a new site for a company I know that in 2/3 years the frameworks is completely outdated and can be replaced by something better. The company isn't going to pay me again to update the site every time a new version of a framework is released/ or a better framework is available. They probably want to use it till it falls apart at some point in time and maybe ask me then. The reason for this is simply the cost they invested in the site and the amount of money it would cost to replace/update a framework.
Say i have a site with knockoutjs, and a js MVC framework. Now I want to replace the knockoutjs with angular (for example). This is really hard, i cannot just use the binding part of Angular. I also need to use their MVC solution.
That is in my personal opinion the problem with modern web frameworks. They all do everything on their own (Databinding, MVC, Dependency injection etcetera.). Nobody ever looks at other frameworks that do the same job (sometimes even better) and integrate that in their own framework. I quess that's a software developer thing or something. We all feel comforabler if we tear down everything an start over from scratch because we are better/smarter/know more etc. than the other guy.
If a web lego 'framework' existed where I can choose whichs blocks i wants to use and build my site then i would be a lot easier to remove one block and replace it with another. This would also cut down on cost because all the blocks are loosely coupled together. Then making a site more modern only means adding/replacing/changing a block with a new block. Then maybe a more evergreen web can be created a little bit easier.
@Keith
Like I said, one has to design for change. There may be parts of a large system that have to be built with the foreknowledge that this area is going to be continually rewritten to keep up with the times.
What if I am doing a factory floor automation system. We decide to go with a browser based system for the user interaction at the various stations across the floor. The rest of the system is control systems and data bases and logistical software built in whatever technologies they need. The user interface on the factory floor is browser based running on a hardened PC ( nasty environmental factors ) using an evergreen pc browser. If the browser is being updated constantly and might present breaking changes, without my ability to know that ahead of time, how do I keep my factory running? If I don't allow the changes to the browser, I have a problem in 3 years when I have to change out one PC because I cant get the version of the browser I need.
Sounds to me as a developer like I don't go with a browser based UI, but write a thick client app that I have complete control over.
If this was a customer facing UI, absolutely it has to keep up with the times. But it appears to me that evergreen browsers would be pushing companies away from internal web apps and back to thick client/apps for internal facing projects.
Like I said, one has to design for change. There may be parts of a large system that have to be built with the foreknowledge that this area is going to be continually rewritten to keep up with the times.
What if I am doing a factory floor automation system. We decide to go with a browser based system for the user interaction at the various stations across the floor. The rest of the system is control systems and data bases and logistical software built in whatever technologies they need. The user interface on the factory floor is browser based running on a hardened PC ( nasty environmental factors ) using an evergreen pc browser. If the browser is being updated constantly and might present breaking changes, without my ability to know that ahead of time, how do I keep my factory running? If I don't allow the changes to the browser, I have a problem in 3 years when I have to change out one PC because I cant get the version of the browser I need.
Sounds to me as a developer like I don't go with a browser based UI, but write a thick client app that I have complete control over.
If this was a customer facing UI, absolutely it has to keep up with the times. But it appears to me that evergreen browsers would be pushing companies away from internal web apps and back to thick client/apps for internal facing projects.
Scott: Getting down to practicalities, how is that page (a) detecting Edge and (b) making a link that opens in IE 11 Desktop? Should we assume they are checking the UserAgent for "Edge/xx"?
@PMONT
As soon as you choose an evergreen browser you are committing to evergreen software.
I have written software that controls large fruit sorting machines and automatic packing systems. Most of that is all locked down. I wouldn't deploy an evergreen browser on the factory floor. If you want to use a browser you are going to have to use a specific version, and you you will need to plan for a replacement PC with an identical setup. In which case you will have the browser you need.
But, if you have a web app that can be consumed by the factory floor managers / owners to monitor their plant, and it can be consumed on many types of mobile phones ( some of which aren't even invented yet) / evergreen browsers etc. Then that must be planned as evergreen software, and the cost needs to be built into the maintenance contract for that plant.
As soon as you choose an evergreen browser you are committing to evergreen software.
I have written software that controls large fruit sorting machines and automatic packing systems. Most of that is all locked down. I wouldn't deploy an evergreen browser on the factory floor. If you want to use a browser you are going to have to use a specific version, and you you will need to plan for a replacement PC with an identical setup. In which case you will have the browser you need.
But, if you have a web app that can be consumed by the factory floor managers / owners to monitor their plant, and it can be consumed on many types of mobile phones ( some of which aren't even invented yet) / evergreen browsers etc. Then that must be planned as evergreen software, and the cost needs to be built into the maintenance contract for that plant.
In the financial services world we have seen a drive from the Regulators towards punishing companies that run Legacy, bespoke systems without an adequate maintenance cycle.
On many occasions I have encountered organisations with software, either delivered through a browser or client based, that is key to the organisation, yet the code base is controlled by a handful of individuals, who effectively hold the company to ransom. This has to stop. It is terrible for business.
Browsers change, evergreen or not. Your application is going to be around longer than the OS, so it is going to land on a different browser in the future, and you have absolutely no way of knowing if it will work or not. But most importantly, Businesses Change. This is a fast paced world, that's why we went Agile in the first place. Today's solution will not solve tomorrow's problems. This means that if a company decides to build its own software, it has to understand that this is not just an 18 month programme. It is a major undertaking that needs to be correctly documented and managed so that you do not end up with a C# developer (like me) as the only person in the world who knows how this stuff works, and can in effect write his own cheque each month, that is Key Man Risk right there!
What makes more sense is that the organisation outsources development to a third part Software House and enters into an SLA for ongoing maintenance. Due Diligence is important here; you need a good, financially stable partner, otherwise you are replacing one risk with another. The software can be delivered SaaS, and be as evergreen as the world in which we live. The business focuses on what it is good at, and leaves the development to the organisations that have the know how to keep software "lights on". If all of your clients are moving across to MS Edge, then you have to make sure their software works, it's in the SLA, if you don't you don't get paid. The Software Houses in turn need to ensure they have adequately documented procedures to ensure they do not end up with the Key Man risks outlined above. But that is a software engineering skill, ie. their core business.
On many occasions I have encountered organisations with software, either delivered through a browser or client based, that is key to the organisation, yet the code base is controlled by a handful of individuals, who effectively hold the company to ransom. This has to stop. It is terrible for business.
Browsers change, evergreen or not. Your application is going to be around longer than the OS, so it is going to land on a different browser in the future, and you have absolutely no way of knowing if it will work or not. But most importantly, Businesses Change. This is a fast paced world, that's why we went Agile in the first place. Today's solution will not solve tomorrow's problems. This means that if a company decides to build its own software, it has to understand that this is not just an 18 month programme. It is a major undertaking that needs to be correctly documented and managed so that you do not end up with a C# developer (like me) as the only person in the world who knows how this stuff works, and can in effect write his own cheque each month, that is Key Man Risk right there!
What makes more sense is that the organisation outsources development to a third part Software House and enters into an SLA for ongoing maintenance. Due Diligence is important here; you need a good, financially stable partner, otherwise you are replacing one risk with another. The software can be delivered SaaS, and be as evergreen as the world in which we live. The business focuses on what it is good at, and leaves the development to the organisations that have the know how to keep software "lights on". If all of your clients are moving across to MS Edge, then you have to make sure their software works, it's in the SLA, if you don't you don't get paid. The Software Houses in turn need to ensure they have adequately documented procedures to ensure they do not end up with the Key Man risks outlined above. But that is a software engineering skill, ie. their core business.
@Ian W: It isn't the page that is detecting Edge, but rather Edge that is detecting that the pages uses a plugin or other things that won't work in Edge (or the page is on the compatibility list). Edge then displays this page, the site is not involved at all.
Typical recycling of the waterfall purchasing / budgeting versus techie have to upgrade to the latest version to be cool discussion.
How do you as an employee justify a browser update that is used for 250+ browser based applications in my Fortune 100 company? How do you meet regulatory requirements for re-testing / validation on those 250+ browser based applications?
The upgrade to a new phone every 9 months does not scale to enterprises larger than the single household.
The tech industry revenue lifeline results in it producing new APIs, training courses, methodologies, libraries, frameworks, books and development tools.
Keeping that in mind, many enterprises skip updates, frameworks, development tools and platforms knowing that there is no return on investment and the new only exists to justify new revenue for the vendor.
A blog entry for the new XYZ framework from large software vendor Q should be measured on the merits of the new XYZ framework with deductions for the unstated financial self-interest of the vendor.
Vendor lock-in problems for installed in-house deployments are bothersome, SAAS/cloud based ones are more deeply int Vendor lock-in since they force upgrades faster.
How do you as an employee justify a browser update that is used for 250+ browser based applications in my Fortune 100 company? How do you meet regulatory requirements for re-testing / validation on those 250+ browser based applications?
The upgrade to a new phone every 9 months does not scale to enterprises larger than the single household.
The tech industry revenue lifeline results in it producing new APIs, training courses, methodologies, libraries, frameworks, books and development tools.
Keeping that in mind, many enterprises skip updates, frameworks, development tools and platforms knowing that there is no return on investment and the new only exists to justify new revenue for the vendor.
A blog entry for the new XYZ framework from large software vendor Q should be measured on the merits of the new XYZ framework with deductions for the unstated financial self-interest of the vendor.
Vendor lock-in problems for installed in-house deployments are bothersome, SAAS/cloud based ones are more deeply int Vendor lock-in since they force upgrades faster.
We ran into a 'problem' with the Evergreen Firefox version 40. Previous versions had a bug that required us to have a work around in our product. Firefox was supposed to fix that bug and it did, happy times!
However, version 40 also broke the fix we had in place! Our browsers on our test machines updated and we were starting to see the bug. Unfortunately this being an evergreen browser, at the same time all our users on firefox were seeing that exact same bug.
However, version 40 also broke the fix we had in place! Our browsers on our test machines updated and we were starting to see the bug. Unfortunately this being an evergreen browser, at the same time all our users on firefox were seeing that exact same bug.
Ted is the kind of person who argues against $100k/year in tech upgrades, then wonders why it costs $10mil five years later to do emergency upgrades when everything collapses in on itself.
@Elroy, thats why Silverlight is/was so great for us and our client. it just worked. No incompatibilities because some software company did browser updates is some JS engine. Our OOB apps are great/fast and works on mac too (.net5 is not even close).
@Ted, hmm makes me wonder why 'they' don't work any further om SL. Its is sure NOT of the benefits of devs or our clients.
Anyway thats why our company is not looking anymore for client software build in VS or from MS. Its too risky. MS dumped too many tools. Whats next!?
But still love you scott !
@Ted, hmm makes me wonder why 'they' don't work any further om SL. Its is sure NOT of the benefits of devs or our clients.
Anyway thats why our company is not looking anymore for client software build in VS or from MS. Its too risky. MS dumped too many tools. Whats next!?
But still love you scott !
@Asbjørn: Thanks for the reply. I did some testing with Edge on some public Silverlight demos. It did not automatically detect that the pages needed IE. Do you have any references or info on what is needed for Edge to decide to show that page?
@Ed
Silverlight was chiefly dropped because the web should be plugin-less, and certainly NPAPI-plugin-less.
Deprecating Silverlight was to the benefit of your clients. The only functional browser that still supports NPAPI is Firefox, and I'd wager that support is not long for this world. Eliminating Silverlight means that you have to move to HTML5, presumably, which is a vastly better solution.
Silverlight was chiefly dropped because the web should be plugin-less, and certainly NPAPI-plugin-less.
Deprecating Silverlight was to the benefit of your clients. The only functional browser that still supports NPAPI is Firefox, and I'd wager that support is not long for this world. Eliminating Silverlight means that you have to move to HTML5, presumably, which is a vastly better solution.
In education (K-12) there are similar problems to what Scott's wife has. I have teachers using Flash or Shockwave based sites built as much as 10 years ago and then essentially abandoned. They survive mostly because they make some ad income and nobody remembers them at hosting company I think. However someday (not too far off) Flash and Shockwave will die (rather than security hole ridden death bed) and these sites will just go away. We already have issues with text books written on standalone Flash 7,8,10 that don't work and sites that use unsigned Java code that are blocked. It would be great if these were rebuilt in HTML5 but who is going to pay for it to happen. Even the services many schools pay for (a lot of money for) aren't getting updated. Ugh.
Our profession too is a moving target, adaptive programmers; adaptive site design. Just count the number of books, blogs and languages we have consumed in the last many years. Ours is not a stagnant profession, it is discouraging though to think of beautiful creations only a few years old that now crumble under the inadequacies of their CSS. Looking forward with well designed responsive code and well structured styles and trying to stay abreast of changes is what it takes today. Here's to evergreen programmers! Nice article.
I really like that Microsoft is getting on the evergreen bandwagon with Edge. But Scott - Edge has been out a month, and FF and Chrome have been evergreen for years. Pointing finger to Safari now is a bit cheeky, when "Everyone needs to get on board and move forward." used to mean IE not so long ago...
Tony Edgecombe - "I'm not sure compatibility modes are a good idea, they just encourage lazy and poor behavior from developers. "
@Tony Edgecombe - I understand your sentiment but the web is bigger and more entangled than just developers producing commercial sites who should know better. There is a lot of useful content on the web that maybe on sites that don't get updated frequently and I think there is a middle area that needs to be supported longer via compatibility (for the better or worse depending on your view). It's not about lazy developers but about content experts in fields who may not be developers and updating every 3-6 months because that's not their niche. A side effect of what makes the web so accessible and amazing is you have people providing sites who may not be experts in creating sites (although these days more and more of that content is moving onto platforms that handle it for you and we may see less issues going forward).
@Tony Edgecombe - I understand your sentiment but the web is bigger and more entangled than just developers producing commercial sites who should know better. There is a lot of useful content on the web that maybe on sites that don't get updated frequently and I think there is a middle area that needs to be supported longer via compatibility (for the better or worse depending on your view). It's not about lazy developers but about content experts in fields who may not be developers and updating every 3-6 months because that's not their niche. A side effect of what makes the web so accessible and amazing is you have people providing sites who may not be experts in creating sites (although these days more and more of that content is moving onto platforms that handle it for you and we may see less issues going forward).
It's kinda of sad to see so many web sites break that easily with browsers updates.
I'm sure the large majority of issues wouldn't even exist if web developers were using a decent DOCTYPE and valid HTML+CSS. I'm not even talking fancy JS libs.
I mean how many website you can count that pass W3C validation ? Yep...
When respecting rules, you have way less problems.
---
@Ian W
More info over here:
http://blogs.windows.com/msedgedev/2015/08/26/how-microsoft-edge-and-internet-explorer-11-on-windows-10-work-better-together-in-the-enterprise/
http://www.smashingmagazine.com/2015/01/inside-microsofts-new-rendering-engine-project-spartan/
http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx
I'm sure the large majority of issues wouldn't even exist if web developers were using a decent DOCTYPE and valid HTML+CSS. I'm not even talking fancy JS libs.
I mean how many website you can count that pass W3C validation ? Yep...
When respecting rules, you have way less problems.
---
@Ian W
More info over here:
http://blogs.windows.com/msedgedev/2015/08/26/how-microsoft-edge-and-internet-explorer-11-on-windows-10-work-better-together-in-the-enterprise/
http://www.smashingmagazine.com/2015/01/inside-microsofts-new-rendering-engine-project-spartan/
http://blogs.msdn.com/b/ie/archive/2014/04/02/stay-up-to-date-with-enterprise-mode-for-internet-explorer-11.aspx
Comments are closed.
Funnily enough, I wrote a short piece about it a few days ago here.