Proton Native – React Native for the desktop • Hacker News Board

Re: Proton Native – React Native for the desktop

#191

Post by c-smile » Thu, May 03, 2018, 1:11 AM UTC

crooked-v wrote: post #190

c-smile wrote: post #182

Am I the only one who think that this: class Example extends Component { render() { return ( console.log('Hello')}> Button ); } } render( ); is using too many artificial parsing layers ? 1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window. Why not just let app = Application({params}); let window = app.window({url:"content.xml", type: "frame" })…

JSX is JS. While there's technically 'parsing' involved, it's fundamentally just syntactic sugar: import { createElement as e } from 'whatever' return e(App, {}, [ e(Window, { title: 'Example', size: { w: 300, h: 300 }, menuBar: false }, [ e(Button, { stretchy: false, onClick: () => console.log('Hello') }, [ 'Button' ]) ]) ])

"JSX is JS"

It is not, https://facebook.github.io/jsx/

It is handled by transpiler - one more parsing layer in loading sequence of your application.

Re: Proton Native – React Native for the desktop

#192

Post by rohan1024 » Thu, May 03, 2018, 1:15 AM UTC

aurailious wrote: post #107

rhinoceraptor wrote: post #103

Earlier quoted context omitted.

Based on the page source, it looks like it's docsify: https://docsify.js.org

Oh weird, I was just looking at docsify this morning, that's why it must be so familiar to me.

Synchronicity!

Re: Proton Native – React Native for the desktop

#193

Post by c-smile » Thu, May 03, 2018, 1:15 AM UTC

uryga wrote: post #189

c-smile wrote: post #182

Am I the only one who think that this: class Example extends Component { render() { return ( console.log('Hello')}> Button ); } } render( ); is using too many artificial parsing layers ? 1) Like run JS, then there 2) parse JSX that will build virtual DOM, then 3) interpret that vDOM to 4) create physical window. Why not just let app = Application({params}); let window = app.window({url:"content.xml", type: "frame" })…

Looks nice for a short example, but later you'd also need some stuff like: let button = new Button("Click me"); window.attach(button, {position: 'center'}); To me, imperative widget creation gets tedious and hard to read pretty fast. I'm not a fan of the many parsing layers involved in the JS example either, but I really appreciate the declarativity they enable.

I am not saying that you don't need markup at all.

Window content can still use markup. But it is not clear why do you need it for defining Application and Window abstractions.

In browsers DOM element is a subject of style applicability and events handling. But why do you need DOM nodes for application and window ?

Re: Proton Native – React Native for the desktop

#194

Post by always_good » Thu, May 03, 2018, 1:24 AM UTC

c-smile wrote: post #193

uryga wrote: post #189

Earlier quoted context omitted.

Looks nice for a short example, but later you'd also need some stuff like: let button = new Button("Click me"); window.attach(button, {position: 'center'}); To me, imperative widget creation gets tedious and hard to read pretty fast. I'm not a fan of the many parsing layers involved in the JS example either, but I really appreciate the declarativity they enable.

I am not saying that you don't need markup at all. Window content can still use markup. But it is not clear why do you need it for defining Application and Window abstractions. In browsers DOM element is a subject of style applicability and events handling. But why do you need DOM nodes for application and window ?

What does your trivial wrapper actually improve though?

    window = (...children) => {...children}

Over the years I've learned that some boilerplate isn't bad. In fact it means App and Window are implemented in the same abstraction that I'm using.

Re: Proton Native – React Native for the desktop

#195

Post by WaltPurvis » Thu, May 03, 2018, 1:26 AM UTC

space_fountain wrote: post #188

WaltPurvis wrote: post #154

Earlier quoted context omitted.

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.

Something I would be curious about is what happens when you try to change the view. Like what if you want to make a counter. For me that was always the best thing about react.

I'm not sure what you're asking, but the answer to what I think you're asking is that views change by way of bindings. They can also be changed directly/procedurally, but I'll give an example of a binding.

(Think of an Item as a visual component, which can either be referred to by an id or, as I've done here, referred to by its children as "parent".)

    Item {
        property int count: 1

        Button {
            height: 30; width: 80
            onClicked: parent.count++
        }

        Text {
            height: 20; width: 30
            text: parent.count
        }
    }

The text will update every time you click the button.

Re: Proton Native – React Native for the desktop

#196

Post by AHTERIX5000 » Thu, May 03, 2018, 1:28 AM UTC

richard_todd wrote: post #168

sjmulder wrote: post #165

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.

It's ridiculous. I can launch a VM running Linux + X11 desktop environment from scratch faster than one of the most popular Electron apps launches & connects. Probably would run few apps in the VM well too with the same amount of memory.

Anything that could fix the current situation even a little bit like this project is much appreciated imho.

Re: Proton Native – React Native for the desktop

#197

Post by flukus » Thu, May 03, 2018, 1:36 AM UTC

zengid wrote: 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

Nice to see this project is still alive, it shows a lot of promise but appeared abandoned for a while.

Have they got the data grid API's working yet?

Re: Proton Native – React Native for the desktop

#198

Post by philliphaydon » Thu, May 03, 2018, 1:41 AM UTC

techbubble wrote: post #174

nautilus12 wrote: post #109

Earlier quoted context omitted.

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

I just declared Chrome bankruptcy and switched to Firefox a few weeks ago. CPU rarely goes over 10% on my 2017 MBP. With Chrome it was almost always above 50%.

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.

Re: Proton Native – React Native for the desktop

#199

Post by flukus » Thu, May 03, 2018, 1:47 AM UTC

vintagedave wrote: post #35

> You can create a GUI using something like Qt, but the code to make it is messy and unorganized. Having made a very large GUI myself, it gets very cumbersome to manage all of that. Haven't we moved past writing UIs in code about twenty years ago? I see your code samples, and all they look like is an improved version of the code UI creation we had in OWL, MFC, and other UI frameworks on other platforms. Starting abou…

Form designers produce their own issues like compatibility between versions, poor interactions with source control and poor responsiveness.

I don't see an issue with creating UI's in code, with a decent API like Qt and Gtk provide it's quite straightforward. Why should UI code be treated differently to other code?

Re: Proton Native – React Native for the desktop

#200

Post by Klonoar » Thu, May 03, 2018, 1:57 AM UTC

saagarjha wrote: post #170

Klonoar wrote: post #118

Earlier quoted context omitted.

You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc. The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's nothing crazy different. It's iOS-style navigation and transitions through and through.

> You're in pretty much every thread that pops up as a naysayer re: not using UIKit/AppKit/etc You got me :) But yes, I'm in a lot of these threads because I do a lot of iOS development and have strong opinions on how iOS apps should work. > The thing about the link you just pointed out is that it's literally 100% UINavigationController. I've used this in projects and had to work with the native source layer - it's n…

...mmhmm, look dude, I do iOS/macOS development as well, and I've corrected you in a few threads around here already. I'm very acutely aware of how UINavigationController works. I've worked on ports of it for React Native, and even ported it backwards to macOS.

All the JS in that package is doing is driving the native interactions on an in-memory UINavigationController. I've used this in recent contract work where I can confirm that the title handling and animations are the same as what you'd get with a stock UINavigationController. That project is not replicating the behavior in JavaScript, contrary to what you seem to be implying - e.g, tapping the status bar does indeed scroll shit to the top. It's all driven by JS that simply calls the native layer code.

There are a lot of reasons to prefer the Apple dev ecosystem on a native level, but this is a moot point at the end of the day.

Finally, look... I was your age once, and believe me, I too thought I was an expert when I was in high school. Age and time are gonna show you otherwise sooner or later. Blind allegiance to a particular tech stack isn't healthy for your career, and throwing this stuff in every thread you find just gives a really bad image to projects that are starting to beat [Apple/Qt/etc]'s dev environment at their own game. These environments need to step up their game to stay competitive, and plugging your ears (and giving this fodder to everyone else) and pretending otherwise isn't helping anything.

This is almost willful ignorance on the level of Twitter's Cocoa community.