3 ms·

> to me this feels like an alternative to the JavaScript industrial complex that ticks all the right boxes The goal is admirable, but the execution and impleme

by cxr 1y ago

> to me this feels like an alternative to the JavaScript industrial complex that ticks all the right boxes The goal is admirable, but the execution and implementation is, in a word, absurd. From the XMLUI website: > XMLUI provides the glue that binds the React ecosystem into a declarative model. This negates the raison d'être of React, which is to bring the development style of immediate mode UIs to the browser—that's the fundamental driving factor behind the creation of React. Components are incidental. (Web browsers in fact do components just fine, with native support for custom elements and shadow DOM—which, along with flexbox, is a descendant of XUL, the other 90s-era technology that worked the way the XMLUI authors lament isn't around.) The purpose of React was to bring the development style of "immediate mode" UIs to the browser[1], which for better or worse inherently has a "retained" model of the UI that developers writing in-browser apps would have to deal with. So now with XMLUI, you have React trying to paper over the fundamental nature of the DOM to make it feel like it's immediate mode instead (and all the fakery involved with that), and you have XMLUI choosing to build upon React and do these retained objects instead—aligning with how the browser actually does things underneath React! The "The Backstory" section on the XMLUI landing page is worth a look and really drives the point home (along with Jon's admission in his blog post that he's never been a React developer): > It began with a relatively small effort to add web-based admin interfaces to some of the company’s products. This resulted in the core engineering team — experienced backend developers whose interactions with UI technology were limited to old-school battleship-gray Visual Basic, Delphi, or .Net/Winform — being surprised by the complexity of modern web development.¶ Calls for simplicity and easy/intuitive tool support were met mostly with blank stares from the React guys on the other side – and the designer, UX guy, and JavaScript folks on the server side of things.¶ But the /n software team refused to take no for an answer, and more than two years of work from a team of Javascript/React wizards resulted in the new semantic layer that is XMLUI. "Simplicity" this is not. Ditch React. You don't need it. You're actively working against it. (And worse, it looks you've put yourself at the whims of hired "experts" who exemplify the stereotype of the React-only programmer who never learned the fundamentals, and in this case can't even spot that you're asking them to undo React.) 1. <https://www.youtube.com/watch?v=8ZlN07IvoPI&t=2131s https://www.youtube.com/watch?v=8ZlN07IvoPI&t=2131s>

DonHopkins 1y ago
Great points! I love Nic Barker's frantic hand gestures while he explains how React works in that video. "Oh gosh, you don't want the hear this! Ha ha *grin*!": https://youtu.be/8ZlN07IvoPI?t=2654 https://youtu.be/8ZlN07IvoPI?t=2654 There was an interesting hn discussion about immediate mode a few years ago: Immediate mode GUI https://news.ycombinator.com/item?id=19744513 https://news.ycombinator.com/item?id=19744513 http://behindthepixels.io/IMGUI/ http://behindthepixels.io/IMGUI/ I wrote up some of my own opinions: https://news.ycombinator.com/item?id=19745034 https://news.ycombinator.com/item?id=19745034 >DonHopkins on April 25, 2019 | parent | context | favorite | on: Immediate Mode GUI >Immediate mode GUI's don't let you apply useful object oriented programming techniques like subclassing and prefabs (persistence) to implement and configure custom components. >Properly object oriented retained mode GUIs let you subclass components to implement custom views and event handling, and develop and publish reusable prefabs and libraries of pre-configured, stylized, specialized component. [...] >I don't know what you mean about easily composing immediate mode API's, or agree that different immediate mode APIs don't need to know about each other. They depend on a lot of behind-the-scenes implicit hidden state (practically a hidden shadow-DOM-like retained mode), so I suspect in many cases they'd walk all over each other (especially text editors dealing with input focus and keyboard navigation). Unity3D has two immediate mode APIs, one for the editor and one for runtime, and they sure don't mix. [...] >How would you write a functional extension for Unity3D's old immediate mode GUI that let you embed an ACE code editor in a Unity WebGL app? What would the API and state management even look like? How could you make it platform independent? >And even if you solved all of those problems with an immediate mode API, by its very nature it still wouldn't enable you to build GUIs in the interface editor or store them in prefabs, and you'd still have to recompile you app (which can take half an hour with Unity) every time you wanted to tweak the user interface (which is why I like programming Unity apps in JavaScript as much as possible). [...] >Embedding object oriented "retained mode" widgets with different APIs inside of each other is old hat and common for backwards compatibility. Whenever you write a new GUI toolkit, embedding widgets from the last toolkit is one of the first things you do (including recursively embedding widgets from the toolkit-before-last). >Concrete example: Microsoft lets you embed old fashioned OLE controls in Windows Forms / Presentation Foundation applications, which might be implemented in MFC themselves. And MFC is all about embedding old Win32 widgets implemented in C, and newer OLE components implemented in Visual Basic or whatever, in venerable C++ MFC user interfaces. Say what you want about how much Win32/MFC/OLE/WF/WPF sucks, and I'll wholeheartedly agree, but if you're running Windows, you probably have widgets on your screen using several different retained mode APIs embedded more than two levels deep right now. [...] >The problem with immediate mode that is you have to come up with somewhere to store and retrieve any values or state required on a case-by-case basis (including the edited value itself, and other view state like scrollbar state for text editors, etc), and that tightly couples your component function with whatever's using it, so they're not very reusable or simple. With OOP, the object has its own place to store that stuff, which is cleanly decoupled from whatever's using the component. >Then there's the issue of event handlers. Some user interface components just aren't so simple that they only have one true/false return value like buttons. Text editors can notify on value change, end edit, select, deselect, etc. And Unity's retained mode GUI supports persistent event handlers that let designers hook up events with methods of objects with parameters, without writing or recompiling any code. >And there's also a lot more to layout that you can easily express with an immediate mode GUI. Sometimes you have to measure a bunch of things and align them in various ways, like grids or flex layouts, and adapt to the screen size and other constraints (i.e. responsive design), and that's really hard to do with immediate mode, while retain mode has a rich set of layout components you can use and extend. And there's nothing like XCode's layout constraints for immediate mode. [...] >A perfect example is TextMesh Pro's text editor. It has so many different (and useful) features and parameters and callbacks and ways to configure it, and it keeps so much state in order to redisplay efficiently with the fewest number of draw calls and reformatting, that it would be extremely impractical and inefficient and unwieldy for it to use an immediate mode API. Especially with C# positional arguments instead of Pythonic or Lisp-like optional unordered keyword arguments. >When you encapsulate your immediate mode layout in a class, or write an engine that interprets (i.e. JSON) data to drive the immediate mode API, or use reflection in your wrapper functions to dispatch event callbacks and bind your widget data to your model data, you're just rolling your own informally-specified, bug-ridden, slow implementation of half of retained mode. (See Greenspun's tenth rule.)

by cxr 1y ago

DonHopkins 1y ago

Great points! I love Nic Barker's frantic hand gestures while he explains how React works in that video. "Oh gosh, you don't want the hear this! Ha ha *grin*!": https://youtu.be/8ZlN07IvoPI?t=2654 https://youtu.be/8ZlN07IvoPI?t=2654 There was an interesting hn discussion about immediate mode a few years ago: Immediate mode GUI https://news.ycombinator.com/item?id=19744513 https://news.ycombinator.com/item?id=19744513 http://behindthepixels.io/IMGUI/ http://behindthepixels.io/IMGUI/ I wrote up some of my own opinions: https://news.ycombinator.com/item?id=19745034 https://news.ycombinator.com/item?id=19745034 >DonHopkins on April 25, 2019 | parent | context | favorite | on: Immediate Mode GUI >Immediate mode GUI's don't let you apply useful object oriented programming techniques like subclassing and prefabs (persistence) to implement and configure custom components. >Properly object oriented retained mode GUIs let you subclass components to implement custom views and event handling, and develop and publish reusable prefabs and libraries of pre-configured, stylized, specialized component. [...] >I don't know what you mean about easily composing immediate mode API's, or agree that different immediate mode APIs don't need to know about each other. They depend on a lot of behind-the-scenes implicit hidden state (practically a hidden shadow-DOM-like retained mode), so I suspect in many cases they'd walk all over each other (especially text editors dealing with input focus and keyboard navigation). Unity3D has two immediate mode APIs, one for the editor and one for runtime, and they sure don't mix. [...] >How would you write a functional extension for Unity3D's old immediate mode GUI that let you embed an ACE code editor in a Unity WebGL app? What would the API and state management even look like? How could you make it platform independent? >And even if you solved all of those problems with an immediate mode API, by its very nature it still wouldn't enable you to build GUIs in the interface editor or store them in prefabs, and you'd still have to recompile you app (which can take half an hour with Unity) every time you wanted to tweak the user interface (which is why I like programming Unity apps in JavaScript as much as possible). [...] >Embedding object oriented "retained mode" widgets with different APIs inside of each other is old hat and common for backwards compatibility. Whenever you write a new GUI toolkit, embedding widgets from the last toolkit is one of the first things you do (including recursively embedding widgets from the toolkit-before-last). >Concrete example: Microsoft lets you embed old fashioned OLE controls in Windows Forms / Presentation Foundation applications, which might be implemented in MFC themselves. And MFC is all about embedding old Win32 widgets implemented in C, and newer OLE components implemented in Visual Basic or whatever, in venerable C++ MFC user interfaces. Say what you want about how much Win32/MFC/OLE/WF/WPF sucks, and I'll wholeheartedly agree, but if you're running Windows, you probably have widgets on your screen using several different retained mode APIs embedded more than two levels deep right now. [...] >The problem with immediate mode that is you have to come up with somewhere to store and retrieve any values or state required on a case-by-case basis (including the edited value itself, and other view state like scrollbar state for text editors, etc), and that tightly couples your component function with whatever's using it, so they're not very reusable or simple. With OOP, the object has its own place to store that stuff, which is cleanly decoupled from whatever's using the component. >Then there's the issue of event handlers. Some user interface components just aren't so simple that they only have one true/false return value like buttons. Text editors can notify on value change, end edit, select, deselect, etc. And Unity's retained mode GUI supports persistent event handlers that let designers hook up events with methods of objects with parameters, without writing or recompiling any code. >And there's also a lot more to layout that you can easily express with an immediate mode GUI. Sometimes you have to measure a bunch of things and align them in various ways, like grids or flex layouts, and adapt to the screen size and other constraints (i.e. responsive design), and that's really hard to do with immediate mode, while retain mode has a rich set of layout components you can use and extend. And there's nothing like XCode's layout constraints for immediate mode. [...] >A perfect example is TextMesh Pro's text editor. It has so many different (and useful) features and parameters and callbacks and ways to configure it, and it keeps so much state in order to redisplay efficiently with the fewest number of draw calls and reformatting, that it would be extremely impractical and inefficient and unwieldy for it to use an immediate mode API. Especially with C# positional arguments instead of Pythonic or Lisp-like optional unordered keyword arguments. >When you encapsulate your immediate mode layout in a class, or write an engine that interprets (i.e. JSON) data to drive the immediate mode API, or use reflection in your wrapper functions to dispatch event callbacks and bind your widget data to your model data, you're just rolling your own informally-specified, bug-ridden, slow implementation of half of retained mode. (See Greenspun's tenth rule.)