5 ms·

You will never convince me that laying out UI elements in code is better then building out an object graph in something like xml. UI views are just containers i

You will never convince me that laying out UI elements in code is better then building out an object graph in something like xml. UI views are just containers inside containers inside containers, and following complex nesting chains through code declarations is a nightmare.

mercurial 9y ago
Works fine in React.
- seanalltogether 9y ago
  That's because HTML as a framework doesn't have a proper inheritable component model. It's all runtime hacks on top of a document model that is composed of divs, spans, and inputs. IOS, Android and any sane application environment have a fully extensible layout and component model to define at compile time.
  - GeneralTspoon 9y ago
    Android and iOS don't really have this to the same level actually. Say for example on Android I wanted to include a layout but change the text color of all the items in that layout - I can't just do <include text_color="purple">. But I can do pretty much exactly that with React. This is because you can't use variables within layouts like that on Android. Sure, I could build a custom view and add a custom attribute and use that - but this is one of the areas where native isn't as nice as React Native (there are plenty of pain points with RN though).
    - pjmlp 9y ago
      You could do that with themes.
azinman2 9y ago
Until you have multiple people editing the same file across multiple branches...
- pjmlp 9y ago
  Doing layouts by code does not make it better, specially in rich UI/UX ones.
space_fountain 9y ago
I think where xml based layouts have always seemed lacking to me is re-usability. With React.js say I can make a special widget to handle calendar input. It could be built from an assortment of html elements + code. I don't see a good solution to duplicate the amount of reuse this allows in a different pariadime. Maybe I don't understand what you're saying, but it can feel almost like advocating for putting everything in one function. Following the execution through all the functions and methods is a nightmare you might say, but the point is not to follow it through all those layers in the vast majority of cases. The point is to enable a higher level of abstraction that means you don't need to look at those lower levels unless you actually have to change something there.
- seanalltogether 9y ago
  What you're describing is an extensible component model, which any sane application framework has, but HTML sadly doesn't. As a result, re-usability is a first class feature and not something that has to be hacked in. XML based UI builders allow for view tree to be composed of vendor or user custom components. <HorizontalLayout gravity="top"> <MyCustomSideBar id="menu" height="100%"/> <VerticalLayout gravity="center"> <Text>Enter a starting date for search</Text> <MyCustomCalendar id="calendar"/> </VerticalLayout> </HorizontalLayout>
  - space_fountain 9y ago
    I thought I'd replied but it looks like not. What's missing for me in these systems seem like they don't usually map the program to manage the behavior of the widget with the layout of the widget. Am I wrong? I really like that I can build a custom widget that encapsulates the entire behavior of the widget not just how it looks.
- pjmlp 9y ago
  Creating reusable components in XML layouts has always been a feature, for example XAML and Facelets.
nikki93 9y ago
How do you think code that parses XML makes the UI elements?
- zbentley 9y ago
  By that logic, should we all write assembly on the server side? Declarative, high-level structures (like UI definitions in XML or some other data-only format) really do change the paradigm. You can argue that it's not a useful change, but saying "it's all parsed by imperative logic at some point!" is specious.
  - nikki93 9y ago
    The point is that a Dart library can write a parser for XML, but if XML was the only supported format, it's hard to go in the other direction. Also if you read example Flutter code, you may notice that their UI spec DSL-like is 'declarative'. In terms of a 'change' as you point out, change is a comparison between two points, and when you compare XML to this declarative paradigm, the main difference isn't along the declarative-or-not axis (because they are similar in that regard), but things like programmability (often with 'templates' in XML) or parseability, in which case in-language DSL-likes work really well (you can write, for example, a lambda returning a UI fragment that closes over some parameters, or you can `.map(...)` a UI fragment over a `List`, ...). The change you may be pointing at is against maybe original GTK-like or Android-Java-like imperative constructs, but this discussion is about a Flutter-XML comparison. Of course, in the Flutter case, the DSL-like is actually just function calls and doesn't involve macros or a separate code generation step.
wmleler 9y ago
The killer feature of building UI elements in code is that you can build up more complex widgets from simpler ones using composition. Flutter does this everywhere, which makes it super easy to modify or customize any widget, or to reuse widgets to build a new one. You mention following complex nesting chains through code declarations. I understand what you are talking about, but the (awesome) Flutter tooling now has two views that make this far easier: the Widget Inspector, which lets you see and modify the widget tree at runtime (there was a talk on this at DartConf), and the new Outline view (just released a few days ago), which helps you play with the widget declarations in your code. See https://flutter.io/inspector/ https://flutter.io/inspector/ and https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45kc4 https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45... (for the outline view)
- pjmlp 9y ago
  > The killer feature of building UI elements in code is that you can build up more complex widgets from simpler ones using composition. You can do this in XAML since 2006, and JSP since 2004.
  - whowouldathunk 9y ago
    Not sure why you're being downvoted. XAML definitely supports complex widget composition in markup. Since the XML is basically just describing an object graph, it's a more concise way of writing the equivalent imperative code: <Button> <StackPanel> <Image/> <TextBlock/> ... <Button> <Canvas> <Ellipse/> although the Dart syntax makes this look similar, albeit a little more verbose, if you squint. Full disclosure: I work at Microsoft.
- cztomsik 9y ago
  So why nobody is writing these "more complex" widgets? Really, react is here for a while and yet there is still no "solid" UI library. Nothing with keyboard-friendly lists, data-grids and trees. And what about "controls"? How come I can't disable the whole form, including tabs and other controls, with just one attribute? Or a panel which can be detached into floating window? Thats what I would call complex (and useful) widget. BTW: This is what customers want (checktree, columncombo, dateragepicker, moneyfield with calculator, ...) https://www.tmssoftware.com/site/products.asp?t=vcl https://www.tmssoftware.com/site/products.asp?t=vcl
s73v3r_ 9y ago
Agreed. Visual things should be laid out visually. I abhor having to recompile and navigate back to the screen I was working on just to make a tweak.
- markdog12 9y ago
  Note that Flutter offers hot reloads that are often sub-second: https://flutter.io/hot-reload/ https://flutter.io/hot-reload/
Hixie 9y ago
I don't have the link handy right now but someone actually implemented an XML-ish syntax transpiler so that they can write code in XML-ish syntax and have it generate the corresponding Dart code for Flutter. So if that's what you prefer, you can totally do that.

mercurial 9y ago

Works fine in React.

seanalltogether 9y ago
That's because HTML as a framework doesn't have a proper inheritable component model. It's all runtime hacks on top of a document model that is composed of divs, spans, and inputs. IOS, Android and any sane application environment have a fully extensible layout and component model to define at compile time.
- GeneralTspoon 9y ago
  Android and iOS don't really have this to the same level actually. Say for example on Android I wanted to include a layout but change the text color of all the items in that layout - I can't just do <include text_color="purple">. But I can do pretty much exactly that with React. This is because you can't use variables within layouts like that on Android. Sure, I could build a custom view and add a custom attribute and use that - but this is one of the areas where native isn't as nice as React Native (there are plenty of pain points with RN though).
  - pjmlp 9y ago
    You could do that with themes.

azinman2 9y ago

Until you have multiple people editing the same file across multiple branches...

pjmlp 9y ago
Doing layouts by code does not make it better, specially in rich UI/UX ones.

space_fountain 9y ago

I think where xml based layouts have always seemed lacking to me is re-usability. With React.js say I can make a special widget to handle calendar input. It could be built from an assortment of html elements + code. I don't see a good solution to duplicate the amount of reuse this allows in a different pariadime. Maybe I don't understand what you're saying, but it can feel almost like advocating for putting everything in one function. Following the execution through all the functions and methods is a nightmare you might say, but the point is not to follow it through all those layers in the vast majority of cases. The point is to enable a higher level of abstraction that means you don't need to look at those lower levels unless you actually have to change something there.

seanalltogether 9y ago
What you're describing is an extensible component model, which any sane application framework has, but HTML sadly doesn't. As a result, re-usability is a first class feature and not something that has to be hacked in. XML based UI builders allow for view tree to be composed of vendor or user custom components. <HorizontalLayout gravity="top"> <MyCustomSideBar id="menu" height="100%"/> <VerticalLayout gravity="center"> <Text>Enter a starting date for search</Text> <MyCustomCalendar id="calendar"/> </VerticalLayout> </HorizontalLayout>
- space_fountain 9y ago
  I thought I'd replied but it looks like not. What's missing for me in these systems seem like they don't usually map the program to manage the behavior of the widget with the layout of the widget. Am I wrong? I really like that I can build a custom widget that encapsulates the entire behavior of the widget not just how it looks.
pjmlp 9y ago
Creating reusable components in XML layouts has always been a feature, for example XAML and Facelets.

nikki93 9y ago

How do you think code that parses XML makes the UI elements?

zbentley 9y ago
By that logic, should we all write assembly on the server side? Declarative, high-level structures (like UI definitions in XML or some other data-only format) really do change the paradigm. You can argue that it's not a useful change, but saying "it's all parsed by imperative logic at some point!" is specious.
- nikki93 9y ago
  The point is that a Dart library can write a parser for XML, but if XML was the only supported format, it's hard to go in the other direction. Also if you read example Flutter code, you may notice that their UI spec DSL-like is 'declarative'. In terms of a 'change' as you point out, change is a comparison between two points, and when you compare XML to this declarative paradigm, the main difference isn't along the declarative-or-not axis (because they are similar in that regard), but things like programmability (often with 'templates' in XML) or parseability, in which case in-language DSL-likes work really well (you can write, for example, a lambda returning a UI fragment that closes over some parameters, or you can `.map(...)` a UI fragment over a `List`, ...). The change you may be pointing at is against maybe original GTK-like or Android-Java-like imperative constructs, but this discussion is about a Flutter-XML comparison. Of course, in the Flutter case, the DSL-like is actually just function calls and doesn't involve macros or a separate code generation step.

wmleler 9y ago

The killer feature of building UI elements in code is that you can build up more complex widgets from simpler ones using composition. Flutter does this everywhere, which makes it super easy to modify or customize any widget, or to reuse widgets to build a new one. You mention following complex nesting chains through code declarations. I understand what you are talking about, but the (awesome) Flutter tooling now has two views that make this far easier: the Widget Inspector, which lets you see and modify the widget tree at runtime (there was a talk on this at DartConf), and the new Outline view (just released a few days ago), which helps you play with the widget declarations in your code. See https://flutter.io/inspector/ https://flutter.io/inspector/ and https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45kc4 https://groups.google.com/forum/#!topic/flutter-dev/lKtTQ-45... (for the outline view)

pjmlp 9y ago
> The killer feature of building UI elements in code is that you can build up more complex widgets from simpler ones using composition. You can do this in XAML since 2006, and JSP since 2004.
- whowouldathunk 9y ago
  Not sure why you're being downvoted. XAML definitely supports complex widget composition in markup. Since the XML is basically just describing an object graph, it's a more concise way of writing the equivalent imperative code: <Button> <StackPanel> <Image/> <TextBlock/> ... <Button> <Canvas> <Ellipse/> although the Dart syntax makes this look similar, albeit a little more verbose, if you squint. Full disclosure: I work at Microsoft.
cztomsik 9y ago
So why nobody is writing these "more complex" widgets? Really, react is here for a while and yet there is still no "solid" UI library. Nothing with keyboard-friendly lists, data-grids and trees. And what about "controls"? How come I can't disable the whole form, including tabs and other controls, with just one attribute? Or a panel which can be detached into floating window? Thats what I would call complex (and useful) widget. BTW: This is what customers want (checktree, columncombo, dateragepicker, moneyfield with calculator, ...) https://www.tmssoftware.com/site/products.asp?t=vcl https://www.tmssoftware.com/site/products.asp?t=vcl

s73v3r_ 9y ago

Agreed. Visual things should be laid out visually. I abhor having to recompile and navigate back to the screen I was working on just to make a tweak.

markdog12 9y ago
Note that Flutter offers hot reloads that are often sub-second: https://flutter.io/hot-reload/ https://flutter.io/hot-reload/

Hixie 9y ago

I don't have the link handy right now but someone actually implemented an XML-ish syntax transpiler so that they can write code in XML-ish syntax and have it generate the corresponding Dart code for Flutter. So if that's what you prefer, you can totally do that.