Please stop shoehorning everything into HTML/CSS/JS

Posted Nov 13, 2024 14:29 UTC (Wed) by jzb (editor, #7867)
In reply to: Please stop shoehorning everything into HTML/CSS/JS by kreijack
Parent article: Anaconda’s new "Web UI" (Fedora Magazine)

I'm curious if you read the article or Garrett's response in the comments? The article explained in some detail why they wanted to pursue this as a web UI rather than GTK. Here's a snippet:

GTK 3 is still currently maintained, but it’s old and showing its age. It won’t be maintained forever. Porting to GTK 4 (and possibly GNOME’s special widget set, libadwaita) will require a lot of effort to adapt to the changes and would require a massive effort to rewrite much of the frontend, especially as Anaconda has many custom GTK widgets.

Since we’d likely have to rewrite a lot of the frontend anyway, we took another approach and have taken advantage of the modularization efforts to retool the frontend to have a web-based interface instead. The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too.

Please stop shoehorning everything into HTML/CSS/JS

Posted Nov 15, 2024 18:38 UTC (Fri) by kreijack (guest, #43513) [Link] (1 responses)

> The article explained in some detail why they wanted to pursue this as a web UI rather than GTK. Here's a snippet:

Not really, the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code (o whichever toolkit you prefer).

I have to point out that I am not arguing the fedora decision; I am only wondering if we reached the point were writing a (non trivial) gui in a web browser is (absolutely) better than writing a gui in C/C++ in a case where *the "remote access" is not a "first" requirement*.

I want to be very clear to a point, I programmed a javascript UI (very simple for what matters), and I found it a friendly language to program. However my feeling was also that due to the lack a lot of "safety" (e.g. type checking) that other language provides, it is not good for big program; at least if we don't consider other aspects. E.g. if I have to program a front-end of a program that run on a server, which must be execute in any PC, yes a browser+javascript is a very good compromise, and may be the best choice.

However I am surprise that the same choice was taken for an installer. Again I am not arguing the other choice or blaming javascript as language; I am only guessing if the correct prospective is that the other are worse. And in this case I am curious about the other opinion.

Please stop shoehorning everything into HTML/CSS/JS

Posted Nov 15, 2024 19:14 UTC (Fri) by jzb (editor, #7867) [Link]

the article explained that in any case they had to rewrote a lot of code, so switching to a web base front end was no so expensive; but the same is true for switching to (e.g.) rust based code

They also explained the choice of a web-based interface:

The Cockpit team has been providing a web-based interface for Linux systems for managing systems for many years in the Cockpit web console, so it made sense to reuse Cockpit as a base and its web-based widget set, PatternFly, as a starting point for the next generation of Anaconda too.

I suppose they didn't go into a blow-by-blow comparision of that approach vs. Rust or whatever, but it's pretty clear they chose tooling they were already familiar with that is in use for other system management tools. We covered Cockpit in March. They also mention the use case of remote installs in the future—which makes sense since there are many instances when an admin may want to install Linux on a system they'll never be in the same room with and a TUI is not seen as friendly.

Also, Red Hat has been investing in Patternfly for UIs for a long time now, I'm not at all surprised to see it employed in an installer because the alternative would be "use Patternfly here, here, and here, but not the installer". If you assume the folks working on Anaconda also work on other UIs, it would be weird to expect them to use Patternfly everywhere but the installer.

However I am surprise that the same choice was taken for an installer.

Fedora isn't alone here. We covered openSUSE's new installer, Agama, in August, which also has a web-based interface. Ubuntu, I think, uses Flutter, but I can see why that wouldn't have appealed to Fedora or SUSE.