Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

.NET MAUI: .NET Multi-Platform App UI

github.com

Post reply on HN
Print view View original

181–190 of 260 posts

Re: .NET MAUI: .NET Multi-Platform App UI

#181

Post by tester34 »

ChicagoDave wrote: post #156
ab_testing wrote: post #151

Earlier quoted context omitted.

What is a good way to learn the .NET framework or a guided path to understand the development hierarchy in .NET. It seems expansive with tools for everything from web, app and desktop development. Microsoft provides tutorials but it feels like they are all over the place and not really directed.

Well this is a very loaded question. I’d tackle it by basic aspects of base development. - File Handling, IO, Streams - Data Storage, ADO.NET - Generics, Collections - Linq, Lambdas - Threading, Tasks - Cryptography I’d just build console apps, which you can do on Windows, Linux, or MacOS. Just install dotnet-core.

I'd recommend skipping ADO and learn Dapper/EF Core (this is harder to learn because its huge)

Re: .NET MAUI: .NET Multi-Platform App UI

#182

Post by [deleted] »

sk5t wrote: post #128
ocdtrekkie wrote: post #92

Earlier quoted context omitted.

> Python was built as an education/learning language first. It's popular because it's often a first language learned That's my point. Colleges have been teaching Visual Basic as a starter programming language for decades. Only in the last handful of years have colleges started switching to teaching Python first... after many years of neglect by Microsoft. My local college still has an entire specialization of their C…

> Colleges have been teaching Visual Basic as a starter programming language for decades. Where? In the US, university-level intro to programming would have been in Lisp, Forth, C, C++, and/or Java before possibly trying something else in the mid 2000s, but I struggle to imagine an American university strong in CS touching anything in the VB namespace (5, 6, .NET) whatsoever.

[deleted]

Re: .NET MAUI: .NET Multi-Platform App UI

#183

Post by GordonS »

dt3ft wrote: post #180
alkonaut wrote: post #177

Earlier quoted context omitted.

The WPF grids are fine and autocompletion is trivial. Which is the proper way to write frameworks: make it easy to make the bits you don't have. I love that it isn't created like the old RAD frameworks where you are supposed to easily drop a datagrid in, connect to a DB and basically have some Line of Business CRUD on your screen within minutes. The Telerik/Syncfusion et.al. components are massive bloated and geared…

So when purchasing Visual Studio subscription in order to write software for windows, you expect nothing to work out of the box? I'd love to see you tackle a WPF monolith within a regulated environment where no 3rd party libs are allowed. It's 2021, we're expected to deliver amazing, feature rich software in very little time, without buying 3rd party libraries. Meanwhile, there's Microsoft, using the funds from our s…

> stuff like Xamarin Forms and abandoning it half-way through

Eh? I've worked on projects using Xamarin Forms, and they turned out just fine.

Yes, it would be nice if there were a few more controls in the main Xamarin Forms library, but I don't see a problem with the community picking up some of the slack (which they have).

Re: .NET MAUI: .NET Multi-Platform App UI

#185

Post by dt3ft »

Ecstatify wrote: post #168

Fool me once shame on you, fool me twice shame on me. Windows phone/Xamarin, Microsoft really doesn’t understand what mobile developers want. What’s the point in investing to learn something when it will be in the hospice next year.

I feel the same way. I’ll bite once I see Microsoft release Outlook built with this.

Re: .NET MAUI: .NET Multi-Platform App UI

#186

Post by 7sharp9 »

eyegor wrote: post #78
alskdj21 wrote: post #25

How likely will it be that F# is supported out of the box? I understand that this is a push for mobile but hopefully a linux support will be considered. https://github.com/jsuarezruiz/forms-gtk-progress/issues/31

F# has barely any dev resources behind it last I checked. Think "fits in one small conference room pre covid". They had more focus on porting F# features than developing the language.

F# has the advantage that the features are very well considered and come from a functional programming heritage. The fact it's a functional-first language rather than a bolt-on like C# is a massive advantage.

The functional features in C# are not like for like ports of F# features and have very large gaps in the functionality and usage. It's great that C# is looking at F# to try and stay relevant but it's massive dishonesty to claim those features are just the same as those in F#.

The basis and usage of a language are steeped in its construction and usage patterns, F# has a distinct base of applying pragmatic functional programming and simplicity, whereas C# is an object oriented language takings usage patterns from Java and the typical patterns formed from that area. They will never converge due to the huge amassed different historical usage patterns. You could say C# is heading for being the new Scala 2 when Scala 3 has learned the lessons of blindly applying features and has now taken a more reasoned approach.

Re: .NET MAUI: .NET Multi-Platform App UI

#187

Post by andix »

bob1029 wrote: post #37

The amount of energy Microsoft is pouring into these front-end efforts is pretty incredible. A more recent development that has me very excited is Blazor Desktop: https://medium.com/young-coder/blazor-desktop-the-electron-f... > This leads to the second difference — in a Blazor Desktop app hosted in WebWindow, there’s no built-in web server. Instead, it’s pure .NET all the way down. And while we haven’t seen exactly…

The concept is revolutionary, for sure.

But for now it doesn't work as well as a classic SPA architecture. The server-side mode works not very well on poor connections (mobile), and the client-side WASM builds are extremely slow. Especially on first load, this takes seconds.

Blazor may be well suited for Intranet apps already, where quick&cheap development is very important, and connections are fast and stable. Blazor Desktop is an example for that use case (no latency between frontend and backend).

For internet apps, something like Gmail or Instagram, it seems to be not very well suited. Especially not for websites with interactive content, for example a comment-box inside a blog. Nobody wants to wait multiple seconds until the content is responsive, or the "reconnecting to server" overlay disappears

Re: .NET MAUI: .NET Multi-Platform App UI

#188

Post by 7sharp9 »

taberiand wrote: post #52
airstrike wrote: post #26

Earlier quoted context omitted.

+1. F# deserves a lot more love

F# seems to get love and recognition through C# slowly evolving and absorbing features that have been the F# advantage for a long time (fingers crossed for C# discriminated unions...)

I think they have been removed from C#10 now, I saw this on the language discussion: >While we wanted to look at discriminated unions for C# 10, we don't think we're going to be able to

Re: .NET MAUI: .NET Multi-Platform App UI

#189

Post by manigandham »

cjblomqvist wrote: post #161
manigandham wrote: post #101

Earlier quoted context omitted.

The fact that you have to interface between different teams/languages is often a big part of the slowdown. The productivity improvements are real. Not having to design and expose an API for the frontend and instead just reuse the same classes and services is a massive shortcut. Running Blazor on the server is even easier because there's no serialization at all and you can directly call database queries in response to…

Then why didn't Meteor take off fully? Because that was the promise of universal JS, about 10 years ago...

Javascript is still struggling to be fully capable server-side today, let alone 10 years ago. Going in reverse is much more functional.

Re: .NET MAUI: .NET Multi-Platform App UI

#190

Post by manigandham »

mumblemumble wrote: post #108
bob1029 wrote: post #106

Earlier quoted context omitted.

The entire point is to avoid javascript as much as possible and to force the few edge cases into an interop shim. We have a very complex Blazor webapp and the JS interop shim is fewer than 200 lines of code. This is 100% of the custom javascript for the entire application. Front and back. We do things like GetClientRect, Get/Set/Delete cookies, keyboard/mouse event subscription, etc. There is little-to-no context swi…

> The notion of "front-end" and "back-end" is completely meaningless here. So to start with, a disclaimer: I carry some baggage here, from working occasionally on 10+ year old GWT app that's developed into quite a tangled mess. Having said that -- this sort of thing doesn't seem like an obvious win to me. The notion of "front end" and "back end" represents a real-world distinction that you want to pay attention to. M…

Blazor has two modes: Blazor client-side is C# code running on a WASM dotnet runtime. It does have the frontend/backend split. Data still has to be serialized (as HTTP calls since that's all a browser can do) but it's done using the same classes & libraries as on the backend.

Blazor server-side has no distinction though because everything is running on the server, and the UI is just a thin stream of HTML updates.

The model you choose is up to you based on resources, latency requirements, payload size, etc. Blazor just gives you more ways to get things done.

Post reply on HN