101–110 of 295 posts
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!
What is this site written in? I've seen this style for a couple others. Is it a github wrapper or something?
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!
Earlier quoted context omitted.
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.
As I stated above, it's my personal opinion on the matter. I've used both of those libraries in a medium-sized project and they don't work well. Simply linking to libraries and saying they exist is hardly making a point.
"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 links are counterpoints to the complex navigation issue. Showing that libraries exist and can handle complex navigation. If you want to argue that they are going over rapid change, which is true, then that is another thing. But I'm gonna disagree with the blanket statement of "there was still no reasonable, scalable way to do complex navigation on the platform" as overstated.
As for the second point. I assume what you mean by 'third-party components', is actually third-party native modules. In which I agree the API for them doesn't seem to have stabilized yet so there is a lot of churn in native modules. But a lot of third-party components I have seen continue to work in newer versions of React Native.
Earlier quoted context omitted.
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.
Agree 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…
What is this site written in? I've seen this style for a couple others. Is it a github wrapper or something?
Based on the page source, it looks like it's docsify: https://docsify.js.org
>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…
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!
Anything that reduces the number of running chrome instances on my poor little laptop would be nice.
I 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 diff…