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

Vue Native

vue-native.io

Post reply on HN
Print view View original

121–130 of 208 posts

Re: Vue Native

#121

Post by giancarlostoro »

lwansbrough wrote: post #66

Here's my pitch for a better ecosystem: we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM. Shells (browsers, native platforms like React Native but without the React requirement, etc.) would give JS renderers access to the lowest level painting calls available (ie. "repaint this node") along with programmatic access…

Wonder where Cordova falls under in this regard?

https://cordova.apache.org/

I think Cordova could be leveraged at the very least.

Re: Vue Native

#122

Post by k__ »

ivm wrote: post #41

Ironically I just saw the tweet about Udacity team removing React Native from their apps: https://twitter.com/n8ebel/status/1006244834351312897

I can understand this.

I already planned 3 weeks for the Android port of an app.

But probably still better than the 5 months the iOS app took to make.

I have to set up an Android build environment and install all the Android versions of my native modules.

Since iPhones required dynamic sized UIs for iPhone5/iPhone/iPhone+/iPhoneX anyway, I expect to use most of the UI code without any change.

Re: Vue Native

#123

Post by ben_w »

securityfreak wrote: post #108
matthewmacleod wrote: post #85

Earlier quoted context omitted.

Frankly I find your view pretty offputting. I’m not really that into the idea of JS-as-a-platform, but it obviously emerged because it fulfilled certain requirements that weren’t covered elsewhere. The “way back” from this is for people like yourself to stop dismissing others’ work as “idiocy” and start building better solutions to these problems as you see them.

Maybe "idiocy" is unnecessarily strong, but I certainly don't have to praise all emerging experiments just to sound polite, do I? The emerging of all these stacks is because of approachability. Everyone has a browser. Anyone who wants to create their first website can do so, by opening up e.g. notepad. By this approach you get low-quality, self-taught JS "experts" who are much cheaper to hire than a proper software e…

> but I certainly don't have to praise all emerging experiments just to sound polite, do I?

Speaking from personal experience, I have found it vastly more productive to focus on the good than the bad. Yes, even in situations where the other person is literally [1] too dumb to put their underwear on correctly without assistance.

I don’t know how or why it works to do that, but it does, and the improvement from doing so is immense.

[1] Alzheimer’s.

Re: Vue Native

#124

Post by jinglebells »

k__ wrote: post #120
jbverschoor wrote: post #117

Earlier quoted context omitted.

And there's no need to make bridges. Simply access the native API from javascript/typescript

NativeScript simply binds to all native APIs by default?

Effectively yes, but not like that. You can access all native APIs with a marshalling layer which maps Javascript to Objective C or JAVA.

For example, when the Javascript parser sees

   var className = NSStringFromClass(NSArray);
The ObjectiveC side executes

    NSString *className = NSStringFromClass([NSArray class]);
Then creates a link between the JS object and the ObjectiveC object. Any methods/properties you access on the JS object, get executed or read from the native component.

It's really quite clever and why we use Nativescript to bring corporate apps to market quickly and cross platform while not worrying about the limitations of the Javascript bit, because you can always access the native APIs anyway.

Re: Vue Native

#125

Post by k__ »

ilurkedhere wrote: post #30

I'm confused. Wouldn't "native" imply it uses platform widgets rather than HTML?

This is what React-Native (which Vue-Native is build upon) does.

Instead of

    Hello
you have

    Hello

Re: Vue Native

#126

Post by Aissen »

lwansbrough wrote: post #66

Here's my pitch for a better ecosystem: we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM. Shells (browsers, native platforms like React Native but without the React requirement, etc.) would give JS renderers access to the lowest level painting calls available (ie. "repaint this node") along with programmatic access…

It's funny because Netflix's Gibbon and YouTube's Cobalt already use some of those ideas. At least the latter is open source. Flutter is built with the same thinking. There will be some kind of convergence in the coming years.

Re: Vue Native

#127

Post by [deleted] »

sireat wrote: post #103
re-actor wrote: post #97

Earlier quoted context omitted.

We are in the odd position where HTML + JS + UI framework (Vue/React) is just by far the best way to create good user interfaces. The performance hit is not going to stop anyone from using or developing software like this. There is NO good alternative.

For certain values of good user interfaces perhaps. There has got to be a better way forward for mobile UI. For desktop creating UI on something like QT designer or XAML on WPF is way more pleasant than HTML+JS+UI framework . Even Actionscript was less convoluted that this mess. I love writing React code but these abstractions are getting too elaborate. I had high hopes for WebComponents but support for those seems t…

[deleted]

Re: Vue Native

#128

Post by k__ »

jinglebells wrote: post #124
k__ wrote: post #120

Earlier quoted context omitted.

NativeScript simply binds to all native APIs by default?

Effectively yes, but not like that. You can access all native APIs with a marshalling layer which maps Javascript to Objective C or JAVA. For example, when the Javascript parser sees var className = NSStringFromClass(NSArray); The ObjectiveC side executes NSString *className = NSStringFromClass([NSArray class]); Then creates a link between the JS object and the ObjectiveC object. Any methods/properties you access on…

Haha, nice.

First time I heared about this killer-feature :D

Re: Vue Native

#129

Post by wjoe »

filleduchaos wrote: post #86
notamy wrote: post #60

Earlier quoted context omitted.

> 32 to 64GB of onboard storage. If only. Probably a lot closer to 4-16GB for a lot of Android phones.

Thankfully even the shitty low-end phones I see these days have 8GB ROM

Of which 7GB is taken up by the OS and system apps.

I was kinda exaggerating, then I checked my phone and there's actually 15GB used by the OS.

Re: Vue Native

#130

Post by vlozko »

ldng wrote: post #89
danielrhodes wrote: post #74

Earlier quoted context omitted.

I've been down this road: it did not end well. Facebook also went down this road and seems to have realized something similar (and hence why they pulled back on HTML5 on mobile and have not attempted to make React Native fully cross platform). The reason why is essentially every platform (iOS/Android/web) has its own characteristics, charms, quirks, habits, and behaviors. Trying to smush these all into one unified UX…

I kind of disagree, the argument back then (6 years ago) was that the rendering was slow. That argument has not been revisited since. And new ones were made along the way. IMHO, Facebook was just looking for developers mindshare. If the core of your app is bloated, speeding up rendering is pretty moot. I'd love to see the argument revisited today.

React native to this day is not performant. On iOS the difference may not be as noticeable for most UIs as most iPhones have pretty powerful processors, even for devices 3-4 years old. However, on Android, it’s a crapshoot.
Post reply on HN