I use 365 Home at home. Five users for $100/year means $20/user/year. How many years at $20/year would it take to pay off a 2019 license? Keep in mind, I've always been anti-subscription because of not wanting my software to expire. I just couldn't make that argument with the 365 Home pricing. The price was too reasonable. The Adobe stuff, on the other hand, is a totally unreasonable subscription. I actually go looking for an Office/365 "gift card" around Christmastime every year when they go on sale for $80. That brings it down to $16/user/year. I haven't analyzed the business/enterprise/education offerings. All I know when it comes to those is that Microsoft is having a whole lot of success with them. So presumably other business people have done their math and decided its the way to go. Apart from the reliable revenue stream, there is another reason for Microsoft to prefer users be on 365. Fewer customer support headaches involving users who have old, but still supported, versions of Office. Every software developers will readily acknowledge they hate getting bogged down supporting old versions of software.

If your Office/365 subscription expires, the apps go into read-only mode. Microsoft took into account people being concerned about potentially not having access to their data.

I tend to view pretty much everything in life as double-sided. Very few things are bad with no good, or good with no bad. I just checked. Seems updates to extensions have "always ignore" as an option. The VS update itself doesn't. Not sure if "always ignore" means never ever again tell me about an update for that extension. What I've found works best for other software products is a combination of "ignore THIS update" (but tell me when another one comes out), and "ignore THIS update for xxx days". The later option is pretty rare. The VS update notifications flag probably makes the later unnecessary. Those developers who are looking for something to be fixed want an update as soon as possible. Those who are not encountering any problems (because they're probably working in a different coding area) "most likely" just want to know when the next actual feature set is released -- and whether any of the new features apply to what they do. That's pretty much my M.O. unless I'm looking for an excuse to do something other than code, so I run updates. I think the VS update process "suffers" from VS being so big and all-encompassing. Most developers are unlikely to use maybe even 10% of the total VS product -- and I'm referring to Community edition. With the grander editions, it's probably even less. Might be nice if Microsoft were able to better figure out whether a given update even matters to a developer, as in, whether the developer even really uses the portion of VS that's impacted. (Hey Cortana, wanna take a shot at that? :) ) Trying to only update the pieces a given developer uses is probably too high-risk. I see that as a test nightmare for Microsoft and ultimately bug-prone. Is VS still stable if only Widget-3 and Widget-7 get updated after previously only having updated Widget-5 and Widget-10 but not Widget-1 and Widget-6? However, simply deciding whether a given developer even uses the code being updated but then requiring a full product update if desired doesn't create those problems. The "friendliest" would be to sort "here's updates we don't think you need" to the bottom of the list in their own group and not add them to the flag count.

JavaScript is now on the very very slow train out of town. Not immediate panic, but the new Web Assembly is lining up to give it the boot over the long haul. Web Assembly is what should have been around all along. JavaScript suffers from never having been intended as a serious enterprise-grade programming language. It was only intended to do little short script tasks. Even Google came face-to-face with that reality when they realized a large code base like Angular was totally irresponsible to try and maintain in JavaScript thus leading to their adoption of arch-enemy Microsoft's TypeScript. Web Assembly is machine readable pseudo-code (similar concept to Microsoft's CIL for .NET). Use the disciplined typed language of your choice and have the compiler output Web Assembly code. Same concept as C#.NET, VB.NET, and F#.NET all compiling to processor independent CIL. The CPU-independent Web Assembly code gets (ideally) compiled into the browser host CPU's machine code upon loading. Compiling existing JavaScript to Web Assembly will certainly be possible and largely desirable. No doubt Google is focused on making sure Angular can be compiled into Web Assembly. (TypeScript to JavaScript to Web Assembly.) Thus JavaScript won't be going anywhere anytime soon. However, very large project code bases are extremely inefficient to maintain in JavaScript. There is a large collection of far better languages that exist to choose from. So new development will migrate to using other languages, and that will be a very large positive for both companies and developers. The potential for a .NET Standard/Core framework targeting Web Assembly would be a huge development for enterprise-class developers. The ability to use existing .NET (C#, VB, F#) business logic libraries, etc, as part of browser client apps means serious new benefits. In the long run it can be envisioned Web Assembly might further unify client app development with mobile apps, desktop apps, and browser apps coming closer and closer to using more and more shared code. There are frameworks for accomplishing much of this already for mobile and desktop. Web Assembly may be the key to bringing browser apps into this realm as well.

I'm constantly at my desktop keyboard also. How long did it take you to get used to the ergonomic keyboards? I already had some 10+ years of working on standard computer keyboards before they came out, so I've always been very hesitant about an ergonomic learning curve. Also, how well do you do switching back to standard keyboards when you have to?

if someone doesn't have a Mac, they are out of luck

Don't go complaining to Microsoft about that. My understanding is that's a restriction imposed by Apple. iOS apps can only be signed on Macs. Remember, once Jobs turned his back on the Apple-II concept and sent Apple down the road of closed-architecture, Apple users have been far more captured than Microsoft users. I was listening to an electrical contractor complain the other day about how Apple's home stuff is "unique" and makes life miserable when it comes to flexibility on what can be used in an overall home system.

I hadn't noticed W10 stopping anyone from having desktop icons if that's what they prefer. W10 works great contrary to the comments from the "I hate change" crowd.

I hadn't noticed W10 stopping anyone from having desktop icons if that's what they prefer. W10 works great contrary to the comments from the "I hate change" crowd.