Live data from Hacker News

Hyperview – Native mobile apps, as easy as creating a website

hyperview.org

131–140 of 150 posts

Re: Hyperview – Native mobile apps, as easy as creating a website

#131
post #83

Earlier quoted context omitted.

What does this mean? There are plenty of big, native apps using React.

React is a web framework. You can put Native behind React, it'll never be.

React allows you to write custom renderer and React Native is a quick and dirty example of that custom renderer. The only reason it does not "feel native" is because Meta does not invest much into it and only subset of the "native" features is implemented in "native way".

Re: Hyperview – Native mobile apps, as easy as creating a website

#132

Earlier quoted context omitted.

I briefly investigated using React Native on a project. Obscure installation and linking process which no one seems to understand exactly, no SPM support on iOS, incomplete documentation that from the start pushes to adopt yet another layer on top (such as Expo, and I suppose Hyperview is now another option)… It felt like I am adopting some rusty legacy software, and not in a good way (more full of quirks than mature…

Probably has changed since then, but I remember the RN docs telling me to use Expo. I was wondering the whole time, do people actually use Expo or no. And why is it uploading my code to some website? Soon I had a clear answer; I had to "eject" from Expo to do a prod build or just add any native components. Not a good first impression. That said, RN was a win in the long run. It was a lot less baffling than the notori…

That hasn’t been true for quite a while. No need to upload code to build or submit, though it certainly makes it easier.

Re: Hyperview – Native mobile apps, as easy as creating a website

#133
post #128
post #126

Earlier quoted context omitted.

React Native actually constructs a view hierarchy in the platform's UI toolkit, so I'm curious what you mean by "still a webpage"?

But everything in that view hierarchy is still drawn using HTML and CSS, and all the logic is implemented in JS, no? If that's the case, then that's not "native".

No, it renders native views.

Re: Hyperview – Native mobile apps, as easy as creating a website

#134

Earlier quoted context omitted.

I briefly investigated using React Native on a project. Obscure installation and linking process which no one seems to understand exactly, no SPM support on iOS, incomplete documentation that from the start pushes to adopt yet another layer on top (such as Expo, and I suppose Hyperview is now another option)… It felt like I am adopting some rusty legacy software, and not in a good way (more full of quirks than mature…

Probably has changed since then, but I remember the RN docs telling me to use Expo. I was wondering the whole time, do people actually use Expo or no. And why is it uploading my code to some website? Soon I had a clear answer; I had to "eject" from Expo to do a prod build or just add any native components. Not a good first impression. That said, RN was a win in the long run. It was a lot less baffling than the notori…

For what it’s worth, the RN investigation I did was just last month, and impression was not good.

On the other hand, regarding iOS in particular, SwiftUI docs improved a lot recently. I remember them being baffling indeed from a few years back.

Re: Hyperview – Native mobile apps, as easy as creating a website

#135

>as easy as creating a website This strikes me as odd - I have a much easier time making a well-functioning native app (iOS or Android) than the equivalent website. That's not typically a checkmark in the web column for web vs app pros and cons. Unless we're including distribution when we say "creating".

Engineers have vastly different definitions of “well-functioning” and “easy”. Once I saw an app that used accelerometer API to determine in real-time whether the user is walking. It was done as a web app (native was considered too difficult) and the data was sent to GCP for processing. Even without the GCP code, which involved a custom ML model, it was in the hundreds of LoC. I don’t know how well it would function in real use, since it did not really reach mass production, but I do know it is possible to do completely on-device with very little bespoke logic and a very small LoC count on iOS (and I’m sure on Android) where APIs would give you exactly that (and even movement speed, if needed).

Re: Hyperview – Native mobile apps, as easy as creating a website

#136

Earlier quoted context omitted.

There's a pretty big difference in what UX "feels nice" to East Asian audiences vs Western audiences. This video provides some insight into why this might be: https://www.youtube.com/watch?v=WSMFnJnY7EA

The comments make it seem like it's more a case of users tolerating it due to the apps usefulness. Interesting video though, haven't had any contact with Chinese apps, so that was enlightening.

Tolerance of bad UI because of its usefulness (or if it is the only available option due to approval process and/or lack of competition) strikes me as a time-tested approach in enterprise environments. I dread to imagine that, but in real life. Is that how it is for people in the most populous country?

Re: Hyperview – Native mobile apps, as easy as creating a website

#137
post #14

Ah finally the Western tech ecosystem has caught up with WeChat/Alipay mini programs. https://developers.weixin.qq.com/miniprogram/en/dev/framewor... China had this DSL for building mobile apps for years. Those these apps are initially embedded inside WeChat/Alipay, there are now frameworks that allow it to run outside, like uniapp. https://en.uniapp.dcloud.io/

I've had very limited exposure to Alipay mini-programs (took a daytrip to Shenzhen from HK); but anything I had to touch (couples of restaurant menus; buying tickets for metro) was _screaming_ "this is poorly constructed webpage", not native-like experience. Are there some you would recommend to see as an example of it being done right?

> poorly constructed webpage", not native-like experience

yes "poorly constructed" is the key here. Poorly constructed "native" apps are not better.

Let's not pretend that all apps need native capabilities. The vast majority of them, or the vast majority of their functionality, can boils down to showing lists and images. Pretty wasteful to make apps in native languages just to do that if you ask me.

Re: Hyperview – Native mobile apps, as easy as creating a website

#138
post #126

Earlier quoted context omitted.

React Native actually constructs a view hierarchy in the platform's UI toolkit, so I'm curious what you mean by "still a webpage"?

React Native constructs only single UIView by default and draw actual UI using poorly man browser engine using JS. This UI does not "feel native" to user, because it has wrong animation timings, scroll speed, border elevation, missing "native" gestures, etc.

That is certainly true of Flutter, which has its own rendering pipeline. React native, if you create a Button then on iOS you'll get an actual UIButton instance constructed, etc.

Re: Hyperview – Native mobile apps, as easy as creating a website

#139

Earlier quoted context omitted.

JSON is same as XML.

No it isn't, XML is an ecosystem with things like dedicated transfer protocols (EXI), schemas (XSD), transformers (XSLT) that JSON still doesn't have standardized/normalised even though JSON has been the norm for nearly 20 years. There's some projects of course (JSON Schema, OpenAPI), but they're separate and not part of the same standardization committee.

I don't remember anything about the XML ecosystem, but XML is already a totally different format from JSON without considering that.

  
    hi
    hi2
    hi2
  
can be thought of as nested objects, each having a typename, text content, and children. It doesn't translate nicely to JSON. Maybe:

  {"type": "body", "attrs": {"myattr": "yeah"},
   "children": [{"type": "thing", "content": "hi"}, ...]}

Re: Hyperview – Native mobile apps, as easy as creating a website

#140
post #47

Earlier quoted context omitted.

JSON is great in it's own regards but the features are not comparable.

At least with XML, you can have custom datatypes, not just strings and numbers and booleans. In all seriousness, everything in JSON can be expressed as XML; but not necessarily the other way around.

Other way around works too (I gave an example above), it's just not pretty in either direction.

XML makes sense for open-ended, human-written things like documents or apps. It doesn't work so well for APIs and other machine-read/written things where you'd normally use JSON.

Post reply on HN