Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

Post reply on HN
Print view View original

261–270 of 295 posts

Re: Proton Native – React Native for the desktop

#261

Post by jcelerier »

mlsarecmg wrote: post #255
westoncb wrote: post #245

Earlier quoted context omitted.

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`.

From what i've seen this is layout inflating, you have a template and you fill it imperatively. Which would be one of the oldest paradigms we have. Maybe i am getting this completely wrong, forgive me in that case, but in all examples i've seen so far it's like that. Could you please paste an example of a real, functional QT component? For instance a component that is re-used in another component, const A = ({ text }…

Here's an equivalent example for your stateful component :

  Text {
    property int count: 0
    text: count

    MouseArea {
     anchors.fill: parent
     onClicked: count++
    }
  }
if you put this in a file `C.qml` or load it as a component (http://doc.qt.io/qt-5/qml-qtqml-component.html), then you can reuse it in other components:

   Item {
     C { }
     C { count: 23 } // starts at 23
   }
For your functionally composed example, all qt objects have a `visible` property so you'd generally do :

   MyItem {
     visible: props.disabled
   }
Note that unlike React, the "default" paradigm is not functional : in QML you describe directly a dataflow graph between the properties of your objects. e.g.

  C { id: myCount }

  Rectangle {
    color: "red"
    // the width will change whenever the count increase
    width: Math.cos(myCount.count) / 2
  }
This is because the objects with which you work in QML are exactly the ones that are going to be rendered - and at a fairly low-level: they mostly translate directly to GL / D3D primitives ; there is no need for a transformative pass like with react.

Re: Proton Native – React Native for the desktop

#262

Post by mlsarecmg »

jcelerier wrote: post #261
mlsarecmg wrote: post #255

Earlier quoted context omitted.

From what i've seen this is layout inflating, you have a template and you fill it imperatively. Which would be one of the oldest paradigms we have. Maybe i am getting this completely wrong, forgive me in that case, but in all examples i've seen so far it's like that. Could you please paste an example of a real, functional QT component? For instance a component that is re-used in another component, const A = ({ text }…

Here's an equivalent example for your stateful component : Text { property int count: 0 text: count MouseArea { anchors.fill: parent onClicked: count++ } } if you put this in a file `C.qml` or load it as a component ( http://doc.qt.io/qt-5/qml-qtqml-component.html ), then you can reuse it in other components: Item { C { } C { count: 23 } // starts at 23 } For your functionally composed example, all qt objects have a…

And that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex.

There is a major difference between that and Reacts approach.

Re: Proton Native – React Native for the desktop

#263

Post by lazerwalker »

I wonder why this is called Proton Native and advertises itself as "using the same syntax as React Native" instead of just _being_ React Native.

There's already plenty of prior art for RN-compatible projects that target non-mobile devices (e.g. react-native-web, a half-dozen different AR and VR projects).

Re: Proton Native – React Native for the desktop

#264

Post by throwaway13456 »

WaltPurvis wrote: post #154
jeena wrote: post #149

Earlier quoted context omitted.

And if we want to compare the syntax then this would be the QML equivalent: 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') } }

Thank you for posting an example. I was going to. I may be biased, but to me the QML code is much cleaner and clearer than JSX.

Tell me about it. Probably going to be down voted, but this is SO true: https://twitter.com/thomasfuchs/status/810885087214637057

Re: Proton Native – React Native for the desktop

#265

Post by realusername »

prophesi wrote: post #88
Benjammer wrote: post #86

Earlier quoted context omitted.

I mean, do you realize that most of the big names on that list have a hybrid solution where they prove concepts, A/B test, and rapidly iterate-on/release new features using React Native, and then they have a native dev team for each platform that goes back and re-implements most of the core features natively?

Discord is the most impressive one to me. They definitely didn't have those resources when they wrote their iOS app[0]. The Android version is just RxJava, iirc, because of some performance issues they couldn't get around. [0] https://blog.discordapp.com/using-react-native-one-year-late...

At that time when they released, the React Native Android was probably still in a kind of beta state.

Re: Proton Native – React Native for the desktop

#266

Post by dahauns »

mlsarecmg wrote: post #262
jcelerier wrote: post #261

Earlier quoted context omitted.

Here's an equivalent example for your stateful component : Text { property int count: 0 text: count MouseArea { anchors.fill: parent onClicked: count++ } } if you put this in a file `C.qml` or load it as a component ( http://doc.qt.io/qt-5/qml-qtqml-component.html ), then you can reuse it in other components: Item { C { } C { count: 23 } // starts at 23 } For your functionally composed example, all qt objects have a…

And that is what i suspected and what i've seen in all examples i have browsed through so far. The enabled prop wasn't the point, it demonstrates functional composition. All of the above uses old, traditional layout inflating, dependency injection, imperative registration for re-using components, ...and common MVC. They are hard for applications that get even slightly complex. There is a major difference between that…

Sorry to go full "get off my lawn" here, but: How is this different from, say, simple GDI rendering or Swing? With both View is a function of state and rendering is done via idempotent function calls (WM_PAINT bzw. paint()/paintComponent()). This is the real traditional method. (BTW: The comparison to MVC doesn't really make sense, unless you add flux/redux/etc. to the equation.)

Re: Proton Native – React Native for the desktop

#267

Post by anthonybullard »

gman83 wrote: post #231
anthonybullard wrote: post #186

Earlier quoted context omitted.

You basically just described Google's Flutter framework. It's currently only mobile but I see it moving into this space at some point - or already is I guess if you count Fuschia.

https://github.com/google/flutter-desktop-embedding

Thanks! Now I have something else to play with.

Re: Proton Native – React Native for the desktop

#268

Post by dahauns »

pjmlp wrote: post #251
flukus wrote: post #243

Earlier quoted context omitted.

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

I have exactly the opposite experience regarding visual designers versus code. Changing a couple of properties in layout files is more maintainable than hundreds of code lines just to change a visual effect.

>Changing [..] hundreds of code lines just to change a visual effect.

If you need to do that, your codebase has a serious problem.

Re: Proton Native – React Native for the desktop

#269

Post by BillinghamJ »

zengid wrote: post #212
BillinghamJ wrote: post #180

Earlier quoted context omitted.

JSC is very fast, and the RN runtime is intended to be a fairly limited API, so I wouldn't necessarily say the access to the Node core packages is hugely beneficial. But it's a fair point. I'm not sure why JIT is relevant. Neither JSC nor Node do any JITting.

Node uses V8. V8 has JIT. http://thibaultlaurens.github.io/javascript/2013/04/29/how-t...

In that sense, so does JSC - even on iOS. It just does so in a controlled fashion.

Re: Proton Native – React Native for the desktop

#270

Post by pjmlp »

dahauns wrote: post #268
pjmlp wrote: post #251

Earlier quoted context omitted.

I have exactly the opposite experience regarding visual designers versus code. Changing a couple of properties in layout files is more maintainable than hundreds of code lines just to change a visual effect.

>Changing [..] hundreds of code lines just to change a visual effect. If you need to do that, your codebase has a serious problem.

Basic example, WPF storyboard animation defined in Microsoft Blend versus coding the full animation by hand in C#.
Post reply on HN