If I want to make a UI in C#, I can pull up WinForms and use one language. If I want to have nice separation of style from code, I can use XAML (which is purpose designed for making layouts easy) and be using 2 purposefully technologies.

There is a lot more mental overhead to HTML + CSS + JS (and then the DOM somewhere) than to just type in

    Button accept = new Button("Accept!", new size(100, 45));
    form.Add(button, 300, 50);

If I want to style my button, I set some properties on the button.

(And if I want to use XAML, I send a file off to a designer who pops it into a purpose built XAML editor who can play around with the styling and layout to their heart's content!)

The thing is, web tech was designed for a non-interactive page based model, and then interactivity was added.

Then someone wanted curved boarders, and what had to be done to make curved borders was rather nasty. So after a good long time web standards caught up with fashion and an ability to add curved borders was added to CSS.

And damn you to the neither regions of hell if you want squiggly borders (Back to nasty scaling PNGs, or a few thousand 1 pixel DIVs!) However, I'm sure if those do come into style and enough people complain, that squiggly borders will also be added to the spec.

In comparison, a real UI framework lets you override the Paint function and do whatever you want.

On that note, about 2 quarters of freshman Java will have students be able to create custom UI widgets that do whatever is desired.

For someone who already knows programming? Point them at OnPaint, "here override it, draw whatever you want, have fun!" The set of concepts needed to modern UI development on the desktop is tiny. This is a problem space that has had three decades of effort put into making it simple and easy.

Again, want separation of concerns? About 2 hours of XAML will have someone making custom widgets, in fact that is the entire way XAML works! (It was sort of a mind twist for me that the easiest way to make an image button in XAML was not to override an OnPaint method and draw an icon, but rather place the XML nodes for an Icon and a Button together!)

But take someone that knows programming, well first you have to introduce them to CSS, which is a bunch of fields that you have to memorize (or rather just keep looking up) with a number of different types of units supported (none of which do exactly what you want, but I'll grant that is the case for all resolution independent UIs). Then of course they get to learn the newest flavor of HTML (semantic everything, don't you dare use <bold>). Then you get to show them JavaScript (Packages? Namespaces? A language in which imports can silently override my variables causing havoc and dismay? Wow, C's #DEFINE is considered harmful, but this is a whole new level.)

But hey thankfully CSS3 makes 3 box layouts no longer an exercise in pain! So that is a good thing. (I've been using flexible layouts that auto adjust the positioning and sizing of elements since the late 90s, it is nice that the web finally caught up by introducing yet another boxing model!)

Of course the final lesson is "oh and by the way this all sucks so you really want to use a third party JavaScript UI framework. Also CSS is sort of painful so you may want to use a preprocessor. Yeah just shove your content in the middle of your client side generated DIVs. Well yes generating the exact same page on every visitors PC is sort of silly and a huge thermodynamic waste, but it is currently in style so stop complaining about it. Yes I know the comments section takes 10 seconds to load. What do you mean BBSs on a 9600 baud modem responded faster?"

(Edit: Of course the last bit about responsiveness isn't relevant to using a web stack for client side apps, it is just me complaining about the poor state of the web in general)

> If I want to style my button, I set some properties on the button.

You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).

The rest of your comment is very rambling and does not really have a point so I will hold off on replying to it. I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job. Nobody will ever say it is perfect of course, but IMHO it beats the hell out of WinForms! You are right, it is a lot to learn for a 1st year developer, but you are going to get a shitty UI out of a 1st year developer, who cares?

> You cannot be serious. A 1000+ line long setup() method that creates a ton of one-off elements, sets a million properties, and saves them all as instance variables is in no way superior to using some XML to structure your elements, and then a separate, extracted layer for styling. I've done the procedural shit before, in Java, UIKit, Cocoa, you name it. There's just no way you can actually think that is better. Presentational separation is a good thing. (btw you can write your UI in the same procedural way in Javascript if you think it is superior/are a masochist).

Depends what I am doing.

Shipping a large scale commercial app with thousands of UI elements? I sure as heck pull everything out.

But if I am making an app that has a dozen UI elements and maybe a couple of screens in total? It isn't worth my time to switch tabs between my code and an XML file.

> I write polished, pixel-perfect, cross-platform interfaces, and HTML/CSS is the best tool I have found for the job.

Pixel perfect is trivial in any system. Winforms can do pixel perfect, and has a damn hard time doing anything else!

A UI that scales across screen sizes? A UI that auto adjusts itself as needed? You can do it in CSS (many websites do!) but isn't fun.

And I do wonder how you found CSS, a layout language which until recently couldn't even do simple math, to be the best tool for creating UIs.

There have been decent CSS pre-processors out for awhile, sure, those work. If you do parts of your layout using JavaScript at run time, hey, that can also work.

But pure CSS before CSS3? Bleck.