Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

181–190 of 295 posts

Re: Proton Native – React Native for the desktop

#181

It's pretty fascinating how tech tends to spread and influence. We spent years trying to make the web more like traditional UI dev, and now we're making traditional UI dev like web. I would never have believed this if you'd told me about it in 2010.

ColdFusion, Flex, XAML, JavaFX

Re: Proton Native – React Native for the desktop

#182
Am I the only one who think that this:

    class Example extends Component {
      render() {
        return (
          
            
               console.log('Hello')}>
                Button
              
            
          
        );
      }
    }

    render();
is using too many artificial parsing layers ?

1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window.

Why not just

    let app = Application({params});
    let window = app.window({url:"content.xml",
                             type: "frame" });

Re: Proton Native – React Native for the desktop

#183
post #22
post #4

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

The tech sounds fantastic but as you’re learning in this thread you should never criticize the competition. Framing your work as easier to read/write (or whatever) than Qt does nothing but pull yourself and the project into the mud. Just delete all references to Qt on the homepage and focus on what your project does and does well. You’ll find that approach does a much better job of communicating what you actually want to get across to people.

Re: Proton Native – React Native for the desktop

#184
post #26

Is this created and maintained by a single developer (kusti8?), community, or corporation?

I'm one highschooler with not enough time. Ideally this would come from someone who can maintain this full-time like a corporation, but so far no one has done it.

Very nice work man! Keep at it! =)

Re: Proton Native – React Native for the desktop

#185

It's pretty fascinating how tech tends to spread and influence. We spent years trying to make the web more like traditional UI dev, and now we're making traditional UI dev like web. I would never have believed this if you'd told me about it in 2010.

> and now we're making traditional UI dev like web It's been like that on Windows since 2006 with XAML. In fact, if you squint at typical JSX, it looks like XAML. Disclosure: I work at Microsoft.

If only MSFT hadn't burned all their hacker bridges with anti-trust behavior in the 90s.

Re: Proton Native – React Native for the desktop

#186
post #25

Earlier quoted context omitted.

Writing React makes me feel more like building for web using native paradigms.

And yet there's not much that's like native GUI paradigms in React. At least when concerning all major GUI libs. It's more like a markup driving an immediate-mode graphics API.

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.

Re: Proton Native – React Native for the desktop

#187

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

70MB is too much for mainly native application.

For the comparison, IDE sketch (editor with syntax highlighting) from Sciter (HTML/CSS/script engine) SDK (https://github.com/c-smile/sciter-sdk/tree/master/samples/id...) takes 43 MB.

Screenshot: https://sciter.com/wp-content/uploads/2018/05/idea-ide.png

Re: Proton Native – React Native for the desktop

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

Something I would be curious about is what happens when you try to change the view. Like what if you want to make a counter. For me that was always the best thing about react.

Re: Proton Native – React Native for the desktop

#189

Am I the only one who think that this: class Example extends Component { render() { return ( console.log('Hello')}> Button ); } } render( ); is using too many artificial parsing layers ? 1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window. Why not just let app = Application({params}); let window = app.window({url:"content.xml", type: "frame" })…

Looks nice for a short example, but later you'd also need some stuff like:

    let button = new Button("Click me");
    window.attach(button, {position: 'center'});
To me, imperative widget creation gets tedious and hard to read pretty fast. I'm not a fan of the many parsing layers involved in the JS example either, but I really appreciate the declarativity they enable.

Re: Proton Native – React Native for the desktop

#190

Am I the only one who think that this: class Example extends Component { render() { return ( console.log('Hello')}> Button ); } } render( ); is using too many artificial parsing layers ? 1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window. Why not just let app = Application({params}); let window = app.window({url:"content.xml", type: "frame" })…

JSX is JS. While there's technically 'parsing' involved, it's fundamentally just syntactic sugar:

    import { createElement as e } from 'whatever'

    return e(App, {}, [
      e(Window, { title: 'Example', size: { w: 300, h: 300 }, menuBar: false }, [
        e(Button, { stretchy: false, onClick: () => console.log('Hello') }, [
          'Button'
        ])
      ])
    ])
Post reply on HN