Web server means additional complexity both to deploy and maintain. After 20+ years in the corporate world I can guarantee that an alone-standing native client it going to beat anything with a web server.
"Beat", how exactly? 20+ years in the corporate world doesn't mean much if you can't back your opinion up with proper arguments.
Besides the confusing fact that you bring HTML5 local storage into the equation for some reason, a local web server doesn't necessarily mean more complex deployment/maintenance than maintaining a .NET application.
The problem is governance. The web sever needs to be patched, the web site configuration needs to be maintained, as does the web application. Bear in mind that a display doesn't live in an IT department, and that developers don't maintain apps - operations does. So if you compare the web server/web site scenario to a single, self-configuring native app (presumably a single .exe and a couple .dlls or something, the .exe is cheaper over a 3 or 5 year lifespan, especially if the .exe works with SCCM and ops can push updates out using WSUS or similar.
I guess if you're into Windows, setting up a web server actually _is_ a hassle to you. Rest assured that there are easier ways. If you simply want to use a web server for local sharing, forget about patching and "maintaining" the configuration. Just install it and you're done (or why not use the file:// URI scheme? I can't see any compelling reason not to in a non-interactive setup). As for maintaining the web application, well, only in the same sense you have to maintain your .NET application.
Also, pulling numbers out of nowhere isn't going to help your argument.
If anyone I oversee actively decides to not patch and maintain a system within an enterprise network for any reason, they will find themselves back on helpdesk doing password resets until they learn better. Pentesters / hackers love using setups like you suggest as easy targets to provide them with perstitant backdoors.
3 and 5 years are the common life cycle's enterprise IT use when discussing any existing implementation or any new system design. These are not pulled from nowhere.
First off, when I say "maintaining" I meant the configuration. When I say patching, I mean patching, not just trivially installing software updates. Spearchucker was trying to make this a look like a huge disadvantage over maintaining a Windows system, which it obviously is not.
Oh and as far as I'm concerned "3 to 5 years" is still pulled out of nowhere. You aren't mentioning any sources, just describing a really vague process that you think is "common". If you have a working, flexible system with which you can harness a huge continuous effort in developing the technology behind it for free, you aren't going to kill it off just because your enterprise clock says so.
The web site you build does the same thing that the standalone app does. The web site is hosted by the web server. That's an added piece of software to maintain and configure, over and above the web site itself.
The web server is going to be fine. It's usually gone through a lot more testing than your display. Displays are trivially and commonly implemented as fullscreen webapps.
It's the browser javascript that I would worry about; responsiveness is always a battle.
