Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

201–210 of 295 posts

Re: Proton Native – React Native for the desktop

#202

Earlier quoted context omitted.

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 onClick…

So nice not so see any and ( ) all over the place in addition to { }.

Re: Proton Native – React Native for the desktop

#203

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.

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).

Re: Proton Native – React Native for the desktop

#204

Using Electron, you are rendering each window in Chrome, with some added OS hooks. With Proton, you are using JavaScriptCore with hooks to the native MacOS UIs and APIs. Seems to me that this should use far fewer resources (especially memory) and make it easier to make an App look more 'MacOS'y. Very eager to give it a go!

I've never heard of JavaScriptCore. I assumed that ReactNative transpiled JS to the native languages/APIs and that this would too.

Re: Proton Native – React Native for the desktop

#205

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.

I'm only an occasional Qt user but I believe since c++11 they've gained much better support for anonymous functions.

Re: Proton Native – React Native for the desktop

#206
post #21

Earlier quoted context omitted.

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 st…

I played with OpenLaszlo way back then. It was pretty nice.

Re: Proton Native – React Native for the desktop

#207

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…

I think you are misunderstanding what this is.

This literally is UINavigationController, controlled by Apple's JavaScriptCore.

If you want extra animations or whatever, you just turn them on.

There are some advantages to using native code vs ReactNative, but access to native controls and their behavior isn't one.

Re: Proton Native – React Native for the desktop

#208

Earlier quoted context omitted.

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.

sounds like you have your project configured wrong, transpiling should impact compilation not the loading aspect of your application

Re: Proton Native – React Native for the desktop

#209
post #21

Earlier quoted context omitted.

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 st…

Adam Wolff, former Chief Software Architect of Open Lazlo, is now the Director of Product Infrastructure at Facebook, and oversees React and React Native.

Re: Proton Native – React Native for the desktop

#210

Earlier quoted context omitted.

UI seems to be effectively described using some sort of a markup language. HTML being the most well-understood markup language becomes a reasonable thing for stuff outside just web pages. It isnt perfect but it gets the job done. Sorta like phonegap :/

Thing is that these days HTML is a pile of div tags that CSS and JS dangle off. Damn it, didn't we just have an article on HN about creating art using CSS?!

Indeed. A part of me is sad to see the semantic vision of XHTML lost in the mix. Though with care HTML5 can be more descriptive than its predecessors.
Post reply on HN