Vue Native
vue-native.io
vue-native.io
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.
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.
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.
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.
I think Cordova could be leveraged at the very least.
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.
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.)
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.
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.
First time I heared about this killer-feature :D
Disclaimer: I'm also contributing on this project.
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).
Why would you not use react native directly then? I don't get it
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.
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 personally am following/want-to-use https://nativescript-vue.org/
It doesn't touch on the Vue integration, since that's relatively new.
Instead of
<div>Hello</div>
<View><Text>Hello</Text></View>I think Weex has better performance and lighter overhead than 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.
This is fork of react-vue
1. https://github.com/SmallComfort/react-vue
Why but Why.
How did it come to this?
Is this due to the principle of getting to the market first and quick prototypes? I don’t see a quick way back.
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.
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
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.
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.
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.
- 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.
I don't feel like this is a valid justification for being wasteful, though.
(Personally, I didn't even realize OnePlus phones still exist - I thought they died out somewhere around OnePlus 3.)
I do think though that we will only be seeing more and more of this, and very soon.
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.
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.
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.
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.
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.
- 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.
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.
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.
- 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.
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.
Do you have a link about this latest rehash? I tried googling without success
Yeah you end up with crap.
I personally don't like it as I think it's wasteful and careless.
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.
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.
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.
The layers of abstraction keep adding up.
Tortoises all the way down.
Next thing someone will incorporate jslinux into this mess
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?
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...
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.
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...
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!
--
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.
Why can't the web+JS be that platform?
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...
Feel free to fork the site's code and send them a PR.
Edit: ah, the get started links to real content. Missed that.
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?
Personally I think Flutter will become the dominant cross platform solution in 2020 or so. ReactNative has always seemed like a hack to me.
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.
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.
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.
Why do you find it harder to maintain React apps after 6 months?
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://medium.com/build-ideas/my-journey-of-writing-an-e-co...
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 ?
react in itself has no two way data binding, vue has (well, it's one wayish, but let's not argue about specifics).
https://www.reddit.com/r/javascript/comments/8o781t/vuejs_or...
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.”
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.
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'd love to see the argument revisited today.
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.
What desktop apps are people using today that still have static sizes (outside of dialog/info boxes)?
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.
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 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"
- 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/
[2]: https://www.nativescript.org/
[3]: https://cordova.apache.org/
[4]: https://ionicframework.com/
[6]: https://vuejs.org/
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.
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.
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)
If only. Probably a lot closer to 4-16GB for a lot of Android phones.
I was kinda exaggerating, then I checked my phone and there's actually 15GB used by the OS.
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.
One depends on the OS to provide its built-in Webview/UIWebview. The other packages an entire damn browser with each app.
browser and web server?
(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.
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)
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.