6 ms·
Because .NET makes it very easy for average developers to write GUI programs, and Visual Studio is what they use to write them. In theory, this developer could
by sillysaurus2 13y ago
Because .NET makes it very easy for average developers to write GUI programs, and Visual Studio is what they use to write them.
In theory, this developer could just use Mono to run his .NET app on Linux. But that requires them to learn how to do that. Personally, I've never found a clear tutorial on how to take a .NET GUI app that you've just written in Visual Studio and get it running on Mono. I haven't looked in several years, so I thought I'd give it a try right now. I googled "visual studio mono" and these were the top 3 results:
http://www.mono-project.com/Visual_Studio_Integration http://www.mono-project.com/Visual_Studio_Integration
http://www.mono-project.com/Working_with_Mono_and_Visual_Studio http://www.mono-project.com/Working_with_Mono_and_Visual_Stu...
http://www.mono-project.com/GettingStartedWithMonoTools http://www.mono-project.com/GettingStartedWithMonoTools
None of those are clear at all. The second page links to this screencast: http://www.mfconsulting.com/product/prj2make-sharp/tutorial/TestInMono-SwfApp.html http://www.mfconsulting.com/product/prj2make-sharp/tutorial/...
which illustrates how to use this thing with Visual Studio 2003(!) and demonstrates part of the problem: the Mono version of the app looks noticeably different from the native Windows version. Sure, this can probably be fixed, but it's yet another issue that the dev has to spend time learning how to hack around.
This situation results in substantial cognitive overhead. It's unlikely that an average .NET dev will be able to go into work, install this Mono plugin, compile their app using it, and present to their coworkers, "Look! We don't have to change our process at all, and we can deploy our app on the latest Ubuntu with a minimum of hassle."
It's hard to imagine how wonderful it is to build .NET apps compared to dealing with Qt, because Visual Studio's GUI designer is just so good. Suffice to say, there are a lot of network effects that keep a developer mentally locked into Visual Studio's paradigm of "here's how you make this GUI form;" a paradigm which is immensely difficult for Linux to support natively.
I think it's a mistake for Linux to even try to support this, though, because it's probably focusing on the wrong problem. The way to beat Microsoft is to make it so easy to write cross platform business apps that newer generations never even bother figuring out how to install Visual Studio. I think the web browser will be that solution within the next decade. It's not quite there yet -- it's way easier to get a GUI workflow up and running using VS's designer -- but it seems inevitable. So if you share the author's concerns, then the best course of action is to write some quality tutorials for your web frameworks, and to invent easier frameworks. The advantages of the web will naturally outweigh any possible native program advantage.
- Spearchucker 13y agoNot to detract from your points (you make good ones); web is probably not a good medium for such displays. Not always, at least. You'd want them to be reasonably functional without comms. Last I checked (I may be wrong), HTML 5 constrains local storage to 5Mb, which is precious little, if the display uses images/media.
- hk__2 13y agoUse local files for that.
- quarterto 13y agolocalStorage isn't for resources, it's for data.
- Spearchucker 13y agoThat's a very valid point.
- krallin 13y agoI'm not an expert in embedded displays, but I assume you'd simply run a webserver on localhost.
- Spearchucker 13y agoWeb 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.
- ams6110 13y agoA lightweight local web server is not going to be any more complicated than a stand-alone program that does the same thing.
- 13y ago