There's an example somewhere of the number of lines of code it takes to show a simple dialog in OOUI vs. jQuery UI (let's just say OOUI doesn't look very good in the comparison and leave it at that). …
☝️ Once we've removed the various technical blockers, I think that Codex will be a big improvement in this area. …
The comparison was in T155567, in the task description. ~20 lines of dense dense OOUI-specific code using moderately advanced inheritance, custom initializers, a window manager, etc. in order to do the equivalent of window.alert("Hello World!"). The equivalent jQuery UI example is three lines of simple and generic JS and three lines of bog standard HTML. It's so simple that one comment on the task (T155567#2958208) actually thought it was a trick!
Looking at T330350 I see ~90 lines, spread over three files, using a mix of syntaxes (html, css, js, and vue), moderately advanced framework-specific concepts, etc.
Granted this code is prompting for user input and doing something with the result rather than just display a dialog, and it's actually running code rather than just a static code example, but ~90% of those code lines also look like boilerplate that could be abstracted away.
Estimating the number of hours I will have to invest into Vue documentation and tutorials in order to be able to use this example code effectively is a somewhat scary number. Estimating the number of hours invested to be able to create something similar from scratch (because, say, my use case is just different enough that I can't just cut+paste+tweak this code) is beyond scary. I would need to have a pretty massive Gadget in mind in order to justify that investment, or an extremely large number of them to amortise the cost across. And for a lot of my use cases the code for the simple dialog will be larger or as large as the core functionality of the Gadget in terms of lines of code.
Without really evaluating that aspect specifically, I also worry that this will force me into writing the non-UI parts of the Gadget in Vue or using Vue patterns rather than generic JS (not to mention jQuery).
In other words, this appears to me to be a significant barrier to entry for most typical Gadget and user script developers (1–5 gadgets, each of relatively low complexity and length, UI needs relatively simple and secondary to core purpose of gadget). Upside is probably that it enables entirely new use cases for Gadgets, and, presumably, that it'll be an actively supported and modern framework (which jQuery UI sure ain't, and OOUI arguably wasn't in practice).
But as with T155567 I think abstractions and simplifications for the long tail of on-wiki developers needs to go on the roadmap somewhere. Simple widgets that are simple to use for simple use cases—"Hello World in three lines of code"—and from which one can graduate to use the full power and expressivity once the needs justify the added complexity and learning curve.
And just as a ottomh ferinstance / strawman, what if every wiki page out of the box was a running Vue app inside which a Gadget, as a "plugin" to that app, could ask for a simple dialog or other basic UI widget? Analogous to having a MW-provided OOUI window manager and widget factory instead of each Gadget having to create and manage those themselves and individually. Can we put enough of the boilerplate and complexity prepackaged in the default execution environment that simple Gadgets can pretend to live in a simple world?