Hacker News Reader

Comment by zcbenz | Hacker News Reader

Hi everyone, I have written a C++ library for creating native GUI apps, it also has language bindings for Lua and JavaScript (V8).

In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.

If you want to see some screenshots and example code, check out the sample apps repo: https://github.com/yue/yue-sample-apps.

If you are wondering how this library is different from other GUI toolkits, check out the FAQ: https://github.com/yue/help#faq.

If you want to learn this library quickly, there is a detailed tutorial on using Yue with Node.js: http://libyue.com/docs/v0.2.0/js/guides/getting_started.html.

View on HN

> In the past I have written the Electron framework, which is a popular project for creating desktop apps with Chrome web engine and Node.js, while this library allows you to create native desktop apps.

Are you the same developer Roger Wang wrote about in his "Statement on the history of node-webkit project" public post?

https://groups.google.com/forum/#!topic/nwjs-general/LIrC7zH...

He claims you misrepresented the scope of your work as an intern on the node-webkit project (now named nw.js), and that you removed copyright notices from code in Electron that was derived from node-webkit.

Seems so - https://github.com/yue/yue/tree/master/docs/paid_plans

Definitely, and those same claims are made in the yue docs.

>I had been the solo developer of Electron and node-webkit (now known as NW.js) for a very long time, and today big corps are building their new apps on them. So I think it should not be hard to be confident about Yue.

https://github.com/yue/help

" Furthermore, the Intel copyright notices were removed and were replaced by GitHub copyright notice in Electron when pieces of code was copied and derivative work was made from some code of node-webkit " ....

" I wouldn't like to spend time on this, but as the previous co-maintainer of node-webkit project, keeps spreading misinformation about his internship work in the node-webkit project on his blog post" ...

Why are you misrepresenting your work..

> Uses native widgets;

> Uses windowless controls on Windows;

Don't these contradict each other? What do you mean under "windowless" and why it is important?

Btw, you can list particular advantages/comparison at least over top 3 popular C++ cross-platform UI toolkits: Qt, wxWidgets, Gtk+/Gtkmm.

Those two statements do contradict each other. According to my own quick analysis, this library uses truly native controls on Mac and GTK+, but its own windowless implementations on Windows. The Windows control implementations use uxtheme so they look more or less native, but that's not "native controls" as far as I'm concerned.

Interesting, what advantages this gives, maybe better skinning/theming support? But that doesn't seem to be the main goal of this framework...

If better skinning is the intended advantage, then it's apparently not implemented yet. I would also like to know the developer's reasoning, since using non-native controls makes it much harder to support accessibility, and this library hasn't yet addressed that.

I think it's easier to port your own drawing code from platform to platform. That's probably why Firefox and Chrome can be multi platform because their rendering code is the same.

Doing a cross platform UI library that uses native controls seems a lot of work.

Btw, wxWidgets uses native controls for each platform. You can even get to underlying native control and use platform specific APIs.

>If you are wondering how this library is different from other GUI toolkits, check out the FAQ

I see no details at all about how this library is different [or not]. While not an UI expert, I have some low-level experience with gtk, qt, appkit and uikit, vcl, immediate ui, and full manual drawing / event processing. When considering new ui framework, these questions are of high priority: how does it integrate with, or supports for, existing custom run loop; what layout system is used and which problems it elegantly solves (i18n, baselining, excessive boxing, complex constraint cases); how does it implement repeating cell rendering and caching, if any; what are base classes and how metamechanics like scrolling/resize/animation/state cues are distributed across these; how does ui state interact with controlling entity and vice versa; which non-ui mid-controllers exist to reduce or abstract out basic boilerplating. Without these details, it is yet another "throw edits, buttons and labels to fixed form and call it a day framework" at most. UI is usually hard because of internals and extension, not because it lacks fixed functionality. Web is partly so popular because it feels like everything is possible from the styled box primitive (but has its obvious downsides; like a 100mb complex c++ rendering engine that only few groups in the world can implement correctly and somewhat effectively on latest i7). Without all this and many more, there is nothing to reason about — ui is not a yesterday's demand, and regular cases are covered by virtually any mature library. Drawing static hearts with beziers is not a big deal.

Tbh, I'm highly doubting any of listed topics can be designed in just one version step, because even most decent frameworks have so many hidden flaws that require insane efforts to overcome under specific requirements.

It would be great to see how it is actually better, e.g. by comparing side-by-side examples of solving normal-to-hard ui tasks in different libraries.

Am I correct in my understanding that this does still use Electron? (And if so, what is it used for?)

It does not use electron, it is total native and does not use web engines, but it can be used in electron as a Node.js mudule.

It might be a good idea to have some C++ sample apps.

What part of electron gets used? Why would it be used? Is it to package an app?

In particular, does Yue spawn the Chromium processes and Blink?

If I understand correctly, one can build JS interfaces in Yue without it, though (either with Node.js or with its Yue-specific fork, Yode). It uses Chromium base, but not Blink, right?

Reply on news.ycombinator.com