About GUI on .NET Framework:

- Windows form works but not perfect. The editor works if you install the template for it, but not the auto generation of code, like double click on button -> handler generated. You write code programmatically. but is used a lot. I use it in the repl (fsi), to generate chart, custom data visualization.

- WPF the same, works, no editor (but codegen is less needed)

- Xamarin support F# ( https://docs.microsoft.com/en-us/xamarin/cross-platform/plat... ) on Forms, etc

Some good from community+MS, because community tried to adapt techonologies and make it more friendly to use in F#

- Xamarin XAML in Elmish style, really more idiomatic ( https://github.com/fsprojects/Elmish.XamarinForms ) from F# creator itself (Don Syme, who now work on xamarin division too)

- WPF and Xamarin xaml can be used with a type provider too for statically type view at compile type ( http://fsprojects.github.io/FsXaml/ )

The only one not yet supported is UWP, because of of .NET Native.

All that without speaking of the gui stack outside .net framework, like electron+fable or just fable+elmish/react/react.native ( https://github.com/SAFE-Stack/SAFE-Nightwatch )

GUI development without designer support is just like time traveling to implementing Turbo Vision and Clipper applications on MS-DOS.

Never understood the mentality for designing UIs by coding instead of visually.

I care for what comes in the box, and is directly supported by Visual Studio and Blend.

If someone needs to lose their .NET GUI tooling productivity to embrace F#, then better wait while C# keeps getting F# most relevant features.

Even C++ has better UI tooling support on Visual Studio than F#.

Depends for what you need GUI. You need it for complex LOB app? So no, editor will be good.

Personally, i write c# and xaml, and i dont use the editor (vs or blend), but i edit directly the xaml.

About f# and gui, depends on use case. For example https://fslab.org/XPlot/ to show graphs.

  let series = [ "bars"; "bars"; "bars"; "lines" ]
  let inputs = [ Bolivia; Ecuador; Madagascar; Average ]
  
  inputs
  |> Chart.Combo
  |> Chart.WithOptions 
       (Options(title = "Coffee Production", series = 
          [| for typ in series -> Series(typ) |]))
  |> Chart.WithLabels 
       ["Bolivia"; "Ecuador"; "Madagascar"; "Average"]
  |> Chart.WithLegend true
  |> Chart.WithSize (600, 250)

this is used to generate programmatically i chart. inside a window with some layout, usually in enough. And i can do testing in the repl.

But yes, if you use editor like c# version, F# is less nice to use. But again, programmatically allow other things, like https://github.com/fsprojects/Elmish.XamarinForms

So depends how much time you edit the view (and why), vs gains in the logic behind the view. For me the global tradeoff, but depends, so you are right.

The only time I have ever felt compelled to design a UI visually is when working with iOS or macOS because the framework is so centered around Interface Builder. When I write a WPF or JavaFX view I am not using Blend/Scene Builder to drag and drop controls, but to have a mostly-accurate preview of what crap looks like without having to build and run.

Yes, it keeps trying to reach parity with native UI design tooling both on desktop and mobile OS.

If you're waiting for feature parity with C# in VS, you'll never get it. There are millions of C# developers and F# devs are counted in the tens of thousands (sadly) so there's a reason for that.

I don't believe most organizations considering adopting F# or Scala are considering them for GUI development so I'm not sure why you'd rule out F# because of that