Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

71–80 of 295 posts

Re: Proton Native – React Native for the desktop

#71
post #38

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…

These are interesting points (although I don't quite follow some of your explanations). I've been trying to learn more about the history of GUI development, so I appreciate hearing about how it's been done. Here's an interesting discussion of Delphi (2013): https://news.ycombinator.com/item?id=7613543

Sure - it was quick! Here's a short overview of how Delphi's UI design works.

First, you have a visual form designer: drop a button, resize it, edit the caption, etc.

All objects like buttons, edit boxes etc are classes with properties. They live on a form, another class. The key is object streaming.

The form has instance variables: a private MyButton : TButton, for example, where TButton is the type. This list of fields is autogenerated by the IDE. However, those are created and values set not in code or managed by the IDE, but by loading from a human-readable text stream at runtime (stored as a separate file at designtime, and linked as a resource at compiletime), something like, from memory:

  Form : TForm
    Button : TButton
      Left = 100
      Top = 50
      Width = 70 // etc
      Caption = 'Hello'
      OnClick = MyClickHandlerMethod
    end;
  end;
When the form loads, the object instances and their properties are created and set on the fly. A form will self-initialise it and its owned objects from that stream: it will create a TButton instance, assign it to its own Button field, set the Left and Caption properties for the button etc. That includes hooking up methods to events, which are just properties of a method pointer type. So effectively, you have a human-readable, easily editable format that is a streamed version of a class and instance/property hierarchy, which the class can recreate itself from. That is generated by a visual editor, and of course you can edit it manually. It is a very simple and clean format; as little as possible is stored. It is also very diff-able.

Your code then is reduced to things like state changes or events - user clicks a button, you write code to do something.

UIs are visual. Writing a complex UI in code is inefficient (manually doing stuff you should not have to do) and with a long modification turnaround time - you can't preview what it looks like, so changes take a long time. The important leap was to design visual elements visually; to stream, so it is OO, diffable, and still human editable if you need to; and to load from a stream via reflection/RTTI.

Delphi did all that in 1995. C++Builder does all that too, in C++! It's beautiful compared even to Qt, and certainly compared to code like the original post, which reads like early nineties techniques to someone used to the above.

Re: Proton Native – React Native for the desktop

#73

Without having used Proton Native myself, comparing your product to React Native is not something you would want to do, honestly. React Native has insanely huge growing pains, still going, even though it's been out since 2015. The last time I checked there was still no reasonable, scalable way to do complex navigation on the platform. Most third-party components are unusable six months in due to API changes. The list…

I'm sorry but this seems overstated. There is already two highly competitive navigation libraries:

https://github.com/wix/react-native-navigation

https://reactnavigation.org

Edit: Replaced the word FUD with overstated, to not seem like I'm attacking the author personally.

Re: Proton Native – React Native for the desktop

#74

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…

>Haven't we moved past writing UIs in code about twenty years ago?

WYSIWYG editors suck for source control on teams. There's a reason why iOS development of the UI elements is still done thru code.

Re: Proton Native – React Native for the desktop

#75
post #55

React Native isn't just for iOS / Android, it also works for macOS and Windows. React Native is React Native for the desktop.

What do you mean? Can you provide some links for building OSX apps with ReactNative? Only iOS/Android are listed as targets on the documentation website (under getting started).

Re: Proton Native – React Native for the desktop

#76

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…

You always need the capability to generate UI in code, because static forms sometimes don't suffice. For example the layout and contents of your form depend on the data that is sent to it, like render a choice as checkbox if it is binary, use dropdown otherwise. I used delphi, etc., MFC was really bad forcing too much inheritance.

Ah, generating dynamic UI in Delphi. It worked surprisingly well, much better than many modern solutions do.

Re: Proton Native – React Native for the desktop

#77

Without having used Proton Native myself, comparing your product to React Native is not something you would want to do, honestly. React Native has insanely huge growing pains, still going, even though it's been out since 2015. The last time I checked there was still no reasonable, scalable way to do complex navigation on the platform. Most third-party components are unusable six months in due to API changes. The list…

It's not "write once run everywhere". It's "learn [React] once, write everywhere". Huge difference.

Re: Proton Native – React Native for the desktop

#78
post #22

Earlier quoted context omitted.

Hey. I'm the author. It's hard to find a simple example that everyone understands but can show capabilities. If you're used to Qt then you're going to like Qt better, but I mainly developed this for people who want to use React. You are obviously free to use whatever you want. But if you have any suggestions let me know!

I think the 'easier to read' is unfair considering that you didn't use QML fur the Qt example. For me QML is easier to read than JSX (and quantitatively it is less verbose)

Is QML declarative?

Re: Proton Native – React Native for the desktop

#79
post #49

Sort of tangential, but does anyone know of a good React Native app? Everything I've tried would clearly have been a better product if they'd just done native development. Like, you're sacrificing product quality for development ease.

No, you sacrifice platform specificity for better or broader functionality (given the same development capacity).

Of course, with unlimited development capacity, for each React Native app there could be a better purely native app.

Another point also often forgotten is that the user experience of a React Native app, while not as 'platformy', will be very coherent for users of multiple platforms. That can also be considered as 'better', given you are such a user.

Re: Proton Native – React Native for the desktop

#80

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…

It turns out it's really hard to get a UI Builder right with HTML/CSS. In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. For example, text getting longer pushes down content beneath it, while at the same time, the text might be 50% of it's parent node's width. The first constraint is bottom-up: the text node influences it's parent and sibling DOM node's geometry, while the second constraint is top-down.

I'm working at Pagedraw (https://pagedraw.io/) which attempts to solve this problem. We make a UI builder for web. It pretty much works like all the UI builders of the past, but translates constraints into divs, flexbox, and other web standard html/css. We don't have the benefit other UI builders in the past have had of compiling into our own layout system, because we refuse to force our users to use a js-based layout library or take extra dependencies which could increase bundle size.

It's only available for React Web for now, but we look forward to supporting React Native, and maybe even Proton Native in the future!

Lastly to matchbok's point:

> NIBs in macOS/iOS are horrible for development and code review.

We hope that this is a problem with NIBs, and not with UI builders in general. We believe that it's because there are no NIB diff/merge tools, so we're building branch/diff/merge into Pagedraw as a first-class feature.

Post reply on HN