Who ever thought running everything in a browser would make for some nice consistency should remember what Emmerson said: A foolish consistency is the hobgoblin of little minds.

Nice post. I understand exactly where you're coming from. One bit I can add is that I can remember, about 15 years ago, taking a relatively large application written in C++/MFC and recompiling it with C++/CX, adding .Net features, hooking it up to WCF, and even having it support auto-install when new versions were available. As far as I was concerned, that was the future. Little did I know how strongly Microsoft was hated. Why didn't C++/CX catch on? Because it was Microsoft-only, and that meant you couldn't write software for the 5% Mac/Linux market that zealots struggled mightily to target. Then Java comes along and, though it does have some strong points, it really has nothing over VB other than it's not Microsoft. Finally, someone figures out the right coding gymnastics and mystical incantations to get javascript to work in a browser. True, the resulting software was and still is vastly inferior, but it does have one thing going for it: It's not Microsoft! So now a generation of developers is condemned to a world where javascript is actually considered capable of making production-quality code because the users have been conditioned to accept it. So here we are now writing software whose responsiveness would make the 90's VB guys laugh all while laboring under platform burdens: *Types, what's that? *Threads, you mean link on my shirt? *Oh, F5? Yeah, don't touch that. *No, don't use that menu, that's the browser's menu. Use the menu within the menu. *No, that window can't be moved. It's just drawn to look like a window. *Sorry, you need Internet access to use the software, but have I mentioned that it doesn't require Windows to run? Yeah, I know most people still run Windows, but Windows isn't open source!

JavaScript is around for one reason: To stick it to Microsoft. There was a time when types mattered (remember why "smart" people hated VB?). There was a time when performance mattered (remember when C++ was cool?). There was a time when user interface standards mattered (Anyone remember UI guidelines?). Now all that matters is having your code - however much of a mess it may be - run in a browser even though if it's a browser running on a PC, 98% of the time it will be running on Windows. But I guess we have to worry about that 2% because it could be Linux! Or, a Mac! Two percent of the market is only a failure if it's Windows phone. Why don't we write apps for PCs? That only is a smashing success for mobile. It would never work for a PC because....Microsoft owns the PC, and we can't have that. No, let's beat our heads against the wall trying to get some hacked together language to do even the most basic things.

Cons: 1. Percentage of sales go to Microsoft. 2. Not sure if non-UWP apps can be sold via the store, but I think they can be distributed privately. 3. There are some other minimal requirements such as passing a certification test and providing several logos of various sizes, but these aren’t difficult and are actually beneficial. 4. You’re subject to potential restrictions on how you classify your application. 5. No support for Win7. Pros: 1. You don’t have to host a site and users don’t have to wonder if they can trust your site. 2. Once you successfully submit an app, updating it is extremely easy. 3. In most cases, updates are automatically downloaded by your users. 4. All financial transactions are handled for you. 5. Many analytics available via DevCenter (download stats, advertising performance, usage stats, crash logs, user reviews, ratings, feedback, etc.) 6. You can provide links to your app that directly open the Windows Store (which is most likely in the center of a user’s taskbar) right to your app. For me, the risk-free ease of hosting and distributing my apps is the best part. I had to embrace UWP, but its similarity to WinForms made it easier and now I have apps that run on and automatically scale to multiple Windows devices.

I am targeting UWP with a combination of C# and C++. I find it very easy especially with its similarity to WinForms. Backward compatibility is an issue, but more people are running Windows 10 by far than are running Linux yet that doesn't stop developers from targeting Linux. Also, I don't have the anti-Microsoft sentiment that drives a lot of developers these days. I prefer to target familiar platforms with robust tools. If I understand Microsoft's current strategy, then developing for UWP makes sense. Why would a business equip it's staff with top-of-the-line iPhones or Androids that are not allowed for personal use when they can buy either a cheaper Windows Phone for strictly phone/email or a more powerful one that is ready for Continuum? The fact that the Windows Phone has less apps is then a positive and adds to the security of the platform. That may change as more business people start ditching laptops in favor of Continuum phones and start demanding more apps. I definitely see the potential there. I also find targeting the Windows Store to be almost painless especially with its integration into Visual Studio. Sure, there are a handful of icons/splashes that cover various resolutions that you need to make, but any good graphics editor will be able to churn those out and your app benefits. It's also extremely easy to release updates. The big negative of UWP is, as has been mentioned in this thread, Microsoft's track record of quickly abandoning a technology. I don't know if there's infighting going on there or what, but it is a risk to adopt anything they offer. I can only say that I've seen many development technologies and in my opinion UWP is superior.

JavaScript is an aberration. Any efforts to make it more manageable (i.e. TypeScript) is just putting lipstick on a pig.

The reason javascript succeeded as much as it has is for one reason: It was non-Microsoft. All of the reason we say the Microsoft approach failed are only applicable to Microsoft. When someone else tries to bring about a closed, proprietary, and poor-performing system that only works on limited platforms, suddenly it's the host OS that needs to adapt. The real breakthrough will occur when a sizeable-enough contingent of developers realizes the folly of writing any kind of serious application code for a browser. I think it will happen when someone finally tires of having to spend 95% of the coding effort just to get the code to work normally in a browser. It takes time to mover the heard, though. But hey, there's hope. Now that Microsoft gives away its OS, there's no need to cripple ourselves in a browser anymore, right? Moooo.... Baaahhhhhh.... The herd is stirring...

I’d like to be able to tell you that you can have a lucrative career as a C# developer, but I can’t. I’m not saying that you CAN’T make it as a C# developer, but the sad fact of the matter is that technology jobs are beholden to factors beyond your control. If you want to make money writing an app, you can go the Xamarin route. Even then, though, you’re at the mercy of the whims of a fickle population. Often an app is successful despite the fact that the app is a rehash of what can already be done (and better) elsewhere. Somehow the app became “cool”, though, and that’s all that counts. As for writing serious software for business/personal productivity, you’re again at the mercy of strange factors. There is still a strong anti-Microsoft sentiment in the industry and that’s the primary reason why teams of developers undergo herculean efforts to get even the simplest application running in javascript. It doesn’t occur to these developers that if a customer purchases your software, then he has a vested interest in being able to install and run your software. There’s no need, then, to make it run in a browser! In almost every case, the browser is just going to be run on a PC, so why burden yourself with a junk language like javascript unless you’re just trying to stick it to Microsoft? Don’t get me wrong. Browser-based software has its purpose. When your customers are web users who aren’t directly purchasing your software, there’s less of a justification for installing software. Even then, though, I’d argue that the severe limitations of web-based development aren’t worth it. But then, I’ve been around long enough to remember when we used to laugh at the kinds of things that are acceptable practices today. Let me finish, then, with advice contrary to what you’ve been hearing. Being a “polyglot” isn’t what it’s cracked up to be. Being “jack of all trades, master of none” is why we have so much bad software out there. If job satisfaction matters to you, then it’s OK to be an expert at fewer things. Though it seems many people are happy with serviceable junk, there are still people out there who will pay for quality.

I think programmers get hung up on some notion of consistency as if it makes sense for a "web" application installed on a client to check the browser cache for an updated copy of an HTML dialog EVERY TIME IT DISPLAYS. If the application is installed, why are you checking for updated pages? Because you want to waste computing cycles? Once step forward, two steps back, I suppose. As for this notion of consistency, Emmerson said it best: "A foolish consistency is the hobgoblin of little minds."

That's all well and good and people can debate about which code is easier to read. What's really important, though, is how easy a language is to look at code written for it and understand all of what it's doing. Unfortunately, the best language for that in the .Net world, C++/CLI, gets almost no support.

Yes, they have definitely forgotten about C++ development. I think it was 2008 that was supposed to have been an answer to C++ concerns, but that version stinks, too: Nearly usless help, intermittent intellisense, no new support for C++/CLI, embarrassing "Class Wizard" dialog, etc. They definitely must have had a change in the Visual Studio team (maybe they outsourced it) because the quality has really suffered lately. Even C# stuff: The project properties dialog is laughable (I could draw it by hand faster) and why can't I redirect object file output? The dumbest thing they did, though, was not follow up with C++/CLI support. They finally had something that could let people ease into .Net and simplify their work by sticking with one language and they all but abandoned it. Try creating any new web service with C++. Or, if you have one, try debugging it - you can't because Visual Studio won't let you. My theory for what went wrong is that Microsoft decided to put Visual Studio under the control of whoever it was who thought it was a good idea (way back when) for Visual Basic to have no main client window. I think the price of getting him to finally make it work like a resonable editor was to give him control of the newer versions.