22 ms·
Proton Native – React Native for the desktop
- c-smile 8y agoAm I the only one who think that this: class Example extends Component { render() { return ( <App> <Window title="Example" size={{w: 300, h: 300}} menuBar={false}> <Button stretchy={false} onClick={() => console.log('Hello')}> Button </Button> </Window> </App> ); } } render(<Example />); 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" });
- uryga 8y agoLooks 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.
- c-smile 8y agoI 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 ?
- always_good 8y agoWhat does your trivial wrapper actually improve though? window = (...children) => <App><Window>{...children}</App></Window> 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.
- crooked-v 8y agoJSX 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' ]) ]) ])
- c-smile 8y ago"JSX is JS" It is not, https://facebook.github.io/jsx/ https://facebook.github.io/jsx/ It is handled by transpiler - one more parsing layer in loading sequence of your application.
- azerothian 8y agosounds like you have your project configured wrong, transpiling should impact compilation not the loading aspect of your application
- mlsarecmg 8y agoThe 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.
- tannhaeuser 8y agoNo it isn't, in the sense that it's not part of a language spec for JavaScript, like E4X (now deprecated) once was considered to become. But I guess E4X's problem was that it was too far ahead of its time and had XML in its name. [1]: https://developer.mozilla.org/en-US/docs/Archive/Web/E4X https://developer.mozilla.org/en-US/docs/Archive/Web/E4X
- mlsarecmg 8y agoJSX 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.
- profalseidol 8y ago); } }
- plaguuuuuu 8y agoInstallation steps didn't work for me in Windows. Otherwise seems cool.
- lazerwalker 8y agoI wonder why this is called Proton Native and advertises itself as "using the same syntax as React Native" instead of just _being_ React Native. There's already plenty of prior art for RN-compatible projects that target non-mobile devices (e.g. react-native-web, a half-dozen different AR and VR projects).
- blklivesmatter 8y agoFacebook products.. no thanks
- tym0 8y agoWithout Yoga and style attribute, it is a lot less interesting than react native.
- zengid 8y agoThis runs on libui-node, which is a binding to the libui library. https://github.com/parro-it/libui-node https://github.com/parro-it/libui-node https://github.com/andlabs/libui https://github.com/andlabs/libui
- flukus 8y agoNice 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?
- zengid 8y agoI don't think so? https://github.com/parro-it/libui-node/issues/63 https://github.com/parro-it/libui-node/issues/63
- flukus 8y agoI was actually thinking of the table view: https://github.com/andlabs/libui/issues/310 https://github.com/andlabs/libui/issues/310 . Doesn't seem to be done yet and is critical for a lot applications.
- parro-it 8y agoHi, 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...
- andlabs 8y agoNo, the data grid has problems on Windows, as that code is being contributed by someone else. I already have it on macOS and Linux, and have for years now... Hopefully soon the Windows code will be merged in and we can keep going.
- 8y ago
- ilurkedhere 8y agoThe example in the getting started section comparing Python Qt isn't very convincing.
- kbumsik 8y agoYeah I personally see Qt code is much cleaner.
- ratsimihah 8y agoI guess it is if you already know and like React Native?
- freedomben 8y agoI tend to agree. I did years of Qt dev and I would never write something like that, nor have I seen it written like that. It works I suppose, but it's very clearly written to be an easy-to-compare example, not a realist example. To really get an idea of what it would be like to use proton native v. Qt I'd like to see a small but complete project.
- rhodysurf 8y agoNot only that... but maybe its the fact that I use Qt everyday at work (C++) or that I'm not really a front end web dev, but the Python example is easier to grasp on first look.
- deleted 8y ago[deleted]
- mstade 8y ago> 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?
- yuchi 8y agoYou can “skip” the whole “closing braces” stuff, then it’s definitely shorter. I’m talking about this: </Button> </Window> </App> ); } }
- xgbi 8y agoWell, then they failed completely at their argument. I count 7 levels of indentation in the react code, when there are only 3 in the PyQt code. Also, the paradigm is completely different in that react is React is déclarative whereas Qt, in this mode, is procedural. I would argue that QML would be a better comparison, and in this case I’m quite sure that qml wins. So much for buzz words..!
- mstade 8y agoNo, you can’t “skip” them. If you skip them, the code is broken. The lines may well be noise, and arguably that’s even worse, but you certainly can’t skip them – counting or otherwise.
- tomtheelder 8y agoYou can skip them if you want by various means, and you can also not put them on their own line. You don't even have to use JSX, which is what is taking up most of the space. A shortened, yet still totally readable (if you are used to not using JSX) version that is shorter in LOC than the Qt example might look like: import React, { Component, createElement as e } from 'react'; import { render, Window, App, Button } from 'proton-native'; function Example() { return ( e(app, {}, e(Window, {title:"Example", size:{{w: 300, h: 300}}, menuBar={false}}, e(Button, {stretch=false}, onClick={() => console.log('Hello)}, 'Button') ) ) ); } render(<Example />); If you really hate the brackets and parens you could certainly use a dialect of JS that doesn't have them, and you could cut it down to like half the length of the Qt example. But this whole discussion is silly. "Shortness" in code terms has much more to do with the number and complexity of statements, not LOC or characters. The JSX in there adds "noise" and characters, but the whole purpose is to simplify understanding code and make it readable. It's not adding any fundamental length. The Proton example is doing a bit less than the Qt example, and for me that's a much more useful definition of shorter.
- WorldMaker 8y agoOther than Linux support, does this offer anything more than React Native's existing macOS and Windows forks/bindings?
- kusti8 8y agoI've tried to improve documentation and make it ready for use. Also all the forks is are platform specific while this is cross platform.
- djhworld 8y agoThe website and github README could do with a lot more examples/screenshots
- freedomben 8y agoIt'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.
- bcheung 8y agoColdFusion, Flex, XAML, JavaFX
- ratsimihah 8y agoWriting React makes me feel more like building for web using native paradigms.
- coldtea 8y agoAnd 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.
- anthonybullard 8y agoYou 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.
- gman83 8y agohttps://github.com/google/flutter-desktop-embedding https://github.com/google/flutter-desktop-embedding
- anthonybullard 8y agoThanks! Now I have something else to play with.
- 8y ago
- bitwize 8y agoNeat. Will keep this in mind for future desktop projects, assuming it has legs (i.e., long term maintenance).
- tshannon 8y agoHm. Proton's are heavier that electrons...
- cpburns2009 8y agoElectron should have been named Lead or maybe Uranium. BTW: It should be "protons" without an apostrophe.
- ratsimihah 8y agoIs this created and maintained by a single developer (kusti8?), community, or corporation?
- kusti8 8y agoI'm one highschooler with not enough time. Ideally this would come from someone who can maintain this full-time like a corporation, but so far no one has done it.
- thomasfromcdnjs 8y agoVery nice work man! Keep at it! =)
- jgalentine007 8y agoFrom my experience, you won't have more time than you do now, it's just a matter of what is a priority. Cool project.
- zengid 8y agoWow that's awesome; you really are still in highschool.. When I read your gitHub profile where it said "A sophmore at High Technology High School" I thought you were being sarcastic!
- ratsimihah 8y agoImpressive indeed :D
- memonkey 8y agoThis is super cool. Are there any demonstrations comparing performance between electron and your app?
- kusti8 8y agoCurrently no. That's one thing that I want to test sometime, but right now I'm busy improving it.
- caspervonb 8y agoIt 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 nonsense.
- zengid 8y ago>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 https://nodejs.org/api/n-api.html#n_api_n_api
- parro-it 8y agoSome days ago I started a N-API version of the bindings: https://github.com/parro-it/libui-napi https://github.com/parro-it/libui-napi Is still really incomplete compared to libui-node, but just in case someone wants to help
- zengid 8y agoIs it a pretty simple re-write or something that requires a lot of c wizardry?
- 8y ago
- vintagedave 8y ago> 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 about 1995 we had a better way: form designers that streamed objects (note: not even auto-generated versions of code, which is not much better, but object streaming.) Your UI is then designed and manipulated largely as a graphical UI -- that's what it is -- and manually written code is reduced to tweaks or state changes. For example: Delphi (the prototype of all modern UI frameworks); C++Builder; others. WPF may count although the generated text is ugly as :) - but it carries the concept. A NIB file on macOS. You get the idea.
- flukus 8y agoForm 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?
- pjmlp 8y agoBecause 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.
- flukus 8y ago> 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.
- pdxandi 8y agoI'm curious how the documentation for this site was created. It resembles Vue.js and I really like it; would love to use a similar template for my projects.
- FLGMwt 8y agohttps://docsify.js.org https://docsify.js.org
- wishinghand 8y agoThe Vue team also just released VuePress, a static site generator based around making documentation sites with Markdown.
- gremlinsinc 8y agoThe website isn't very responsive, can't resize on hn reader app on Android and still see text on right pane.
- dilap 8y agoSort of tangential, but does anyone know of a good React Native app? Everything I've tried would clearly have been a better product if they'd just done native development. Like, you're sacrificing product quality for development ease.
- rimliu 8y agoEven development ease is somewhat illusionary. To be effective you will still need to know the details of iOS/Android and sometimes just write native code. At the end, why not just go full-native instead of writing and rewriting bridges.
- foobarandgrill 8y agoInstagram uses react native, I believe
- a13n 8y agoYou might recognize a few on this list: http://facebook.github.io/react-native/showcase.html http://facebook.github.io/react-native/showcase.html
- saagarjha 8y agoNone of those are apps I particularly enjoy using or would want to use.
- symlinkk 8y agoFacebook? Instagram? Airbnb? We're talking about some of the most popular apps in the world. What exactly is your problem with them?
- Benjammer 8y agoI mean, do you realize that most of the big names on that list have a hybrid solution where they prove concepts, A/B test, and rapidly iterate-on/release new features using React Native, and then they have a native dev team for each platform that goes back and re-implements most of the core features natively?
- a13n 8y agoReact Native isn't just for iOS / Android, it also works for macOS and Windows. React Native is React Native for the desktop.
- notheguyouthink 8y agoWhat do you mean? Can you provide some links for building OSX apps with ReactNative? Only iOS/Android are listed as targets on the documentation website (under getting started).
- scottmf 8y agohttps://github.com/Microsoft/react-native-windows https://github.com/Microsoft/react-native-windows https://github.com/ptmt/react-native-macos https://github.com/ptmt/react-native-macos
- notheguyouthink 8y agoBut aren't those 3rd party react native for desktop implementations, just like Proton Native? Does Proton Native differ in some meaningful way that OP was referring to? We're in a thread about a React Native for desktop implementation.. saying "React Native is React Native for Desktop" is confusing; hence my question.
- carloscr 8y agoI like react on the web, but sometimes I find it cumbersome all that sending props down and passing functions to update global state. When I'm almost done with an app and then I decide that it will be nicer to open a modal window to ask the user 2 or 3 parameters is when I miss the most the desktop paradigm of just call a method that opens a small window and returns an object with the collected data
- a13n 8y agoI have a ModalContainer that passes down this.context.openModal. https://reactjs.org/docs/context.html https://reactjs.org/docs/context.html
- roberttod 8y agoUsing 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!
- _bxg1 8y agoI've never heard of JavaScriptCore. I assumed that ReactNative transpiled JS to the native languages/APIs and that this would too.
- ikurei 8y agoThe only part that's translated to native APIs is the rendering itself. Instead of rendering a WebView with an HTML <button />, it renders a UIButton from the native UIKit. The app logic is still in Javascript, never compiled to another language. IMHO this is perfectly fine. I have a fairly large app in react-native, and most users that have tried it are fine with its performance. Scrolling in lists and maps, being native components, is as snappy as in a real native app. I'm only having performance issues in page transitions, and I think I can fix that with a bit more work.
- sydd 8y agoYeah, but before we say anything we should look the the performance and memory benchmarks.
- roberttod 8y agoAbsolutely, though I can't think of a good reason why it couldn't be leagues better in performance. I'll post here with some numbers later in the day if no one beats me to it.
- ben_jones 8y agoI'd love to see electron "suddenly" start reducing memory footprint as soon as a competitor starts gaining market share
- BillinghamJ 8y agoI don't totally understand why this exists to be honest. React Native for desktop is... React Native. It isn't mobile-specific in any way. In fact, it is already possible to make Windows (UWP) and macOS apps with it. If this project was about formalising proper stable support for Windows and macOS within React Native, that would totally make sense. But it seems more like it's trying to be an alternative, under a different name, different branding, etc. Surely it's better to remain as one widely compatible project?
- jscholes 8y ago> React Native for desktop is... React Native. It isn't mobile-specific in any way. In fact, it is already possible to make Windows (UWP) and macOS apps with it. And what if you want to make a non-UWP app for accessibility or other reasons? Just your standard, straight forward Win32 GUI. Bringing the power of React to that space will still appeal to many.
- BillinghamJ 8y agoIf your use-case is specialist enough that you can't use UWP or WPF, I feel like maybe it's specialist enough that it might be best for you to just use the standard native tools rather than React Native?
- com2kid 8y agoReact-Native for WPF already exists. Same repro as React Native for UWP.
- Etheryte 8y agoWithout 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 goes on. On the tin, React Native, and in the same way, Proton Native, look very promising, but for anything that's more complex than a demo application, my personal recommendation is to steer far away. You're free to disagree, of course, but having extensively tried to use the "write once run everywhere", my personal experience is that it always ends up more along the lines of "write once, then patch all the bugs separately on all the platforms".
- RubenSandwich 8y agoI'm sorry but this seems overstated. There is already two highly competitive navigation libraries: https://github.com/wix/react-native-navigation https://github.com/wix/react-native-navigation https://reactnavigation.org https://reactnavigation.org Edit: Replaced the word FUD with overstated, to not seem like I'm attacking the author personally.
- rimliu 8y agoI 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.
- ballenf 8y agoAgree with you, but think it's somewhat unfair to call the parent comment "FUD", given the specific examples cited. To me, FUDdy comments are more vague and less dis-provable. More like "but you never know whether Facebook is going to deprecate React tomorrow". Just a nitpick because I think "FUD" borders on ad hominem in the way it's sometimes used. Again, as a React dev, I haven't encountered the cited issues and they seem a little dated, but I wouldn't call them FUD.
- jeremiep 8y agoI found about proton-native earlier this week! Sadly it doesn't have a `<video>` element thats required for the project I'm building :(
- triptych 8y ago"On mobile, it used to be hard to build beatiful cross-platform apps" might want to run a spell checker on your docs.
- WaltPurvis 8y ago>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.) lives in a well-organized project that is easily managed using the Qt Creator IDE. The project structure is well-documented and standardized. It's also quite strange to compare React code to code using the Python binding for Qt. That's not how most Qt apps are written. Most Qt apps these days use QML, which is based on regular old JavaScript. Besides being a more accurate representation of the way Qt development is normally done, it would also be more interesting to compare one JavaScript-based framework to another. (Although I recommend not making the comparison at all, since I don't believe a fair comparison would favor Proton.)
- kusti8 8y agoThanks for the feedback! I'm not a Qt dev, so I wasn't aware of the practices. I'll revise it and remove the Qt code.
- mlsarecmg 8y agoThis 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 = fn(state) solves longstanding issues with all the previous approaches, and of course it decreases their complexity. It is also the first approach that's breaching the platform barrier successfully while maintaining the high-level. You can write React for countless of targets, being able to re-use and apply the eco-system.
- westoncb 8y agoThere 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`.
- aurailious 8y agoWhat is this site written in? I've seen this style for a couple others. Is it a github wrapper or something?
- rhinoceraptor 8y agoBased on the page source, it looks like it's docsify: https://docsify.js.org https://docsify.js.org
- aurailious 8y agoOh weird, I was just looking at docsify this morning, that's why it must be so familiar to me.
- rohan1024 8y agoSynchronicity!
- mmgutz 8y agoThe advantage of this over Qt is the licensing. React is an advantage if you are familiar with it over QML. One thing to note, the naming convention of props differs from React Native which is a bummer. https://github.com/kusti8/proton-native/issues/9 https://github.com/kusti8/proton-native/issues/9 IIRC the project is a light mapping from libui-node project to React.
- latortuga 8y agoThe issue you linked to seems to indicate that they are going to transition to React-idiomatic naming.
- augbog 8y agoWill keep my eyes on the project but right now, the example for Notepad doesn't even work properly :/ hopeful for this project though.
- tuananh 8y agoi've been quite impressed with Yue [0] and it's first real world demo app Wey [1] - a Slack client. It's way more robust than any Electron apps i've used. [0]: https://github.com/yue/yue https://github.com/yue/yue [1]: https://github.com/yue/wey https://github.com/yue/wey