
Vue Native - tomcam
https://vue-native.io
======
lwansbrough
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 to the new standard UI API. Renders could then
build on top of that API, implement the draw call optimizations themselves
based on whatever makes sense for the rendering engine (for instance, React
Fiber would be issuing draw calls differently than Vue's rendering engine.)

This would allow developers to get native performance out of a web-based
rendering context. It would also be theoretically easy to build new renderers
around the standard UI API. So you could swap out your backend between
browser-native and a mobile/desktop library backed by OpenGL/WebGL, or another
headless solution, etc.

Importantly, I think you need to limit the scope of this new UI standard
(perhaps just to basic shapes, like how SVG is similarly limited), that way
you leave UI implementations like dropdown boxes to ecosystem programmers (so
you'd have a dropdown box for each React, Vue, etc. -- this sounds bad but
people do this already.) Limiting the API scope also means making it easier
for new renderers to enter the scene. Compare such a world to the current
hellscape that is building your own HTML renderer. The API is so insane it's
really only possible for big companies to take it on (Google, Microsoft,
Apple, Mozilla.)

How this ties back into this post: you could create an _____ Native, which
would really just implement everything you want from React Native, but without
React. Then you can just plug Vue or React into the renderer and boom you're
done.

Edit: Observant people will notice my ideal system resembles X11. Indeed, I
think X11 is an interesting proposition in "shell" (browser, native) contexts,
as shell applications are inherently window-managed and sandboxed. This allows
for applications to reinvent the wheel without disrupting the fundamental UX
of window management on the system OS.

~~~
danpalmer
While I admire your hopefulness that this could solve the problems, I don’t
think it will for two reasons.

1\. This is what the DOM is, to some extent. All those components on the page
are “native” components, we have declarative markup for them (HTML) and we can
script them. They are “rendered” by native code in browsers which are some of
the most highly optimised codebases around.

2\. The API design for JS and for higher performance systems is quite
different. Take UITableViewDataSource for example, it does view prefetching,
caching, object reuse, etc. As of iOS 12, this also feeds into the CPU
throttling control to ensure enough compute is available on a cell fetch that
it will meet the 8-16ms deadline so that no frames are dropped. This is just a
totally different way of thinking about APIs and performance that the JS
ecosystem is not designed to work with.

It’s possible that a total rewrite of that stack could provide significant
benefits, but I think that would be more from removing legacy cruft in the
DOM, than from it being a paradigm shift.

~~~
lwansbrough
Your UITableViewDataSource is a common problem with big JS applications, and
has been solved to some extent with the same optimizations you've mentioned.
However because JS and HTML is what it is, it has to be solved on a per-
library basis (React Virtualized List, Vue Virtualized List, etc.) The problem
remains that the JS renderer does not have access to those low level draw
calls to optimize performance further.

As for the DOM, again I think that while it's true that native HTML elements
are highly optimized, many applications have much larger performance goals in
mind and HTML/DOM has proven to be an ineffective system when trying to do
very specific performance optimizations. Check out flipboard.com on your phone
for an example of how much smoother a web app can feel when you bypass the DOM
and let React take over the draw calls.

~~~
stefanfisk
AFAIK all virtual lists break native searching in the browser, so sadly the
problem is far from solved

~~~
danpalmer
Well browsers are probably doing virtual lists themselves, it's just that the
JS/DOM API doesn't provide a way to expose that to the application developer,
which means the impact will be limited.

------
hardwaresofton
I prefer NativeScript[0] & it's vue-specific extension NativesScript Vue[1]
due to NativeScript's ability to work with more than one paradigm/framework.
NativeScript enables _any_ Javascript application to become a mobile app
(along with ones built in Angular and Vue) and I think that's pretty great.

[0]: [https://www.nativescript.org/](https://www.nativescript.org/)

[1]: [https://nativescript-vue.org/](https://nativescript-vue.org/)

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

~~~
k__
NativeScript simply binds to all native APIs by default?

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

~~~
k__
Haha, nice.

First time I heared about this killer-feature :D

------
reilly3000
This is the only missing piece that has held me back from jumping into Vue. I
know its not the most advantageous aspect of the framework, but my personal
favorite aspect of it is the single file components. Being able to create a
complete logical unit of UI of in one file feels more natural and produtive.
All the speed of inline styles without the guilt and shame.

~~~
sideproject
Yes! :) I've been using VueJS for awhile and my next step was to create a
mobile app - either via RN or even Flutter. But, hello vue-native!

~~~
pdanpdan
You can also give a shot to Quasar (quasar-framework.org) that will provide
you with single code base SPA, PWA and mobile through Cordova, and in a few
days also SSR.

Disclaimer: I'm also contributing on this project.

------
arendtio
For those who haven't heard of it, there is a project to render native desktop
applications with Vue too:

[https://github.com/mimecorg/vuido](https://github.com/mimecorg/vuido)

------
maxwell2022
> Vue Native transpiles to React Native.

Why would you not use react native directly then? I don't get it

~~~
neya
A lot of us prefer Vue over React, I for one favor Vue over React personally
and have been using it in all my recent projects. So, just a matter of
preference for those who don't want to use React.

~~~
mieseratte
I'm curious, what do y'all actually like about Vue over React? I spent over
two months doing proof-of-concept migration work for an AngularJS to (React-
Redux|Vue-Vuex) and, other than the component-data wiring it does internally,
I found it to be worse in nearly all respects.

Despite being an "opinionated" framework, Vue provides so many escape hatches
and alternatives that it, in practice, hardly seems opinionated. Additionally,
the templating language it promotes seems like a step backwards compared to
JSX render functions. As it were, the "unopinionated" React, by offering a
small handful of primitives, ends up making things simpler and more ergonomic
to work with.

I really can't seem to grok why folks like Vue over React.

~~~
Kihashi
I got into Vue because it was much easier to approach coming from a back-end
(Python/Flask/Jinja or PHP/Symfony/Twig) perspective. It made it easy to adopt
small pieces and learn as I went. React probably allows this sort of thing,
too, but the documentation for Vue pointed it out first thing. Since I've
started working with it, I haven't gotten a compelling reason to change to
react or angular.

~~~
mieseratte
> React probably allows this sort of thing, too, but the documentation for Vue
> pointed it out first thing.

That's actually a pretty good difference I hadn't really thought about from
the other perspective. React does a good job explaining the how and why, but
is a bit more clinical leaving the last-mile as an exercise to the reader
whereas Vue seems a bit more focused on coaching you.

I, personally, found Vue's documentation to be a bit less in-depth than I like
and hadn't considered folks would prefer Vue's.

------
ivanfon
How does this compare to nativescript-vue?

[https://nativescript-vue.org/](https://nativescript-vue.org/)

~~~
hardwaresofton
It looks like Vue Native is a wrapper around React Native UIs
[https://github.com/GeekyAnts/vue-native-
cli](https://github.com/GeekyAnts/vue-native-cli) (in the README)

I personally am following/want-to-use [https://nativescript-
vue.org/](https://nativescript-vue.org/)

------
inopinatus
Their website may have repurposed the look and logo of the Vue project, but
(unlike React Native's relationship with React) this doesn't appear to have
any official association. In particular, Evan You called it an "interesting
approach" but added "not endorsing this"[1].

[https://twitter.com/youyuxi/status/1006565660091125760](https://twitter.com/youyuxi/status/1006565660091125760)

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

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

Instead of

    
    
        <div>Hello</div>
    

you have

    
    
        <View><Text>Hello</Text></View>

------
quangio
Similar projects:
[https://weex.incubator.apache.org/](https://weex.incubator.apache.org/)
[https://www.nativescript.org/](https://www.nativescript.org/)

I think Weex has better performance and lighter overhead than this(?)

~~~
kendallpark
I'd love to get a side by side comparison of Weex and Vue Native.

~~~
shubham_sinha
Weex lacks english documentation and most of the Weex devs are from China and
support forums also tend to be in Chinese. By far RN has best documentation
and plugin / package ecosystem. A full fledged app can be built using RN.
Whereas it'll be hard for Weex, Vue-Native. Just search for Google Maps
package for any of these frameworks, you'll have tough time finding any
(barring React Native)

------
mgalka
Ironic the site does not seem to be responsive

~~~
sanketsahu
Going to fix it ASAP.

------
ivm
Ironically I just saw the tweet about Udacity team removing React Native from
their apps:

[https://twitter.com/n8ebel/status/1006244834351312897](https://twitter.com/n8ebel/status/1006244834351312897)

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

------
jefflombardjr
> How does it work?

This is fork of react-vue

[https://vue-native.io/docs/how-does-it-works.html](https://vue-
native.io/docs/how-does-it-works.html)

------
codesternews
It's based on react-vue[1] and It is internally using react-native.

1\. [https://github.com/SmallComfort/react-
vue](https://github.com/SmallComfort/react-vue)

Why but Why.

~~~
securityfreak
I honestly do not understand how did a large part of the software engineering
community get to this point of idiocy.

Is this due to the principle of getting to the market first and quick
prototypes? I don’t see a quick way back.

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

~~~
securityfreak
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 engineer with fundamentals of computer science.
After a few years these developers feel so confident, they decide to launch
their own perfect new framework/library to solve all the problems they
experienced!

There is a better solution. It's called native app development, without a
hyphen of any sorts in front of "native". Different platforms have different
quirks and there is no way to have the exact same UI/UX on all platforms.

The true challenge is to explain the executives, that hiring 2 developers will
be much better in the long run, than 1 underpaid JS developer for all
platforms.

~~~
m_fayer
I used to agree with you. But over the last few years, in their own ways,
Apple and Microsoft have dropped the ball on their native desktop UI toolkits.
So, whereas the argument for native used to be "rewrite your client once per
platform, and you get a better language, better performance, better usability,
and a better development experience", now it's "rewrite your client once per
platform and you may get a better language, depending on your taste, probably
better performance, an aging closed-source toolchain, an outdated development
paradigm, outdated APIs covered in legacy-barnacles, debugging-resistant
performance pitfalls, and decent usability if you're ok with a generic one-
size-fits-all look (and you're on your own if you're not.)" In other words,
the argument for native, and native development itself, is not aging well.

------
dvdhnt
Site is broken on mobile. Styling issues make it undreadable.

~~~
xrd
It's hilarious that you can't view this site on native browsers. How ironic!

------
steiner_j
I'm genuinely confused as why this is getting so much attention. The
NativeScript-Vue integration is out for over a year already. It fulfils
exactly the same purpose, without the additional strange cross-
compilation/transpilation.

------
elyobo
Page consists of an example (useful) and slides (not). Might look again once
there's some useful content; slides aren't _quite_ as bad as a video, but it's
pretty awful.

Edit: ah, the get started links to real content. Missed that.

~~~
zpr
Maybe you also didn't notice you can scroll down on the slides to get more
info on the headlining topic (I missed it at first).

------
baybal2
I'm no longer a career webdev, but when I still do need to do something front-
end related, Vue is a tool of choice. I really like Ethan's non-doctrinal
approach, and that Vue is as isolated from dreaded committee designs of opens
source projects invaded by corporate types.

I still regard GTK+ as one of the best C GUI toolkits. Particularly when it
comes to thought-through design of layouting mechanism and that the widget lib
was build with ergonomic in mind.

When you work with UIs in plain C, you invariably come to getter-setter
pattern.

I wonder, can Vue guys somehow glue Vue components to GTK widgets?

------
pier25
Considering there is already Weex and NativeScript with Vue, what does this
add?

Personally I think Flutter will become the dominant cross platform solution in
2020 or so. ReactNative has always seemed like a hack to me.

~~~
spraak
What about it seems like a hack? Why do you think Flutter will become
dominant?

~~~
pier25
Flutter basically works like a game engine. It has a rendering area and it
uses Skia to paint stuff. This means it has a lot of control over what's going
on and the bridge to the OS is minimal.

ReactNative is basically giving tons of instructions from the JS engine to the
OS. Sure the performance of the OS is great, but this has limitations and many
moving pieces.

For example animations used to be a problem in RN because someone thought it
was a good idea to send instructions on every frame from the JS engine to the
OS. Of course many devices can't keep up with this, and I imagine Facebook
solved this by creating an animation engine on the native side of things and
JS only passing start/end states and such.

------
snarfy
Aren't native Vue apps already supported with Weex[1]? Why would I use this
over Weex?

[1] -
[https://weex.incubator.apache.org/guide/](https://weex.incubator.apache.org/guide/)

------
tribby
what's the difference between this and react-vue?[1]

I would prefer to be using weex, but that project has seemed stagnant ever
since it became part of the apache foundation. or at least, they haven't
really updated their site or fleshed out the docs etc. it's very hard to get
buy-in from other developers because of that.

1\. [https://github.com/SmallComfort/react-
vue](https://github.com/SmallComfort/react-vue)

------
htormey
Can someone explain what the differences are between React and Vue? Why is
this a good idea and what benefits would it afford me as a React Native
developer?

~~~
neya
This page is a good start, it discusses the differences in detail:

[https://vuejs.org/v2/guide/comparison.html](https://vuejs.org/v2/guide/comparison.html)

My personal experience wasn't that positive with React and then, the whole
treatment of JSX as a first class citizen isn't really my style (although
you're allowed to use React without involving JSX). Vue just feels more mature
(personal opinion) and much, much easier to reason your code about, down the
line in 6 months.

I've had super-complex apps that required so many nested components and I had
no problem picking them up after about 6 months. With react, you have to be
careful as it's easier to shoot yourself in the foot (personal opinion).

Also there's flux, redux which do require a bit of a learning curve if you
want to architect your applications using them. Vue has something called Vuex
which again, in my opinion is slightly friendlier to beginners.

I re-wrote my entire teaching syllabus for my programming course to use Vue
instead of React, simply because it's much better to maintain Vue apps rather
than React apps after 6 months, which is the most important value add for me
in any framework.

Anyone can pick up a trendy new JS framework and hack a TODO app over the
weekend these days, but if you're working on client side, or some serious
projects that require long term commitment and maintenance, then you will
realize it's more important to consider the framework's maintainability and
code readability. For me, Vue triumphs React in this aspect easily.

So, there you go.

~~~
spicyj
> I re-wrote my entire teaching syllabus for my programming course to use Vue
> instead of React, simply because it's much better to maintain Vue apps
> rather than React apps after 6 months, which is the most important value add
> for me in any framework.

Why do you find it harder to maintain React apps after 6 months?

~~~
neya
One of the main reasons - JSX. Contrary to popular belief, JSX is all cool
until you're in a situation where you need to maintain the app you wrote.

I know React can be written without JSX as well, but frustratingly most
documents/resources online are all examples with JSX.

And then, this:

[https://twitter.com/thomasfuchs/status/810885087214637057](https://twitter.com/thomasfuchs/status/810885087214637057)

~~~
jhall1468
That doesn't really clarify your position. JSX is a syntax, why in the world
does that cause maintainability issues? And that tweet is a massive straw man.
It's poorly spaced, poorly written and YEARS after React came out it shows
that people still don't understand the difference between separation of
concerns and separation of languages.

------
pietrovismara
The funny thing? The website renders for desktop on my S8, making it
completely unusable.

------
mathiasrw
Anyone else getting "This site is blocked due to a security threat."?

------
jacob019
So are all those beautiful UI elements in the kitchen sink demo included?

------
pjmlp
I get an HSTS error while accessing the web site.

------
rubyn00bie
Pardon my ignorance on the matter, and I’m truly sincere when I ask, but why
does there need to be a *-native library for “each” different JavaScript
framework?

Why this instead of say Electron or something that seems, to me, to be more
general purpose and thereby useful[1] (I’m not coupling my mobile apps to a
single JavaScript framework).

... I suppose “React” is more of an API now-a-days, and so it may not be so
bad to port to another transpiler/compiler/build system? But I still feel like
I’m missing something. Are folks writing games in React or something that
requires the performance optimization’s from a specific build system? If so
would anyone mine showing an example? Or just learn me in general?

Many thanks.

1\. Don’t take “useful” personally please. I mean it mostly in the context of
shipping and supporting an app for a few years. Which... is probably not the
best _use_ of “useful.”

~~~
filleduchaos
Christ, Electron would be truly terrible for mobile apps.

All the excuses people have for its bloat ("we all have tons of RAM anyway!",
"storage space is cheap!", etc) evaporate when you're running on an ARM
processor with maybe 2GB of RAM and 32 to 64GB of onboard storage.

~~~
notamy
> 32 to 64GB of onboard storage.

If only. Probably a lot closer to 4-16GB for a lot of Android phones.

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

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

------
EugeneOZ
App stores should be abandoned, web app is the only thing you can 100%
control.

If you can't publish critical update for your app in minutes, just because you
use phone vendor's store, then that store is a huge priblem.

If store can just uninstall your app in any moment (without user's request) -
it is a huge problem.

