Earlier quoted context omitted.
And yet there's not much that's like native GUI paradigms in React. At least when concerning all major GUI libs. It's more like a markup driving an immediate-mode graphics API.
You basically just described Google's Flutter framework. It's currently only mobile but I see it moving into this space at some point - or already is I guess if you count Fuschia.
Proton Native – React Native for the desktop
231–240 of 295 posts
Re: Proton Native – React Native for the desktop
#232This 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?
Hi, libui-node author here. I'm glad for your appreciation.
The project is well alive now, proton-native give me new motivational energy
The data grid has still problems on macOS unfortunately, but @andlabs is working on it...
Re: Proton Native – React Native for the desktop
#233Using 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!
Correction: it's using Node, not JavaScriptCore. (I think that makes it even more useful, and it should still be far more performant)
ReactNative runs the js in plain V8 that in turn calls native apis. Native code is never generated from js at compile or runtime.
Re: Proton Native – React Native for the desktop
#234Earlier quoted context omitted.
It seems to runs on "UI" from andlabs, which is a fairly lightweight C wrapper around the the Windows, Cocoa and Gtk API's. Sidenote as for why a UI library would wrap another UI wrapping library, Gtk is what is considered "native" on Gnome based distros. So weight-wise, it's basically comes at the cost of native node module which is not bad compared to Electron's crazy IPC bridge back and forth communication nonsens…
> So weight-wise, it's basically comes at the cost of native node module And now with NAPI [1] it should be easier than ever to make node modules! [1] https://nodejs.org/api/n-api.html#n_api_n_api
Some days ago I started a N-API version of the bindings:
https://github.com/parro-it/libui-napi
Is still really incomplete compared to libui-node, but just in case someone wants to help
Re: Proton Native – React Native for the desktop
#235Earlier quoted context omitted.
And yet there's not much that's like native GUI paradigms in React. At least when concerning all major GUI libs. It's more like a markup driving an immediate-mode graphics API.
You basically just described Google's Flutter framework. It's currently only mobile but I see it moving into this space at some point - or already is I guess if you count Fuschia.
You can get it working on Desktop (I've got it on Windows with the help of https://github.com/ds84182/flutter_sdl and few other hacks, but certain things are missing - there is no support for mousewheel events, docking, or more than one window. Or keyboard input (though that should be easier to add than the three listed).
Re: Proton Native – React Native for the desktop
#236Am 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 gets transpiled, not parsed. The effort is completely on the tooling side, there's no loading effort that changes JSX into functions. The main difference between your two snippets is that one is declarative and the other is imperative. The declarative piece can reflect state and react to changes, the other can't - you do that manually.
Re: Proton Native – React Native for the desktop
#237Earlier 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.
The transpiler is a build build (a babel plugin), it isn't even a part of the application nor does it run while loading. The snippet above turns into a bunch of nested functions.
Re: Proton Native – React Native for the desktop
#238It's pretty fascinating how tech tends to spread and influence. We spent years trying to make the web more like traditional UI dev, and now we're making traditional UI dev like web. I would never have believed this if you'd told me about it in 2010.
> 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.
XAML is a template, JSX is a DSL. A template kills scope, duplicates coding semantics, messes up app flow with bindings and needs dependency injection to get local scope back - all of this has been solved with JSX, which now pretty much fulfills Silverlights dream: https://news.ycombinator.com/item?id=16198843
The crazy part is, that you can share code and eco-system components among these targets, no matter if they're native or otherwise. Here's a shell applications for instance that uses react-motion to shift stuff around: https://github.com/gaearon/react-blessed-hot-motion
Microsoft seems heavily invested in it as well (react-windows, reactXP, UI-fabric, ...).
Re: Proton Native – React Native for the desktop
#239Earlier quoted context omitted.
Absolutely, most big mobile development teams I know do not use storyboards or NIBs because they are not easily human reviewable. (A small change will rearrange sections for seemlying no reason.)
Same. I wonder how anyone uses them, honestly.
Oh come on. For most parts of an application Interface Builder is just fine. Sure, for the stuff that actually matters the code is necessary because IB is not turing complete anyways.
But to arrange the view controllers and segways + some static tables it is mighty fine.
Re: Proton Native – React Native for the desktop
#240Without having used Proton Native myself, comparing your product to React Native is not something you would want to do, honestly. React Native has insanely huge growing pains, still going, even though it's been out since 2015. The last time I checked there was still no reasonable, scalable way to do complex navigation on the platform. Most third-party components are unusable six months in due to API changes. The list…
I'm sorry but this seems overstated. There is already two highly competitive navigation libraries: https://github.com/wix/react-native-navigation https://reactnavigation.org Edit: Replaced the word FUD with overstated, to not seem like I'm attacking the author personally.
I had some discussion with the Wix engineer. Let's just say, they still feel the pain of going RN route. There are reasons why this may still be beneficial to them, but it is still painful.