4 ms·
With GTK, QT, Tk, etc we used to have a fairly good near-native cross platform story before mobile happened. Apple's reluctance to accept non-native code, Googl
by sjmulder 9y ago
With GTK, QT, Tk, etc we used to have a fairly good near-native cross platform story before mobile happened. Apple's reluctance to accept non-native code, Google's pick of Java for Android and early smartphone resource limits made native code a necessity. Meanwhile the web developed into a universally supported application platform which made it inevitable that JavaScript made its way to mobile as processing power increased.
The desktop became just another platform to target. Few cross platform apps can afford to not target the web with all of its benefits like instant, no install required delivery. A whole generation of developers is growing up on Webpack, Babel and React.
Who can fault Electron for existing?
As a user I mourn the cost at which this new wave of desktop apps come. If it were only memory I could buy more – up to a limit – but many of these apps put us back a good 10 years in responsiveness and even screen real estate. My workstation feels like a two year old phone. Who thought unchecking “Show window contents while dragging” would ever make sense again?
Luckily, to get to the original question, we are getting new options. I'm quite excited about Xamarin, which lets us provide a good experience on mobile, against the native toolkit if we like, but also a fast, familiar desktop app.
This isn't worth anything as long as we can't target the web and this is where I hope WebAssembly will bring us.
I remain hopeful. We must be able to do better than ship web browsers to our desktop users, but maybe we're not quite there yet.
- TensorMetric 9y agoIf only Microsoft would let us build native UWP apps in F# without having to jump through hoops with web frameworks https://news.ycombinator.com/item?id=15007166 https://news.ycombinator.com/item?id=15007166
- millstone 9y agoWait what? That's totally astonishing - I thought the entire point of .NET and the CLR was to be a language-agnostic runtime. Why can't you build UWP apps with it? How do they even know?
- bonoetmalo 9y agoI'm currently working through a CLR via C# book club at work, so I'm curious as well. I know you can make WPF apps in F#.
- pjmlp 9y agoThere is no CLR on UWP, see https://news.ycombinator.com/item?id=15015761 https://news.ycombinator.com/item?id=15015761
- pjmlp 9y agoThere is no CLR on UWP, everything is AOT compiled to native code, excluding JavaScript. VB and C# make use of .NET Native and C++/CX are just a few C++ extensions that look like C++/CLI but compile to native code as always. One can also use standard C++ with WRL or C++/WinRT libraries. .NET Native shares the compiler backend with Visual C++. The issue is that the .NET Native compiler team doesn't care about supporting the IL required by F#.
- seanmcdirmid 9y agoI once had to really compile one of my UWP apps to get it working on a locked down Surface Hub (otherwise, I just ever ran them in the debugger). My freaking god, it took 45 minutes to compile a small app...no way...they threw out everything that was good about the CLR for AOT that allowed them to what...run on embedded devices? It's really too bad, Win2D was quite nice.
- pjmlp 9y agoPerformance. Windows 8 was also AOT compiled to native code, but using the old Bartok toolchain from Singularity(MDIL). UWP is what Longhorn should have been in first place, if WinDev and DevTools actually worked together. COM based OS ABI fully native, to the point only VB and C# are used in most Windows talks, even for the new UI composition engine. C++ is still there for the kernel, device drivers, audio and graphical critical performance components like DirectX. Everything else can enjoy the productivity of .NET languages and respective tooling. Which meant that any of my WP 8.x and 10 devices run considerably faster than Android devices of similar price range, while having less overall memory requirements.