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!
Isn't it running on Node?
Proton Native – React Native for the desktop
141–150 of 295 posts
Re: Proton Native – React Native for the desktop
#142Earlier quoted context omitted.
I've used Qt developing various data-heavy apps for financial research at work and agree that making this comparison is rather inappropriate. For people who are not familiar with JSX this is not any better than the Qt syntax. This would be an alternative to Qt, but before I see a full-fledging app developed with great performance/memory metrics using this, I am not convinced enough to put it in my framework stack.
I used Qt in the early days, and always found the signal/slot model to handle events quite cumbersome. Handling events through closures (like typically done in JavaScript) is, imho, much nicer.
You have been able to bind closures to events in Qt for... dunnno... 6 years maybe ?
Re: Proton Native – React Native for the desktop
#143Earlier quoted context omitted.
Or MXML, which most certainly was influenced if not entirely derived from XAML. Everything old is new again!
Yeah the Silverlight vs Flex days of 2006ish really inspired this quite a bit. Today Xamarin does all this pretty well cross platform, desktop and mobile for UWP/Mac and iOS/Android.
Re: Proton Native – React Native for the desktop
#144Earlier quoted context omitted.
Anything that reduces the number of running chrome instances on my poor little laptop would be nice.
I tried out the example "Notepad" app in the git repo and it ran at 70MB. Is that good? I don't have any metrics about how much memory a hello world Electron app uses.
Re: Proton Native – React Native for the desktop
#145Earlier quoted context omitted.
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?
Menu {
title:qsTr("File")
MenuItem {
text: qsTr("&Open")
onTriggered: console.log("Open action triggered");
}
}Re: Proton Native – React Native for the desktop
#146Re: Proton Native – React Native for the desktop
#147> It is not only shorter, it is also easier to read and to edit, and can easily utilize the power of the state. Easier to read and edit is obviously subjective, but shorter is not and that front page is just straight up lying. The Qt example is most definitely shorter. What am I missing?
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!
import QtQuick 2.7
import QtQuick.Controls 2.2
ApplicationWindow
{
title: "Example"
Button {
height: 300
width: 300
x: 50
y: 50 // not represented in the react code for some reason
onClicked: console.log("Hello")
}
}Re: Proton Native – React Native for the desktop
#148Re: Proton Native – React Native for the desktop
#149>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…
import QtQuick 2.9
import QtQuick.Controls 1.3
ApplicationWindow {
title: "Example"
visible: true
width: 300
height: 300
Button {
text: "Button"
anchors.centerIn: parent
onClicked: console.log('Hello')
}
}Re: Proton Native – React Native for the desktop
#150Earlier quoted context omitted.
No, you can’t “skip” them. If you skip them, the code is broken. The lines may well be noise, and arguably that’s even worse, but you certainly can’t skip them – counting or otherwise.
You can skip them if you want by various means, and you can also not put them on their own line. You don't even have to use JSX, which is what is taking up most of the space. A shortened, yet still totally readable (if you are used to not using JSX) version that is shorter in LOC than the Qt example might look like: import React, { Component, createElement as e } from 'react'; import { render, Window, App, Button } f…
import QtQuick 2.7
import QtQuick.Controls 2.2
ApplicationWindow {
title: "Example"
Button { height: 300; width: 300; onClicked: console.log("Hello") }
}
look ma, 6 LOC !