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

Proton Native – React Native for the desktop

proton-native.js.org

Post reply on HN
Print view View original

151–160 of 295 posts

Re: Proton Native – React Native for the desktop

#151

Post by [deleted] »

kusti8 wrote: post #22
mstade wrote: post #4

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

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!

[deleted]

Re: Proton Native – React Native for the desktop

#152

Post by jcelerier »

symlinkk wrote: post #82
saagarjha wrote: post #62

Earlier quoted context omitted.

None of those are apps I particularly enjoy using or would want to use.

Facebook? Instagram? Airbnb? We're talking about some of the most popular apps in the world. What exactly is your problem with them?

they are the most popular because they are needed to access a service. But they are all a fucking pain to use.

Re: Proton Native – React Native for the desktop

#153

Post by jcelerier »

wilonth wrote: post #42
memonkey wrote: post #18

This is super cool. Are there any demonstrations comparing performance between electron and your app?

I dont think that'd be very useful. Proton is pretty much native C with just a JS runtime on top, it might even be faster than Qt. So a benchmark against Qt maybe?

Qt's event loop is much faster than node's though ; see for instance benchmarks of web servers using either : look at the scores of Cutelyst vs the score of Node servers here : https://www.techempower.com/benchmarks/#section=data-r15&hw=...

Re: Proton Native – React Native for the desktop

#154

Post by WaltPurvis »

jeena wrote: post #149
WaltPurvis wrote: post #98

>You can create a GUI using something like Qt, but the code to make it is messy and unorganized. It doesn't serve the author well to make this comparison. Saying it's less messy to manage Proton/React source code files and the associated Node/JS/etc infrastructure is an extremely dubious claim. One of the things I like best about Qt is how non-messy Qt development is. Most everything (source files, resources, etc.) l…

And if we want to compare the syntax then this would be the QML equivalent: import QtQuick 2.9 import QtQuick.Controls 1.3 ApplicationWindow { title: "Example" visible: true width: 300 height: 300 Button { text: "Button" anchors.centerIn: parent onClicked: console.log('Hello') } }

Thank you for posting an example. I was going to.

I may be biased, but to me the QML code is much cleaner and clearer than JSX.

Re: Proton Native – React Native for the desktop

#155

Post by jakelazaroff »

roberttod wrote: post #128
Klonoar wrote: post #119

Earlier quoted context omitted.

Actually, earlier today Electron 2.0.0 dropped and includes an `affinity` option, which throws everything under one process. Supposed to help with memory/resource usage.

Wow, nice! Didn't think there was much room to improve given the dependency on Chrome.

According to [the PR that introduced this to Electron](https://github.com/electron/electron/pull/11501), it just takes advantage of a similar feature in Chromium.

Re: Proton Native – React Native for the desktop

#156

Post by kingosticks »

nautilus12 wrote: post #109
inamberclad wrote: post #104

Earlier quoted context omitted.

Anything that reduces the number of running chrome instances on my poor little laptop would be nice.

Chrome is like the elephant that comes and sits on my laptop. Would be unusable without the great suspender.

How have I never heard of this!? Thank you!

Re: Proton Native – React Native for the desktop

#157

Post by int_handler »

jcelerier wrote: post #152
symlinkk wrote: post #82

Earlier quoted context omitted.

Facebook? Instagram? Airbnb? We're talking about some of the most popular apps in the world. What exactly is your problem with them?

they are the most popular because they are needed to access a service. But they are all a fucking pain to use.

Can you give some examples of popular apps that are not "a fucking pain to use?"

Re: Proton Native – React Native for the desktop

#158

Post by symlinkk »

jcelerier wrote: post #152
symlinkk wrote: post #82

Earlier quoted context omitted.

Facebook? Instagram? Airbnb? We're talking about some of the most popular apps in the world. What exactly is your problem with them?

they are the most popular because they are needed to access a service. But they are all a fucking pain to use.

How are they a "fucking pain to use"? I have never heard an average person complain about Instagram's UI. It's fine. It's good, even.

Re: Proton Native – React Native for the desktop

#159

Post by drb91 »

amelius wrote: post #131
stuffedBelly wrote: post #108

Earlier quoted context omitted.

I've used Qt developing various data-heavy apps for financial research at work and agree that making this comparison is rather inappropriate. For people who are not familiar with JSX this is not any better than the Qt syntax. This would be an alternative to Qt, but before I see a full-fledging app developed with great performance/memory metrics using this, I am not convinced enough to put it in my framework stack.

I used Qt in the early days, and always found the signal/slot model to handle events quite cumbersome. Handling events through closures (like typically done in JavaScript) is, imho, much nicer.

Perhaps ironically, Javascript is a first class qt/qml citizen these days. You’ve been able to use QML with javascript—including/mainly via closures—for a while now.

Re: Proton Native – React Native for the desktop

#160

Post by osteele »

mstade wrote: post #21
whowouldathunk wrote: post #17

Earlier quoted context omitted.

> and now we're making traditional UI dev like web It's been like that on Windows since 2006 with XAML. In fact, if you squint at typical JSX, it looks like XAML. Disclosure: I work at Microsoft.

Or MXML, which most certainly was influenced if not entirely derived from XAML. Everything old is new again!

I’ll put in a plug for my former employer’s OpenLaszlo, introduced in 2002 (preview) and 2003 (version 1.0).

OpenLaszlo was most immediately inspired by HTML and (for data binding) XSLT. I looked at Mozart for ideas on constraints, but we ended up rolling our own design — mostly because constraints were never supposed to be a feature, so they were designed and developed incrementally, in discretely releasable baby steps.

Adobe did due diligence of the company sometime around 2002-2003 too, but that deal fell through. An Adobe PM also signed up for our beta program, initially under a pseudonym, but he eventually came clean. I’ve always been curious whether Flex/MXML was related to either of those encounters.

[1] https://en.wikipedia.org/wiki/OpenLaszlo

[2] https://ssl.weepee.org/lps-4.6.1/docs/developers/program-dev...

Post reply on HN