Our customers have an environment where most laptops run Windows 10 but most company phones are iPhones. Those who sport tablets have iPads and occasionally Android tablets. When developing for this device environment we have to consider emulation and only use real devices when testing. We are trying hard to adopt Edge as a development browser but with the current developer tools emulation only having Windows Phone devices out of the box our guys have to resort to custom configurations. Considering the market share of Windows Phone devices versus the market share of Android and iOS devices it doesn't make sense for us to use Edge on our dev boxes and as such we default to Chrome. The result is that our user experience is very refined for Chrome on Windows, quite good for iOS devices and rather choppy for Edge on Windows. I believe that if we managed to default to Edge as a dev browser we could improve that experience but it won't happen as long as device emulation is so limited out of the box.

Recently at work we upgraded to Windows 10. We still have the option of using Windows 8.1. Reason being our Software System that is pertinent to our business only works well with 8.1. There is another issue that I have found with Windows 10 and Windows 8.1 when using simultaneously. In Windows 8.1 when you click on a link to a webinar, a video, or fill out a form or application where you have to hit a submit button to send. There are many applications that will not work by clicking on the link you have to open Microsoft Edge and copy and paste the link and Edge in order for it to submit a form or open a link to another source. This is a work around that we have been using for a long time but it is very frustrating. Is this something that was just locked out of 8.1 or is it because the other end is using 10 and it's not compatible if I'm using 8.1? My email address no longer works but I'm going to go ahead and enter it in the Box down below anyway

I'm the founder of a company producing a web based EHR on classic ASP with jscript (not vbscript) since 2001. I've looked at and tried almost every platform that was or is since then (java, PHP, ASP.NET, Ruby/Rails, node, python, scala, go) and have yet to find a superior development platform.

Instead of using vbscript, we chose to use jscript. As the universal language of web development, javascript is now the only language my programmers need to know for both client and server, and every web programmer knows javascript. So, I don't have any problem finding developers. I also don't have much trouble training someone to develop, since javascript is relatively easy.

ASP isn't fast, but, it doesn't matter. All of our HTML is built by transforming XML with XSL. This process DOES use compiled code, so, it's about 10x faster than ASP for building HTML. So, we have very little javascript code inside our pages actually running to build HTML. So, our app is fast.

node is of course a js server; but, the event loop is prone to break and callback oriented coding is a confusing mess esp. for inexperienced developers. MUCH easier to just run ASP on IIS, and have a separate thread for each process; no concerns when a single process crashes. Additionally code can then be written for sequential execution without callbacks. Yeah!

IIS also provides a level of security filtering bad requests, etc. No one wants to have to code this in to their node or python server. IIS also provides SSL support, load balancing, and a host of other features (note, it would be REALLY great if you made ASP run on Apache!)... We can focus on coding and let MS focus on keeping IIS up to date.

Windows development environment allows us to run the debugger on client AND server. Step through execution of jscript makes development enormously faster.

Compilation is eliminated. Obviously, there are speed tradeoffs, but, development is much faster and easier. Additionally, I'm relatively sure that ASP is JIT compiled, and that this is cached, so, there are some optimizations and it runs faster than it would under straight interpretation. Additionally, if classic is brought back, could always add compilation.

jscript is loosely typed which obviously increases the chance of errors. However, most web applications are database driven, and, the database anyway enforces the types. Additionally, loose typing is again easier for devs and in the real web app world, rarely causes any problems. i.e. if someone is consistently putting in strings instead of numbers, it soon causes problems with the app, and, someone soon adds validation to that field.

C#, java, etc, are a pain **********. They are needlessly complex and compilation is always a headache; compatibility issues are never ending. They are fine for heavy duty coding (although, then, C++), but, heavy duty coding is less needed in the web world.

The shortcoming of classic ASP with jscript is lack of access to the windows API (although this DOES increase security). When necessary, we use com/dll/active x components, and this works fine, and there are a lot of them out there. However, it would be great if the reincarnation of classic ASP had support for the native API, particularly for access to office components, pdf manipulation, file manipulation, zipping, etc. Also classic asp with jscript is really bad at dealing with binary data.

In short, classic ASP was a great, simple platform, and it would be great (and easy) to bring it back (not that it ever even really went).

FBOFW, it would also help MS to compete in the web dev world.

The performance tools in Firefox and Chrome both have flame graphs and improving performance there is really easy. Our site is an order of magnitude slower in Edge but we have no idea why because the performance panel just says the time is being taken up by JavaScript without telling us anything else.

I assume this is already on your roadmap because I have no idea how developers at Microsoft are able to improve the performance of their web apps in Edge otherwise. Consider this a strong vote for this feature. When this is implemented, +1000 points for using an open JSON format like Firefox and Chrome do instead of an opaque internal format (we have automated internal tools that consume profiler data from Firefox and Chrome).