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 !