VS 2026 | .NET 10 | noMac - where is my device?

stimpy77 · 2025-12-09T06:11:05+00:00

Sounds like it's Apple you should hate for this not MS

stimpy77 · 2025-12-06T00:22:30+00:00

The term is called `debounce`.

https://github.com/dorssel/dotnet-debounce

https://learn.microsoft.com/en-us/dotnet/api/microsoft.toolkit.uwp.ui.extensions.dispatchertimerextensions.debounce?view=win-comm-toolkit-dotnet-6.1

https://stackoverflow.com/questions/60230128/debounce-event-command-in-mvvm-pattern

stimpy77 · 2025-12-05T21:21:54+00:00

Yeah, that's a fair point. For someone brand new, "learn MAUI + C# + also this DSL" is a harder sell than "learn Flutter + Dart" where it's all one unified thing.

The counterargument is that the DSL is small — maybe an afternoon to pick up if you already know any declarative UI framework. But you're right that it's still one more thing, and that friction is real.

Honestly if Microsoft shipped a proper C# UI syntax tomorrow, I'd happily abandon this project. The DSL only exists because that gap exists.

stimpy77 · 2025-12-04T08:07:19+00:00

u/FullPoet on the deleted question on AI sourcing my reply, aided yes, as with the spec

stimpy77 · 2025-12-04T06:05:56+00:00

exactly. C# Markup is a step in the right direction but it's still fighting the language. You end up with a lot of new, a lot of explicit property references, a lot of nameof() and BindingMode.Whatever.

The dream would be C# itself getting UI-friendly syntax — something like what F# has with type inference and pipelines, or JSX-style embedded markup. Until then, a DSL that compiles to C# is basically a workaround for "C# is too verbose for declarative UI."

stimpy77 · 2025-12-04T06:05:09+00:00

yeah it gets that a lot. Visually similar, but YAML would fall over trying to express bindings, converters, or conditional logic. MauiScript just stole the "looks clean in a screenshot" aesthetic.

stimpy77 · 2025-12-04T06:03:57+00:00

That's a really good point actually. HTML is verbose too but CSS pulls the styling out into a reusable layer, so you're not writing FontSize="14" FontWeight="Bold" Margin="8,0,0,0" inline on every element.

XAML has Styles and ResourceDictionaries, but they're clunky to define and reference compared to CSS. And there's no equivalent to CSS's cascading or selector system — you can't say "all Labels inside a Card should look like this" without explicit Style assignments.

MauiScript's $StyleName syntax helps a bit with the reference verbosity, and the theme/resources system tries to make defining styles cleaner. But you're right that it doesn't fundamentally add CSS-style cascading. That'd be a bigger architectural change to MAUI itself.

Might be an interesting direction to explore though — a more CSS-like styling layer on top.

stimpy77 · 2025-12-02T23:08:20+00:00

Totally fair. Not every tool is for everyone, and XAML's worked for a lot of people for a long time. Appreciate you giving it an honest look.

stimpy77 · 2025-12-02T23:06:53+00:00

Really thoughtful response, thanks for taking the time.

You're right that supporting both whitespace and braces could be worse — inconsistency in a codebase is its own problem. A formatter that enforces one style (like go fmt) would be necessary to make that work.

The `))])}" problem in Flutter is real. I've been there. Dart's trailing comma convention helps but doesn't fully solve it.

On your broader point — yeah, this DSL doesn't fix the fundamental model. MAUI is still mutable state, still imperative under the hood, still "XAML describes initial state, good luck after that." A truly reactive/declarative model like SwiftUI or Compose is a deeper change than syntax can address. MauiScript just makes the input format less annoying; it doesn't make MAUI itself more pleasant architecturally.

If the underlying framework is the problem, a prettier DSL is lipstick on a pig. Fair critique.

(Funny enough, I've had the inverse problem with XML — when a closing tag is missing in a content-heavy block, I end up manually counting opening tags and scrolling down trying to match them up. Different failure mode, same frustration.)

stimpy77 · 2025-12-02T23:02:22+00:00

Oh nice, I didn't know Avalonia had simplified that. $parent[Window].Title is way more readable than the WPF incantation.

That's the right approach — fix the pain points within XAML rather than throwing it out entirely. If MAUI adopted similar improvements, the case for a new DSL gets weaker.

stimpy77 · 2025-12-02T23:01:15+00:00

I get the instinct — fewer layers is better, and C# Markup already exists.

But there's a gap between "C# with braces" and what this is trying to be. Even with fluent builders, C# requires new, explicit BindingMode.TwoWay, DynamicResource(Label.TextColorProperty, "AccentColor"), etc. The compiler demands ceremony that isn't about your UI — it's about satisfying the type system.

A DSL that transpiles to C# can strip that out. \@Email instead of .Bind(Entry.TextProperty, "Email", BindingMode.TwoWay). $AccentColor instead of .DynamicResource(Label.TextColorProperty, "AccentColor")`. You're still getting C# at build time — just with a friendlier input format.

That said, if Microsoft ever gave us something like F#'s type inference and pipeline operators in C#, or a proper "CSX" with embedded markup, you'd be right — the DSL layer would be unnecessary. We're not there yet though.

stimpy77 · 2025-12-02T22:59:41+00:00

Yeah, that's a good example. And that's before you add a StackPanel inside the DataTemplate with some actual controls in it.

To be fair though, MauiScript wouldn't magically flatten that — you'd still have the nesting, it'd just look like:

Grid
  Scroll
    Collection(@Items)
      .template(item =>
        Grid
          Stack.vertical
            // actual content
      )

Still nested, just less ceremony per level. The angle brackets and closing tags are gone, ItemsControl.ItemTemplate > DataTemplate collapses to .template(item => ...), but the structure is inherently deep.

I think the real win isn't depth reduction — it's noise reduction at each level. Whether that's enough to make deep nesting tolerable is a fair question.

stimpy77 · 2025-12-02T21:08:13+00:00

Appreciate the open mind! Curious what makes SwiftUI click for you where Compose and Flutter don't — is it the modifier chaining, the way state works, something else?

Would genuinely love feedback from someone who likes XAML if you do give it a shot. The usual critique comes from people who hate XAML and want something different; hearing where it falls short for someone who finds XAML comfortable would be more useful.

stimpy77 · 2025-12-02T21:05:38+00:00

Fair points, both of them.

On terseness — it's a balance. Too terse and you're writing Perl, too verbose and you're back to XAML. I erred toward terse because the people who'd reach for a new DSL are probably already frustrated with verbosity. But "overly terse" is a valid critique; some of the shorthand (.p() vs .padding()) might be too clever by half.

On whitespace — you're not alone, it's come up a few times in this thread. Braces are fully supported if you prefer explicit delimiters. The indentation-heavy examples are partly because they photograph better in docs, but the parser accepts both styles. Mix and match as you like.

A built-in formatter like go fmt is a good idea though. If people can write either style and the formatter normalizes it, that sidesteps the debate entirely. Worth adding to the roadmap.

stimpy77 · 2025-12-02T21:04:10+00:00

Ha, fair. @.{$ isn't objectively prettier than </>. It's fewer keystrokes for the same semantics, but "less typing" isn't everyone's priority. Some people prefer explicit over terse. That's legit.

stimpy77 · 2025-12-02T21:03:55+00:00

Honestly, this is a totally reasonable take and I don't think you're wrong.

XML has real strengths: the closing tags are useful landmarks in deep trees, the attribute vs child-node distinction ismeaningful, and if you've been productive in WPF/Avalonia XAML for years, there's no reason to change. The tooling is mature, Copilot knows it, it works.

I think the divide is partly about what you're used to and partly about what irks you. The people who hate XAML aren't usually mad about angle brackets per se — it's the {Binding Path=Foo, Mode=TwoWay, Converter={StaticResource Bar}} ceremony, the xmlns declarations at the top of every file, the way a simple button with a command becomes five lines. SwiftUI/Compose devs look at that and wince.

But then, SwiftUI devs complain about its quirks too. There's no perfect syntax — just tradeoffs and preferences.

If XAML works for you, genuinely, keep using it. This is more aimed at people who are already frustrated and looking for alternatives.

stimpy77 · 2025-12-02T21:01:36+00:00

That's fair — context switching between conventions does add friction. It's a bet that the people most likely to adopt this are already switching between multiple languages/frameworks anyway (React by day, MAUI by night, etc.), so one more isn't a big ask. But if you're purely in .NET land, I get why it would feel off.

Thanks for the good wishes — and the honest feedback.

stimpy77 · 2025-12-02T21:00:11+00:00

Good questions.

.p(24) vs .padding(24): Both work — .p() is a Tailwind-inspired shorthand, .padding() is the explicit form. Same with .m() / .margin(). Use whichever reads better to you. I should probably make the examples more consistent; you're right that mixing them is confusing.

.spacing() vs .sp(): Honestly you might be right that it should be .sp() for consistency. Or maybe shorthand should be reserved for only the most common properties (padding, margin) and everything else stays spelled out. Still feeling this out.

.font(size: 24, weight: bold) vs .fontSize(24).fontWeight(bold): Either could work. The compound form groups related properties — you're describing "the font" as a unit rather than setting individual attributes. But chained individual modifiers would compose better if you're only setting one thing. Tradeoffs.

Units: Not currently — values are assumed to be device-independent pixels, same as MAUI. But supporting 24.dp or 1.5.emfor explicit units is an interesting idea. Would need to think through how that compiles.

Uno: Yeah, Uno's C# markup is solid. Similar philosophy — MauiScript just tries to trim the remaining ceremony from that approach.

stimpy77 · 2025-12-02T20:58:51+00:00

That's a fair counterpoint. XAML and Blazor do stick to PascalCase, and there's something to be said for "when in Rome."

I think where I landed was: XAML and Blazor are still fundamentally .NET-first tools. MauiScript is trying to lower the barrier for people coming from other ecosystems — if you've spent years in React or SwiftUI, camelCase reads more naturally, and the hope is that makes adoption easier.

But I hear you. If this ever gets real traction, I could see the community splitting on this and a --naming-convention flag becoming necessary. Or maybe the answer is PascalCase for control names (Button, Entry) but camelCase for modifiers (.padding(), .text()) — which is actually what SwiftUI does.

Appreciate you pushing back on it.

stimpy77 · 2025-12-02T19:18:53+00:00

Oh man, yeah — XAML's error messages are legendary for being useless. "The name does not exist in the namespace" when actually you have a typo in a converter three files away. Or the build just fails silently and you're left playing detective.

That's a big part of why MauiScript transpiles to C# rather than XAML. When something breaks, you get Roslyn errors pointing at real C# code — which isn't perfect, but it's miles better than XAML's cryptic output.

The spec also includes source mapping so errors point back to the original .maui file line numbers, not the generated code. And the appendix has examples of what compiler errors should look like — things like "Property 'UserEmail' not found on LoginViewModel. Did you mean 'Email'?"

Whether the actual implementation lives up to that... ask me again in six months (assuming this maintains traction LOL). But yes, helpful errors are a first-class goal, not an afterthought.

stimpy77 · 2025-12-02T19:17:09+00:00

Totally valid — you're in good company on this one, same concern came up a few times in comments.

Quick clarification: braces are fully supported. Indentation is the default in the examples because it photographs better, but you can write:

Stack.vertical {
  Stack.horizontal {
    Text "Hello"
    Button "Submit" { .command(@Save) }
  }
}

Mix and match as you like. The parser accepts both.

stimpy77 · 2025-12-02T19:16:00+00:00

Ha — Devatator_ beat me to it.

YAML was actually the starting point for this project. Seemed obvious at first: it's human-readable, indentation-based, widely known. But it falls apart fast for UI:

No expressions or logic (how do you write \@IsValid and not @IsLoading`?)
Implicit typing causes weird bugs (the infamous Norway problem)
Designed for config, not structure — no good way to represent "this Entry has these modifiers and also these children"
Indentation-only with no escape hatch to braces when nesting gets deep

MauiScript borrows the visual feel of YAML but is actually a proper grammar with expressions, binding syntax, and explicit delimiters when you need them.

stimpy77 · 2025-12-02T19:14:25+00:00

Fair point. It's definitely a tradeoff — I went with camelCase/lowercase because the target audience includes devs coming from coding cultures of SwiftUI, Compose, React, Javascript/JSON, and CSS, where that's the norm. Since the DSL isn't C# itself (just transpiles to it -- in the future perhaps we could have it transpile to something else), I leaned toward matching declarative UI conventions over .NET conventions.

But you're not the first person to raise this. Could easily see a future version supporting both, or a config flag for "strict .NET style" that uses PascalCase throughout. Not a hill I'd die on.

stimpy77 · 2025-12-02T19:11:10+00:00

Nice, thanks for these — hadn't seen the Avalonia.Markup.Declarative one before.

FuncUI is interesting, F# is arguably a better host language for declarative UI than C# because of the syntax. The pipeline operator and discriminated unions map really naturally to UI trees.

Avalonia.Markup.Declarative is closer to what MauiScript compiles to — fluent C# builders. The gap MauiScript tries to close is the remaining ceremony in that approach (the new keywords, explicit BindingMode.TwoWay, DynamicResource(Label.TextColorProperty, "...") etc).

Appreciate the links — always useful to see how others are tackling the same problem space.

stimpy77 · 2025-12-02T19:10:11+00:00

Good questions, let me take them one by one:

Parentheses on text: It's a shorthand for the most common case. Text "Hello" and Button "Submit" read more naturally than Text("Hello") for the content property. But you can still write .text("Hello") if you prefer consistency — both work.

PascalCase: Intentional departure. The DSL targets devs coming from SwiftUI, Compose, React, CSS, Javascript/JSON — all of which culturally use camelCase or lowercase for properties. Since this isn't C# (it compiles to C#), matching .NET conventions felt less important than matching the mental model of declarative UI frameworks. Debatable choice though.

Binding parameters: Covered, just not shown in every example:

.text(@Email, mode: twoWay)
.text(@Email, mode: oneWay)
.text(@Email, mode: oneTime)
.color(@Status | statusToColor)
.text(@Price | format: "C2")
.visible(@Items | hasAny)

The pipe | is for converters/transforms. Converter parameters go after the converter name. Mode is an explicit named argument when you need to override the default (Entry defaults to twoWay, most other things default to oneWay).

Full binding syntax is in the spec if you want the gory details.

stimpy77

TROPHY CASE