Vue Native(vue-native.io)
vue-native.io
Vue Native
https://vue-native.io
207 comments
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.
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.
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.
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.
AFAIK all virtual lists break native searching in the browser, so sadly the problem is far from solved
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.
Sounds like browser vendors should start implementing a "find" API which allows long lists to virtualize while still retaining find-ability.
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.
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.
I'm trying really hard to understand your argument.
So you believe such a UI API should be immutable (whatever that means in this context), and modelled as a sequence of actions? I think that's fine, but probably not practical in reality. I don't see the point of having a debate about the merits of functional programming vs. OOP in the middle of your post. People are going to build tools around the API that will abstract away whatever semantics you feel are best in order to fit their own needs. So the goal is to build an API that's simple at it's core to implement and use.
Inevitably someone actually has to go and code the adapter layer between the protocol receiver and the actual low level rendering layer (be it OpenGL, UIKit, etc.) and unless you build a system that's easy to understand on that end as well, you're gonna end up with an API no one actually likes or wants to use.
I don't think it's unreasonable to expect that the low-level rendering engine (ie. an implementation in UIKit) maintains some level of UI state. That is - after all - where most of the optimizations will come from. And that's how UIKit, OpenGL and most other rendering systems work. Things generally aren't immutable because it's a.) not efficient, and b.) a nightmare to work with at the lowest levels. It seems to me the appropriate abstraction is build the protocol around a UI state tree, because that's what everyone else is already working with. This is incredibly easy to maintain on either end, and higher level libraries can easily remove the pain of UI state management (a la React, Vue, etc.)
So you believe such a UI API should be immutable (whatever that means in this context), and modelled as a sequence of actions? I think that's fine, but probably not practical in reality. I don't see the point of having a debate about the merits of functional programming vs. OOP in the middle of your post. People are going to build tools around the API that will abstract away whatever semantics you feel are best in order to fit their own needs. So the goal is to build an API that's simple at it's core to implement and use.
Inevitably someone actually has to go and code the adapter layer between the protocol receiver and the actual low level rendering layer (be it OpenGL, UIKit, etc.) and unless you build a system that's easy to understand on that end as well, you're gonna end up with an API no one actually likes or wants to use.
I don't think it's unreasonable to expect that the low-level rendering engine (ie. an implementation in UIKit) maintains some level of UI state. That is - after all - where most of the optimizations will come from. And that's how UIKit, OpenGL and most other rendering systems work. Things generally aren't immutable because it's a.) not efficient, and b.) a nightmare to work with at the lowest levels. It seems to me the appropriate abstraction is build the protocol around a UI state tree, because that's what everyone else is already working with. This is incredibly easy to maintain on either end, and higher level libraries can easily remove the pain of UI state management (a la React, Vue, etc.)
> but probably not practical in reality.
Thats how I've been building UIs for the last few years. `re-frame` in ClojureScript for one is a fantastic framework built on top of these concepts.
> I don't see the point of having a debate about the merits of functional programming vs. OOP in the middle of your post
I made that distinction to highlight the differences between retained-mode UIs versus immediate-mode UIs. There are more similarities to OOP vs FP than differences here.
Think of it this way; the application itself already contains all the state it needs. A retained-mode UI will deep copy that state into the UI components while an immediate-mode UI will make the UI state a function of the application state. There is huge value in doing that because it dramatically simplifies the UI stack, this translates into shorter iteration times, simpler reasoning and less bugs. Its no good thinking about higher level tooling if the fundamental API is overly complex.
> unless you build a system that's easy to understand on that end as well
We shouldn't care about whether something is easy or difficult; we're only going to learn it once after all. We should instead care about whether its simple or complex, because that is a direct function of our ability to reason about things once they are learned. Most things that are easy to learn generate more complexity than simplicity and I believe this is harmful in the long term.
> I don't think it's unreasonable to expect that the low-level rendering engine (ie. an implementation in UIKit) maintains some level of UI state.
You're right, its perfectly reasonable and precisely what React does under the hood. Where I disagree is that I don't want the cached UI state to leak into the components. Just like the current state of the DOM is irrelevant when rendering the virtual DOM. Its purely an optimization mechanism and one which should be allowed to evolve independently from the higher level components.
> Things generally aren't immutable
Then why are so many things moving towards immutability? Modern video game renderers push really hard to be stateless, to be completely decoupled from the game threads, to not leak cached state into entities and a bunch of other FP-inspired concepts.
The end result is incredibly more parallelism. The rendering pipelines are much simpler and performant. There are quite a few advantages to this approach. It also generates optimal memory layouts and accesses, these are simply emerging from such a design. Its much easier to have linear memory accesses if you constantly recreate the display lists in fresh memory. Updating a state tree is much more complex than creating a display list and it greatly cripples the potential optimizations.
> higher level libraries can easily remove the pain of UI state management
That is not the feeling I get when I look at the average React project; most components use getState/setState, need to touch the virtual DOM for almost every operation, are needlessly maintaining two views of the same state (app and UI) and whatnot. Or they go full Functional Components and the result is a huge stack of component layers from hell.
> It seems to me the appropriate abstraction is build the protocol around a UI state tree
I believe this is fundamentally wrong; the appropriate abstraction should be built around the application state. You can derive UI state from that, and doing so liberates you from having to maintain the UI state independently.
Thats how I've been building UIs for the last few years. `re-frame` in ClojureScript for one is a fantastic framework built on top of these concepts.
> I don't see the point of having a debate about the merits of functional programming vs. OOP in the middle of your post
I made that distinction to highlight the differences between retained-mode UIs versus immediate-mode UIs. There are more similarities to OOP vs FP than differences here.
Think of it this way; the application itself already contains all the state it needs. A retained-mode UI will deep copy that state into the UI components while an immediate-mode UI will make the UI state a function of the application state. There is huge value in doing that because it dramatically simplifies the UI stack, this translates into shorter iteration times, simpler reasoning and less bugs. Its no good thinking about higher level tooling if the fundamental API is overly complex.
> unless you build a system that's easy to understand on that end as well
We shouldn't care about whether something is easy or difficult; we're only going to learn it once after all. We should instead care about whether its simple or complex, because that is a direct function of our ability to reason about things once they are learned. Most things that are easy to learn generate more complexity than simplicity and I believe this is harmful in the long term.
> I don't think it's unreasonable to expect that the low-level rendering engine (ie. an implementation in UIKit) maintains some level of UI state.
You're right, its perfectly reasonable and precisely what React does under the hood. Where I disagree is that I don't want the cached UI state to leak into the components. Just like the current state of the DOM is irrelevant when rendering the virtual DOM. Its purely an optimization mechanism and one which should be allowed to evolve independently from the higher level components.
> Things generally aren't immutable
Then why are so many things moving towards immutability? Modern video game renderers push really hard to be stateless, to be completely decoupled from the game threads, to not leak cached state into entities and a bunch of other FP-inspired concepts.
The end result is incredibly more parallelism. The rendering pipelines are much simpler and performant. There are quite a few advantages to this approach. It also generates optimal memory layouts and accesses, these are simply emerging from such a design. Its much easier to have linear memory accesses if you constantly recreate the display lists in fresh memory. Updating a state tree is much more complex than creating a display list and it greatly cripples the potential optimizations.
> higher level libraries can easily remove the pain of UI state management
That is not the feeling I get when I look at the average React project; most components use getState/setState, need to touch the virtual DOM for almost every operation, are needlessly maintaining two views of the same state (app and UI) and whatnot. Or they go full Functional Components and the result is a huge stack of component layers from hell.
> It seems to me the appropriate abstraction is build the protocol around a UI state tree
I believe this is fundamentally wrong; the appropriate abstraction should be built around the application state. You can derive UI state from that, and doing so liberates you from having to maintain the UI state independently.
> we develop an intermediate standard for fundamental UI building blocks (divs/blocks/layers, images, video, etc.) + a layout engine, sort of like the DOM
http://qmlbook.github.io/en/ch04/index.html
http://qmlbook.github.io/en/ch04/index.html
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.
In some respects I think they've already paved the way. An adapter could be created to target canvas or WebGL. As for APIs like file system access, I don't think there's anything wrong with the JS web APIs as they exist today. I'd love to see Apple actually push ahead with the implementation of more of these APIs, as well as PWAs, etc. but I know it's not at all in their interest.
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.
What are Gibbon and Cobalt?
I tried google but with no success.
Do you have any link?
Gibbon:
- https://medium.com/netflix-techblog/crafting-a-high-performa...
- https://medium.com/netflix-techblog/building-the-new-netflix...
- https://www.youtube.com/watch?v=eNC0mRYGWgc
Cobalt: https://www.cobalt.dev/
- https://medium.com/netflix-techblog/crafting-a-high-performa...
- https://medium.com/netflix-techblog/building-the-new-netflix...
- https://www.youtube.com/watch?v=eNC0mRYGWgc
Cobalt: https://www.cobalt.dev/
I find it funny that youtube made a cool new tech specifically to render UI on tv's and yet it works like shit on any tv I encountered.
Some of your points remind me of Flutter.
Wonder where Cordova falls under in this regard?
https://cordova.apache.org/
I think Cordova could be leveraged at the very least.
https://cordova.apache.org/
I think Cordova could be leveraged at the very least.
Web Components?
No, because web components assume you're using the DOM. Which we definitely do not want. I want to go lower level. Give me a hashmap of nodes currently on screen. Let me design how the nodes are arranged in a render tree. Let me design how the nodes are redrawn. Let me design how the nodes are styled. I shouldn't have to compile my styles to CSS. Make the browser a rendering slave with a small but effective layout engine + UI API.
What about accessibility? Accessibility helpers would need semantic information about the UI to be of any use. And I doubt that many homegrown or halfbaked Ui libraries (which would certainly sprout like mushrooms on a platform like yours) would provide correct annotations through an accessibility API. Most developers wouldn't care.
Accessibility is definitely something I have thought about, too. Including accessibility features in the API is vital I think. I'm not very familiar with accessibility features as they exist today, but I think it would be possible for longer term projects built on top of such a UI system to emerge which would provide accessibility information by default, and the rest would resemble what we have with HTML today.
Can't you do this by yourself by implementing a thin layer on top of the canvas element?
What do you need more than a z-map of all of your nodes to keep track of which one is at the top and should receive mouse and touch events?
A render list would be more efficient than a tree, simply because you're not jumping left and right in RAM with cache misses on every jump.
A hashmap of nodes on screen is still very high level; you're basically replacing the DOM with data, yet keeping the exact same structure. But now you lose static types and everything is slower.
Redrawing doesn't happen at the node level either; that would be terribly inefficient. Things are instead batched together.
You don't have to compile your styles to CSS currently; just write them as JS objects and call the CSS constructors yourself from code. You'll quickly find its not productive for most styling.
I simply don't believe the vast majority of developers to be able to properly handle rendering at that level. No offence but all your points about low-level rendering is not how it actually works. Its incredibly easy to fool yourself into thinking you wrote a well-designed, efficient piece of code and learn years later every single piece of it was far from optimal.
Thats why we have layers of abstractions.
A hashmap of nodes on screen is still very high level; you're basically replacing the DOM with data, yet keeping the exact same structure. But now you lose static types and everything is slower.
Redrawing doesn't happen at the node level either; that would be terribly inefficient. Things are instead batched together.
You don't have to compile your styles to CSS currently; just write them as JS objects and call the CSS constructors yourself from code. You'll quickly find its not productive for most styling.
I simply don't believe the vast majority of developers to be able to properly handle rendering at that level. No offence but all your points about low-level rendering is not how it actually works. Its incredibly easy to fool yourself into thinking you wrote a well-designed, efficient piece of code and learn years later every single piece of it was far from optimal.
Thats why we have layers of abstractions.
have you heard of React Canvas?
https://engineering.flipboard.com/2015/02/mobile-web
https://engineering.flipboard.com/2015/02/mobile-web
Flutter?
Flutter is closer, but it is too focused on being a framework. I'm thinking of a platform agnostic protocol with implementations in whatever language you like. Flutter is too many of things at once. If they basically ripped out each native platform's implementation and made it target the protocol I've described, then made their OOP framework target that protocol, then had the two interface using the protocol, that's what I'd like to see. That way you could write React Native on top of that new "Flutter Native Core".
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/
[1]: https://nativescript-vue.org/
[0]: https://www.nativescript.org/
[1]: https://nativescript-vue.org/
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.
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
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.
For example, when the Javascript parser sees
var className = NSStringFromClass(NSArray);
NSString *className = NSStringFromClass([NSArray class]);
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.
Haha, nice.
First time I heared about this killer-feature :D
First time I heared about this killer-feature :D
Looks interesting, and it's sponsored by Progress? Looks like old dogs can learn new tricks.
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.
Thank god. Angular is just way too big now. There's way too many files and they try to push you into using typescript.
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!
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.
Disclaimer: I'm also contributing on this project.
Don't forget about NativeScript Vue!
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).
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).
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
> Vue Native transpiles to React Native.
Why would you not use react native directly then? I don't get it
Why would you not use react native directly then? I don't get it
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.
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.
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.
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.
> 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.
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.
I've been working with RN for a few months now. Good luck with that. I can't imagine another layer of abstraction.
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.
Its actually practical to start using Vue in existing projects without a complicated transpilation process. It's not ironic, VueJS shines in both scenarios.
It's a choice. Basically you have Java, Kotlin, C# and SWIFT for native apps, why use React Native. If you learning React is easier for web dev, then I'll say Vue is even easier for them. If you know React then Vue-Native isn't worth it.
Because you prefer vue.
How does this compare to nativescript-vue?
https://nativescript-vue.org/
https://nativescript-vue.org/
It looks like Vue Native is a wrapper around React Native UIs https://github.com/GeekyAnts/vue-native-cli (in the README)
I personally am following/want-to-use https://nativescript-vue.org/
I personally am following/want-to-use https://nativescript-vue.org/
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.
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].
https://twitter.com/youyuxi/status/1006565660091125760
https://twitter.com/youyuxi/status/1006565660091125760
I'm confused. Wouldn't "native" imply it uses platform widgets rather than HTML?
Similar projects:
https://weex.incubator.apache.org/
https://www.nativescript.org/
I think Weex has better performance and lighter overhead than this(?)
I think Weex has better performance and lighter overhead than this(?)
Xamarin: https://www.xamarin.com
Xojo: https://www.xojo.com
Flutter: http://flutter.io
Xojo: https://www.xojo.com
Flutter: http://flutter.io
I'd love to get a side by side comparison of Weex and Vue Native.
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)
Ironic the site does not seem to be responsive
Going to fix it ASAP.
Yes. Its worse than terrible on a mobile. Going to see if its open source and put a pull in for it.
If that doesn't put you off I'm not sure what would.
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
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.
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.
> How does it work?
This is fork of react-vue
https://vue-native.io/docs/how-does-it-works.html
This is fork of react-vue
https://vue-native.io/docs/how-does-it-works.html
It's based on react-vue[1] and It is internally using react-native.
1. https://github.com/SmallComfort/react-vue
Why but Why.
1. https://github.com/SmallComfort/react-vue
Why but Why.
> Introduce react-vue-loader, which compiles the Vue component into a React component. As you might think, your previously written Vue components can run inside the React component, and your React components can also run inside the Vue component
How did it come to this?
How did it come to this?
Because:
1) many people prefer Vue over React - you can google them and their reasons.
2) one of the great selling points in the React ecosystem is React-Native - you can write many parts of your code once and use both for web and native applications.
There are other solutions for this for Vue (Weex and NativeScript) but React Native has the mindshare. Perhaps there are other benefits - I don't work with apps so I don't have experience.
1) many people prefer Vue over React - you can google them and their reasons.
2) one of the great selling points in the React ecosystem is React-Native - you can write many parts of your code once and use both for web and native applications.
There are other solutions for this for Vue (Weex and NativeScript) but React Native has the mindshare. Perhaps there are other benefits - I don't work with apps so I don't have experience.
Vue Native is a bit of a misnomer then.
The layers of abstraction keep adding up.
Tortoises all the way down.
Next thing someone will incorporate jslinux into this mess
The layers of abstraction keep adding up.
Tortoises all the way down.
Next thing someone will incorporate jslinux into this mess
Because, it solves a problem. I'm sorry, but, outside of the "let's use react for everything" bubble, people believe in different ideologies and use different frameworks to accomplish similar tasks. One of them is using Vue for web applications, and now thanks to this new project, the same Vue developers can also make use of Vue to build their mobile apps.
What it uses under the hood isn't really a concern for me as a Vue developer as long as I'm able to develop mobile apps with it.
> Why but Why.
Sorry, but this comment seems arrogant. As though just because it's out there on React, others aren't entitled to opine differently or use different frameworks?
What it uses under the hood isn't really a concern for me as a Vue developer as long as I'm able to develop mobile apps with it.
> Why but Why.
Sorry, but this comment seems arrogant. As though just because it's out there on React, others aren't entitled to opine differently or use different frameworks?
>Because, it solves a problem
Some solutions are worse than the original problem.
Besides, not everything qualifies as a problem.
"I want to build a good mobile app" is a problem.
"I like to use Vue and want to use it specifically to quickly build an app no matter how slow / bloated the result will be" is not exactly a problem. More like a capricious wish that was granted...
It's like how "I want to eat" defines a problem, but "I want to eat McDonalds every day" is more like a bad judgement...
Some solutions are worse than the original problem.
Besides, not everything qualifies as a problem.
"I want to build a good mobile app" is a problem.
"I like to use Vue and want to use it specifically to quickly build an app no matter how slow / bloated the result will be" is not exactly a problem. More like a capricious wish that was granted...
It's like how "I want to eat" defines a problem, but "I want to eat McDonalds every day" is more like a bad judgement...
> Some solutions are worse than the original problem.
Wow, that's a pretty harsh claim. This was just released and you already think it's worse with no sort of data to back up your claims. Sorry, that's not a sound argument.
Wow, that's a pretty harsh claim. This was just released and you already think it's worse with no sort of data to back up your claims. Sorry, that's not a sound argument.
You still think it's about Vue Native. It's not. It's about using web stack for desktop applications. This is a "solution worse than the original problem".
And the damage is done. This[0] comment by 'm_fayer elsewhere in the thread is quite chilling. Actual native toolkits are rotting, as big companies join the web-for-everything bandwagon. Not only delivering bloated applications with toy-like UIs becomes the norm, we're losing the ability to deliver fast, useful UIs!
--
[0] - https://news.ycombinator.com/item?id=17301972
And the damage is done. This[0] comment by 'm_fayer elsewhere in the thread is quite chilling. Actual native toolkits are rotting, as big companies join the web-for-everything bandwagon. Not only delivering bloated applications with toy-like UIs becomes the norm, we're losing the ability to deliver fast, useful UIs!
--
[0] - https://news.ycombinator.com/item?id=17301972
>And the damage is done. This[0] comment by 'm_fayer elsewhere in the thread is quite chilling. Actual native toolkits are rotting, as big companies join the web-for-everything bandwagon.
What's worse is that actual native toolkits are rotting, while at the same time we never managed to produce a single, great native cross platform toolkit -- even less so a great cross platform one.
Not because it's impossible, but because no major player cares (they have their own platforms), and OSS attempts like Wx and GTK+ don't have the manpower.
What's worse is that actual native toolkits are rotting, while at the same time we never managed to produce a single, great native cross platform toolkit -- even less so a great cross platform one.
Not because it's impossible, but because no major player cares (they have their own platforms), and OSS attempts like Wx and GTK+ don't have the manpower.
>we never managed to produce a single, great native cross platform toolkit
Why can't the web+JS be that platform?
Why can't the web+JS be that platform?
Tons of reasons. For one, I wrote "native" above, and the web+JS aint that.
But even if we ask the more general question, why "web+js can't be the great cross platform toolkit", the answer IMHO is:
Web+JS are and will always be (due to the nature of the platform) inherently slower than optimal (even if "fast enough" for simple apps), use more memory, use more CPU, don't use the native facilities and so are foreign to every OS look and feel (from themes to usability features), and so on. And of course they're "bring your own theme" affairs, so no standard users can get used to, everybody does their own BS UI in SPAs and web-engine based apps (like Spotify and Atom).
Add the amateur hour development practices that they enable (where a company that would previously hire actual GUI programmers can now hire some web devs and let them loose to create its app) and the picture is not nice...
But even if we ask the more general question, why "web+js can't be the great cross platform toolkit", the answer IMHO is:
Web+JS are and will always be (due to the nature of the platform) inherently slower than optimal (even if "fast enough" for simple apps), use more memory, use more CPU, don't use the native facilities and so are foreign to every OS look and feel (from themes to usability features), and so on. And of course they're "bring your own theme" affairs, so no standard users can get used to, everybody does their own BS UI in SPAs and web-engine based apps (like Spotify and Atom).
Add the amateur hour development practices that they enable (where a company that would previously hire actual GUI programmers can now hire some web devs and let them loose to create its app) and the picture is not nice...
Notice how I said "some", and not "this particular solution".
I haven't evaluated this, but having suffered many (similar in concept) React Native and Electron based apps as a user, I speak of my general experience with those bloated / uncanny valley monstrosities...
I haven't evaluated this, but having suffered many (similar in concept) React Native and Electron based apps as a user, I speak of my general experience with those bloated / uncanny valley monstrosities...
So does heroin, and creates a new class of problems.
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.
Is this due to the principle of getting to the market first and quick prototypes? I don’t see a quick way back.
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.
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.
>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.
Maybe they weren't covered for a reason?
The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
Now businesses do that just because they can.
Maybe they weren't covered for a reason?
The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
Now businesses do that just because they can.
They do it simply because it's the most cost effective solution overall.
Typical capitalism outcome.
Cheapest to produce AND worst quality. In this case by bad performance and unneeded cellphone battery drain.
These products will be dominated by superior options eventually.
Cheapest to produce AND worst quality. In this case by bad performance and unneeded cellphone battery drain.
These products will be dominated by superior options eventually.
> These products will be dominated by superior options eventually.
Would love that to happen, but all the other market sectors suggest otherwise. "Cheapest to produce and worst quality" seems to be all that's available to majority of the population.
Would love that to happen, but all the other market sectors suggest otherwise. "Cheapest to produce and worst quality" seems to be all that's available to majority of the population.
Like Apple, Lexus and Infiniti products. Totally.
Yes. It's the most cost-effective solution, because:
- we haven't figured out how to make companies care about "delivering value" part of the "delivering value in exchange for money" work, and
- we allow them to dump externalities on users without consequences or compensation.
So the most cost-effective solution in this scheme will be a half-assed product that's barely good enough to be sellable, and which makes my computer use more electricity while being less capable of running software simultaneously.
- we haven't figured out how to make companies care about "delivering value" part of the "delivering value in exchange for money" work, and
- we allow them to dump externalities on users without consequences or compensation.
So the most cost-effective solution in this scheme will be a half-assed product that's barely good enough to be sellable, and which makes my computer use more electricity while being less capable of running software simultaneously.
And the whole point of native components in Vue/react is to reduce those negative externalities, but the first thread I see in this post is criticizing Vue for sharing from react's ecosystem instead of inventing an indentical solution from scratch?
At the current rate we will soon have phones with 8GB RAM and who knows how many cores not having to rewrite same code 3 times in 3 lang. will def. be catching on more.
If by soon you mean in 2 years on flagships (looking at current specs, I don't buy it), then for regular users buying regular smartphones it'll be ~7 years from now.
I don't feel like this is a valid justification for being wasteful, though.
I don't feel like this is a valid justification for being wasteful, though.
The OPO 6 is out now with 8GB RAM, so no not in two years, let alone 7.
That's an outlier, pretty niche one at that.
(Personally, I didn't even realize OnePlus phones still exist - I thought they died out somewhere around OnePlus 3.)
(Personally, I didn't even realize OnePlus phones still exist - I thought they died out somewhere around OnePlus 3.)
Actually, now that I'm looking into it - the OPO 3T had 8gb of RAM as well :P It's been a while!
I do think though that we will only be seeing more and more of this, and very soon.
I do think though that we will only be seeing more and more of this, and very soon.
> The ability to have your web team churn out lowest common denominator bloated JS based mobile/desktop apps was not a real requirement, more like a wish of some.
Come on, the requirement has always been there. It is "Shit out that underbudgeted project in half the promised time". Those small frameworks where you can hire a cheap front-end guy and have him manage the entire project alone or in a small team are perfect to fill that niche.
Come on, the requirement has always been there. It is "Shit out that underbudgeted project in half the promised time". Those small frameworks where you can hire a cheap front-end guy and have him manage the entire project alone or in a small team are perfect to fill that niche.
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.
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.
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.
> 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.
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.
it will get worse before it gets worser
It just made possible for web developers to jump on the native apps train
It's hard to think of it as an improvement
The idiocy is in the hundreds of engineering hours spent to build half baked solutions that never work as expected and never will
It's developers not wanting to adapt, while if they spent half of that effort on red or even visual basic 6 we would have end up with something better
Diversity is king, web everywhere for everything will impoverish the entire developer's community
It's hard to think of it as an improvement
The idiocy is in the hundreds of engineering hours spent to build half baked solutions that never work as expected and never will
It's developers not wanting to adapt, while if they spent half of that effort on red or even visual basic 6 we would have end up with something better
Diversity is king, web everywhere for everything will impoverish the entire developer's community
I find it entertaining that you post this a within 24 hours of the linus/tanenbaum rehash.
Getting crap done counts for a lot. Web, and hci in general, isnt figured out well at all, so we can spend a few decades pursuing an ideal we don't even have defined...or we can get stuff done.
If you are arguing for some specific non-"idiocy", please, explain why your version hasn't taken off.
Getting crap done counts for a lot. Web, and hci in general, isnt figured out well at all, so we can spend a few decades pursuing an ideal we don't even have defined...or we can get stuff done.
If you are arguing for some specific non-"idiocy", please, explain why your version hasn't taken off.
> I find it entertaining that you post this a within 24 hours of the linus/tanenbaum rehash.
Do you have a link about this latest rehash? I tried googling without success
Do you have a link about this latest rehash? I tried googling without success
Sorry for the late reply - the article is old, but the HN link (and comments) is recent: https://news.ycombinator.com/item?id=17294907
> getting crap done
Yeah you end up with crap.
Yeah you end up with crap.
Non-serious: maybe they have to spend so much time chasing the latest trends in JS frameworks that none is left to learn about alternatives.
Semi-seriuos: I am afraid many honestly believe that JS is the best language and has the best ecosystem.
I consider myself lucky having learnt programming back when you had no choice but to use different tools/languages for different tasks. It provides with a luxury of being able to compare different approaches.
Semi-seriuos: I am afraid many honestly believe that JS is the best language and has the best ecosystem.
I consider myself lucky having learnt programming back when you had no choice but to use different tools/languages for different tasks. It provides with a luxury of being able to compare different approaches.
It's all about developer productivity and nothing else. Well, maybe a healthy dose of cargo cutting. But anyway, no care is really given anymore about resource usage, etc because all of that is abundant.
I personally don't like it as I think it's wasteful and careless.
I personally don't like it as I think it's wasteful and careless.
> no care is really given anymore about resource usage, etc because all of that is abundant.
They're abundant for people who you only think about themselves. Who believe that their application will be the only one running on the machine. Which may be the case if you're developing software for touchscreens on a factory floor, but is definitely not true for end-user software, and doubly not true for anything on the web.
They're abundant for people who you only think about themselves. Who believe that their application will be the only one running on the machine. Which may be the case if you're developing software for touchscreens on a factory floor, but is definitely not true for end-user software, and doubly not true for anything on the web.
Nah it's the culture - at some point someone started teaching people that learning new programming languages and more fitting tools is hard. So now there's a whole herd of people who refuse to learn anything but JS and then spend time wrapping the wrappers and debugging them instead of taking a tool better fitted for the task.
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.
I'm sorry, but the way the web stack is typically is the opposite of good user interfaces. It's not that the web can't be used to create good UIs, it's just I've never seen it used in this way, and I find that the less of web technologies you use, the better.
A good user interface will, among other things, be consistent with its environment, efficient wrt. to its purpose and performant.
Consistency with the environments using similar interface primitives to other applications at all levels - not just looking like other applications (to facilitate knowledge transfer/principle of least surprise), but also supporting universal idiosyncrasies - like the context menus in text field, copy-paste, integration with system-wide settings, etc. Looking the same is anathema to web designers, and reconstructing anything else than basic functionality of an UI component is something webdevs usually can't be bothered with.
UIs that are efficient for purpose happen on the web, as long as people do not follow popular UI/UX guidelines. Efficiency for purpose usually means denser interfaces, less bells and whistles, more data on screen, more features and functionality, and a bit of learning curve - all of these are actively hated in the current web ecosystem. All the efficient interfaces I see on the web these days are of those products that didn't get the "web 2.0" memo and are stuck in early 2000s.
Performance. They say V8 is heavily optimized and all, but for some reason the modern web is still fucking slow. Might have something to do with ads and tracking, but it also might have something to do with trying to be first-to-market, and putting in lots of pretty looking bells and whistles. The end result is that I say the data table might need to display 10 000 rows, and I see the UI team cringe at the thought of slowdown. Well, why on Earth would 10k rows in a 4-column table be a problem? Oh, you used lots of JS magic to make that table pretty and "reactive" and shits, that's why.
--
TL;DR: The web is the opposite of good UIs. I'm not really sure if the problem is technological - it seems to be almost entirely cultural.
A good user interface will, among other things, be consistent with its environment, efficient wrt. to its purpose and performant.
Consistency with the environments using similar interface primitives to other applications at all levels - not just looking like other applications (to facilitate knowledge transfer/principle of least surprise), but also supporting universal idiosyncrasies - like the context menus in text field, copy-paste, integration with system-wide settings, etc. Looking the same is anathema to web designers, and reconstructing anything else than basic functionality of an UI component is something webdevs usually can't be bothered with.
UIs that are efficient for purpose happen on the web, as long as people do not follow popular UI/UX guidelines. Efficiency for purpose usually means denser interfaces, less bells and whistles, more data on screen, more features and functionality, and a bit of learning curve - all of these are actively hated in the current web ecosystem. All the efficient interfaces I see on the web these days are of those products that didn't get the "web 2.0" memo and are stuck in early 2000s.
Performance. They say V8 is heavily optimized and all, but for some reason the modern web is still fucking slow. Might have something to do with ads and tracking, but it also might have something to do with trying to be first-to-market, and putting in lots of pretty looking bells and whistles. The end result is that I say the data table might need to display 10 000 rows, and I see the UI team cringe at the thought of slowdown. Well, why on Earth would 10k rows in a 4-column table be a problem? Oh, you used lots of JS magic to make that table pretty and "reactive" and shits, that's why.
--
TL;DR: The web is the opposite of good UIs. I'm not really sure if the problem is technological - it seems to be almost entirely cultural.
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 to be stagnating.
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 to be stagnating.
Xaml and Wpf? Qt? I am honestly asking you, have you worked with React before? XAML has a learning curve of 2 years and more to get to expert level. I developed with it for more or less 5 years and i still have nightmares. Qt and the others are all imperative layout inflaters. React was a revolution, maybe the first cross platform paradigm that actually made sense. A learning curve that doesn't span more than a day. In all my years as a frontend developer i haven't seen a simpler way to create user interfaces. And sure as hell i would prefer React on the desktop or mobile over aged native toolkits that still struggle with obsolete oop-mvc-templating semantics, especially wpf and xaml, which in my opinion where the sole reason why i started hating my job.
I love writing React code and it is easy to get up to speed there.
I abhor the mix of HTML/CSS for UI design. I'd rather code UIs in Actionscript.
The web browser as an abstraction for general use UIs is just not ideal.
XAML might be a company induced mess underneath but my point is that you don't have to be XAML expert to make nice interfaces. I made CRUD apps on WPF and rarely did I have to touch XAML directly. I had a big thick book on XAML and it sat unopened on my shelf.
I am forced to do front-end webdev work and I hate it. I need to worry about UI breaking instead of worrying about business logic.
Let's say client needs a dropdown menu added at a certain location. On desktop this is cake on most toolkits.
On web the problem is that there is no certain location, there is no absolute. You have to delve deep into CSS abyss to figure out how the component will behave.
I abhor the mix of HTML/CSS for UI design. I'd rather code UIs in Actionscript.
The web browser as an abstraction for general use UIs is just not ideal.
XAML might be a company induced mess underneath but my point is that you don't have to be XAML expert to make nice interfaces. I made CRUD apps on WPF and rarely did I have to touch XAML directly. I had a big thick book on XAML and it sat unopened on my shelf.
I am forced to do front-end webdev work and I hate it. I need to worry about UI breaking instead of worrying about business logic.
Let's say client needs a dropdown menu added at a certain location. On desktop this is cake on most toolkits.
On web the problem is that there is no certain location, there is no absolute. You have to delve deep into CSS abyss to figure out how the component will behave.
Well i give you that, css is what it is, but even with basic css knowledge, making a dropdown appear anywhere you want is not hard: https://codesandbox.io/embed/w7499vxrzk
It could be better, but it's even got a proper grid system now, close to wpf's. From what i remember though, wpf's styles also had some rough spots.
It could be better, but it's even got a proper grid system now, close to wpf's. From what i remember though, wpf's styles also had some rough spots.
Uh, there is in fact, an absolute(position:absolute). It has caveats, but doesn't XAML? The 'certain location' bit is actually quite complex:
- how is it supposed to adapt to different resolutions?
- is an inner absolute component allowed to escape its container?
- how does it layer with other components?
The CSS required to position an element at an absolute location must take all of these into consideration, and I'm not sure how much better a native toolkit can make it.
- how is it supposed to adapt to different resolutions?
- is an inner absolute component allowed to escape its container?
- how does it layer with other components?
The CSS required to position an element at an absolute location must take all of these into consideration, and I'm not sure how much better a native toolkit can make it.
[deleted]
Compared to vue, qt and all its reincarnations are a nightmare to work with.
Maybe. But it boils down to where you want to put the crap - contain it within the dev team, or drop it on your users? Obsessive trading of developer time on your end for compute use on users' end is a big part of what makes web UIs suck. Also, for keeping some of the crap on your end, native-native toolkits give you consistency and performance for free.
I'm almost at a loss for words. The web stack is frankly one of the worst ways to create a good UI. The best UI's typically have three key area's:
- It's easily discoverable by the user - The web is typically horrible at this. Custom controls, look and feel's, and a severe lack of common UI patterns. Native app's have this in spades.
- It's performant - Native wins this hands down everytime. The web stack lacks threading and one of the major keys is to NOT do work on the main thread for a great UI. The vast majority of web dev's have never even thought about threading.
- The design puts features in a place the user can easily and quick get to. This has little to do with the technology platform.
Bottom line is the web stack is at a MAJOR disadvantage for building a UI. The only use for it on mobile is that developers refuse to put in the work to learn how to do the platform justice.
- It's easily discoverable by the user - The web is typically horrible at this. Custom controls, look and feel's, and a severe lack of common UI patterns. Native app's have this in spades.
- It's performant - Native wins this hands down everytime. The web stack lacks threading and one of the major keys is to NOT do work on the main thread for a great UI. The vast majority of web dev's have never even thought about threading.
- The design puts features in a place the user can easily and quick get to. This has little to do with the technology platform.
Bottom line is the web stack is at a MAJOR disadvantage for building a UI. The only use for it on mobile is that developers refuse to put in the work to learn how to do the platform justice.
Site is broken on mobile. Styling issues make it undreadable.
It's hilarious that you can't view this site on native browsers. How ironic!
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.
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.
Edit: ah, the get started links to real content. Missed that.
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).
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?
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?
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.
Personally I think Flutter will become the dominant cross platform solution in 2020 or so. ReactNative has always seemed like a hack to me.
What about it seems like a hack? Why do you think Flutter will become dominant?
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.
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.
Aren't native Vue apps already supported with Weex[1]? Why would I use this over Weex?
[1] - https://weex.incubator.apache.org/guide/
[1] - https://weex.incubator.apache.org/guide/
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
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
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?
This page is a good start, it discusses the differences in detail:
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.
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.
> 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?
Why do you find it harder to maintain React apps after 6 months?
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
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
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.
I find it the other way around actually. It's much easier for me to maintain JSX then using an html template engine.
On topic of vue, I've been working on one app for a few months now, and I'm having a hard time maintaining clear code, especially for nested components. I often resort to Vuex to share info between components, which might not be the best solution...
Also my app mainly revolves around a map vizualisation, and gmaps api is a pain to manage, bloating my code. Everything in my project works fine btw and I have great pleasure developing using Vue, but I'm sure I could be more elegant/efficient. Yet it's rather hard to find complete open vue projects online to check code organisation, so how can I get better on that aspect ?
Also my app mainly revolves around a map vizualisation, and gmaps api is a pain to manage, bloating my code. Everything in my project works fine btw and I have great pleasure developing using Vue, but I'm sure I could be more elegant/efficient. Yet it's rather hard to find complete open vue projects online to check code organisation, so how can I get better on that aspect ?
Is your course online? If so, do you mind sharing a link?
Oh, actually, it's offline, but I plan to put them all in one place online on Medium. I've already started writing a piece about writing an E-Commerce engine:
https://medium.com/build-ideas/my-journey-of-writing-an-e-co...
https://medium.com/build-ideas/my-journey-of-writing-an-e-co...
Vue is more beginner friendly. It's easier to learn (particularly for people coming from Angular Js background). As a RN developer you won't be getting any benefits as such. If you're already comfortable with React and JSX then jumping to Vue-Native won't be of any use. But if you're purely a HTML, CSS, jQuery dev and want to get into mobile app dev, I guess Vue-Native will be quite easy to learn and build production ready apps.
Evan said he doesn't agree with everything but said it is one of the more reasonable discussions about the topic.
https://www.reddit.com/r/javascript/comments/8o781t/vuejs_or...
https://www.reddit.com/r/javascript/comments/8o781t/vuejs_or...
vue is similar to react+mobx.
react in itself has no two way data binding, vue has (well, it's one wayish, but let's not argue about specifics).
react in itself has no two way data binding, vue has (well, it's one wayish, but let's not argue about specifics).
The funny thing? The website renders for desktop on my S8, making it completely unusable.
Anyone else getting "This site is blocked due to a security threat."?
[deleted]
So are all those beautiful UI elements in the kitchen sink demo included?
I get an HSTS error while accessing the web site.
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.”
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.”
Cordova is the "electron" equivalent for mobile. I.E. running a browser rendering engine embedded inside an app.
There are 2 main reasons for making (or using) the *-native libraries as opposed to using a browser rendering approach -
1- performance. Html and CSS are insanely bloated specification for making an app. There is really no way for a browser to rival the performance of a native app. This comes into play in mobile more then desktop and is really visible when dealing with animations and very large lists/tables.
2- native looking UI. using electron you can fake a webapp to look like a native app, but it will never have all of the edge cases (for example some keyboards don't open in a browser. Web inputs behave differently then native inputs. And of-course animations).
You can think of the Native part in react-native or native-script etc... as native ui components. Which is what all of these technologies are attempting to achieve - having the look and feel of the native components of each OS while keeping the logic and layout code the same.
As to why vue-native, react-native, nativescript (angular) etc... rather then having a single base where you can use multiple different frameworks on top - nativescript is trying to do that. react-native is built in such a way that only virtual dom diffing based frameworks can work with it (which is why vue can while angular can't)
There are 2 main reasons for making (or using) the *-native libraries as opposed to using a browser rendering approach -
1- performance. Html and CSS are insanely bloated specification for making an app. There is really no way for a browser to rival the performance of a native app. This comes into play in mobile more then desktop and is really visible when dealing with animations and very large lists/tables.
2- native looking UI. using electron you can fake a webapp to look like a native app, but it will never have all of the edge cases (for example some keyboards don't open in a browser. Web inputs behave differently then native inputs. And of-course animations).
You can think of the Native part in react-native or native-script etc... as native ui components. Which is what all of these technologies are attempting to achieve - having the look and feel of the native components of each OS while keeping the logic and layout code the same.
As to why vue-native, react-native, nativescript (angular) etc... rather then having a single base where you can use multiple different frameworks on top - nativescript is trying to do that. react-native is built in such a way that only virtual dom diffing based frameworks can work with it (which is why vue can while angular can't)
It's normally in an attempt to "build once deploy everywhere" using tools first built as web technologies. The same selling point as the JVM for Java. In some ways Electron serves as a bit of a JVM for web, but then, that is also the utility of a browser. You can see it as an artifact of the web technology coming first and trying to port it backward to other devices. I wish we had ported some of the awesome GUI libraries from native languages forward to the web instead, perhaps when Web Assembly is ubiquitous we can finally have some coherence in tooling.
What is it about native ui technology that you think is better than web tech? In my experience, the singular advantage of native tech is performance. Am I missing something?
Native UI gives you things like decent accessibility support and conformance to platform conventions for free, as well as automatic support for new system features like the dark mode being added in macOS Mojave.
Other than that, it’s just one less thing you have to bundle when distributing your app — especially if you opt to use the local JS engine instead of V8. A JS desktop app written with something like Vue Native and system JS will be a great deal more lightweight than its electron equivalent.
Other than that, it’s just one less thing you have to bundle when distributing your app — especially if you opt to use the local JS engine instead of V8. A JS desktop app written with something like Vue Native and system JS will be a great deal more lightweight than its electron equivalent.
I would say taking 1/10th or 1/100th of resource is a pretty damn big advantage even if that's just one advantage. Modern browsers are probably the most inefficient mainstream computer technology ever regardless of how useful it might have been.
Ironically, web browsers themselves are extremely optimized. They are one of the most efficient pieces of software out there. It takes actual work to screw all that up and turn it into the molasses that is modern web. Careers are built out of that work.
Lots of times the people on HN advocating for native ui toolkits just have fond memories of a form builder on Windows 95 when you didn't have to worry about all these different screen sizes and stuff.
Nowadays you can design responsive UIs with Interface Builder or the Android Studio equivalent with joy.
And yet not a single valid reason is given. "Because it's the old way of doing things" is completely inadequate as a technical reason to not use a technology.
Having to worry about all these different screen sizes, devices, browsers and OS is a completely valid reason for not using a Windows 95 era form builder anymore.
As pointed out in other responses, pretty much every native kit nowadays offers sizing. Hell, it was one of the selling points for GTK+ back in 1998.
What desktop apps are people using today that still have static sizes (outside of dialog/info boxes)?
What desktop apps are people using today that still have static sizes (outside of dialog/info boxes)?
No one is talking about using form builders instead of react. They are talking about using modern, competent application frameworks that power some of the most powerful applications in use today. Almost everything in the web stack is an adaptation of a native technology.
The basic metaphors are still the same because we're still using mouses on the desktop. With mobile devices these metaphors break down fairly quickly, though.
HTML-based applications however also introduced a number of new metaphors and patterns such as the page paradigm that, while originally reminiscent of printed pages, is different from anything both in the physical world and within native desktop applications.
Typography and information hierarchy are other aspects that usually can't be implemented as easily or as flexibly with native UI kits as with HTML-based approaches.
HTML-based applications however also introduced a number of new metaphors and patterns such as the page paradigm that, while originally reminiscent of printed pages, is different from anything both in the physical world and within native desktop applications.
Typography and information hierarchy are other aspects that usually can't be implemented as easily or as flexibly with native UI kits as with HTML-based approaches.
Can you qualify this "lots of times" claim?
It's not constantly churning and it has matured over many years. Those are genuine benefits.
I am not a fuddy duddy holding onto old memories, I am a long term web developer watching people try to shoehorn the churning spaghetti mess of dependencies and tooling that is the javascript ecosystem back into native platforms that have dedicated clean frameworks already.
It has gotten better of course, but the only reason we have so much engineering capital in Javascript is because it runs everywhere on the web. If everyone using typescript and ES6 transpilers could have just used a better language 10 years ago they would have.
It seems backwards to go from web tech to native, because native has always had numerous advantages as a platform over the web. Everything we have in the javascript ecosystem is just us saying "man I wish we could do this thing the non-web platforms can do already"
I am not a fuddy duddy holding onto old memories, I am a long term web developer watching people try to shoehorn the churning spaghetti mess of dependencies and tooling that is the javascript ecosystem back into native platforms that have dedicated clean frameworks already.
It has gotten better of course, but the only reason we have so much engineering capital in Javascript is because it runs everywhere on the web. If everyone using typescript and ES6 transpilers could have just used a better language 10 years ago they would have.
It seems backwards to go from web tech to native, because native has always had numerous advantages as a platform over the web. Everything we have in the javascript ecosystem is just us saying "man I wish we could do this thing the non-web platforms can do already"
> Why this instead of say Electron
The major difference is that Electron is a way of wrapping a webapp with access to the filesystem, etc. via Node, and React Native is a way of instantiating, styling, and manipulating actual native components with JavaScript.
The major difference is that Electron is a way of wrapping a webapp with access to the filesystem, etc. via Node, and React Native is a way of instantiating, styling, and manipulating actual native components with JavaScript.
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.
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.
Well, those excuses are garbage everywhere. :/ All the extra electricity burned around the world would easily pay for more highly skilled devs to write a native application (source: plucked from thin air ;) ).
I'll admit making desktop applications in electron seems just as crazy to me as it does many others, but.. after using Vscode I've questioned that there must be something to it.
Vscode has pretty great performance and is a serious pleasure to use with the right customizations. Should some of that success be credited to electron? (I'm just asking, not implying)
Vscode has pretty great performance and is a serious pleasure to use with the right customizations. Should some of that success be credited to electron? (I'm just asking, not implying)
I've been using it a bit at work.. The thing that stops me fully adopting it is how long it takes to start, and then it's very laggy for the first few seconds after that. It is a very nice editor once it's running though for sure!
VSCode's success is due to the team that builds it using Electron as a tool, not as a crutch.
> 32 to 64GB of onboard storage.
If only. Probably a lot closer to 4-16GB for a lot of Android phones.
If only. Probably a lot closer to 4-16GB for a lot of Android phones.
For a brand new phone. If everyone around you is using a phone that's less than 2 years old and purchased brand new, then you're living in a bubble.
Same issue with web apps that run just great on the developer's 9 month old iMac over a symmetrical 100/100 connection vs the typical family's 5 year old chromebook (or the 8 year old Dell at the office) and 10/768 that's also supporting a Netflix stream.
Same issue with web apps that run just great on the developer's 9 month old iMac over a symmetrical 100/100 connection vs the typical family's 5 year old chromebook (or the 8 year old Dell at the office) and 10/768 that's also supporting a Netflix stream.
That hopefully motivates at least some developers not to ship 500mb apps.
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.
I was kinda exaggerating, then I checked my phone and there's actually 15GB used by the OS.
Electron for mobile is called Cordova and has been around for a long time.
Cordova is not Electron for mobile. Calling it that is a fundamental misunderstanding of how both work.
One depends on the OS to provide its built-in Webview/UIWebview. The other packages an entire damn browser with each app.
One depends on the OS to provide its built-in Webview/UIWebview. The other packages an entire damn browser with each app.
>browser with each app.
browser and web server?
browser and web server?
Requires special modules, you can't just take random npm module e.g. sequelize. Deal breaker for me.
Capacitor is the new Cordova. Check it out.
What's the advantage of Capacitor over Cordova?
I think it basically boils down to the prominence of what I call Universal User Experience, which is basically an attempt to give users a similar experience across different device and form factors.
I believe this UUX is the powerhouse behind this second(?) weave of Write Once Run Anywhere and why we have so many libraries with web/html and iOS, Android, and various desktop frontends.
I believe this UUX is the powerhouse behind this second(?) weave of Write Once Run Anywhere and why we have so many libraries with web/html and iOS, Android, and various desktop frontends.
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 experience is producing something that feels and acts weird on every platform, and people notice. Trying to unify is a solution for a developer problem, not a solution for a user problem -- and thus it's not really a problem.
What this comes down to is focus. Developing across multiple platforms is a hard problem and requires a lot of work. It's really only suitable for larger teams. As a small team, it is better to focus on one platform, do really well, and then later when you can afford it, go to other platforms.
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 experience is producing something that feels and acts weird on every platform, and people notice. Trying to unify is a solution for a developer problem, not a solution for a user problem -- and thus it's not really a problem.
What this comes down to is focus. Developing across multiple platforms is a hard problem and requires a lot of work. It's really only suitable for larger teams. As a small team, it is better to focus on one platform, do really well, and then later when you can afford it, go to other platforms.
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.
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.
React native afaik is more about the native components, written in the target language, that receive information from the javascript code. This allows for smooth animations and in general a more responsive interface, as well as a more native look and feel than components made from html.
There's not a lot of consensus about what primitves good *-native framework needs, implementations are often pretty tied to specifics of the JS libraries they were built to be driven by (go figure), and the whole niche is still discovering what the right tradeoffs might be. On top of that, the technology atop which the star-native frameworks are built is moving forward too. Seems reasonable to expect that eventually a good non-DOM standard for these things might eventually emerge but I suspect it wouldn't be for a while .
I'll try and boil it down to some points that hopefully build on each other:
- In the mobile development there are a few approaches, including but not limited to: full-native, near-native, and webview (these aren't official terms, I just made them up)
- "full-native" is using Java on Android, Swift/ObjC on iOS, generally implying using all the tooling/patterns/etc that come. This is the hardest in terms of learning curve, Swift concepts often do not translate to android, so it's like two steep climbs.
- "near-native" is using some library/tool that compiles down to JVM bytecode/native code but usually implies bringing in new/alternative tooling (integration levels vary) that holds the promise of having less warts. This is where tools like React Native[0], Vue Native[1], NativeScript[2] fit in (I'll explain how later).
- "webview" is when you just make a mobile-friendly webpage and embed it inside an app by simply displaying it fullscreen. Android/iOS also has features these days where you can pin webpages that act like mobile apps to screens, and IIRC android "instant" apps are the same concept. These have been criticized heavily for performance/platform integration issues. This is where tools like Cordova[3] and Ionic[4] fit in.
SIDENOTE: FirefoxOS (RIP) was a mobile OS that took this to the extreme, having everything just be a webview and investing in the browser ecosystem heavily.
- In terms of difficulty/ramp-up-time/vendor-lockin, webview < near-native < native -- assuming that you know web tech already, and that the near-native toolchain is indeed easier.
- While React[7] started by targeting the web exclusively (though I think it might have always been a goal to branch out), they built in enough generalization to support react-native, whose feature is that it moved the boundaries a bit -- it works using native platform code to run a JS processing thread, and offers interop to native features directly. So it's not a webview, and not completely native, it belongs in the near-native camp but it uses concepts that allows you to treat it almost like a webview app.
- The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point.
- Since react native's near-native mechanism is well known, other projects have started to incorporate it -- Angular[5] proponents (and actually any js app in general) can use NativeScript[2] and Vue[6] proponents has been working on Vue Native[1] for a while.
- React Native, Vue Native, NativeScript are all attempts to bring the render-in-a-thread, shim-to-native-code-where-possible paradigm to different frontend frameworks that have existed.
- There are differences between Angular, React, and Vue that make it difficult for one project to interface with all of them (theoretically NativeScript could do it, as it supports any old JS app), and those differences are often opportunities for tight integration and developer ergonomics/features.
- In the end, all this is meant to enable native-feeling application development with minimal vendor/SDK lock-in and difficulty.
- There are other interesting approaches in the near-native space like https://flutter.io/ (almost like web view except natively by drawing every pixel on the screen) and http://www.lambdanative.org/ (take a small lisp runtime with you)
[EDIT] - As pointed out in the subcomments on this post, React Native does not 'compile down' to native code -- that is true. What I should have written was that it integrates with native code, not Web/DOM driven integration points.
[EDIT2] - I forgot to include/mention nativescript-vue[8] which is my favorite.
[0]: https://facebook.github.io/react-native/
[1]: https://vue-native.io/
[2]: https://www.nativescript.org/
[3]: https://cordova.apache.org/
[4]: https://ionicframework.com/
[5]: https://angularjs.org/
[6]: https://vuejs.org/
[7]: https://facebook.github.io/react
[8]: https://nativescript-vue.org/
- In the mobile development there are a few approaches, including but not limited to: full-native, near-native, and webview (these aren't official terms, I just made them up)
- "full-native" is using Java on Android, Swift/ObjC on iOS, generally implying using all the tooling/patterns/etc that come. This is the hardest in terms of learning curve, Swift concepts often do not translate to android, so it's like two steep climbs.
- "near-native" is using some library/tool that compiles down to JVM bytecode/native code but usually implies bringing in new/alternative tooling (integration levels vary) that holds the promise of having less warts. This is where tools like React Native[0], Vue Native[1], NativeScript[2] fit in (I'll explain how later).
- "webview" is when you just make a mobile-friendly webpage and embed it inside an app by simply displaying it fullscreen. Android/iOS also has features these days where you can pin webpages that act like mobile apps to screens, and IIRC android "instant" apps are the same concept. These have been criticized heavily for performance/platform integration issues. This is where tools like Cordova[3] and Ionic[4] fit in.
SIDENOTE: FirefoxOS (RIP) was a mobile OS that took this to the extreme, having everything just be a webview and investing in the browser ecosystem heavily.
- In terms of difficulty/ramp-up-time/vendor-lockin, webview < near-native < native -- assuming that you know web tech already, and that the near-native toolchain is indeed easier.
- While React[7] started by targeting the web exclusively (though I think it might have always been a goal to branch out), they built in enough generalization to support react-native, whose feature is that it moved the boundaries a bit -- it works using native platform code to run a JS processing thread, and offers interop to native features directly. So it's not a webview, and not completely native, it belongs in the near-native camp but it uses concepts that allows you to treat it almost like a webview app.
- The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point.
- Since react native's near-native mechanism is well known, other projects have started to incorporate it -- Angular[5] proponents (and actually any js app in general) can use NativeScript[2] and Vue[6] proponents has been working on Vue Native[1] for a while.
- React Native, Vue Native, NativeScript are all attempts to bring the render-in-a-thread, shim-to-native-code-where-possible paradigm to different frontend frameworks that have existed.
- There are differences between Angular, React, and Vue that make it difficult for one project to interface with all of them (theoretically NativeScript could do it, as it supports any old JS app), and those differences are often opportunities for tight integration and developer ergonomics/features.
- In the end, all this is meant to enable native-feeling application development with minimal vendor/SDK lock-in and difficulty.
- There are other interesting approaches in the near-native space like https://flutter.io/ (almost like web view except natively by drawing every pixel on the screen) and http://www.lambdanative.org/ (take a small lisp runtime with you)
[EDIT] - As pointed out in the subcomments on this post, React Native does not 'compile down' to native code -- that is true. What I should have written was that it integrates with native code, not Web/DOM driven integration points.
[EDIT2] - I forgot to include/mention nativescript-vue[8] which is my favorite.
[0]: https://facebook.github.io/react-native/
[1]: https://vue-native.io/
[2]: https://www.nativescript.org/
[3]: https://cordova.apache.org/
[4]: https://ionicframework.com/
[5]: https://angularjs.org/
[6]: https://vuejs.org/
[7]: https://facebook.github.io/react
[8]: https://nativescript-vue.org/
> The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point.
The reality is that while it may ease the transition a bit, your front-end developer will be having to dip into Swift/Obj-C often enough that eventually the supposed benefits here are moot.
Personally I think it's worth just taking the hit and learning the framework. A good book will have you productive within a week. The learning curve these days is easier with Swift and now that front-end developers are used to things like React, Flex Box, and so on, the concepts behind making iOS apps are not as different and alien as they once were.
The reality is that while it may ease the transition a bit, your front-end developer will be having to dip into Swift/Obj-C often enough that eventually the supposed benefits here are moot.
Personally I think it's worth just taking the hit and learning the framework. A good book will have you productive within a week. The learning curve these days is easier with Swift and now that front-end developers are used to things like React, Flex Box, and so on, the concepts behind making iOS apps are not as different and alien as they once were.
I can tell you, from experience building multiple apps in production from scratch, that that's not the case.
You practically never get to touch Obj-C or Java, and if you do it's usually to tweak a line or two in some third-party library which requires little to no knowledge of Obj-C or Java.
Good summary, one addition to the corrections others already made:
Android Instant Apps are not web apps. They are normal native apps, but limited in size (4MB), can be launched from a weblink and don’t get installed permanently on the device.
React native does not compile down to native code.
Correct. It does interoperate with it though, and the built-in components are indeed in native code but called via the JS bundle. Of course, a lot of external libraries are just Views-within-Views and give up some of the nice performance benefit of the native code underneath, sadly...
This is what I meant, and also what I meant when I mentioned that React Native pushed the boundaries (that I laid out above) -- it's a weird in-between of near-native, webview and native.
Let me chime in with my perspective.
(TL;DR : I can see the use for the lazy or otherwise-occupied developer who already knows vue and needs to dabble in mobile dev)
I'm the CTO of a start-up whose core product is a set of APIs. We have a little bit of front-end we had to build in a hurry for a "special" customer (as in, special enough to not know how to interface with an API). We used vue.js because frankly that's the framework the dev with the most front experience was comfortable with. So we're starting to get up to speed on vue.js, which honestly is a pretty good framework. But let me emphasize once again that building customer-facing front-ends is not our business.
I dread the day when we bring in another "extra special" customer who absolutely needs an app to use our products... vue-native, if it's robust and stable enough, might just be a quick way to build such an app without having to learn an entire stack (on another platform, no less) for a quick one-off.
(TL;DR : I can see the use for the lazy or otherwise-occupied developer who already knows vue and needs to dabble in mobile dev)
I'm the CTO of a start-up whose core product is a set of APIs. We have a little bit of front-end we had to build in a hurry for a "special" customer (as in, special enough to not know how to interface with an API). We used vue.js because frankly that's the framework the dev with the most front experience was comfortable with. So we're starting to get up to speed on vue.js, which honestly is a pretty good framework. But let me emphasize once again that building customer-facing front-ends is not our business.
I dread the day when we bring in another "extra special" customer who absolutely needs an app to use our products... vue-native, if it's robust and stable enough, might just be a quick way to build such an app without having to learn an entire stack (on another platform, no less) for a quick one-off.
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.
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.
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.