Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

React Native for Windows and Mac

microsoft.github.io

Post reply on HN
Print view View original

451–460 of 505 posts

Re: React Native for Windows and Mac

#451

Post by epidemian »

jmull wrote: post #422
hyperbovine wrote: post #412

Earlier quoted context omitted.

A lot of these "packages" are just silly though. Among the horde of dependencies in that web is `number-is-nan`. Behold its awesome functionality: https://www.npmjs.com/package/number-is-nan Want Array#filter/map/reduce? Why that'll be three separate packages: https://www.npmjs.com/package/array-filter https://www.npmjs.com/package/array-map https://www.npmjs.com/package/array-reduce It just seems to be the culture o…

The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.

Yeah, but the thing is that it's just unnecessary.

isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on.

So, at least for React Native, the package number-is-nan shouldn't be necessary at all. But it's probably a transitive dependency, and that's basically the problem with all these sort of polyfill packages: you might not need them, but a library that runs on older engines on which you depend (directly or transitively) does need them, so you end up paying the price anyway.

Re: React Native for Windows and Mac

#452

Post by diegof79 »

antigirl wrote: post #220
diegof79 wrote: post #145

Earlier quoted context omitted.

I had the same experience. Expo is wonderful for prototyping and quick iteration. The ability to use Snacks online and see them working on the phone is great. But beyond that everything in RN feels hacky and unfinished. While working with it I had some silly issues with Metro, and found some subtle bugs in Text and Button components. About the "Native" part. I think that a lot of people have the expectation that doin…

That’s a massive claim to say RN doesn’t feel native without alot of extra work? Please elaborate because it feels pretty native out of the box using the standard components. It’s nothing like ionic. When is the last time you used RN? RN apps are hard to tell from native.

Take the most basic example: a Button.

The RN's core Button it’s a Text composed with a Touchable (https://github.com/facebook/react-native/blob/master/Librari...). It behaves in the same way but there are subtle differences in text rendering: the font size and letter spacing is not exactly the same, so when you create a native looking iOS view it doesn’t look the same unless to fine tune the font settings (and of course that will break when iOS decides to change it). This is just one small example, another one in iOS is “routing”. With the RN Router you don’t get the native components but a simulation of it. But Apple HIG doesn’t document many details of the animations and behavior of headings and nav bar (they assume that you use the native component). So if you want to have a native look and feel your options are: try an alternative router built for iOS, try to build your own adapter (hard unless you have tons of native dev experience), or try to imitate the native platform. All the options have pros and cons, and require more extra work over a small UI detail that you get for free using native tools. At least Flutter took the effort to make it look native by default.

In the end is similar to the desktop: if you want cross platform code is easier to not follow the platform rules. The differentiator of RN is that you have the option to embed the native widgets, which is not always easy. (The last time I used RN was mid-2019, I didn’t see substantial changes since then)

Re: React Native for Windows and Mac

#453

Post by eyelidlessness »

iainmerrick wrote: post #313
eyelidlessness wrote: post #175

Earlier quoted context omitted.

It uses a combination of both JS and native code. That JS that RN calls ultimately makes calls out to native Andriod and iOS (and Windows, and macOS) APIs that are compiled to Java and ObjC/Swift (and, I assume, C#?). All of RN's targeted platforms leverage scripting bridges for JS, but only a portion of the actual running code is JS, the part that's native is (usually, but not exclusively) generalized.

It uses a combination of both JS and native code. That JS that RN calls ultimately makes calls out to native Andriod and iOS (and Windows, and macOS) APIs Exactly like a web browser. only a portion of the actual running code is JS “Only a portion” meaning your entire React application! The native parts are the RN framework, any native libraries you’re using, and any native code you’ve added yourself. What RN brings t…

> Exactly like a web browser. > > “Only a portion” meaning your entire React application! The native parts are the RN framework, any native libraries you’re using, and any native code you’ve added yourself.

Exactly, in the sense that JS is a hosted language in both scenarios, but that's pretty much where the similarities end.

In a web browser, JS is the programmatic interface to behavior after the HTML and CSS are rendered. With React, a function of props that returns a JSX data structure is a declarative-ish interface to additional JS behavior. It's JS all the way down to the renderer.

With RN, JS is an interface to a lower level UI API on the host OS. A function of props that returns a JSX data structure is a declarative-ish interface to a bridge to that API, which performs the actual work.

It's hard to visualize the difference when just thinking of a static output, but easy once you start to think about user events. E.g. there is no `onPress` in the JS bridge for these APIs.

All of React is JS. A substantial portion of React Native, itself, is native. That's the difference.

> What RN brings to the table, as compared to a browser, is a different layout model that’s simpler than the DOM and maps a bit more closely to native widgets.

That's... maybe part of what would attract a dev to RN, but certainly not all of it. It also brings actual (not just close) native UI, with all of the performance and UX expectations that come with that. And it brings the ability to implement performance-critical logic in the native environment while sharing a lot of the rest of your logic with code for other environments.

> It also has APIs for sending messages back and forth between JS and native code. That’s also possible with WebViews on all platforms, but RN has a more consistent API (at least on the JS side), so a decent amount of native bindings have been written by third parties.

If I'm not mistaken, that's how RN works. (I could be mistaken.) In any case... that capability is hardly attractive unless the API is not just consistent internally, but with APIs on other platforms.

Re: React Native for Windows and Mac

#454

Post by techntoke »

dep_b wrote: post #342

Those JavaScript cross-platform solutions are opaque boxes that run basically their own operating system within an operating system. This comes at a penalty of a non-standard UX and higher than usual CPU usage and memory usage. But after they tackled that hurdle (like Visual Studio Code, excellent work), they still lack a lot of platform standard goodies like Accessibility and AppleScript. I prefer solutions like Xam…

It's almost like people want a new markup language for defining interfaces that isn't based on JavaScript.

Re: React Native for Windows and Mac

#455

Post by [deleted] »

epidemian wrote: post #451
jmull wrote: post #422

Earlier quoted context omitted.

The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.

Yeah, but the thing is that it's just unnecessary. isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on. So, at least for React Native, the package number-is-nan shouldn't be necess…

[deleted]

Re: React Native for Windows and Mac

#456

Post by bryanrasmussen »

epidemian wrote: post #451
jmull wrote: post #422

Earlier quoted context omitted.

The purpose of that kind of package is to provide a standalone implementation of a function. To criticize this organization, you would need to understand why people find that to be valuable and show a better approach. You’re attributing it to “culture” but there may be deeper, less arbitrary reasons. Look up “ponyfill” if you are interested in learning about it.

Yeah, but the thing is that it's just unnecessary. isNaN() has been in the language forever. And in case you really need Number.isNaN() (because it's weird for isNaN('foo') to be true), it's been there for quite a long time too. Not enough to be on IE, sadly, but certainly more than enough to be on the modern JS engines React Native runs on. So, at least for React Native, the package number-is-nan shouldn't be necess…

no, isNaN has been in the language for quite a while, num !== num has been in the language forever.

which actually if I look at number-is-nan it returns

return typeof value === 'number' && value !== value;

I never use the typeof value === 'number' myself because I always know if what I'm checking is NaN should be a number of not, but probably that's a bad habit to get into.

Re: React Native for Windows and Mac

#457

Post by realharo »

mythz wrote: post #450
realharo wrote: post #437

Earlier quoted context omitted.

Yes, it is theoretically possible for a TypeScript type to be "wrong" and the underlying variable to have a different type. But there are only a few ways in which that can happen: - a bug in type definitions - a JS library with .d.ts files which "lie" about the actual types - this is no different than any other bug in a library, needs to be reported and fixed. In my experience, such bugs are not very common (I've yet…

> Yes, it is theoretically possible for a TypeScript type to be "wrong" and the underlying variable to have a different type. Unlike most languages, TypeScript is just a high-level static analysis compiler service that compiles to JS that executes in a JS VM. It has no control over what happens at runtime, it doesn't know about external libraries and user input, how its TypeScript functions are going to be invoked. A…

I know how it works. I'm talking about practical implications.

In practice, say I have

    type User = { name: string, email: string } 
    let loggedInUser: User = { name: 'Bob', email: 'bob@examaple.com' }
or even

    // Can't change the contents, only reassign the whole variable
    let loggedInUser: Readonly = ...
and only ever use that `loggedInUser` from TypeScript code (because my entire codebase is TypeScript), and I avoid the 3 scenarios mentioned above (buggy JS library type definitions, non-validated external data, casting/any/`!`).

How would a `null` email ever get inside `loggedInUser`? It just won't happen. I know there are no run-time checks - I don't need any run-time checks. I don't need 100% theoretical guarantees. I can be reasonably certain that `loggedInUser.email` will always be a non-null non-undefined string. It's a good enough™ practical guarantee. A null-check on `loggedInUser.email` would be pure confusing noise (because anyone reading it would go "wait, this can be null? I thought it was non-null").

Do you have a practical explanation of how a `loggedInUser.email === null` situation might occur given the above assumptions?

>Given any JS variable can be assigned both `undefined` and `null`

Any JS variable can be assigned literally anything. I don't need to check that `loggedInUser.email` is not null, just like I don't need to check that `loggedInUser.email` is not a boolean or a number. Because how would that even happen? Not having to do those checks is half the point of having a static type system in the first place (the other half is being notified of type errors at compile/edit time).

If you need to defensively check whether something so basic that is never supposed to happen has happened, then the code is already a giant unmaintainable mess.

Re: React Native for Windows and Mac

#458

Post by conradfr »

distantaidenn wrote: post #239
satvikpendem wrote: post #69

I tried using this a few months ago, as well as React Native for mobile and React Native Web for web, and I felt like they were all just hacks glued together to get cross-platform support, and RN isn't even native, it still includes a Javascript bridge. Build dependencies and packages were a nightmare, things continuously broke. I tried Flutter afterwards and it just felt like a breath of fresh air. Everything "just…

I've done a few client projects in the past using React Native. I get the appeal of having a "single" codebase for iOS and Android, but I absolutely detested using it. I'm quite sure and aware of people that love it, but just from my personal development background, it just never really seemed appealing to me. Definitely not a fan of how state is handled. I've rolled my own system, Redux, and a host of other solution…

Not sure why NativeScript and Ionic are not more popular on HN, I've seen more success with both of these than React-Native.

I guess the first is not backed by a big company and the second still has the Cordova stigma.

Re: React Native for Windows and Mac

#459

Post by vips7L »

pjmlp wrote: post #371
jamil7 wrote: post #358

Earlier quoted context omitted.

Some do, while I can't speak for the emacs community the (n)vim community is very active and engaged. There are modern vim plugins for nearly everything. The developers using VSCode tend to be developing on overpowered workstations where the difference is less noticeable. It doesn't mean it isn't wasteful. At some point we'll hit some upper bounds as an industry and have to rethink how we develop software, the trend…

> the trend back towards statically typed, compiled languages like Rust, Swift, Go are already leading us in that direction. Indeed, even Java and .NET are improving their AOT stories, while available since the early days, weren't as widely deployed as they could have been.

Hopefully soon Java will have a friction-less path to compiling to native. As of now, its quite difficult for anything that isn't trivial.

Re: React Native for Windows and Mac

#460

Post by hyperbovine »

rodinia wrote: post #444
e_proxus wrote: post #431

Earlier quoted context omitted.

Wouldn’t the alternative simply be bigger libraries grouped around common functionality or extension points? Like jQuery or similar (only an example, not sure what is hip today). I’d rather trust a fairly big library with an organized open source group behind it than thousands of small libraries by unknown developers.

fwiw, I've been doing professional JS (mostly server, good amount of client) for about 5 years now and have never pulled in a single function package before as a direct dependency. Every team I've been on has used Lodash or Underscore in the capacity you describe. https://lodash.com/docs/4.17.15 https://underscorejs.org/

I agree that this is the sane alternative, but sanity does not seem to be winning out. Our friend number-is-nan, for example, has 12 million downloads a week.

A week!

Post reply on HN