UMG vs. Web Browser Widget (HTML, CSS and JS) to make a UI

I’m thinking about redesigning my entire interface using HTML, CSS, and JS.
UMG is impressive, I won’t dispute that, but the resizing is similar to WoW and I don’t like it at all. Sometimes the resizing with anchors isn’t what I expected, nor with weights.

My question is, if we have powerful computers these days, why not use it?

Many will think it’s because of performance and lag with the UE5 interface. Well, they’re right, since I understand that this plugin has to open something like “Chromium.” But it also reminds me of my days when people used to say “optimizing arrays, garbage collectors, pointers…” all for memory. Even today, we use algorithms to optimize at O(n), O(n log n), and at most O(n^2).

Why?.. given how simple it is to render “something existing based on resources.” But Unreal Engine has its own style of making things slow. Why? Well, I guess the people who designed it were stuck in old practices.

You can see it’s not that fluid:
https://youtu.be/ks1tjqq3qaw?t=50

You can see it has a frame rate of 15-20 fps. How do I know? Simple.
So, if UIs normally have to have 60 fps but the vast majority are buttons, basically 1-5 fps would be enough as long as the animation isn’t excessive (like a time lapse).

Is the trend toward using HTML? It doesn’t seem like it, according to the Unreal Engine docs. Why did they delete it? Well, I know the inside scoop. Let’s say it was simply something incompatible that they made compatible. But the problem isn’t calling HTML and rendering it. The problem is how it does it.

My question is, why not use HTML in interfaces if we have computers that can already handle 16k ultra streams? Are we stuck in the old adage “it’s not the right time” to load 200MB plus the interface…?

What’s the difference between UMG vs HTML, CSS, and JS?

I don’t know about you, but I see this as modern instead of the old-fashioned button.

HTML + CSS + JS. Is it complicated for you? Ask the AI ​​to generate what you want then. With several lines of code, you get what you want.

By the way, couldn’t the functionality of the web browser wrapper that disappeared be recovered? Could you bring back HTML5 support for UE5? - #7 by Drakgoku

No, I’m not crazy right now.


All CSS and JS behaviors work correctly.

It’s true that you have to follow more steps:
1 - Each modular piece. Since the entire piece itself counts as a widget, otherwise, you won’t be able to use focus to move your character.

  • Each web browser within a layout. And each with its own behavior. You can reuse them.

2 - Load the web browsers along with the map. It takes a while to open. Then it’s better to hide and unhide.
3 - Collect the data using JS and pass it to UMG. (Here’s a simple example: GitHub - DimaChaichan/UnrealWebBrowser )

It’s true that if you can achieve a good effect, it could be powerful. But since there’s little support and it’s in the experimental phase, and above all… it doesn’t seem like they’ll continue it… I’ll leave it as a reminder.

Basically, you have to do “magic” since the HTML renderer is literally ■■■■■■■ garbage.

If this ever changes course and he gets rehabilitated, count me in.

Code used:

Summary
<!DOCTYPE html>
<html lang="es">
<head>
<meta charset="UTF-8" />
<title>Barra de Hechizos Modular</title>
<style>
  body {
    margin:0; padding:0; background:#20232a; color:#eee; font-family: Arial, sans-serif;
  }
  #spell-bar {
    position: fixed;
    bottom: 20px;
    left: 50%;
    transform: translateX(-50%);
    background: rgba(40, 40, 40, 0.7);
    border-radius: 8px;
    padding: 8px 12px;
    display: flex;
    gap: 14px;
    box-shadow: 0 0 12px #3a64a9aa;
    user-select: none;
  }
  .spell {
    width: 48px; height: 48px;
    background: #555;
    border-radius: 8px;
    cursor: pointer;
    display: flex;
    justify-content: center;
    align-items: center;
    font-weight: bold;
    font-size: 1.6em;
    color: white;
    transition: background 0.3s ease;
  }
  .spell:hover {
    background: #8a3;
  }
</style>
</head>
<body>

<div id="spell-bar" aria-label="Barra de Hechizos">
  <div class="spell" tabindex="0" aria-label="Bola de Fuego" onclick="castSpell('Bola de Fuego')">🔥</div>
  <div class="spell" tabindex="0" aria-label="Rayo de Hielo" onclick="castSpell('Rayo de Hielo')">❄️</div>
  <div class="spell" tabindex="0" aria-label="Escudo Arcano" onclick="castSpell('Escudo Arcano')">🛡️</div>
  <div class="spell" tabindex="0" aria-label="Curación" onclick="castSpell('Curación')">💖</div>
</div>

<script>
  function castSpell(spellName) {
    alert(`He lanzado: ${spellName}`);
  }
</script>

</body>
</html>

Using the code:

Summary

For professional UIs with HTML, CSS3, and JS

Here are AAA games like Spiderman 2, Minecraft, PUBG, Sea of ​​Thieves, and others. However, it comes at a cost.

I’m leaving it here since the EPIC team itself doesn’t seem to have anything on their roadmap regarding this.

Example doc:

Good news.

1- I’ve already managed to make it instantaneous when it opens.
Solution: It only loads when the map is opened in hidden mode. But I’ll set it at the player level.
2- Modifying HTML, CSS, and JS code is instantaneous without lag, with an event.

I did a quick test.

My test project - Modifying HTML, CSS and JS at runtime :slight_smile:

The documentation project:

UMG changes more than I do food. It’s not the same as it was in 2014, 2017, or 2021. There have been too many improvements and changes these days. HTML, CSS, and JS are the de facto standard for the general web.

What I’m going to laugh about is the issue of transporting the data to my HTML and collecting the events from my HTML to UMG. That’s going to give me headaches.

What’s slow? My computer, which is a :hot_beverage:
What would I need? Confirmation that this won’t be deprecated.

Yes, it works with Bootstrap and everything. I’m freaking out about the performance. It’s quite a bit faster than I thought :slight_smile:

What does this mean? UI in a matter of seconds. It’s exactly what I was looking for.

I can’t believe how fast it is, even loading Bootstrap on each iteration. I can’t imagine the moment Unreal Engine does what “React” does, updating only a few sections instead of the entire code.

Okay, UMG for the slots and within each Web browser slot in my case. I can program my interface outside of UE.

In conclusion, UMG has better performance but is more manual. Web Browser (HTML, CSS3, JS) is fine for creating rich UIs. The frame rate is around 20-30 fps, while UMG has the native ones with the engine.

What’s so complicated about Web Browser? It handles all the web browser events. So the scheme would be UMG passes the data to Web Browser, and this, with JS, passes it to → UMG.

What do I recommend?

  • If you have no knowledge of the Web, use UMG.
  • For AAA studies, it’s better to use UMG unless you use Coherent Labs.

I can’t wait for this tool to continue to deprecate and I look forward to the new things it releases.

I give the last example.


Then there is only UMG connection → Web Browser for:

  • Tooltips
  • be able to click on your character
  • And others

Intensive UI refresh test on my computer, which is a coffee maker.

Currently what it does is update the entire html every 0.1 sec:
1 - Bootstrap CDN loading
2 - You are going to search for a web image

I don’t know if it uses something similar to React, but it seems so.

Problems with different UI? It seems like for some reason it uses something similar to “React”. If the UI is loaded and you update it it works at 0.1. If it has another user interface and you load another interface in the same interface it seems that there is a delay of a few thousandths when the stress test is done.

For example:

  • UI A and update = works perfectly at 0.1 sec at 100 repetitions
  • UI A and refresh with UI B = Doesn’t work as well at 0.1 sec at 100 reps
    • In addition, you will never have a UI that completely changes to another and even if that were the case, nothing would happen since you are not going to refresh it 100 times every 0.1 sec.

So I conclude that for real-time combat, it is functional. However, this answer is somewhat hasty, more tests must be done. For example: In a fight with buffs and debuffs, hovering the mouse over the tooltype while changing inventory items and it is active. Even if it were 0.1 or 0.2 sec of refreshment it is good enough “for me”.

So I can conclude that the web browser does something similar to React. Not bad for now.

Note: For HTML, CSS, the fact that the CSS is adaptable to the layout is enough for it to render correctly within a UMG layout. You can also disable the “right click” so that it does not make strange interactions from CSS.

With 48 hours I can conclude that it has potential and that is precisely why I will go with Web Browser.
If you’re wondering what to use, do what you want, but keep one thing in mind. If you migrate from the engine one day, your entire UMG will have to be refactored while with HTML you can even take the UI in a browser game.

I once heard a “fool” say that web code would be the future… I’m sounding like that fool and I can tell, how much vision that guy had.

Now you can firmly defend UMG against the web browser widget plugin, since UMG is native and is native to the Unreal Engine. Nobody disputes it and we know that UMG tends to have a higher refresh rate. However, the WBB style is web-based and this CSS consortium has been improving its graphical appearance for years since they have been working since “1996.”

1 Like

Nice work done and thanks for your insights about all of these,

I personally come from a time where html 1 exists, no css invented and saw many things change in a good way, seen many engines, many frameworks, many frameworks for interfaces and I think one of the most advanced tech in interfaces if for sure web tech. There are entire clients and games that work on this so I don’t think you are a fool at all.

I am still interested in these and totally ok with approaches of web, though I would like to mention some stuff that is still a problem and common insights about the tech changes around it. (though I am not an epic employee)

  • Web is advancing : Though it’s advancing it is also becoming more complex. CSS become robust does much more than styling nowadays however its also growing in size and still fragile if you don’t know what you are doing :slight_smile: JS is not meant to replace php however it kinda did which is good however its kinda more unsecure as application compared to other ones at least imo.
  • Web still has base rendering problems : Even though chromium did somehow put it’s weight to streamline code standartization its still a problem. Font Kerning is still a problem and it can be only solved between hardware developers and W3C standization.
  • Some engines even tried to bring these mindset and I will be blunt about it, they did a horrible job with it, it doesn’t works at high level. I don’t think its a tech problem but its a design problem more likely even they tried USS style sheets etc.
  • I saw internal frameworks coherent and they have their own problems, sometimes they are too narrow that you feel stuck just to do a simple thing since the architecture designed that way. Similar to mold code that you are doing (it not bad) but it will come with its own cost burden and that is generally human burden around UX. I saw action scripts frameworks too which I hated hope nobody encounters those ever :slight_smile:
  • As you said we can defend UMG or something else, its just about tradeoffs what needs to be done. what sources are there. How easy to onboard somebody. What I see the real difference UMG is the rendering framework that is growing. Lastly there is SDF for fonts which is awesome improvement and there will be more. Think some legacy things should change but and somebody has to clean up that :slight_smile: UMG rendering unlock HLSL graphs to do many animations on ui which would be overly complicated with web tech or webgl, that is what I love the most about it. On the other hand for sure it needs more, with render targets, inputs, shader frame work and usability of it.

Web is future and I am that fool aswell and let’s think of a game that you have to access game client outside of game which is a huge benefit and the best way to do that is webtech. Its consistent, reusable, accessible. League of Legends is exactly like that, However when we use same tech in game thats when the real pain starts with all the creativity we want to deliver, the people who want to do it and their knowledgebase/learning curve, thats where think unreal steps in the right direction.

Another problem that is hidden in the shadows is localization and font rendering/ font handling. I would appriciate if you take a look of those aspects, like runtime language change from latin to → traditional chinese or from latin to → latin extended (English to Turkish with glyphs ğüışöçİ these are the real problems still exist and I wonder hot reload etc we can do on these? especialy with quest/speech/subtitle on runtime?

Think the real problem of the webtech is onboarding artists that can go crazy with it. Will always require a technical designer, engineer or developer and that would be a cost probably a big one.

1 Like

You can also unfortunately get extra limitations from web tech. Any use of browser tech introduces external restrictions like CORS (Cross-Origin Resource Sharing) if you want to dynamically load any external asset from an online source. You also do not have direct access to files and drives from browsers. I’m not sure if for example you could trigger any menus for save game etc or is it a one way refresh by reading external values through an exposed API in game or is it a two way street?

if you could poll the server via ajax then you could refresh parts of the “site” via target id’s or css selectors without full reloads.

1 Like

As a Spring Boot backend, I’d never considered enabling CORS in UE5, as the game typically loads assets locally or via sockets, rather than from an external repository.

If CORS were enabled, Unreal Engine 5 could function practically as a full-stack environment, independent of local assets, loading everything on demand just like a browser. In that case, the backend would act as an API server serving resources CDN-style.

CORS only applies in the context of HTTP/HTTPS, but it doesn’t affect socket communication, which is currently one of the most efficient transfer systems. Unreal Engine can load assets both locally and via WebSocket, so in most cases, CORS wouldn’t be relevant unless a practical use is found (security for multidisciplinary teams, etc.).

UE’s Web Browser is based on CEF, so yes, complete UIs with HTML, CSS, and JS can be built without issue.
If you also serve them externally (via CORS), you gain a decoupled UI, very useful if you work with multiple teams or want to prevent your design from being copied.
However, Epic would need to provide support in its API to handle CORS headers and permissions natively.

UWebBrowser | Unreal Engine 5.6 Documentation | Epic Developer Community.

In any case, the current WebSockets-based model is still more efficient than the traditional one based on HTTP and CORS.