6 ms·

No doubt there are many different architectures that can work well in this sort of situation. I’m just arguing that, contrary to your earlier comment that I fir

No doubt there are many different architectures that can work well in this sort of situation. I’m just arguing that, contrary to your earlier comment that I first replied to, an immediate mode UI can be one of them even when the requirements are not so simple. 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.

Const-me 6y ago
> immediate mode UI can be one of them even when the requirements are not so simple Just because you can doesn't mean you should. > a function in your presentation data layer has generated the correct top 10 items in order There're too many things which can go wrong with visuals. Incorrect order has smaller probability than a bug in a style somewhere which makes data invisible. For the 2nd reason you want to test that thing somehow else anyway: unit tests don't catch rendering bugs. Some other automated tests can in theory, but in practice maintaining these tests wastes a lot of time i.e. expensive. > Around 10–15 years ago, when what we call “single page applications” today were starting to gain serious traction Traction is overrated. Around 20 years ago Outlook Web Access (a server-side component of Exchange server) already was a modern single page application, written in HTML and JavaScript. All the required functionality was already there in IE, and even documented nicely on MSDN. > everything we’d want to display in that drawing might still be the same. Totally different. SVG renders vector 2D graphics, WebGL is a 3D GPU API. Try to render something slightly more complicated than rectangle of solid color, and you'll see. One example is rectangle with rounded corners: trivially simple in SVG, relatively hard on GPU. A Mandelbrot set is opposite example. > animations where the data to be shown at each step needs to be determined according to complex requirements Doesn't matter if the data is static or not. Once you know the data, you do not want to run your code at 60 Hz (or 240Hz if you're really unlucky) computing functions of time and updating things. It's almost always a good idea to use the GUI framework for playing animations. They do better with rendering and power saving.
- Chris_Newton 6y ago
  Just because you can doesn't mean you should. Sure, but that’s not an argument for not doing it either. As I’ve been trying to explain, I’ve had practical success building applications using the kind of software architecture I described. I don’t like to get into personal backgrounds in these discussions, because as a rule I think arguments should stand on their own merit. However, just for some perspective, I wrote my first professional GUI around three decades ago. More to the immediate point, the longest I’ve maintained and extended a single GUI built using the architectural pattern I described was over a decade, and that one was probably more complicated in its requirements than a lot of web applications you’d see today. So although it’s just one anecdotal data point, I think it’s a good demonstration that this kind of architecture can work well over an extended period. There're too many things which can go wrong with visuals. Incorrect order has smaller probability than a bug in a style somewhere which makes data invisible. For the 2nd reason you want to test that thing somehow else anyway: unit tests don't catch rendering bugs. You seem to be making some implicit assumptions about the platform here with the reference to styling. In any case, this is why I mentioned that you might want a different testing strategy for the presentation rendering layer to the code that collects the presentation data. Totally different. SVG renders vector 2D graphics, WebGL is a 3D GPU API. Try to render something slightly more complicated than rectangle of solid color, and you'll see. Sorry, I’m not sure I understand the point you’re trying to make here. 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. Obviously which native technology you’d choose would depend on what kind of visuals you were creating and how you wanted any interactions with them to work. Once you know the data, you do not want to run your code at 60 Hz (or 240Hz if you're really unlucky) computing functions of time and updating things. It's almost always a good idea to use the GUI framework for playing animations. They do better with rendering and power saving. To the best of my knowledge, the GUI framework you are describing does not exist. You might be able to extract some basic movements that could be handed off to something running at a lower level with hardware acceleration, but ultimately you still need code to define the way the layout should animate according to whatever rules your system uses, for the same reason you need to define a static layout before or after the animation that way. I’m not sure what you’re getting at with “doing better with rendering and power saving”. Can you clarify?

Const-me 6y ago

> immediate mode UI can be one of them even when the requirements are not so simple Just because you can doesn't mean you should. > a function in your presentation data layer has generated the correct top 10 items in order There're too many things which can go wrong with visuals. Incorrect order has smaller probability than a bug in a style somewhere which makes data invisible. For the 2nd reason you want to test that thing somehow else anyway: unit tests don't catch rendering bugs. Some other automated tests can in theory, but in practice maintaining these tests wastes a lot of time i.e. expensive. > Around 10–15 years ago, when what we call “single page applications” today were starting to gain serious traction Traction is overrated. Around 20 years ago Outlook Web Access (a server-side component of Exchange server) already was a modern single page application, written in HTML and JavaScript. All the required functionality was already there in IE, and even documented nicely on MSDN. > everything we’d want to display in that drawing might still be the same. Totally different. SVG renders vector 2D graphics, WebGL is a 3D GPU API. Try to render something slightly more complicated than rectangle of solid color, and you'll see. One example is rectangle with rounded corners: trivially simple in SVG, relatively hard on GPU. A Mandelbrot set is opposite example. > animations where the data to be shown at each step needs to be determined according to complex requirements Doesn't matter if the data is static or not. Once you know the data, you do not want to run your code at 60 Hz (or 240Hz if you're really unlucky) computing functions of time and updating things. It's almost always a good idea to use the GUI framework for playing animations. They do better with rendering and power saving.

Chris_Newton 6y ago
Just because you can doesn't mean you should. Sure, but that’s not an argument for not doing it either. As I’ve been trying to explain, I’ve had practical success building applications using the kind of software architecture I described. I don’t like to get into personal backgrounds in these discussions, because as a rule I think arguments should stand on their own merit. However, just for some perspective, I wrote my first professional GUI around three decades ago. More to the immediate point, the longest I’ve maintained and extended a single GUI built using the architectural pattern I described was over a decade, and that one was probably more complicated in its requirements than a lot of web applications you’d see today. So although it’s just one anecdotal data point, I think it’s a good demonstration that this kind of architecture can work well over an extended period. There're too many things which can go wrong with visuals. Incorrect order has smaller probability than a bug in a style somewhere which makes data invisible. For the 2nd reason you want to test that thing somehow else anyway: unit tests don't catch rendering bugs. You seem to be making some implicit assumptions about the platform here with the reference to styling. In any case, this is why I mentioned that you might want a different testing strategy for the presentation rendering layer to the code that collects the presentation data. Totally different. SVG renders vector 2D graphics, WebGL is a 3D GPU API. Try to render something slightly more complicated than rectangle of solid color, and you'll see. Sorry, I’m not sure I understand the point you’re trying to make here. 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. Obviously which native technology you’d choose would depend on what kind of visuals you were creating and how you wanted any interactions with them to work. Once you know the data, you do not want to run your code at 60 Hz (or 240Hz if you're really unlucky) computing functions of time and updating things. It's almost always a good idea to use the GUI framework for playing animations. They do better with rendering and power saving. To the best of my knowledge, the GUI framework you are describing does not exist. You might be able to extract some basic movements that could be handed off to something running at a lower level with hardware acceleration, but ultimately you still need code to define the way the layout should animate according to whatever rules your system uses, for the same reason you need to define a static layout before or after the animation that way. I’m not sure what you’re getting at with “doing better with rendering and power saving”. Can you clarify?