There is no way a reasonable person would not deploy to Linux and postgres for cost reasons alone. No one wants to pay Microsoft or Oracle money for databases, operating systems or frameworks nowadays.
All my .Net web apps are now deployed to Linux and Sqlite. Good riddance to Windows Server and IIS (which was dogshit from day one). With the tiny memory profile of .Net 10 it's crazy how small a VM you need to get good performance.
.NET Framework was always called .NET Framework and not renamed from
NET 4 to .NET Framework. There was a time where .NET was applied as a prefix/suffix to everything Microsoft released. Microsoft Windows Server .NET. that had nothing to do with the framework/CLR/programming platform but with Internet connected features.
Fair enough - I meant that, at least in Microsoft's own communication, they started more consistently referring to .NET Framework 4.x to differentiate it from first .NET Core and later .NET.
While it was always called .NET Framework, it was very commonly referred to simply as .NET (e.g. .NET 4.5) - and the "Microsoft .NET" logo was widely used in .NET Framework branding/marketing.
No. Was hard enough to convince people of .NET Core away from the .NET Framework. Adding a completely different name and I would have several hundred java devs now instead of beautiful .net 10 on Linux.
I agree. For Blazor there is hope. It is standard based (web assembly, HTML, css) and it feels very intuitive particularly when compared to other spa frameworks like react. Also you can reuse all your html, css and design systems you have. Which is huge because like that it hooks up with the whole web development stack.
The answer to that is well known: Windows division builds WinUI/Win32 as their native C++/COM API, Office division went to React on their path to the web and the dev division fills gaps (WPF) and provides tools for external and internal devs (Maui for cross platform uis).
It is history not the lack of will. At one point the windows division was in shambles (remember vista) and WPF pops up. At another point, the windows and dev division have no answers to the office group (because you know who uses non win tech) so they went react. And then external devs screamed: where is the .net cross platform story so Microsoft acquired xamarin and later form Maui out of it.
It is history not lack of trust. But the outcome is the same: lackluster support for all UI toolkits.
Well summarized, and just as shocking today as it was every minute while it developed.
Someone needs to remind those cats that they own the platform. Being able to sanely develop apps for and on that platform should be possible, and UI kinda-sorta matters for that. At a certain point with the MFC they had it dialled in, while pioneering asynchronous browser tech, with many best in class tools. Decades later with a cross-platform cloud-centric stack they have a shrug emoji as big and wide as the eyes can see, and no sense this basic question of development will ever get improved.
Ballmer chanting ‘developers, developers, developers …’ springs to mind.
Ballmer was not my favourite person to run MS, but that was a pretty good time to be a Windows developer if you bought in. Early Nadella days too. Now? It's too easy to find no MS answers for almost everything, even triple-A gaming is not the windows anchor it's been since they ran that doom demo
> but that was a pretty good time to be a Windows developer if you bought in
I did, it was great. Very apple-esque in a way. As long as you stayed in Microsoft's garden, you had a good time. Microsoft had, at the time, one of if not the most productive stack to build GUI desktop line of business apps. If your whole org was Microsoft from top to bottom, even better. AD auth in your desktop app in a couple of lines.
It was an expensive stack for sure, but I'd argue there's still nothing that has come close to it if you want to build an enterprise desktop app.
As I understand it, Sinofsky is largely responsible for this mentality in the various places he worked across Microsoft: he instilled a distrust for anything originating out of other teams.
Can only confirm that. Such a smooth platform overall for web and API development. We use it with several 100 devs on it and the choice never failed us, neither in technology or hiring. And it is not that we have .NET gurus or anything.
As a counter-point, my company was original purely .NET, then added Python (and later JS).
For us, hiring .NET is WAY harder than the other stacks. We get a lot more applicants in general, but almost zero that meet our standards. For Python roles we get way fewer applicants, but the average quality is much much higher than the .NET average. (JS is a whole other thing, and we frankly aren't as good at hiring there yet)
No, we don't do any coding tests, just discussions of what you've done and how deep your knowledge of your tools goes. .NET folks are far less likely to understand much beyond the syntax, nevermind the "why" of things (even WHY you need StringBuilder) or what a database index is, etc.
Mountaineering, climbing, bouldering, going to gigs, playing pool, running, music festivals, gaming, photography, watching F1, watching NBA, eating out with friends...
A lot of good news recently for swift. I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things.
I really like swift going beyond Apple. Particularly the port to android is IMHO crucial, however, now they are in the UI cross platform hell. Let us see if Apple is playing this better than Microsoft. Unfortunately, I have little hope. The only native contenders in the field right now are IMHO are react native and flutter which are both UI toolkits first and language second. Which I find gruesome.
It'd be nice if Apple made SwiftUI cross platform and I'd be singing in the streets if UIKit got ported, but that seems unlikely at best.
I believe that there's strong community interest in some kind of Swift UI framework for Android, though, and so there's a substantial chance that a third party solution will appear.
Correct me if im wrong, but isn't the pain points for mobile devs, the need to have intimate knowledge of both pl to build & maintain a good "backend/functionality" of the app over time and that the UI portion of the app is quite simple to learn, build and maintain.
So is it necessary for the swift team to try get swift ui onto android, versus a developer building their app "backend/functionality" in swift, compiling it down for both ios and android, then bridging the android bindings with a UI made in kmp etc
I recently learnt that amo and protonmail use this solution but instead of swift android, they were using uniffi-rs and seemed to have great results, I think proton ditched react native for this solution, which to me sounds like a more streamlined way of getting native performance without needing the overhead of managing multiple language. I guess we will have to see how mature swift android gets and if it can replace uniffi-rs etc which would save even more time
I’d absolutely love it if they made SwiftUI cross platform for both mobile and desktop. Flutter is nice but it’s still sort of a mess sometimes when targeting desktop instead of mobile.
Let’s be honest. It’s a mess targeting iOS. It’s like the old days with VB - first 80% done in no time, last 20% takes forever, requiring ever more elaborate hacks to get around stupid restrictions (eg try hiding the keyboard associated with a TextField when you tap on a Picker).
Don’t have links, but it’s true. iTunes for Windows also includes chunks of AppKit.
The Windows ports of AppKit in both likely trace their lineages back to Yellow Box, which was the Windows port of AppKit that Apple briefly made available prior to the release of OS X 10.0.
Jetpack Compose is just as "native" as Android views at this point; it hooks into the same accessibility frameworks and renders to the same surfaces as the framework toolkit. This isn't like Flutter which renders to an opaque Skia buffer.
UIKit is very mature and tied to the iOS ecosystem and a bit more complex. SwiftUI is easier to port (since it is still a incomplete / subset features of UIKit).
Yes historically but not by design. It's more of a transition tactic.
Starting with iOS 26, new UIKit and AppKit features are implemented by "native" SwiftUI (specifically, Liquid Glass's implementation). In recent years they have also been replacing UIKit/AppKit-backed SwiftUI views with "native" SwiftUI implementations.
But besides this technical change I don't think Apple has any desire to bring SwiftUI to other platforms.
BTW: https://skip.tools has bridged it to Compose. Your SwiftUI code runs in native Swift on Android.
> I am a bit jealous as my go to language C# / .NET is recently not announcing fancy things.
Depends on what you think fancy things are. Both C# and .net are busy releasing a lot of features.
You're forgetting that C# is a 25-year-old language at this time. The exciting features they release are things like "access native memory allocation in a GC language", "native Arm64 support", "support for post-quantum cryptography", "tensor support" etc. while already running on all the platforms that Swift is only now announcing as achievements.
I guess it's a matter of perspective. Dotnet 10 just came out[1] with a bunch of solid new shiny that I'm enjoying.
And, as it stands, Dotnet is much further along in the multi-platform game than Swift. As far as I know, none of the Swift-based UI stuff is being ported to, let alone going to be usable on non-Apple platforms.
> The only native contenders in the field right now are IMHO are [...] and flutter
I wouldn't really call Flutter "native".
I don't have a strong enough grasp of where React Native is at now. It was severely lacking when I looked at it circa 2018. But then we needed to call in to our own native code libraries, so we were probably quite niche.
Xamarin.Forms worked well enough, but the transition to MAUI has been full of woe and even more bugs and weird edge case functionality than Xamarin had.
I do not know why people still think Tesla is a unique company. They are a regular car company now. Nothing more, nothing less. Yes, they disrupted the market and the reward is a standalone, viable car company. That is a huge achievement. But their disruption and uniqueness is gone. The rest of the car industry woke up and all are producing many more EV variants and EV cars in total.
Pre Texting, Pre Email in the 90s I believe this kind of work was normal. All this self motivated, hyper context switching jobs we all do are relatively new compared to human evolvement. And we see the tax on us.
reply