hA! Hit the nail on the head :P

However, React introduces a lot of complexity to avoid unnecessary DOM updates, which makes me wonder about the viability of an immediate mode GUI in the browser using canvas.

- it is badly designed. If state is too hard to manage it means often that the design is bad

- state is not the most important part of the UI. Interaction and being elastic to changes are the most important things

- frontend is often overengineered in a bad way. When you use bad solutions like React or Redux there is no change there won't be any problems.

If you have a problem synchronizing your views with a light, that's because the light should exist outside of your views.

MVC was invented in the 70s. Why do we have to act that this is not a solved problem?

The home page is a bit ugly, but it contains a range of examples that are commonly awkward to implement in other UI libraries:

http://www.react4s.org/

No programming paradigm can stand up to rushed/flawed mental models.

The domain can become quite complex; it is wishful thinking to believe that a single approach could drain it of all complexity.

How is the click propagated recursively through every component and is the position compared repeatedly at every step?

Well no. There are applications with nice well thought out GUIs.

>"Congratulations, a large amount of your effort will go towards resolving weird message bus problems as opposed to writing the business logic of your app"

Sorry but I do not resolve "weird message problems". I use my own publish-subscribe mostly asynchronous message bus for my GUI apps (actually I use it also for non GUI parts as well). Components (visible or not and including running threads) can subscribe to events. It does not exhibit any performance / memory problems and in combination with the global app state object makes programming interactions a piece of cake.

1. Mixed concerns and a lack of application layering. In React code bases and others like them, its not uncommon for me to find business logic embedded directly inside the components themselves. This makes the component inherently coupled to the specific implementation its being used and can only be re-usable in other contexts by passing in modifier flags to the props etc. In my opinion, components should be mostly of the stateless flavor and delegate anything not directly related to their immediate UI concerns elsewhere. This increases the likelihood of re-usability of your components and makes testing business and component logic much much more straight forward.

2. This might just be my personal experience, but I've noticed a bit of a dismissive attitude around design patterns and traditional computer science principles among my front end brethren. YAGNI and all that. While I think its fair that the UI != to the back end, I think frequently the baby gets thrown out with the bath water. For instance, I frequently leverage dependency injection in my front end work as a way to make my code more flexible and testable. It's hard to sell the benefits of something like DI until your application grows in complexity to the point that you are dealing with things like nested mocks in your tests and/or need to make a non trivial change to some piece of functionality. I've been seeing the winds start to shift a bit on this which is encouraging.

3. Most of the time there is little to no overall _conceptual integrity_ to a given front end code base. Its uncommon for me to come into an existing code base and have anyone be able to tell me what the architecture is comprised of. Things like what logic lives where and why. I'm not saying people _don't_ do this, but in the more gnarly code bases I've encountered, this "accidental architecture" is more common.

4. Front end is still see as "easy" and the place you stick the less experienced engineers first. I sincerely hope this doesn't come off like I am gatekeeping or anything. I work with some absolutely brilliant people who are only a year or two into their career and much smarter than me. IMO its less about skill and more about having been burned enough times to know where unexpected complexity lie.

I love front end. Its challenging and interesting and maddening. My hope is that it will continue to mature and grow to the point that it gets the same respect as other disciplines within this field. These days I work full stack so its not all I do, but it will always be my favorite. :)

As a rule practical and manageable UIs use all these approaches at the same time.

Components, class based and/or functional (fe: UserSection, InventoryTable ), are in principle loosely coupled. They may not know about each other and use messages to communicate.

The Flight by Twitter ( https://flightjs.github.io/ ) was/is probably the first practical thing that pioneered that approach.

The Flight is not even a framework but rather a design principle.

In fact it is an anti-framework - it postulates that in practice each component may have its own optimal internal architecture. One component is better to use React-ivity, another - Angular-ish data binding, etc. On some, immediate mode drawing is the most natural.

Smaller the task (component) - greater the chance to find silver bullet for it.

I see OP doesn't mention this option, but is slightly related to both option 1 (connect the box) and 3 (message bus / event emitter). This option is similar to how OS provides an API to user space application program. For example Windows provides an API to an application to flash its window without exposing all of its state like mentioned in option 1. https://docs.microsoft.com/en-us/windows/win32/api/winuser/n...

Here's the detail:

A self-powered object, let's call it workingIndicatorObject, can be introduced to work on the working indicator. It provides 1.) `getState() -> WORKING/NOT-WORKING` a function to get its state, and 2.) `register() -> None`, a function to register user activities. These functions are dependencies for UserSection component and InventoryTable component respectively. In term of lifetime and hierarchy, it precedes and outlives both components.

The workingIndicatorObject MUST have its own lifecycle to regulate its internal state. Its core lifecycle MUST NOT be managed under the same event loop as the GUI components, assuming the program is written on top of a framework that has it (React, Vue, etc). This is to assure that it doesn't directly affect the components managed by the framework (loose coupling). Although, a binding MAY be made between its state and the framework-managed event loop, for example, in React environment, wrapping it as a React hook. An EventEmitter can also be provided for a component to listen to its internal event loop.

Injecting it as a dependency can use features like React Context or Vue's Provide/Inject pattern. Its consumer must treat it as an optional dependency for it to be safe. For example, the UserSection component can omit drawing the "working" indicator if it doesn't receive the `getState` function as a dependency.

Internally, the workingIndicatorObject can use a set. The set is used to store a unique value (a Symbol in Javascript). `register` function creates a Symbol, stores it in the set, and deletes it after $TIMEOUT, while firing event both at addition and deletion. `getState` function is a function that returns `set.size()`. When bound to the component, an addition to the set fires an "update" command to the component, which redraw the component along its internal state. This is just one example of implementation and there are other simpler ways to have the same behaving workingIndicatorObject.

This approach allows UserSection and InventoryTable to only know `getState()` and `register()` function and nothing else, and having both of them optional. Using static type system such as TypeScript can help a lot in this since we can pin down the signatures of both function to `null | () => WORKING | NOT_WORKING` and `null | () => void`, where we can enforce both dependent components to check if it exists and to call it with the correct types, otherwise the compiler yells.

Small point, but it grated.

https://en.wikipedia.org/wiki/Mediator_pattern

https://floooh.github.io/sokol-html5/imgui-highdpi-sapp.html

There are also demos for other immediate-mode UI systems on the parent page (Nuklear and microui):

https://floooh.github.io/sokol-html5/

As I wrote in another thread, Immediate Mode UI doesn't imply how the UI rendering is implemented, only how the API works.

But a system that may be clean and elegant for a 1-person gig may end up falling to bits if you attempt to have 100 people working on it.

I get what you mean about hooks, I was initially apprehensive and like you I realized the problem they solved. I think the problem we have now, is they are the answer to everything, along with Context. Code that could have been a plain Javascript module is a hook that uses Context to pass refs between components.

I think a big issue is reactivity outside of a reactive view library isn't talked about much. You have libraries like RXJS and Effector, which I'm a big of, that let you handle reactivity separately from a view but they're still full black boxes themselves. I'm not sure many people think about reactivity as a quality separate from any library.

The libraries react-query and svelte-query are an interesting manifestation of this. I haven't diffed the code or anything but they share a core that is essentially the same. Observer based reactivity to handle async calls. Yet there are two different repos with duplicated code providing different frontends based on React and Svelte. I don't want to pick on how the code architecture or anything but it feels like the reason there isn't just a base "query" library that exposes its own Observer API with bindings to React and Svelte is because of the general refusal to accept splitting out responsibilities and there should be a "React way" of doing things.

I'm hoping the TC-39 Observer proposal along with Svelte's idea of a store contract might open a few eyes and show people that the frontend doesn't have to be the closed off black box that it currently is but a lot of people already seem set on the idea that Observers are some RXJS stream based thing that they want no part of.

Anyway sorry for the long reply. I've been thinking about this stuff a lot in trying to establish my course through all this.

It's an unpublished roguelike that I'm working on, slowly, on hobby time. ASCII graphics, focused on distance combat, and with a hybrid ECS/event-based architecture, where the entire game state is stored in an in-memory SQLite database. More of a research project into the benefits of such architectural decisions than an actual game.

The DI system kind of grew out of my design goal to make the game logic testable in headless mode, without rendering or input (I have only so much time to write and maintain it, and I sometimes code over SSH). I started architecting things with dependency inversion in mind, and then figured I could have the whole game's object graph instantiated in a single place. I decided to make it declarative and composable (pretty much concatenative) by writing code that automatically instantiates the objects in correct order, and then I realized I've reinvented a DI container.

John Milton:

"Into this wilde Abyss, / The Womb of nature and perhaps her Grave, / Of neither Sea, nor Shore, nor Air, nor Fire, / But all these in thir pregnant causes mixt / Confus’dly, ..."

Daniel Defoe:

"And now I thought myself pretty well freighted, and began to think how I should get to shore with them, having neither sail, oar, or rudder, and the least capful of wind would have overset all my navigation."

William Wordsworth:

"Neither vice nor guilt, / Debasement undergone by body or mind, / Nor all the misery forced upon my sight, / Misery not lightly passed, but sometimes scanned / Most feelingly, could overthrow my trust / In what we may become"

Thomas Macaulay:

"Neither blindness, nor gout, nor age, nor penury, nor domestic afflictions, nor political disappointments, nor abuse, nor proscription, nor neglect, had power to disturb his sedate and majestic patience."

Jonathan Swift:

"I find likewise that your printer has been so careless as to confound the times, and mistake the dates, of my several voyages and returns; neither assigning the true year, nor the true month, nor day of the month"

George Bernard Shaw:

"But there are men who can neither read, write, nor cipher, to whom the answer to such sums as I can do is instantly obvious without any conscious calculation at all; and the result is infallible."

G K Chesterton:

"He takes us into the schools of inhumanist learning, where there are neither books nor flowers, nor wine nor wisdom, but only deformities in glass bottles, and where the rule is taught from the exceptions."

Since the above are all notable English (or in two cases Irish) writers, here are a few notable Americans.

Herman Melville:

"But neither great Washington, nor Napoleon, nor Nelson, will answer a single hail from below, however madly invoked to befriend by their counsels the distracted decks upon which they gaze"

H L Mencken:

"I am thus neither teacher, nor prophet, nor reformer, but merely inquirer."

Mark Twain:

"It is not pleasant to see an American thrusting his nationality forward obtrusively in a foreign land, but Oh, it is pitiable to see him making of himself a thing that is neither male nor female, neither fish, flesh, nor fowl--a poor, miserable, hermaphrodite Frenchman!"

Neither sleet, nor snow, nor gloom of night..

Note that in this case, most modern framework actually focus on what Microsoft called MVVM in Silverlight (Model View View-Model), a lesser strict "clean controller" approach where view and controller are tangled in each other since it's throw away code for the most part, while the model stays clean.

Focus is the hardest one, because that can move around really erratically. But even that sometimes has to be done in state. IE11 doesn’t have descendant focus selectors so at my last job I wrote a hook for our dropdown children to dump their focus state into a React context so our renderers could stay pure and not rely on CSS and therefore DOM state.

Just last week I implemented a hook to reposition a tooltip based on the mouse cursor.

You do need to think about DOM state a little when doing these things. But I would argue that’s somewhat separate from the activity of building a React UI. It’s pretty rare you can’t just render purely based on the React state, using off-the-shelf hooks.

So, I think that you're both not wrong: State tends to be one of the (if not the) fundamental problems in most of programming. Often, looking at things from another perspective is very helpful. And we should be uncovering new strategies to do that for all places where we haven't, including the GUI.

Of course, that also means that we arrive at the meta-problem of synchronizing the state backing various systems at one point. Which mostly encapsulates Karlton's "two hard things": Cache invalidation and naming things. :)

We don't play around with event sourcing right now, but it might be feasible at and above the UI state services if we wanted to do things like replay a user interaction with our app. The only caveat is that our domain services are very very messy in terms of side effects, so the practical utility is bounded to isolated UI testing.

I really enjoyed learning about the hierarchical state machines using statecharts.

There are just so many problems with MobX. For example reactions - ever tried figuring out why some value changes in a bigger app? Not to mention abysmal tooling (compared to Redux DevTools). But the biggest problem is that everything is... sprinkled with magic. Just give me Redux(-toolkit), thank you very much, I can understand these much more deeply. /rant

If I sound confrontational, sorry about that... I just had the misfortune of inheriting a MobX app. Magic indeed.

If it comes to the question. I think you have answered yourself by writing React won't stop you from making bad design decisions.

I can state from experience that using Dear ImGui over Qt massively sped up the application we developed (Media player with non-trivial UI that decoded RAW video in real-time using CUDA/Metal/OpenCL). Framerate increased by around 10%, and there was no longer any significant difference between the consumer-oriented software and an internal engineering tool that was literally nothing but an SDL window and some direct API calls.

Perhaps caching was performed driver-side, or perhaps maintaining indexing is not a huge issue on modern GPUs. I couldn't tell you, honestly, but I saw the performance gains with my own eyes. Entire UIs would chew up less resources than a blank QWindow.

This is actually a fascinating example: https://lucywang000.github.io/clj-statecharts/docs/get-start...

... because it highlights precisely my criticism.

  ;; define the machine
  (def machine
    (fsm/machine
     {:id      :lights
      :initial :red
      :context nil
      :states
      {:green  {:on
                {:timer {:target  :yellow
                         :actions (fn [& _]
                                    (println "transitioned to :yellow!"))
                         }}}
       :yellow {:on
                {:timer :red}}
       :red    {:on
                {:timer :green}}}

      :on {:power-outage :red}
      }))

You might argue that the data model makes it flexible. But I look at that and go, that's what a function is for. The only thing you need is `(println "transitioned to :yellow!")` inside of a function called transition-to-yellow, or if you're feeling adventurous, a function called transition-to which takes yellow as an argument.

Then that some people make React components change state on render/mount/update, is a different failure, but not really a failure of React as much as a failure of the one using React.

But in general no, React doesn't really prevent you from having a component updating and re-rendering because some state changed, and because of that, changes the state again and thus re-renders again, forever.

If you take a look at the syllabus of the course, it's not about JavaScript, it's about the formalism and understanding the core concepts, without locking you to a particular technology. Whatever they are teaching in the course, you can apply to JavaScript/Swift as much as you can apply it to Desktop/Mobile.

Disclaimer: haven't actually taken the course, but planning to and I've read the description of it.

> laying out a diagram

I think layout belongs to the views (you call them presentation rendering).

View models provide data to be visualized, but it’s rarely a good idea to compute pixel positions, or handle low-level input there. These things are coupled with views too much.

Similar to animations. Unless the app being developed is a video editor or similar where animation is the core functionality, animations don’t affect models nor view models, they merely prettify GUI state transitions or provide progress indication. No need to wire them all the way into view models. Some frameworks even run them on a separate thread called “compositor thread” so they play fine even if the main thread is blocked or starved for CPU time.

When you call ImGui::Button("Hello World") it has no way of telling if it’s the same button as on the previous frame, or a new one. You’re simply not providing that data to the framework.

It’s often good enough for rendering, they don’t really care if it’s an old or new button as long as the GPU renders identical pixels. When you need state however (animations certainly do), the approach is no longer useful.

A framework might use heuristics like match text of the button or relative order of things, but none of them is reliable enough. Buttons may change text, they may be dynamically shown or hidden, things may be reordered in runtime.

> Layout problems can be solved by running several passes over the UI description before rendering happens.

You’re correct that it’s technically solvable. It’s just becomes computationally expensive for complex GUIs. You can’t reliably attach state to visual elements, gonna have to re-measure them every frame.

> There need to be accessibility APIs which let user interface frameworks connect to screen readers

Windows has it for decades now. For Win32 everything is automatic and implemented by the OS. Good custom-painted GUI frameworks like WPF or UWP handle WM_GETOBJECT message and return IAccessible COM interface. That COM interface implements reflection of the complete GUI, exposing an objects hierarchy. I’m not saying it’s impossible to do with immediate rendering, just very hard without explicit visual tree that persists through the lifetime of the window.

But otherwise, yes, just use a framework that separates State from UI and has bidirectional updates, like SwiftUI.

For example from a quick look at the code it looks like this project needs to draw in a bunch of unrelated to each other libraries just to get some basic GUI functionality you'd find even in toolkits from the 80s provide (e.g. drawing text or using file dialogs).

And check these sources [0] and [1], this is doing at least as much bookkeeping as in a "retained" GUI toolkit - except it also has to do things that such a toolkit would do automatically, like explicitly drawing the widgets [2]. People at the past were complaining how tools like Visual Basic were mixing presentation and logic, yet the worst you could do in these tools is to have the logic in event handlers (...which if you think a bit about it at least that does make a bit of sense), yet here is actual application logic being part of the drawing code in [3] (this is inside a method View::DrawPlayback, scroll a bit upwards to find it).

Now sure, someone might say that this isn't the best example of immediate GUIs... but this is the one that was brought up as a good example. And TBH all it convinced me is that if (for some reason) i had to use ImGui (the library), to spend some time building a retained GUI wrapper around it :-P.

[0] https://github.com/wolfpld/tracy/blob/master/server/TracySou...

[1] https://github.com/wolfpld/tracy/blob/master/server/TracyVie...

[2] https://github.com/wolfpld/tracy/blob/d8c1dae9e120c27801e762...

[3] https://github.com/wolfpld/tracy/blob/d8c1dae9e120c27801e762...

I sincerely hope no one looks at the screenshot on that page and thinks "this is something that works well". This UI screams "I've been made that way because that was the easiest way in the tool I'm built with" (which is bad - good tools should not dictate the form of the resulting product)

Not a distinction made because of immediate vs retained GUI.

1. writing code adds “debt” 2. Your solution is to now add state charts too which also adds “debt”

Where are these state charts tracked? Who maintains them? When product asks engineering to change code => you now also update state charts. Added technical debt.

If this is difficult for you to understand (the problem I’m describing is very common at large companies) I’m happy to expand more on it.

Thoughts?

In the apps I work on this happens all the time. User clicks “do something” button, the model needs to start doing that, in the meantime the view needs to disable that button and show “doing something, please wait…” with a progress bar. For this reason, I normally handle such higher-level events in VMs and call models from there.

I used too strong a word before. As you point out, situations where you’d want to update both the application and presentation data aren’t really unusual. You gave one good example. Another might be controlling a modal UI, like closing a dialog box or moving to the next step of a wizard, when maybe you also want to commit data user has entered in a temporary form to the permanent application state. In these cases, handling a UI event would indeed need to get the relevant information to both of the other layers one way or another. This still easily fits within the architecture pattern I was describing, though.

I think strongly typed languages handle 90% of what people usually unit test for, with better developer’s UX.

I am a big fan of using expressive type systems to prevent defects, particularly as an alternative to huge unit test suites full of boilerplate that still don’t do as good a job.

However, no mainstream type system will verify that for a given list in your application data and a given sorting option chosen in the UI, a function in your presentation data layer has generated the correct top 10 items in order. (No unit test can ever verify that property in general either, of course, but at least we can test some representative example cases.)

I think that only works when switching to something extremely similar. I did when porting iPhone code to iPad, or WPF XAML to UWP XAML, but these were very similar platforms. UI libraries are complicated; replacing them with something else is huge amount of work.

I suppose that depends on what you consider extremely similar. Around 10–15 years ago, when what we call “single page applications” today were starting to gain serious traction, if you wanted an interactive visual representation of your data, you probably used one of the proprietary embedded technologies like Flash, Java or ActiveX. But if you were drawing, say, an org chart, you were still ultimately just putting boxes and lines and text in certain places within the allocated area on the page. Today we have tools like SVG, canvas and WebGL available handle the drawing part, but everything we’d want to display in that drawing might still be the same.

I don’t believe these pieces are portable in practice. Both coupled with UI libraries too much. For the diagram, half of the 2D rendering libraries are immediate mode other half are retained mode. Animations are totally different as well, CSS animations in HTML don’t have much in common with visual state manager in XAML.

I think perhaps we have very different types of animation in mind. From the above, I’m guessing you’re thinking of things like pulsing a button when it’s pressed or a little progress spinner while downloading some data? I’m thinking of things like smoothly moving all of the boxes on that org chart to their new positions, including animating the shapes of the paths between them, when the user does something that moves the chart around. Another example might be animating weather data overlaid over a map graphic through the next few hours when the user presses a “play” button. That is, I’m talking about animations where the data to be shown at each step needs to be determined according to complex requirements, not just playing a simple, predetermined effect that a UI library or platform API might handle for you almost for free anyway.

Yeah, because I'm not trying to convince you of anything. It's a tool in your toolbox, use it when you think it's advantageous, otherwise use your other tools. I couldn't care less of what you chose to do or how you "sell this to teams". I'm a developer who simply chooses the best tool for the job, sometimes that's Statecharts and sometimes it's something else. Also don't have any idea about what ideas are circling around in "Academia" as I'm far away from that ecosystem and only focus on shipping working products.

If you're looking for something "easy" in particular, then whatever you don't know is gonna be hard. Such is the life of a developer, where sometimes the simpler way is harder but worth it in the end. React was hard for people to grok in the beginning as well, but that doesn't mean it's bad, it just means people are not familiar with it. If you're just looking for easy solutions then yeah, feel free to stop improving and continue use the stuff you already know or is familiar to you.

So in the end, do what you will with the knowledge and experience I've shared with you, I have zero interest in selling you anything and I'm simply discussing stuff here on HN as I'm curious about things and want to have discussions with people who are also curious about things, but this discussion stopped being productive a long time ago.

But I guess different UI frameworks have different solution for this. Creating and updating a 1 million item list wouldn't be a cheap operation in a traditional UI system either.

This sounds a lot like paintEvent() in traditional OO-style GUI systems; i.e. event-driven.

So my understanding now is that with immediate-mode callbacks happen within the scope of a function-call rather than from some event-loop. I probably have to look into it deeper to get a good understanding. It is still unclear where state is stored (e.g. for the position of a scroll-view), and if state is passed through the function call tree on every frame.

I think for me the figure is about 8 years of development of 1 GUI software, with MVVM and .NET.

> implicit assumptions about the platform here with the reference to styling

It's 2021, pretty much all of them support styling now.

> I was saying that web-based GUIs might have moved from rendering graphical content using one of the plugins a few years ago to rendering it using one of the native technologies today, without necessarily changing the content itself.

None of them were able to reuse much code while switching just the renderer: ActiveX written in C++, Flash in ActionScript.

> the GUI framework you are describing does not exist

WPF and UWP definitely exist. I think modern HTML+CSS can do that too, but I ain't a web nor electron developer and not sure.

> ultimately you still need code to define the way the layout should animate according to whatever rules your system uses

It's the matter how you define them. When you offload playing animations to a framework, you tell the framework which properties to animate and how: define function of time (typically supported ones include step functions, polylines, and Bezier), pass metadata about timing and repeats, etc. That's for the hard case when animations depend on the data, when they do not they're made offline by art people.

> Can you clarify?

When you do them manually, i.e. computing functions of time and changing visuals, following happens.

1. Your code runs at refresh rate of the monitor, typically 60Hz, but for high-end gaming monitors can be 240Hz. Even if you aren't animating anything, this alone prevents certain power saving modes from engaging.

2. If you manually change positions of things not just color, your updates gonna invalidate layout.

3. There're multiple ways of measuring time with different tradeoffs about precision and when it's running versus paused.

A framework is in a better position because it drives the main loop. It knows how many nanoseconds passed since the last frame. It knows when to render at 240Hz and when to sleep on GetMessage() because there's nothing to update. If it knows which properties are animated, it can integrate animations with layout for reasonable performance cost.

Not so much, if you’re only asking them to do the last step of translating information you already have into whatever format/APIs are needed for a particular medium, which is essentially what I’m advocating with the architecture here.

Long-lived web apps have had to deal with this several times in recent years as the various plugin technologies have been deprecated and ultimately removed from browsers. It obviously takes a certain amount of time to reimplement that logic on what might effectively be a new platform, but it’s certainly achievable, and it’s easier than rewriting more of your application because you’ve been forced to change platforms.

Sometimes XAML can.

I think perhaps you’re misunderstanding my argument, because it is literally impossible for any GUI framework to do what I’ve been describing. It absolutely requires application code to specify what animation is to be constructed, based on the data available. A GUI framework can then handle the mechanics of actually running that animation, but it can’t know what the animation should be. That’s an application problem.

Take a simple example. Suppose we want to illustrate a sorting algorithm. We will do this by drawing 10 boxes in a row on the screen, labelled with different data values to be sorted. Without me telling you how I want to animate those boxes from one order to another after each step of the sorting algorithm, how will your XAML or whatever know what animations to draw? Are we fading out the items that will change positions and then fading them back into their new positions? Are we going to animate a moving item up out of the row, then slide the other items along one way as the moving item slides above them the other way, then animate the moving item back down to its final place? If we do that, are we going to do both horizontal slides at the same time, or one and then the other? What if we want a hybrid, where the moving item fades out, then we slide the others that need to shift, then the moving item fades back in at its new position?

There is no way any GUI framework can know what should happen in a situation like this. The required behaviour needs to be specified as part of your code. The GUI framework can handle the mechanics of fading things in and out or sliding shapes from A to B according to some timing curve, but only once you’ve told it what needs to happen.