What do you have in mind from an engineering perspective? Replacing the OOUI library's function code with calls to Codex components?

I think assuming that OOUI and Codex map 1:1 might not be correct. I have a feeling they've probably diverged in many ways.

I think that is what should ideally happen, unless if a legacy parameter is specified, in which case legacy behavior is activated instead. OOUI was already quite featured at the time Codex was announced, and there are still quite a lot of people especially user script developers like me who are more familiar with OOUI than with Codex. All the OOUI components should be reimplemented in Codex and should be instantiable with the current OOUI libraries. I never was a big fan of how OOUI got suddenly replaced by Codex, but that is the path WMF wants to take probably because they want to move to a React.js framework.

I don't think there's a good way to do a drop-in 1:1 replacement of existing OOUI code with Codex code. The way you write Vue-based code is completely different, and the Codex components aren't based on the OOUI components so they're written with different names and options.

In T398742#11145184, @Awesome_Aasim wrote:

React.js framework

The js framework part of Codex uses the Vue.js framework

I agree with Jdforrester. Perhaps it's possible to create a tool that could assist user script creators with the conversion of existing scripts in some way, but backwards compatibility isn't going to happen.

The OOUI library will probably remain available for the foreseeable future though.

If there was such a tool that converted JS code instantiating OOUI to JS code instantiating Codex, that would be really awesome.

backwards compatibility isn't going to happen.

That's a shame. Although it would have been really nice as calls to OOUI redirecting to Codex would be really great. I was envisioning something like:

function OO.ui.ButtonWidget(...) {
   // instantiate Codex button here while preserving all of the OOUI properties so as not to break user scripts
}

And the same for IconWidgets, etc. Maybe I should have created the task as "Ensure backwards compatibility between OOUI and Codex" not "porting". But even then there would be a good chance that my task would have gotten declined instead.

In T398742#11148630, @Awesome_Aasim wrote:

backwards compatibility isn't going to happen.

That's a shame.

It's not my call of course, but I severely doubt resources would be allocated for that. It's likely not trivial.

Although it would have been really nice as calls to OOUI redirecting to Codex would be really great. I was envisioning something like:

function OO.ui.ButtonWidget(...) {
   // instantiate Codex button here while preserving all of the OOUI properties so as not to break user scripts
}

And the same for IconWidgets, etc. Maybe I should have created the task as "Ensure backwards compatibility between OOUI and Codex" not "porting". But even then there would be a good chance that my task would have gotten declined instead.

For a few basic elements you could perhaps do that, but whole forms with a gazillion possible options, not likely. On top of that, there are likely differences in behavior and available options so a complete automatic conversion could turn out to be literally impossible. And even if you could, user scripts can meddle with the HTML and/or CSS that OOUI outputs directly.

On top of that, there are likely differences in behavior and available options so a complete automatic conversion could turn out to be literally impossible. And even if you could, user scripts can meddle with the HTML and/or CSS that OOUI outputs directly.

Just to agree with this, yes, these things are wildly structurally different, and not in ways that are easily compatible. We'd need to make some sort of shim wrapper that could turn a Vue component into the extremely-different structure of a OOUI object... and it'd only be superficial. As soon as you wanted to do anything at all beyond accessing .$element to append it somewhere it'd need a lot of individual customizations to hook it up.