5 ms·

There's so much going on that it's almost making me hesistant about taking on the new strategies like .NET Core or where to go with user interfaces. For the lon

by jug 10y ago

There's so much going on that it's almost making me hesistant about taking on the new strategies like .NET Core or where to go with user interfaces. For the long term, is it better to lock myself into UWP and Windows Store, or reap the benefits with Xamarin? Much would be easier if UWP was open and DirectX accelerated on Windows and OpenGL accelerated on Linux or macOS, and uploading these apps on Windows _could_ be to Windows Store but wouldn't be so architecturally tied to it. I know there are ways to dodge their store even with UWP apps, but it feels like you're hacking their intented model and on thin ice for whatever will come or change in the future. I never really liked platforms where application development is tied to distribution methods, especially not when .NET has it in its history to not be that (other than maybe a very slight nudge towards ClickOnce). I felt like a part of the .NET philosophy died with UWP. I applaud Microsoft for where they have come and their latest developments are intriguing but I see many quite major annoyances remaining. I work almost full time with .NET though, simply because that's where my money is for now. But I'm not touching UWP either at work or at home. It's still also receiving a mixed response at best by developers, from what I've heard. It's like... "OK, so here's this limited UWP app compared to WPF on desktop, because we have to build it on an API with Windows Phone in mind which no one uses and then upload it to this single store out of our control, with the excellent company of scam apps tarnishing our trademark". I feel like this is Microsoft's unfortunate reality of where things stand which they should move from. "How do we best fix these concerns?"

DaiPlusPlus 10y ago
> But why should a web application willingly be tied to a particular web application host? Performance. ASP.NET wasn't originally tied to IIS - the grand version (back in 2001) was to allow any application to host a website too, that's all in the `System.Web.Hosting` code - along with Cassini for lighter workloads and "IIS Hostable Core" as an analog to today's IIS Express, but that fizzled out in the late-00s only to come back as part of the post-Node trend lately. This all dates back to 10 years ago: IIS7 introduced a fully CLR-managed request lifecycle which was was aligned with ASP.NET's own lifecycle, so the reasoning goes you might as well let the two become one-and-the-same - there's no point running two separate request pipelines (the webserver's and your runtime framework's) when one will do. ...of course this was back in the day of the "fat" threaded webservers, like Apache and Netscape Server - and remember IIS took it further by adding a kernel-mode component: `HTTP.sys` to get an edge over usermode-only servers. So far I haven't seen any work on reinventing IIS for today's fast and light servers like nginx where all people want to do is serve Node.js applications.
- jug 10y ago
  Sorry, edited my post to try stay more focused and less all over the place so what you quote got lost. :) Interesting about Cassini etc, I never knew! I guess then the question rather becomes whether it's worth the performance benefits since lockins and added Windows licenses can be so off putting, but it's becoming at least less of a worry now that you can transition to ASP .NET Core.
- my123 10y ago
  There is the Kestrel server, which is used for ASP.NET Core AFAIK, it's multiplatform also, but it's recommended to use a reverse proxy as it isn't fully audited yet
pjmlp 10y ago
Actually I think that UWP has brought .NET back to its roots, as .NET was originally born as COM+ Runtime. Also I look forward for sandboxing everywhere, since micro-kernels only got lucky on embedded systems.
mlsarecmg 10y ago
Electron + React or React-native is the way to go. You get cross platform out of the box, mobile as well, it is silly easy to work with, hard parts all abstracted (notifications, updating, installers), the biggest dev community on earth and an immense eco system. The traditional desktop application is dead. In desktop land you have dusty tools, slow and outdated UI frameworks (as in MVVM or worse: UI-in-code) like GTK, XAML, ..., barely any community or components to re-use. Microsoft itself starts to make its products on these new platforms. Visual Studio Code, or Office fabric for instance. Many popular everyday apps that people use without knowing it are Electron based. We're currently transferring a huge C#/WPF monster into React. The gains are ridiculous. React runs circles around XAML (less code, less boilerplate, faster) while Redux makes handling state simple. And it's a thing of beauty seeing it run everywhere, Windows, Linux, MacOs. Android and IOS as well with few adaptions (React-native) while thanks to Redux the heart of the app is 1:1 portable.
- rpeden 10y ago
  This approach doesn't solve the problem of Electron and NW.js apps being terrible for laptop battery life, but this appears to be something that typical end users aren't terribly concerned about. On the bright side, React Native for Windows works quite well, and there's even a WPF version of it[1]. React native for macOS[2] worked decently when I tried it, too. [1] https://github.com/ReactWindows/react-native-windows/tree/master/ReactWindows/ReactNative.Net46 https://github.com/ReactWindows/react-native-windows/tree/ma... [2] https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
  - mlsarecmg 10y ago
    I've only brushed over React native for desktop. How was your impression of it, is it worth a try over Electron? How do you handle packaging, notifications, updating, installing?
- m_fayer 10y ago
  I mostly agree with you and I'd like to take the leap, but Javascript. I've tried to love it, and Typescript is a big improvement that I use happily. But in the end I'm just always going to be way more productive (especially in large projects) with a modern statically typed language with functional features. That is, C#, Kotlin, maybe F# or Scala. Really, you're right - for most consumer apps outside of games and graphics, the web stack is hard to beat. Between the devtools and inspectability of the view layer, the fast and interactive nature of development, and the sheer size of the community, there's nothing like it. So I really blame Apple/Google/Msft for neither updating their UI toolkits to keep pace with the web, nor shipping something Electron-like in combination with a CSS framework and nice bindings for Swift/Java/.NET that would allow for development on the respective platforms that really feels and performs native while leveraging web technology in the view layer. Both of those approaches would have worked, and neither was chosen - so now we have this bizarre situation with no good choices on the desktop. I have high hopes for WebAssembly, and if that fizzles I guess I'll have to make peace with using a language I don't like. At least if I ever want to develop for the desktop again.

by jug 10y ago

DaiPlusPlus 10y ago

> But why should a web application willingly be tied to a particular web application host? Performance. ASP.NET wasn't originally tied to IIS - the grand version (back in 2001) was to allow any application to host a website too, that's all in the `System.Web.Hosting` code - along with Cassini for lighter workloads and "IIS Hostable Core" as an analog to today's IIS Express, but that fizzled out in the late-00s only to come back as part of the post-Node trend lately. This all dates back to 10 years ago: IIS7 introduced a fully CLR-managed request lifecycle which was was aligned with ASP.NET's own lifecycle, so the reasoning goes you might as well let the two become one-and-the-same - there's no point running two separate request pipelines (the webserver's and your runtime framework's) when one will do. ...of course this was back in the day of the "fat" threaded webservers, like Apache and Netscape Server - and remember IIS took it further by adding a kernel-mode component: `HTTP.sys` to get an edge over usermode-only servers. So far I haven't seen any work on reinventing IIS for today's fast and light servers like nginx where all people want to do is serve Node.js applications.

jug 10y ago
Sorry, edited my post to try stay more focused and less all over the place so what you quote got lost. :) Interesting about Cassini etc, I never knew! I guess then the question rather becomes whether it's worth the performance benefits since lockins and added Windows licenses can be so off putting, but it's becoming at least less of a worry now that you can transition to ASP .NET Core.
my123 10y ago
There is the Kestrel server, which is used for ASP.NET Core AFAIK, it's multiplatform also, but it's recommended to use a reverse proxy as it isn't fully audited yet

pjmlp 10y ago

Actually I think that UWP has brought .NET back to its roots, as .NET was originally born as COM+ Runtime. Also I look forward for sandboxing everywhere, since micro-kernels only got lucky on embedded systems.

mlsarecmg 10y ago

Electron + React or React-native is the way to go. You get cross platform out of the box, mobile as well, it is silly easy to work with, hard parts all abstracted (notifications, updating, installers), the biggest dev community on earth and an immense eco system. The traditional desktop application is dead. In desktop land you have dusty tools, slow and outdated UI frameworks (as in MVVM or worse: UI-in-code) like GTK, XAML, ..., barely any community or components to re-use. Microsoft itself starts to make its products on these new platforms. Visual Studio Code, or Office fabric for instance. Many popular everyday apps that people use without knowing it are Electron based. We're currently transferring a huge C#/WPF monster into React. The gains are ridiculous. React runs circles around XAML (less code, less boilerplate, faster) while Redux makes handling state simple. And it's a thing of beauty seeing it run everywhere, Windows, Linux, MacOs. Android and IOS as well with few adaptions (React-native) while thanks to Redux the heart of the app is 1:1 portable.

rpeden 10y ago
This approach doesn't solve the problem of Electron and NW.js apps being terrible for laptop battery life, but this appears to be something that typical end users aren't terribly concerned about. On the bright side, React Native for Windows works quite well, and there's even a WPF version of it[1]. React native for macOS[2] worked decently when I tried it, too. [1] https://github.com/ReactWindows/react-native-windows/tree/master/ReactWindows/ReactNative.Net46 https://github.com/ReactWindows/react-native-windows/tree/ma... [2] https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
- mlsarecmg 10y ago
  I've only brushed over React native for desktop. How was your impression of it, is it worth a try over Electron? How do you handle packaging, notifications, updating, installing?
m_fayer 10y ago
I mostly agree with you and I'd like to take the leap, but Javascript. I've tried to love it, and Typescript is a big improvement that I use happily. But in the end I'm just always going to be way more productive (especially in large projects) with a modern statically typed language with functional features. That is, C#, Kotlin, maybe F# or Scala. Really, you're right - for most consumer apps outside of games and graphics, the web stack is hard to beat. Between the devtools and inspectability of the view layer, the fast and interactive nature of development, and the sheer size of the community, there's nothing like it. So I really blame Apple/Google/Msft for neither updating their UI toolkits to keep pace with the web, nor shipping something Electron-like in combination with a CSS framework and nice bindings for Swift/Java/.NET that would allow for development on the respective platforms that really feels and performs native while leveraging web technology in the view layer. Both of those approaches would have worked, and neither was chosen - so now we have this bizarre situation with no good choices on the desktop. I have high hopes for WebAssembly, and if that fizzles I guess I'll have to make peace with using a language I don't like. At least if I ever want to develop for the desktop again.