Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

91–100 of 295 posts

Re: Proton Native – React Native for the desktop

#91

Earlier quoted context omitted.

NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.

I think that is a uniquely iOS thing since they insist on using computer generated IDs to link objects together, while %100 human editable UI formats like HTML or Android's UI XML formats don't do that. It's the same issue that project.pbxproj has in Xcode.

Oof. I've had nightmares about the project.pbxproj file. Such a weird design decision on Apple's part.

Re: Proton Native – React Native for the desktop

#92

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

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 they seem a little dated, but I wouldn't call them FUD.

Re: Proton Native – React Native for the desktop

#93

Earlier quoted context omitted.

NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.

Exactly. I feel like the design experience of HTML/CSS is the best of both worlds. You're designing in code, but it's not imperative code, which is what you have to do in iOS if you want to escape the NIB. Using declarative code to define your interface just...makes sense.

A few libraries have tried to build declarative UIs for iOS, with varying degrees of success.

This is what I love RN so much - I can build UI in 20% of the time and effort.

Re: Proton Native – React Native for the desktop

#94

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

NIBs in macOS/iOS are horrible for development and code review. Using a UI to build UI is slow and clunky. There is no "moving past" it. That's a bad way to develop stuff. We don't do it with HTML, do we? No.

But you use live reload, no? That's just webshit for an UI editor.

WPF has(d?) this figured out. No drag and drop of UI elements (aka "components"); that gets you into "absolute position" hell of Windows Forms. Instead you have a DSL that you use to build the UI with grids and other standardized layout containers and the WYSIWYG view is there mostly as a preview and navigation help.

Of course their fatal mistake was having no code whatsoever in the DSL. They wanted to make it so designers would use it; designers will never use anything but Photoshop, so the other half of them that isn't resistant to learning now calls themselves frontend developers. The model binding on steroids helped some but still "inverting" an enum required 15 lines of code somewhere else to create a converter.

Re: Proton Native – React Native for the desktop

#95

Without 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 looked at the GIF that the first one had on their GitHub page and it doesn't do iOS navigation right at all. I'm not impressed.

Re: Proton Native – React Native for the desktop

#96

Earlier quoted context omitted.

None of those are apps I particularly enjoy using or would want to use.

Facebook? Instagram? Airbnb? We're talking about some of the most popular apps in the world. What exactly is your problem with them?

None of those are apps that I'd hold up as paragons of UI design…

Re: Proton Native – React Native for the desktop

#97

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

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.

Re: Proton Native – React Native for the desktop

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

Re: Proton Native – React Native for the desktop

#99

It'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.

or windows dialog RC files

Re: Proton Native – React Native for the desktop

#100

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

It turns out it's really hard to get a UI Builder right with HTML/CSS. In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints. For example, text getting longer pushes down content beneath it, while at the same time, the text might be 50% of it's parent node's width. The first constraint is bottom-up: the text node influences it's parent and sibling DOM node's geometry, while t…

> In particular, layout is tricky because DOM trees imply both bottom-up and top-down constraints.

Well you can always choose to roll your own layout algorithm and position everything in the DOM using absolute coordinates - e.g. https://diasli.de implements an 'auto layout' mechanism disregarding DOM layout.

Post reply on HN