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
Proton Native – React Native for the desktop
241–250 of 295 posts
Re: Proton Native – React Native for the desktop
#242Sort 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.
Re: Proton Native – React Native for the desktop
#243Earlier 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.
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…
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…
Re: Proton Native – React Native for the desktop
#246Earlier 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.
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
#247This runs on libui-node, which is a binding to the libui library. https://github.com/parro-it/libui-node https://github.com/andlabs/libui
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…
Re: Proton Native – React Native for the desktop
#249>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
#250Using 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 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.