Live data from Hacker News

Proton Native – React Native for the desktop

proton-native.js.org

171–180 of 295 posts

Re: Proton Native – React Native for the desktop

#171

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.

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

I've had the exact opposite experience.

Storyboards are great - they simply force separation of concerns among developers.

One person handles one part of the app, and other people keep their hands off of it.

Each person has their storyboard/collection of nib files.

Multiple people should absolutely not be tinkering with the same files randomly - obviously I hope.

As for things rearranging for 'no reason' - it'd help if people took 2 days to understand auto layout. Every person I've ever met who dislikes sql, or storyboards/auto layout etc, simply doesn't understand what is happening.

It's trivial to create a mess in auto layout, if you don't know what you're doing, just like people create cocoapod soup in every other iOS project. There is no silver bullet for curing mediocrity - just make sure you're not part of the problem :)

Re: Proton Native – React Native for the desktop

#173

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.

Come on... That's not fair on XAML

Re: Proton Native – React Native for the desktop

#174

Earlier quoted context omitted.

Anything that reduces the number of running chrome instances on my poor little laptop would be nice.

Chrome is like the elephant that comes and sits on my laptop. Would be unusable without the great suspender.

I just declared Chrome bankruptcy and switched to Firefox a few weeks ago. CPU rarely goes over 10% on my 2017 MBP. With Chrome it was almost always above 50%.

Re: Proton Native – React Native for the desktop

#175

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

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

Re: Proton Native – React Native for the desktop

#176

Earlier quoted context omitted.

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

I 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?

That’s correct. AirBnB’s iOS app is written mostly in Swift. And Facebook’s iOS app is a piece of shit performance wise.

Re: Proton Native – React Native for the desktop

#177

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.

Visual Studio Code is pretty light and extremely responsive for me on 2012 hardware

Re: Proton Native – React Native for the desktop

#179

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…

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

If 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?

Re: Proton Native – React Native for the desktop

#180
post #117

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…

React Native seems to be geared for mobile. Proton Native uses bindings with NodeJS (via libui-node, which uses libui), which seems to be (IMO) a much better run-time for the JS part than JavaScriptCore because Node already can handle a huge amount of the OS interop. Also, JIT isn't restricted on desktop the way it is on iOS, so JSCore doesn't have a good reason to be used.

JSC is very fast, and the RN runtime is intended to be a fairly limited API, so I wouldn't necessarily say the access to the Node core packages is hugely beneficial. But it's a fair point.

I'm not sure why JIT is relevant. Neither JSC nor Node do any JITting.

Post reply on HN