Live data from Hacker News

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

hyperview.org

141–150 of 150 posts

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

#142
post #46

"Serve your app as XML" As someone who started his professional career in 2005: All the old is new again.

I wonder what going back to the 90's will bring up.

Was going to say "please no XMPP again," but apparently that was 2000.

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

#143
post #138

Earlier quoted context omitted.

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.

It is true for a few components derived from TouchableOpacity like Button, sure. That is NOT true for most other components. You does not have UICollectionView, UINavigationView (only solvable with third-party buggy components), etc.

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

#144

Earlier quoted context omitted.

The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner. I get that in theory a PWA can do offline stuff and whatever, but 99% of the time someone is only making a PWA to make the app installable on a phone home scre…

It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it. Service workers are just JavaScript that runs in the background in their own process in a browser. Could think of them as separate threads. Anyway, all of that can be done in less than 20 lines of JS? I consider it simple compared to people building React apps and making the proc…

Yeah, it's no big deal, I just find it odd that it's even a requirement. And using React doesn't get you out of making a service worker either.

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

#145

Earlier quoted context omitted.

You're making it sound as if the difference in choice between China and western countries is negligible. Surely that's not the case? If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens. I could be wrong of course, since I don't know how many AliPay and WeChat competitors there are.

> If every VC company tries to pull you into their walled garden, I can still choose from among a variety of said walled gardens. When they play it right, you're forced to choose all of them , or at least a significant subset of them, so that their partially overlapping offering add up to the actual thing you need.

Ah, modern video streaming services and every restaurant's special snowflake app.

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

#146
post #63

"Serve your app as XML" As someone who started his professional career in 2005: All the old is new again.

The web is, was, and forever will be stuck reinventing shitty versions of things that they could have had decades earlier if they stuck with XML. Custom elements, client side templating, form validation against schemas, they had it all and threw it away.

Yup. They’re learning why XML needed to be complicated, one simplistic bolt-on HTML/CSS/JS layer at a time in a musical chairs fashion.

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

#147

"Serve your app as XML" As someone who started his professional career in 2005: All the old is new again.

I think webapps should be xml (with all the data to display) transformed into html on the client side with XSLT generated by framework templating system). There's a really nice binary XML format that browsers haven't implemented yet: https://en.m.wikipedia.org/wiki/Efficient_XML_Interchange

How would such a webapp make API calls and act on the responses? Even for a static website, HTML isn't very good at handling arbitrary sizes, which I think was part of the original motivation for React.

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

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

With respect, literally the exact opposite is true. I think you're mistaking it with something else.

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

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

So incredibly true. And that one time you see what XML can do that little else can.

Like that time there were hundreds of forms to build, refused, held a silent protest until a reasonable way presented itself.

Enter "XML Form Template" or "XML Form Definition.", A form is generated from the XML in html, filled in, and on submit, the XML is filled back in.

Built one form renderer and done. Never got old watching it.

XForms (W3C standard)

https://www.w3.org/TR/2003/REC-xforms-20031014/slice2.html

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

#150

Earlier quoted context omitted.

The service worker thing is a weird amount of boilerplate. Every time I go back to making a PWA, I skip through 10 search results explaining what a service worker is (idc) until I just find whatever .js code I have to copy. And it's not some trivial one-liner. I get that in theory a PWA can do offline stuff and whatever, but 99% of the time someone is only making a PWA to make the app installable on a phone home scre…

It is not a trivial one liner no, but you need 3 events implemented in your service-worker file, then in your main.js file you register it. Service workers are just JavaScript that runs in the background in their own process in a browser. Could think of them as separate threads. Anyway, all of that can be done in less than 20 lines of JS? I consider it simple compared to people building React apps and making the proc…

You can't run native ads or handle payment via store with pwa
Post reply on HN