Hacker News Reader

Comment by mstade | Hacker News Reader

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

View on HN

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!

I have zero experience with Qt, but I'm pretty sure I can follow along with the examples anyway. (I do have experience with React, JS, and Python.)

It seems to me you're making a syntax comparison and using shorter as an argument for Proton Native, yet the example is obviously not shorter so it's factually incorrect. My suggestion is you don't use shorter as an argument. Aside from being incorrect, it's probably not very useful since a few characters here and there doesn't necessarily mean one is more or less complicated than the other – which I presume is what you're really trying to convey.

I'd probably refrain from using syntax comparison (mostly a matter of preference and familiarity anyway) and instead show why Proton Native is obviously less complex than Qt (or other options, if that matters.)

Yeah I'll reword that. My bad.

Oh, I forgot – it's probably worth considering using examples written in the same programming language as well.

Here's your Hello World in real Qt code for reference:

    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")
        }
    }

I guess just drop the comparison with Qt or other similar things. Just highlight that you can build native applications using React syntax. This alone is a good argument, no point on comparing, really. Only if you want to compare performance, etc.

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.

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?

As declarative as JSX

Menu {

  title:qsTr("File")

  MenuItem {

    text: qsTr("&Open")

    onTriggered: console.log("Open action triggered");

  }

}

Aren't all markup languages declarative by definition?

QML isn't only about markup, it also support property binding directly in the language - it's a full-fledged reactive environment.

Probably?

Why didn’t you address the claim that you were just straight up lying?

Because I forgot. I updated the page. My bad.

You can “skip” the whole “closing braces” stuff, then it’s definitely shorter.

I’m talking about this:

          </Button>
        </Window>
      </App>
    );
  }
}

Well, then they failed completely at their argument. I count 7 levels of indentation in the react code, when there are only 3 in the PyQt code.

Also, the paradigm is completely different in that react is React is déclarative whereas Qt, in this mode, is procedural. I would argue that QML would be a better comparison, and in this case I’m quite sure that qml wins.

So much for buzz words..!

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 } from 'proton-native';

  function Example() {
    return (
      e(app, {},
        e(Window, {title:"Example", size:{{w: 300, h: 300}}, menuBar={false}},
          e(Button, {stretch=false}, onClick={() => console.log('Hello)}, 'Button')
        )
      )
    );
  }

  render(<Example />);

If you really hate the brackets and parens you could certainly use a dialect of JS that doesn't have them, and you could cut it down to like half the length of the Qt example.

But this whole discussion is silly. "Shortness" in code terms has much more to do with the number and complexity of statements, not LOC or characters. The JSX in there adds "noise" and characters, but the whole purpose is to simplify understanding code and make it readable. It's not adding any fundamental length.

The Proton example is doing a bit less than the Qt example, and for me that's a much more useful definition of shorter.

This seems like as much of a non sequitur as "skipping" syntactic elements. The comparison is clearly syntactic, and thus factually incorrect – the second example is in fact longer than the first.

Sure, if you swap in another example that is in fact shorter, then it'd not longer be an incorrect statement. Maybe I am indeed being silly, but it seems getting the hook-line-sinker arguments as right as possible is a worthwhile goal, particularly when at least one of them can be objectively verified.

If by "shorter" you mean "less complex" than stop saying "shorter" and start saying "less complex" instead – just as you say they aren't the same thing. It'd mostly be redundant I guess, given "easier to read" and "easier to edit" implies "less complex", but at least it'd be harder to immediately refute.

Here's an equivalent Qt example though, shortened like yours:

    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 !

Reply on news.ycombinator.com