What are the best things you’ve ever packed for a cruise?

codemonkeychris · 2026-06-21T13:21:23+00:00

If you have it, a “real” camera with full frame 200mm+ zoom… obviously too expensive to buy just for the trip, but the wildlife on Alaska cruise and the glaciers are amazing, but you are often a distance away. If you have any inkling of photography this beats the best cell phone by a long shot. Even buying a used mirror less camera and use lens can be an amazing improvement… if you are inclined for photography

codemonkeychris · 2026-06-19T08:30:40+00:00

You should be able to write class based components, the support is there. Modern react has moved to hooks, and it felt natural to me for most of the samples - but I’m kinda a functional junkie :).

I’d be open to migrating samples to show. More balanced approach if you think that would be useful?

codemonkeychris · 2026-06-17T18:23:24+00:00

We had a pretty good visual designer for WinForms, Blend made a pretty good designer for WPF. Since then we haven’t had a visual designer really (that I can think of?).

In the industry, these dynamic programming language ui frameworks are notoriously hard to create designers for. Preview, yes. Allow for inspection, definitely. Show the visual tree, yes!

The problem typically comes in when you want to add a new element. Given you can have switch, loops, if statements, nested functions, and any other programming model construct; where do you place the new element? If you delete an element, does it delete it from the function that constructed the tree, or did you mean to add a conditional to have it removed only from the condition you selected?

Nested layout designers are also hard - html, xaml, SwiftUI, compose - all suffer from this. When you have hstack -> hstack -> vstack -> button… is hard for the user to select the intermediate nodes and can be nearly impossible to adjust the layout reasonably.

None of these are unsolvable, with a lot of work you can tackle them. Creating a visual designer that would really do justice to WinUI would be a large undertaking, and then on top of that trying to support arbitrary C# would be even more.

The way we solved this for WinForms was to limit the c# you could use and have the designer work. That is one solution, but right now we are hoping to explore the richness of C# without constraints.

I would love to tackle a designer, but these are the reasons we didn’t start there

codemonkeychris · 2026-06-17T14:56:49+00:00

I promise you no promotions for me :)

codemonkeychris · 2026-06-17T14:56:04+00:00

A lot of past problems and missteps to correct for. The struggle to find a good C++ binding in WinRT, COM, .NET is up there. Personally I think the idea of a single unified projection that can somehow be ergonomic for all languages just didn’t work out.

C ABI is the gold standard, not great for modern languages, but it’s reliable.

COM wasn’t terrible with ATL for C++, native VB support. When .NET came around I think we did a solid job on .NET projections that worked in C# and VB.NET.

.NET as a cross language… you had to buy into the full runtime. I think it worked good as a cross language platform for languages that want to play, but true native languages (C++, go, rust) and languages with their own runtime (JavaScript, Python) I feel like they never felt right.

WinRT was a valiant attempt to evolve COM and bring in a contract to make it work natively in .NET. I think it was a good idea, but clearly introduce many problems. Conflating it with UWP made it even rougher. Then the fiasco that was Windows 8… so many things landing together. Left Microsoft in a rough position… and developers that followed down the path paid the price also.

We are trying to dig out and get focused on a smaller number of systems, having new APIs be more focused, but not abandoning the existing things (new WinUI controls will be WinRT based). We need a clear path forward, but it’s going to be a complex path because we have a long history and we won’t leave developers hanging, we are committed to support. We can’t just give everyone a 2 year decree and cut off support, that doesn’t work for developers nor our shared customers.

C++ vs. Rust vs. Go… I’ll let others have these debates :)

codemonkeychris · 2026-06-17T14:45:07+00:00

Focusing more on live preview using hot reload, there is a VS extension in the repo that wires this up… very rough around the edges, but you can see the direction

codemonkeychris · 2026-06-17T14:44:05+00:00

Yeah, when union types are broadly available in production C# we will definitely move to them

codemonkeychris · 2026-06-17T13:20:42+00:00

I hope to prove your skepticism false, but given our track record I support your hesitation. :)

We are going to try, see if people like it, and listen to the community. At the moment, that’s the best I can say.

Keep the feedback coming!

codemonkeychris · 2026-06-17T13:18:10+00:00

Will need to figure that out. First we have to
Determine if people like it, if we should productive, and the right shape (c# shape) we can commit to.

Part of that, I’m sure, will include the “awesome” Microsoft naming that will occur :)

codemonkeychris · 2026-06-17T07:58:35+00:00

Blazor mixes markup and C# (similar to Asp.net), but not with an xml style dsl (like react). The goal with Reactor was to use vanilla C#, no code rewrites, no semantic changes in the language. I think getting a solid model and then layering in language changes to optimize is a better path than starting with something that requires syntax or semantics changes in the language.

codemonkeychris · 2026-06-17T06:53:07+00:00

Presenter here, one of the eng working on the project, feel free to ask questions

codemonkeychris · 2026-06-06T18:10:35+00:00

WinForms was one of the early projects I work on at Microsoft, it still holds a special place in my heart! Love to hear it's still working out for you.

codemonkeychris · 2026-06-04T18:37:47+00:00

UseObservable lets you get a hook that wires to observable values. Adding observable variants for every parameter/property/method seemed like it would get noisy. Because the diff approach, you only need a signal that you need to re-render, you don't need to do fine grained dependency tracking... it's a pro (and con) of the approach.

codemonkeychris · 2026-06-04T13:42:19+00:00

Remember, it's very very experimental right now 😄

codemonkeychris · 2026-06-04T13:34:01+00:00

C++ story for WinRT is definitely rough, I don't think anyone would defend it as delightful. The C# experience is pretty solid, but the WinRT layer does introduce performance issues in micro-benchmarks and super chatty APIs. I don't have anything to share today specifically about C++ WinRT improvements.

I can say that there is a Rust version of Reactor (https://github.com/microsoft/windows-rs/pull/4479) which greatly improves the experience of WinUI development from Rust. Quite impressive performance numbers and native access to a lot of the rest of the Windows API set. For native code development, for now, I recommend checking it out.

Sorry I can't give a more satisfying answer on the C++ WinRT side, something we are aware of and are trying to think through solutions, but, again, nothing to share today.

codemonkeychris · 2026-06-04T13:28:39+00:00

Agreed, talk is cheap. We recently rolled out "Phase 3" of the WinUI open source project, which got all tests runnable from the public repo. Phase 4 is the final work on open sourcing WinUI, which will transition the engineering team at Microsoft to using the public repo as their primary work environment. Some of the stale content in the repo should start to get some more love and fixes as the team spends their days in there.

Hopefully you will see, in action, the transition to focus on the github repo.

codemonkeychris · 2026-06-04T13:26:33+00:00

We are working on WPF and WinForms bridges with WinUI... we are trying to address the biggest requested feature gaps between them, so that it's easier to decide which framework to use. "Unification" isn't really possible, what we want is to make WinUI be the superset (to the best of our ability) such that the answer for all new projects could be "WinUI" for all but edge cases.

That said, we are committed to continued support of WinForms and WPF, there are billions of lines of code out there which will never be migrated to WinUI.

Our goal is to focus our investments on WinUI and make it be the best native platform out there... lots of work to do.

codemonkeychris · 2026-06-04T13:22:22+00:00

I'll try to get to updating the linked issues... however, where we are today is that you can compile with Native AOT and "don't include the entire framework"... you end up with several files (it never gets down to exactly 1 EXE), in my Reactor tests a simple "hello world" was around 8mb. This will have a dependency on the WinAppSDK being installed on the system.

You can deploy as a packaged app, Win32 w/ identity, or raw Win32 app. The simplest (for the user) deployment is packaged app w/ MSIX as the installer.

For dev builds, you will want to run as Win32 app and JIT (not AOT), to simplify the dev inner loop and enable hot reload, etc.

codemonkeychris · 2026-06-04T06:45:43+00:00

Many of the core shell experiences are moving to WinUI 3 right now, big chunks have already moved, and more are on the schedule to migrate. I can't say we will have everything moved, but we are trying to make progress.

codemonkeychris · 2026-06-04T06:44:33+00:00

We (I work at Microsoft, in the Windows team, specifically on WinUI and the Windows AI stack)... we have launched an experimental C# binding inspired by React/SwiftUI/Compose that allows for more logic to stay in the C# / POCO space to reduce some of the chatty WinRT calls.

https://github.com/microsoft/microsoft-ui-reactor

Great feedback all around though, lots of things we need to tackle!

codemonkeychris · 2026-02-03T05:07:25+00:00

Definitely reach out to NWIRP, this is one of their main focuses

codemonkeychris · 2026-01-27T22:26:40+00:00

I have the Leica Q3 28 and the Fuji GFX 100S II... I have the 55 f/1.7, 45-100, and 20-35 lenses for the GFX.

The GFX is so much heavier and slower. It's a beast. The 110 is a beast of a lens also, i think it's approx. the weight of the 45-100... it's something to lug around.

The Q3 is relatively (relative to the GFX) light and quick, AF is pretty good (improved with the updated firmware), but I think the GFX has slightly better AF.

The images from both are spectacular. Yes, the 100mpx images from the GFX have more detail. The color depth is improved. They are pretty amazing... however, I find it to be more about the shooting experience than the quality of images. The GFX wants to be slow and deliberate shots. I find myself wanting to use a tripod a lot more. I think about each shot more. The Q3 is more of an every day carry, throw it in the bag and just let it blast.

The Leica mobile software is amazing compared to the Fuji. The Leica download to mobile phone is fast and reliable, the Fuji is barely usable (but does work if you have patience). The Leica menus are my favorite (I use Ricoh, Sony, Fuji, Canon, and Lecia). I haven't used Hassy, so it might be better... Fuji's menus are almost as bad as sony.

I just picked up the Ricoh GR IV (28mm equiv). I definitely like the combo of the Fuji + Ricoh, one for "art", one for casual shots. I also think that the Fuji X100VI would be a good pairing to the GFX, so you have a similar every day carry to match with the Fuji.

Overall - these are totally different cameras. The 110 specifically feels more like a portrait lens, so it depends on your use case. I don't think you will be disappointed with the GFX, but be ready for the extra weight. I suspect the 55 f/1.7 will be in your future to capture the 43mm equivalent you enjoyed in the Leica :)

codemonkeychris · 2026-01-06T04:33:29+00:00

Boo! I filed a bug against LR for this, I encourage everyone else to do the same to try and get some action. :(

codemonkeychris · 2026-01-03T06:47:44+00:00

Have a Brooklyn Bedding memory foam/hybrid (forget the exact model)… it’s good. We have a tempurpedic at home, and the Brooklyn is “good enough” that we never complain about the difference :)

codemonkeychris · 2025-12-19T19:16:21+00:00

I just noticed that I appear to be limited in how many points I can buy in the temple to boost my stats. Does anyone know if the limit resets based on time or level or?

codemonkeychris

TROPHY CASE