Comment by __d | Hacker News Reader

Comment by __d | Hacker News Reader

I work in a similar space, although more focussed on the backend. I agree with everything you say as is applies to banking/trading.

BUT ... it's not clear to me that the majority of enterprise software development falls into this category. I think the vast majority is quite likely old VB apps that work perfectly well as web apps.

Most information workers don't have the density or latency constraints that the finance space does.

And where they do, I think in most cases their needs are satisfied by a small-ish set of applications: Excel, AutoCAD/ProE/Solidworks/etc, Photoshop/Illustrator/etc, VisualStudio, and so on.

I do think Microsoft (and Windows) needs a story for the development of "professional" apps like these. And UWP doesn't work for them. I'm not sure C# and WPF does either: how many of even Microsoft's own professional apps are written (or being rewritten) in C#?

Perhaps banking/trading is just too small a market to make it worth Microsoft's while to care about? Perhaps it's a market best served by a third-party stack/tools?

SMH that so many people think that the only ones who like information density and complex desktop apps are finance people.

What about store managers restocking product?

What about developers working on complicated projects?

What about data scientists staring at spreadsheets?

What about power users?

What about anyone with the kind of intelligence that doesn't shy away from large amounts of information?

Do most designers ever think about ANY of these people? Modern app design doesn't even TRY to throw any of these types a bone. No "Advanced >" menus anymore, no pages of options anymore, nothing. It's all just 'sit down, shut up, push the button like a good stupid little user so we can all get paid.'

I think the OP's issue is custom-written enterprise application development though: I agree with your examples of spreadsheets and IDEs (I mentioned those above), but they're generic applications, and their development doesn't justify Microsoft investing in an entire stack.

If the UX and latency requirements can be met with a web app, it doesn't support WPF/.NET maintenance/enhancement.

Web apps can do density so long as the latency requirements aren't too tight. There's where the banking folks spend their IT money.

  they're generic applications, and their development
  doesn't justify Microsoft investing in an entire stack.

Seems to me there's one or two applications for every profession, and they probably mount up.

I mean, I'm sure if you look at the statistics only 0.1% of users use Photoshop, or Premiere Pro, or AutoCAD, or SolidWorks, or Altium, or Matlab, or whatever - but if you drop support for all of them, what are users going to do?

There are also new development fronts in specialist domains that are computationally intensive or a poor fit for web-apps.

Specifically, when WPF was launched all they could talk about were the cool 3D possibilities for doctors, researchers, and such... The reality has been less "Minority Report" than we had hoped, but those kinds of demands are growing, and very often will require the level of control over hardware that demands a desktop app.

In theory a lot of this is solvable with webapps, in practice there is a reason desktop computing environments exist :)

In the past 30 seconds OP went down by two points. Downvoters... may I ask why?

MSFT got into the office.

And no keyboard shortcuts!

Visual Studio is written in C# and I think WPF, but I'm not sure anymore at this point. Most professional apps have a wide audience, and therefore can justify more development resources, so they tend to get written in harder ways (C++ and whatever UI works there). C#/WPF work great for apps that require lower costs/more productivity because they aren't going to a million seats.

I agree.

The question is whether there's enough of a market between broad-based professional apps and web apps to justify maintenance of the WPF/.NET stack.

How is the maintenance of WPF/.Net better or worse than the JavaScript flavor of the week and Browsers that are now updated weekly - if not faster?

I can understand a "Is it worth the maintenance?" question...

but I would bet .Net has better longevity and Enterprise support compared to the rapidly evolving landscape of HTML/CSS/Javascript.

Well, at least WPF has stayed in existence, relatively unchanged, for what would be eons in JS framework-years.

Number of users an app has is a horrible way to decide whether to write it in C++ or not, and even if it were a good driver Visual Studio is a $1B business for Microsoft so it’s hardly a little niche app lacking a wide audience.

VS has a lot of things going on, many of the teams to specific pieces of functionality that might seem obscure to many of us. The Shell team isn’t that big from what I recall, so yes VS is a huge business but there are a lot of things going on so it’s not like everyone in devdiv is working on core VS. It is really different from a consumer office app.

Visual Studio is not written in C#/WPF, it’s written in a mess of legacy COM and WIN32 code with some C# and SWF.

(Visual Studio for Mac is, of course, an entirely different product and codebase).

I thought it was the other way around? C# on the outside, legacy code connected on the inside? Anyways, I found that confusing. For the rest, visual studio most definitely uses WPF for much of the UI but also the chrome (e.g. see https://softwareengineering.stackexchange.com/questions/7532... and https://www.quora.com/As-of-2015-how-much-of-Microsoft-Visua... and https://blogs.msdn.microsoft.com/visualstudio/2010/02/16/wpf...).

All the new code in Visual Studio for Mac for .NET tooling is being shared with Visual Studio, written in C#.

The new plugin architecture, replacing the COM one, is implemented in .NET.

I thought VS for the Mac was just a rebrand of Xamarin Studio?

Initially yes, but they have been making the Roslyn tooling the same across both IDEs.

Visual Studio for Mac has many new features that weren't present in Xamarin Studio, like .NET Core support, ASP.NET types of workflows. And all new Xamarin.Forms improvements are shared between both IDEs.

I'm quite sure the IDE is WPF. You can attach a debugger to it and inspect the WPF component tree.

You're both right. Yes, it's WPF, and there are lots of parts written in C#. But the parent is right -- Visual Studio is C++ using COM and Win32 at its core, going back all the way to the Visual Basic IDE that shipped as part of Visual Studio 6. It would be a very difficult port to Mac, Linux, etc. As of this writing there is even no 64-bit version for Windows (although that's just a matter of spending the time and money to do it.)

The brand name has been re-used for other software. Visual Studio for Mac is Xamarin. Visual Studio Code is on the Electron platform.

Surprisingly, the lack of a 64 bit version is a performance choice.

”For a long time now developers have been asking why Visual Studio hasn’t made to switch to 64-bit. Rather than effort or opportunity cost, the primary reason is performance.” https://www.infoq.com/news/2016/01/VS-64-bit

Visual Studio 2017 launches a child process with a nodejs server upon start for a servicing stack and also javascript language services.

Reply on news.ycombinator.com