Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

241–250 of 295 posts

Re: Proton Native – React Native for the desktop

#241
post #216
post #197

Earlier quoted context omitted.

Nice to see this project is still alive, it shows a lot of promise but appeared abandoned for a while. Have they got the data grid API's working yet?

I don't think so? https://github.com/parro-it/libui-node/issues/63

I was actually thinking of the table view: https://github.com/andlabs/libui/issues/310 . Doesn't seem to be done yet and is critical for a lot applications.

Re: Proton Native – React Native for the desktop

#242
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.

Even development ease is somewhat illusionary. To be effective you will still need to know the details of iOS/Android and sometimes just write native code. At the end, why not just go full-native instead of writing and rewriting bridges.

Re: Proton Native – React Native for the desktop

#243
post #224
post #199

Earlier quoted context omitted.

Form designers produce their own issues like compatibility between versions, poor interactions with source control and poor responsiveness. I don't see an issue with creating UI's in code, with a decent API like Qt and Gtk provide it's quite straightforward. Why should UI code be treated differently to other code?

Because of productivity, and UI/UX workflows while prototyping. Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? It is not good to generalize, but most coders I have meant without any sense of UI design never used graphical tooling for doing UIs.

> Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks?

Because maintainability is more important than instant gratification. If you can do both then great, but IME visual designers are a maintenance headache.

Re: Proton Native – React Native for the desktop

#244

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

This seems like a misunderstanding of what React is. JSX is not a template. It is a DSL or superset with direct access to the presentational layer. It gets "transpiled" away in the building phase. React components are not imperative but declarative, they reflect state instead of inflating layout. Layout inflating (QT, Android), MVC/MVVM (XAML), and views being functions of state (React) are paradigm changes.

View = fn(state) solves longstanding issues with all the previous approaches, and of course it decreases their complexity. It is also the first approach that's breaching the platform barrier successfully while maintaining the high-level. You can write React for countless of targets, being able to re-use and apply the eco-system.

Re: Proton Native – React Native for the desktop

#245

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

This seems like a misunderstanding of what React is. JSX is not a template. It is a DSL or superset with direct access to the presentational layer. It gets "transpiled" away in the building phase. React components are not imperative but declarative, they reflect state instead of inflating layout. Layout inflating (QT, Android), MVC/MVVM (XAML), and views being functions of state (React) are paradigm changes. View = f…

There is no reason you couldn't use the example QML above in place of JSX and still receive the same benefits. It would still be `View = fn(state)`; it's just a different syntax for specifying `fn`.

Re: Proton Native – React Native for the desktop

#246

Earlier quoted context omitted.

I'm not sure what you're asking, but the answer to what I think you're asking is that views change by way of bindings. They can also be changed directly/procedurally, but I'll give an example of a binding. (Think of an Item as a visual component, which can either be referred to by an id or, as I've done here, referred to by its children as "parent".) Item { property int count: 1 Button { height: 30; width: 80 onClick…

Can you have higher order components? In react this is a function that returns a component, often taking another component as a parameter. What's nice about react is that the JSX syntax is just sugar that converts to function calls.

> Can you have higher order components? In react this is a function that returns a component, often taking another component as a parameter.

The standard way to do this in QML is using the Loader object: http://doc.qt.io/qt-5/qml-qtqml-component.html

You can also go full-eval of course: http://doc.qt.io/qt-5/qtqml-javascript-dynamicobjectcreation...

Re: Proton Native – React Native for the desktop

#247
post #2

This runs on libui-node, which is a binding to the libui library. https://github.com/parro-it/libui-node https://github.com/andlabs/libui

That's exactly what I thought looking at the screenshots and having to look it up from the source is pretty disappointing. Libui is great work and since it seems to be the biggest part of this project, it should be mentioned.

Re: Proton Native – React Native for the desktop

#248

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

Doesn't QT cost $459 per month per developer[1] for use in commercial applications? That price is prohibitive for anyone but established enterprise.

[1] https://www1.qt.io/buy-product/

Re: Proton Native – React Native for the desktop

#249
post #248

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

Doesn't QT cost $459 per month per developer[1] for use in commercial applications? That price is prohibitive for anyone but established enterprise. [1] https://www1.qt.io/buy-product/

No. In many cases, you can use Qt under the LGPL and thus for free. This is especially true when you use it via Python bindings such as PyQt.

Re: Proton Native – React Native for the desktop

#250
post #204

Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!

I've never heard of JavaScriptCore. I assumed that ReactNative transpiled JS to the native languages/APIs and that this would too.

The only part that's translated to native APIs is the rendering itself. Instead of rendering a WebView with an HTML , it renders a UIButton from the native UIKit.

The app logic is still in Javascript, never compiled to another language.

IMHO this is perfectly fine. I have a fairly large app in react-native, and most users that have tried it are fine with its performance. Scrolling in lists and maps, being native components, is as snappy as in a real native app. I'm only having performance issues in page transitions, and I think I can fix that with a bit more work.

Post reply on HN