Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

251–260 of 295 posts

Re: Proton Native – React Native for the desktop

#251
post #243
post #224

Earlier quoted context omitted.

Because of productivity, and UI/UX workflows while prototyping. Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? It is not good to generalize, but most coders I have meant without any sense of UI design never used graphical tooling for doing UIs.

> Why should I spend 30 coding something away that is doable in a few seconds with a couple of mouse clicks? Because maintainability is more important than instant gratification. If you can do both then great, but IME visual designers are a maintenance headache.

I have exactly the opposite experience regarding visual designers versus code.

Changing a couple of properties in layout files is more maintainable than hundreds of code lines just to change a visual effect.

Re: Proton Native – React Native for the desktop

#252
post #248

Earlier quoted context omitted.

Doesn't QT cost $459 per month per developer[1] for use in commercial applications? That price is prohibitive for anyone but established enterprise. [1] https://www1.qt.io/buy-product/

No. In many cases, you can use Qt under the LGPL and thus for free. This is especially true when you use it via Python bindings such as PyQt.

That's good to know. Thanks for the info.

Re: Proton Native – React Native for the desktop

#253
post #248

Earlier quoted context omitted.

Doesn't QT cost $459 per month per developer[1] for use in commercial applications? That price is prohibitive for anyone but established enterprise. [1] https://www1.qt.io/buy-product/

No. In many cases, you can use Qt under the LGPL and thus for free. This is especially true when you use it via Python bindings such as PyQt.

PyQT isn't LGPL though, it only offers GPLv3 or Commercial licensing.

Re: Proton Native – React Native for the desktop

#254

Earlier quoted context omitted.

No. In many cases, you can use Qt under the LGPL and thus for free. This is especially true when you use it via Python bindings such as PyQt.

PyQT isn't LGPL though, it only offers GPLv3 or Commercial licensing.

That's true. So using PyQt you likely need a commercial license for PyQt and not Qt. Alternatively, you can use PySide2 instead of PyQt to avoid this restriction, but it's less mature.

Re: Proton Native – React Native for the desktop

#255

Earlier quoted context omitted.

This seems like a misunderstanding of what React is. JSX is not a template. It is a DSL or superset with direct access to the presentational layer. It gets "transpiled" away in the building phase. React components are not imperative but declarative, they reflect state instead of inflating layout. Layout inflating (QT, Android), MVC/MVVM (XAML), and views being functions of state (React) are paradigm changes. View = f…

There is no reason you couldn't use the example QML above in place of JSX and still receive the same benefits. It would still be `View = fn(state)`; it's just a different syntax for specifying `fn`.

From what i've seen this is layout inflating, you have a template and you fill it imperatively. Which would be one of the oldest paradigms we have. Maybe i am getting this completely wrong, forgive me in that case, but in all examples i've seen so far it's like that.

Could you please paste an example of a real, functional QT component? For instance a component that is re-used in another component,

    const A = ({ text }) => {text}
    const B = () => 

     // -> hello
as well as functional composition (higher-order-components):

    const canBeDisabled = Component => props => props.disabled ? null : 
    const ComposedB = canBeDisabled(B)

     // -> hello
     // -> null
an example for statefull components would also be nice:

    class C extends Component {
        state = { count: 0 }
        up = () => this.setState(state => ({ count: state.count + 1 })
        render() {
            return {this.state.count}
        }
    }

     // -> 0, clicks count up reactively

Re: Proton Native – React Native for the desktop

#256

Earlier quoted context omitted.

I recently experienced Visual Studio 6 in a Win2k VM, and it was sickening how fast it was compared to modern tools. Same with Office2k apps, and all using an order of magnitude less memory. There has to be a better way than the path we are on, software-wise.

Hence why so many enterprise installs are still proudly running Office 2010. I do wonder why nobody takes a stab at creating a bonafide Excel clone that looks modern and runs fast (and, no, LibreOffice isn’t good enough).

LibreOffice was written using an overachitected component system; it is very slow. Just writing something without the layers of abstraction would be refreshing.

Re: Proton Native – React Native for the desktop

#257

Earlier quoted context omitted.

On Windows 10, Notepad uses 2 MB and Wordpad 12 MB. I'm quite surprised that the latter can fit a full, Ribbon equiped word processor in so little memory. Not that I'd be concerned about a few tens of MB nowadays but on the whole we're consuming computing resources at the same rate faster hardware is put out (Gates' law). I have a Pentium 3 running NT4 sitting on the same desk and it is faster at many tasks than my i…

I recently experienced Visual Studio 6 in a Win2k VM, and it was sickening how fast it was compared to modern tools. Same with Office2k apps, and all using an order of magnitude less memory. There has to be a better way than the path we are on, software-wise.

Well, we started prioritizing code cleanliness over everything else and throwing away good tooling because it was old. Blocking performance optimizations because they're "unmaintainable," or just not thinking about resource usage, is going to result in bad software.

I'd bet Slack, for example, has all sorts of abstraction and indirection layers in it, making it impossible to figure out the fastest way to do the job.

Re: Proton Native – React Native for the desktop

#258

Earlier quoted context omitted.

I swapped when the new FF came out. Was sick of chrome using 3–4gb of memory and bringing my computer to a grinding vault. 3 times the number of tabs in Firefox and I have 0 issues. I recommend FF now.

I used Firefox for a couple of years for the same reason, but the new release broke my keyboard shortcuts and VimFx plugin. Now I use opera and cVim, it's even better. Much faster to start than chrome, shortcuts work, syncing works, vim works, developer tools are great, no bloated background services and square tabs!

I faced the same problem with new FF. Although not as great as Vim-Fx, saka-key does solve the problem to some extent.

Re: Proton Native – React Native for the desktop

#259
post #2

This runs on libui-node, which is a binding to the libui library. https://github.com/parro-it/libui-node https://github.com/andlabs/libui

Shameless plug to let you all know that there's the python bindings for libui at https://github.com/joaoventura/pylibui/ if someone wants to help on those..

Re: Proton Native – React Native for the desktop

#260

Earlier quoted context omitted.

I recently experienced Visual Studio 6 in a Win2k VM, and it was sickening how fast it was compared to modern tools. Same with Office2k apps, and all using an order of magnitude less memory. There has to be a better way than the path we are on, software-wise.

Hence why so many enterprise installs are still proudly running Office 2010. I do wonder why nobody takes a stab at creating a bonafide Excel clone that looks modern and runs fast (and, no, LibreOffice isn’t good enough).

Because writing an Excel clone which is "good enough" is really, really hard work, takes a really long time and you probably won't get away with "Let's do 80% in version 1 and then optimize" - People expect Excel. Not Excel lite. Especially if they have to pay for it.
Post reply on HN