7 ms·

With 90s UI tools, you only created the initial state of the UI, that you then had to manually mutate with code. With React, you functionally describe how the

With 90s UI tools, you only created the initial state of the UI, that you then had to manually mutate with code. With React, you functionally describe how the UI looks in every possible state.

goatlover 9y ago
But you have to specify how the UI looks in code, as opposed to having RAD tools to work with your code. If you don't like 90s comparisons, how about Unity?
- realharo 9y ago
  True, you would need a drag-and-drop tool for essentially editing functions (with `if`, `forEach` objects) in order to achieve this with React (well, if you had that, you would have achieved a lot more than the old-school UI tools did). I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. Obviously, you don't need to know how to code, but many designers know at least HTML/CSS. You could have some nice basic DSL, plus a good set of layout components that hide the CSS ugliness in this area. The "code" you would need to write would be little more than JSX with some basic `if`s and `forEach`es, because you are only writing the render function. The props and state could then be manipulated inside the tool to see all the possible variations (you could even add new props/state fields if you need them, and then export this structure as TypeScript interfaces). You would have a list of components on the side, like the tool in the OP does, to help with discovery.
  - TuringTest 9y ago
    > I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. The idea is to have both. Finally this is possible thanks to reactive programming. UI designers make mockup tools that basically support that kind of rule-making with drag and drop, but that logic cannot be exported to the development environment, only the visual components. With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves in the prototyping tool, rather than having to write them down in English in a specification document for developers to re-write them in a proper language.
    - realharo 9y ago
      >With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. When doing just the look of a component as a pure function (just the render function and nothing else), that can be achieved, but as soon as you allow the design to have side-effects, that isolation is gone. Unless that's not what you meant...
      - TuringTest 9y ago
        > I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. A UI designer should be able to develop the interactions over a single component isolated. For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code. In reactive programming, the effects of each interaction don't need to be represented as side-effects, but as output of events over a functional and composable "stream". UI designers can learn to think in that programming model, which is way saner than callback hell.
        realharo 9y ago
        The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be. For example, you have an action that will ask some remote server whether the user has a permission to do something, and if it receives a positive response, it performs that action and only then updates the UI (and shows the error UI if the user doesn't have the permission). With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong. >For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code. That's fine, but I don't count that as an interaction. In React, you would just define that as a prop and pass it to the buttons and the keypress event, so that would be ok. `setState` would not be ok (unless it only stays in the mockup and is not exported).
jcelerier 9y ago
> With React, you functionally describe how the UI looks in every possible state. That's how Qt works too (and the designer is prettier imho) : https://youtu.be/Ko3YPM_tStM?t=47 https://youtu.be/Ko3YPM_tStM?t=47
- tutuca 9y ago
  Ok, then again... Qt is not "the nineties".
  - jcelerier 9y ago
    well, the ide is more recent, but Qt was released in 1993 or something like this and the core concept did not change that much since then, it has just manifested itself in a simpler language than C++ with qml / qtquick.
    - TuringTest 9y ago
      The declarative QML makes all the difference when building a user interface programmatically. You could create interfaces in Qt in the nineties, but you couldn't create mockups of the different states and integrate them without writing the supporting code for those states by hand.
  - pjmlp 9y ago
    Delphi, VB and C++ Builder surely are, and we could do a full application just by dragging components and setting properties, without a single line of code.
- realharo 9y ago
  That doesn't look like what I was talking about. He basically has an entire new component for every possible state - and his state is just a single variable. That seems very wasteful if what you want to do is just to show a bunch of extra controls if a small part of the state changes. Later when he works with bindings, that's closer, but the expression still had to be written in as code, so no win there. Plus it's classic data-binding, where it can only affect pre-defined properties (usually of primitive types), but not the entire structure of the component.
pjmlp 9y ago
If you enjoy lots of XML, you can do that in XAML as well, just playing with bindings, transitions and behaviors.
nurettin 9y ago
>> With React, you functionally describe how the UI looks in every possible state. I've made games with react and I have no idea what that means.
- realharo 9y ago
  The `render()` function describes the look of the UI. With "traditional" libraries, you either have to imperatively mutate the initial UI (e.g. `button.setText`, `layout.addWidget(new Button)`, `removeWidget(button2)`) or use data-bindings which are pretty limited and you often have to adapt your data for them. With React, you write the `render()` function that answers the question "given this state, how does the UI look?".
  - altcognito 9y ago
    With Turbo Pascal's widget system you could describe the UI with a data structure from functions (not just the initial state), and it would bind those UI structures to a database (depending on the application). I'll admit, it's not the default way people generally built applications, built, but it could be done.
  - nurettin 9y ago
    "traditional" frameworks have had the concept of "design time" since the 90s. Unless you were writing winapi using notepad and compiling with cl.exe
    - realharo 9y ago
      That has nothing to do with it. Most UIs display some kind of data to the user. When the data changes, how do you update the UI?
      - nurettin 9y ago
        For example: In Qt you can bind signals and slots in the form editor declaratively. This way when a widget signals text change, another widget's set text is automatically called.

With 90s UI tools, you only created the initial state of the UI, that you then had to manually mutate with code. With React, you functionally describe how the UI looks in every possible state.

goatlover 9y ago

But you have to specify how the UI looks in code, as opposed to having RAD tools to work with your code. If you don't like 90s comparisons, how about Unity?

realharo 9y ago
True, you would need a drag-and-drop tool for essentially editing functions (with `if`, `forEach` objects) in order to achieve this with React (well, if you had that, you would have achieved a lot more than the old-school UI tools did). I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. Obviously, you don't need to know how to code, but many designers know at least HTML/CSS. You could have some nice basic DSL, plus a good set of layout components that hide the CSS ugliness in this area. The "code" you would need to write would be little more than JSX with some basic `if`s and `forEach`es, because you are only writing the render function. The props and state could then be manipulated inside the tool to see all the possible variations (you could even add new props/state fields if you need them, and then export this structure as TypeScript interfaces). You would have a list of components on the side, like the tool in the OP does, to help with discovery.
- TuringTest 9y ago
  > I wonder if drag-and-drop tools really provide that much value compared to just editing a component with instant live-preview on the side. The idea is to have both. Finally this is possible thanks to reactive programming. UI designers make mockup tools that basically support that kind of rule-making with drag and drop, but that logic cannot be exported to the development environment, only the visual components. With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves in the prototyping tool, rather than having to write them down in English in a specification document for developers to re-write them in a proper language.
  - realharo 9y ago
    >With a tool like the one in the article, this will be possible, and UI designers will be able to create the basic user interactions by themselves I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. When doing just the look of a component as a pure function (just the render function and nothing else), that can be achieved, but as soon as you allow the design to have side-effects, that isolation is gone. Unless that's not what you meant...
    - TuringTest 9y ago
      > I'm not sure if it's a good idea to allow actual interactions (`setState`, etc.) to be handled by a tool like this. The whole idea of such a tool is that you can develop components relatively in isolation, without having to mess with the application code. A UI designer should be able to develop the interactions over a single component isolated. For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code. In reactive programming, the effects of each interaction don't need to be represented as side-effects, but as output of events over a functional and composable "stream". UI designers can learn to think in that programming model, which is way saner than callback hell.
      - realharo 9y ago
        The problem is that in order to play with the mockups and test them, you could create interactions that work with the expected happy path, but are not what the final application logic is supposed to be. For example, you have an action that will ask some remote server whether the user has a permission to do something, and if it receives a positive response, it performs that action and only then updates the UI (and shows the error UI if the user doesn't have the permission). With a tool like this, you could easily create an interaction that updates the UI immediately. It would look correct, but it would be wrong. >For example they could define a "Send form" event and tie it to the button and the "Enter" keypress all from the visual designer, just like you would do it in code. That's fine, but I don't count that as an interaction. In React, you would just define that as a prop and pass it to the buttons and the keypress event, so that would be ok. `setState` would not be ok (unless it only stays in the mockup and is not exported).

jcelerier 9y ago

> With React, you functionally describe how the UI looks in every possible state. That's how Qt works too (and the designer is prettier imho) : https://youtu.be/Ko3YPM_tStM?t=47 https://youtu.be/Ko3YPM_tStM?t=47

tutuca 9y ago
Ok, then again... Qt is not "the nineties".
- jcelerier 9y ago
  well, the ide is more recent, but Qt was released in 1993 or something like this and the core concept did not change that much since then, it has just manifested itself in a simpler language than C++ with qml / qtquick.
  - TuringTest 9y ago
    The declarative QML makes all the difference when building a user interface programmatically. You could create interfaces in Qt in the nineties, but you couldn't create mockups of the different states and integrate them without writing the supporting code for those states by hand.
- pjmlp 9y ago
  Delphi, VB and C++ Builder surely are, and we could do a full application just by dragging components and setting properties, without a single line of code.
realharo 9y ago
That doesn't look like what I was talking about. He basically has an entire new component for every possible state - and his state is just a single variable. That seems very wasteful if what you want to do is just to show a bunch of extra controls if a small part of the state changes. Later when he works with bindings, that's closer, but the expression still had to be written in as code, so no win there. Plus it's classic data-binding, where it can only affect pre-defined properties (usually of primitive types), but not the entire structure of the component.

pjmlp 9y ago

If you enjoy lots of XML, you can do that in XAML as well, just playing with bindings, transitions and behaviors.

nurettin 9y ago

>> With React, you functionally describe how the UI looks in every possible state. I've made games with react and I have no idea what that means.

realharo 9y ago
The `render()` function describes the look of the UI. With "traditional" libraries, you either have to imperatively mutate the initial UI (e.g. `button.setText`, `layout.addWidget(new Button)`, `removeWidget(button2)`) or use data-bindings which are pretty limited and you often have to adapt your data for them. With React, you write the `render()` function that answers the question "given this state, how does the UI look?".
- altcognito 9y ago
  With Turbo Pascal's widget system you could describe the UI with a data structure from functions (not just the initial state), and it would bind those UI structures to a database (depending on the application). I'll admit, it's not the default way people generally built applications, built, but it could be done.
- nurettin 9y ago
  "traditional" frameworks have had the concept of "design time" since the 90s. Unless you were writing winapi using notepad and compiling with cl.exe
  - realharo 9y ago
    That has nothing to do with it. Most UIs display some kind of data to the user. When the data changes, how do you update the UI?
    - nurettin 9y ago
      For example: In Qt you can bind signals and slots in the form editor declaratively. This way when a widget signals text change, another widget's set text is automatically called.