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

What dif­fer­enti­ates front-end frame­works

themer.dev

Post reply on HN
Print view View original

251–256 of 256 posts

Re: What dif­fer­enti­ates front-end frame­works

#251

Post by rubymamis »

onsclom wrote: post #249
rubymamis wrote: post #248

Earlier quoted context omitted.

BTW, someone created Flexbox for QML: https://github.com/tripolskypetr/qml-flexbox

It's really awesome someone did this. If you just want the expressiveness of flexbox and don't care about performance, this is perfect! However, wouldn't the performance for this be very optimal? Check out the `Flex.qml` code[1]. It's all very unoptimized and dynamic QMLScript. None of the function arguments are typed. There is no way the QML compiler is turning any of this into efficient, statically typed C++ code.…

Nope, from what I can tell the entire backend is a Qt C++ binding[1] for the C++ Yoga library[2][3]. You can see the Qt C++ backend is exposed to QML here[4]. So it's C++ all the way down just in a comfortable setting.

[1] https://github.com/tripolskypetr/qml-flexbox/blob/master/obj...

[2] https://github.com/tripolskypetr/qml-flexbox/tree/master/thi...

[3] https://github.com/facebook/yoga

[4] https://github.com/tripolskypetr/qml-flexbox/blob/677a1287df...

P.S. I'll answer your other reply very soon. I'm releasing a new version of my app so it takes its toll on me.

Re: What dif­fer­enti­ates front-end frame­works

#252

Post by rubymamis »

onsclom wrote: post #243
rubymamis wrote: post #236

Earlier quoted context omitted.

> Though slight nitpicks, these breaking changes were probably entirely NextJS changes and not React changes. Yes, you're right that's probably the case. > I read the article and I'm skeptical that most QML code is compiled to C++. Well, all the core Qt Quick components are written in C++[1]. Other components either reuses them in C++ or QML. So they're mostly C++ underneath. > QML doesn't even allow you to type your…

> Well, all the core Qt Quick components are written in C++[1]. Other components either reuses them in C++ or QML. So they're mostly C++ underneath. Gotcha, this makes sense. To be fair, browsers write HTML elements like and using C++ too. Though I admit the core Qt Quick components cover more functionality use cases than HTML elements. > And JS list? There's this[2]. Ooh whoops, good catch on the typed lists. I seen…

> TypeScript ensures this code will be totally typesafe at runtime:

That's cool. I think QML is going in that direction.

"In addition, Qt 5.14 introduced the possibility to provide type information in function signatures, similar to how it is done in TypeScript:"[1] `function add(a: int, b: int) : int { return a + b }`

> I'm still a bit skeptical about all that QMLScript getting compiled to native code

"Additionally, in Qt 6.3, there will be another compiler: The QML type compiler, or qmltc. With the QML type compiler, you will be able to compile your object structure to C++. Each QML component becomes a C++ class this way. Instantiating those classes from C++ will be much faster than the usual detour through QQmlComponent. qmltc, like qmlsc, is built on the availability of complete type information at compile time. In contrast to qmlsc, though, qmltc has no graceful fallback in case the type information is lacking. In order to use qmltc, you will have to provide all the information it requires. qmltc will be available with all versions of Qt." [1]

I read your entire comment. It takes a lot of effort to respond here. You make some interesting points. I do think each should find the right tool for his job. I found QML very appealing. And I think it keeps improving and I hope they integrate some of the cool security features of typed languages etc. I might not be the best person to respond technically to your arguments, tho. In any case, I'd love to keep in touch. I saw you on Twitter so that's cool. I'm also (more available) on Discord. My username is "rubymamis" so feel free to send a DM (:

[1] https://www.qt.io/blog/the-new-qtquick-compiler-technology

Re: What dif­fer­enti­ates front-end frame­works

#253

Post by onsclom »

rubymamis wrote: post #251
onsclom wrote: post #249

Earlier quoted context omitted.

It's really awesome someone did this. If you just want the expressiveness of flexbox and don't care about performance, this is perfect! However, wouldn't the performance for this be very optimal? Check out the `Flex.qml` code[1]. It's all very unoptimized and dynamic QMLScript. None of the function arguments are typed. There is no way the QML compiler is turning any of this into efficient, statically typed C++ code.…

Nope, from what I can tell the entire backend is a Qt C++ binding[1] for the C++ Yoga library[2][3]. You can see the Qt C++ backend is exposed to QML here[4]. So it's C++ all the way down just in a comfortable setting. [1] https://github.com/tripolskypetr/qml-flexbox/blob/master/obj... [2] https://github.com/tripolskypetr/qml-flexbox/tree/master/thi... [3] https://github.com/facebook/yoga [4] https://github.com/tripo…

Whoops, I should have been more clear. When I said "It's all very unoptimized and dynamic QMLScript" I meant just the file `Flex.qml`. I'm sure the Qt C++ bindings are fast and great, but check out the `updatePositions` function in `Flex.qml`[1]. This unoptimized and dynamic QMLScript gets ran every time a flex item's width, height, or children change. I imagine if that QMLScript was given types then at least that QMLScript compiler could generate some C++ for it, but right now there are no types so I doubt there is any efficient C++ generated for this script.

On the web it's common to animate the size of flexbox items with CSS animations. These animations are entirely implemented by the browser, and I imagine much of it is even GPU accelerated. No JavaScript is executed for this on the browser. But with this library, you would be running the `Flex.qml`'s `updatePositions` function every frame of the animation. Isn't that wasteful when compared to how flexbox works in the browser? It seems like a browser would be much faster at computing layout for flexbox elements than this, especially when that flexbox's size is being animated with CSS animations.

[1] https://github.com/tripolskypetr/qml-flexbox/blob/master/qml...

Re: What dif­fer­enti­ates front-end frame­works

#254

Post by dezmou »

Capricorn2481 wrote: post #247
dezmou wrote: post #222

Earlier quoted context omitted.

"If you pass a prop to a child component, it will update whenever you change state" Well if you update a state, every children of your component is updated as well regardless of if they have a prop passed. I know there are way to make react trully reactive like Valtio using proxy or maybe Zustand, but my point is that useState or useContext is not "reactive" at all, you must call a function to rerender the components…

If by "Updated" you mean they are looked at in the virtual DOM to determine if they have to update, then yes. But children aren't repainted onto the DOM just because their parent is. This still is Reactive

By Updated I mean that more than comparing virtual DOM to real DOM. - If you have a useEffect without dependendy, it trigger it. - If you have some map, filter, sort, any lambda in your template, it will be executed again. And that is true for your component and every children recursively.

Re: What dif­fer­enti­ates front-end frame­works

#255

Post by rubymamis »

onsclom wrote: post #253
rubymamis wrote: post #251

Earlier quoted context omitted.

Nope, from what I can tell the entire backend is a Qt C++ binding[1] for the C++ Yoga library[2][3]. You can see the Qt C++ backend is exposed to QML here[4]. So it's C++ all the way down just in a comfortable setting. [1] https://github.com/tripolskypetr/qml-flexbox/blob/master/obj... [2] https://github.com/tripolskypetr/qml-flexbox/tree/master/thi... [3] https://github.com/facebook/yoga [4] https://github.com/tripo…

Whoops, I should have been more clear. When I said "It's all very unoptimized and dynamic QMLScript" I meant just the file `Flex.qml`. I'm sure the Qt C++ bindings are fast and great, but check out the `updatePositions` function in `Flex.qml`[1]. This unoptimized and dynamic QMLScript gets ran every time a flex item's width, height, or children change. I imagine if that QMLScript was given types then at least that QM…

Hmm I get your point. I wonder if the the QML type compiler (qmltc) could still compile to C++. It would seem like dark magic if it did tho, because as you said it hasn't given the types. I wonder if it's possible to put this code in the backend in C++, what do you think?

Re: What dif­fer­enti­ates front-end frame­works

#256

Post by onsclom »

rubymamis wrote: post #255
onsclom wrote: post #253

Earlier quoted context omitted.

Whoops, I should have been more clear. When I said "It's all very unoptimized and dynamic QMLScript" I meant just the file `Flex.qml`. I'm sure the Qt C++ bindings are fast and great, but check out the `updatePositions` function in `Flex.qml`[1]. This unoptimized and dynamic QMLScript gets ran every time a flex item's width, height, or children change. I imagine if that QMLScript was given types then at least that QM…

Hmm I get your point. I wonder if the the QML type compiler (qmltc) could still compile to C++. It would seem like dark magic if it did tho, because as you said it hasn't given the types. I wonder if it's possible to put this code in the backend in C++, what do you think?

> I wonder if it's possible to put this code in the backend in C++, what do you think?

Yeahh, looks like you'd have to connect to all these signals and be able to access sizing/position from C++. Not sure how possible this is, you probably know better than me.

Post reply on HN