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.
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.
This assumes the web rendering context is the proper abstraction to build application UIs. Its not. Its too complex and object-oriented to be efficient. It was intended for documents and is a general pain to work with for applications.
For one, there's a lot to be learned from immediate-mode UIs (I'm thinking Dear IMGUI, not Unity3D's GUI); ie state inside components generates complexity, which is a bad thing. Your views should be nothing more than a pure FSM transforming app state to UI directives. IMGUIs have a ton of tricks to simplify UI development. With these in mind, FP becomes a much more interesting paradigm than OOP for this. The same logic applies whether you render the entire UI 60 times a second or you cache the previous render to only do the minimum amount of updates.
A good abstraction is one where features can emerge from its design. For example you rarely have to test your views when they're just a simple pure transform. You don't need an entire framework and command-patterns to implement undo when your app state is immutable and modelled as a sequence of actions. With each emergent feature you remove the need for tons of code and tooling; that yields agility.
I still believe most web application are much more complex than they should be, especially on the UI level, regardless of the framework used. And until we solve that problem, I don't think the web stack is the way to go for native. We're just replacing one set of problems for another one.
I strongly believe we shouldn't make things easier, but simpler.
> we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM
The problem is: the platform owners (Apple and Google) have absolutely no incentive to make this see the day of light. They make money selling apps, and want to bind developers to their platform.
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.
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.
Yep, NativeScript looks neat and we're starting to dive into it at my office. Trying to head into a direction where we can extract out a bunch of JS logic and share it between a NativeScript-Vue repo for mobile apps and our main Laravel/Vue app.
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.
FWIW, the next version of Ionic (in beta) decouples from Angular, so that people can use the tools and platform support of Ionic to build mobile apps with Vue, or whatever they prefer.
This uses react-native, I would not consider jumping on the Vue ship if you've been waiting for a native solution.
This seems more like a hack-y way of going about it.
Some other solutions are out there, one of the main ones being nativescript. However it feels like the community still hasn't "agreed" on a solution like React did.
To my knowledge, Vue still does not have anything official around native.
I would consider waiting for now, unless this proposed solution suits you.
(This doesn't mean you shouldn't start using Vue elsewhere however, I have been using it for the past few months at work on a pretty large-scale project and it is my favorite library by far, for many different reasons).
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.
This is ironic, given that a lot of people advocating for vue on the web talk about how it's better because it doesn't involve all that complicated transpilation.
Since the underlying tech is React Native (Vue Native) and Nativescript (Nativescript Vue), here's a comparison (albeit written by someone from Progress/Telerik, who maintain nativescript): https://www.quora.com/What-are-the-key-difference-between-Re...
It doesn't touch on the Vue integration, since that's relatively new.
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].
Probably they are just people and didn't have the time to write a responsive css, which is not as simple as it sounds, especially if you are not using a grid framework.
Feel free to fork the site's code and send them a PR.
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.
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.
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?
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.
[+] [-] lwansbrough|7 years ago|reply
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|7 years ago|reply
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.
[+] [-] jeremiep|7 years ago|reply
For one, there's a lot to be learned from immediate-mode UIs (I'm thinking Dear IMGUI, not Unity3D's GUI); ie state inside components generates complexity, which is a bad thing. Your views should be nothing more than a pure FSM transforming app state to UI directives. IMGUIs have a ton of tricks to simplify UI development. With these in mind, FP becomes a much more interesting paradigm than OOP for this. The same logic applies whether you render the entire UI 60 times a second or you cache the previous render to only do the minimum amount of updates.
A good abstraction is one where features can emerge from its design. For example you rarely have to test your views when they're just a simple pure transform. You don't need an entire framework and command-patterns to implement undo when your app state is immutable and modelled as a sequence of actions. With each emergent feature you remove the need for tons of code and tooling; that yields agility.
I still believe most web application are much more complex than they should be, especially on the UI level, regardless of the framework used. And until we solve that problem, I don't think the web stack is the way to go for native. We're just replacing one set of problems for another one.
I strongly believe we shouldn't make things easier, but simpler.
[+] [-] jcelerier|7 years ago|reply
http://qmlbook.github.io/en/ch04/index.html
[+] [-] amelius|7 years ago|reply
[+] [-] Aissen|7 years ago|reply
[+] [-] mda|7 years ago|reply
[+] [-] giancarlostoro|7 years ago|reply
https://cordova.apache.org/
I think Cordova could be leveraged at the very least.
[+] [-] mark_edward|7 years ago|reply
[+] [-] basch|7 years ago|reply
https://engineering.flipboard.com/2015/02/mobile-web
[+] [-] sanketsahu|7 years ago|reply
[+] [-] hardwaresofton|7 years ago|reply
[0]: https://www.nativescript.org/
[1]: https://nativescript-vue.org/
[+] [-] dabernathy89|7 years ago|reply
[+] [-] jbverschoor|7 years ago|reply
[+] [-] pstuart|7 years ago|reply
[+] [-] reilly3000|7 years ago|reply
[+] [-] sjellis|7 years ago|reply
[+] [-] sideproject|7 years ago|reply
[+] [-] sebastienrocks|7 years ago|reply
Some other solutions are out there, one of the main ones being nativescript. However it feels like the community still hasn't "agreed" on a solution like React did.
To my knowledge, Vue still does not have anything official around native.
I would consider waiting for now, unless this proposed solution suits you.
(This doesn't mean you shouldn't start using Vue elsewhere however, I have been using it for the past few months at work on a pretty large-scale project and it is my favorite library by far, for many different reasons).
[+] [-] arendtio|7 years ago|reply
https://github.com/mimecorg/vuido
[+] [-] maxwell2022|7 years ago|reply
Why would you not use react native directly then? I don't get it
[+] [-] neya|7 years ago|reply
[+] [-] zappo2938|7 years ago|reply
[+] [-] woah|7 years ago|reply
[+] [-] ivanfon|7 years ago|reply
https://nativescript-vue.org/
[+] [-] hardwaresofton|7 years ago|reply
I personally am following/want-to-use https://nativescript-vue.org/
[+] [-] Kihashi|7 years ago|reply
It doesn't touch on the Vue integration, since that's relatively new.
[+] [-] inopinatus|7 years ago|reply
https://twitter.com/youyuxi/status/1006565660091125760
[+] [-] ilurkedhere|7 years ago|reply
[+] [-] quangio|7 years ago|reply
I think Weex has better performance and lighter overhead than this(?)
[+] [-] threeseed|7 years ago|reply
Xojo: https://www.xojo.com
Flutter: http://flutter.io
[+] [-] kendallpark|7 years ago|reply
[+] [-] mgalka|7 years ago|reply
[+] [-] sanketsahu|7 years ago|reply
[+] [-] squiggy22|7 years ago|reply
[+] [-] kingosticks|7 years ago|reply
[+] [-] ivm|7 years ago|reply
https://twitter.com/n8ebel/status/1006244834351312897
[+] [-] k__|7 years ago|reply
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|7 years ago|reply
This is fork of react-vue
https://vue-native.io/docs/how-does-it-works.html
[+] [-] codesternews|7 years ago|reply
1. https://github.com/SmallComfort/react-vue
Why but Why.
[+] [-] dvdhnt|7 years ago|reply
[+] [-] xrd|7 years ago|reply
[+] [-] xab9|7 years ago|reply
Feel free to fork the site's code and send them a PR.
[+] [-] steiner_j|7 years ago|reply
[+] [-] elyobo|7 years ago|reply
Edit: ah, the get started links to real content. Missed that.
[+] [-] zpr|7 years ago|reply
[+] [-] baybal2|7 years ago|reply
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|7 years ago|reply
Personally I think Flutter will become the dominant cross platform solution in 2020 or so. ReactNative has always seemed like a hack to me.
[+] [-] snarfy|7 years ago|reply
[1] - https://weex.incubator.apache.org/guide/
[+] [-] tribby|7 years ago|reply
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