16 ms·

Vue Native (2018)

205 points by alokrai 6y ago

Malfunction92 6y ago
I’ve been putting off switching my native apps to cross-platform simply because I’m too busy to learn react, so it’s great to see that vue is finally an option. Of course it’s probably a little too soon to completely switch live apps to this, at least until it stabilizes a little bit. Edit: never realized this existed for the past two years and is simply a wrapper for react native.. any reason it’s being posted now?
- The_rationalist 6y ago
  Ionic and quasar already allow you to make Vue on smartphones
  - sarabad2021 6y ago
    Quasar and Ionic aren’t native though. They give you the JS app in a browser packaged into an app. React/Vue native give you a real native byte code app.
    - The_rationalist 6y ago
      Ionic capacitor seamlessly integrate with native plugins and you can write your own. Btw the react native js engine is much slower than the one on Ionic, at least on IOS.
  - dstick 6y ago
    Shoutout for Framework7. I built a test app in both Ionic and Framework7 and vastly enjoyed the experience of F7 over Ionic. For Ionic Vue is still in beta, poorly documented and had some vague errors with obtuse solutions. It didn't have all the components you might want in an app either, so less boiler plate. Framework7 has full Vue documentation, and the handful of components that aren't Vueified (Calendar, Toasts) are easily integrated using native JS and the this.$f7 helper. Their creator is highly active and responds to almost all (non-idiot) questions on their forum. Downsides of F7: no SCSS but CSS variables which clutters the inspector, a lot. You can always overwrite these with a scss file but the variables are always there.
    - The_rationalist 6y ago
      Ionic vue is no longer in beta, though it will take ~a year before it reach full parity support vs other VDOMs
      - dstick 6y ago
        I stand corrected, thank you :) https://ionicframework.com/blog/announcing-ionic-vue/ https://ionicframework.com/blog/announcing-ionic-vue/ Will give it another spin. Because UI wise, it was faster.
  - IgorPartola 6y ago
    Ionic screwed me like a deck screw with their update path being more of a secret way into Mordor. Perfectly good app that can’t be compiled anymore without a full rewrite in what is effectively a completely different framework.
    - The_rationalist 6y ago
      You had to upgrade from which version to which one?
      - IgorPartola 6y ago
        I initially used it with version 1/Angular 1.x. Then when Angular 2 was basically a complete rewrite from scratch Ionic did the same. For a little bit I was still able to compile the code but quickly their tools became unavailable and unusable.
        The_rationalist 6y ago
        You were very early in the history of Ionic, I understand you :( but such breaking change should not happen anymore at this scale
        IgorPartola 6y ago
        It's true. But also I consider Angular 2+ to be inferior to other similar frameworks. It was overengineered to no end had as much to do with Angular 1.x as a space shuttle has to do with a horse buggy. I remember looking at how they proposed to specify templates via `` template strings as part of the JS code, making their template language completely unreadable and thinking how that's such a step back in usability compared to how Angular 1.x did it, which was basically what Vue.js does. And I do still have some scars that haven't fully healed from that transition. Look at Vue's evolution from 1.x to 2.x to 3.x. The new way to create components in Vue 3 is what Douglas Crockford proposed way back in like 2008. Except it's reasonably worse for code readability compared to Vue 2.x because it is completely unstructured. And at one point the Vue team was talking about taking out half the features that I routinely use in Vue 2.x such as $emit()/$on(), watchers, etc. I don't have as much experience with React, but from what I understand they break compatibility much more frequently than Vue does. Plus, JSX is a very polarizing tech and I am firmly on the side that dislikes it. Compare all of the above with a project like Django where backwards compatibility is maintained for years and developers consider it a big cost to break features. It's a much more carefully developed project and it makes running the code much easier. The template syntax has not changed in what, 10 years at least? In the meantime how many JS frameworks have we seen rise and fall? As far as I am concerned, every time a framework or library update breaks my application, the framework is imposing a cost on me. Adding new features and refining existing features? Fine. Breaking the world because someone didn't like how $emit()/$on() worked? That's like if the Linux kernel decided tomorrow to switch to using Windows syscalls because they got a Windows developer on the team.
- MatekCopatek 6y ago
  FYI - NativeScript has had Vue support for a few years now and is production ready (in my limited experience). Don't know now it compares to this though.
  - string 6y ago
    NativeScript unfortunately just can't compare with React Native in my experience. I've been a Vue dev/consultant for several years, I wanted to love NativeScript, but every single time I try to build something with it (last attempt was about 2 weeks ago) I come across a missing feature and end up begrudgingly switching to React Native.
    - simik 6y ago
      Could you give a couple examples of such missing features?
- user-the-name 6y ago
  If your goal is to actually put out high-quality apps, do not switch away from doing them natively. No cross-platform kit can compete. You are making sacrifices, sometimes big ones, in order to get the cross-platformness.
  - Malfunction92 6y ago
    I've thought a lot about this. My biggest problem is that I'm the only one maintaining the project, and using something like vue + cross-platform would make things a lot easier than maintaining 3 different code bases (ios, android, web). My understanding is that cross-platform tools have matured enough to be used as replacements to native implementations. Is that not the case?
    - stall84 6y ago
      From the (limited) work I've done building React Native app's.. In most cases, the user is not going to be able to tell any difference from a native app.
    - user-the-name 6y ago
      For simple apps, you can get away with it. If you are aiming for more than the basics, you'll run into trouble or impassable roadblocks.
bsaul 6y ago
is there any project that would us the same js - native bridge as react native, except with wasm. The idea would be to let us write cross-platform business level code in any language targeting wasm, while using a native UI framework
- jamil7 6y ago
  Not exactly the implementation you described but Kotlin Multiplatform is targeting this workflow. Shared business logic in Kotlin and Native UI on each platform. You can currently compile to iOS/Android/Web and Desktops. I imagine the could support wasm at some point too. Edit: Kotlin Multiplatform not Kotlin Native
  - aceisnotmycard 6y ago
    I think you meant Kotlin Multiplatform: https://kotlinlang.org/docs/reference/mpp-intro.html https://kotlinlang.org/docs/reference/mpp-intro.html. Kotlin/Native is a LLVM-based backend which is used in case of Kotlin Multiplatform for iOS part.
    - jamil7 6y ago
      I absolutely did! thanks. Regarding OPs point I just double checked and it does indeed support WASM as a target now.
  - bsaul 6y ago
    kotlin multiplatform looks nice, but my idea of using wasm is to support any PL able to target wasm (and the number seems to grow every day)
ktpsns 6y ago
I love functional concepts such as stateless systems, but young folks should acknowledge that two way event binding is something graphical desktop toolkits are doing since decades. For instance, Qt signal-slot mechanism https://doc.qt.io/qt-5/signalsandslots.html https://doc.qt.io/qt-5/signalsandslots.html or https://libsigcplusplus.github.io/libsigcplusplus https://libsigcplusplus.github.io/libsigcplusplus Furthermore, MVC is, when done correctly, a sane two way data-GUI binding. However, I have never seen a sane implementation ;-)
- m463 6y ago
  I wish I could figure out the openwrt MVC gui stuff
- keyle 6y ago
  Yes and yes. And I think that as a whole the industry moved towards MVVM which is a lot more achievable than MVC for the better.
- seanalltogether 6y ago
  Additionally, html documents inside browser windows are naturally stateless content systems, but applications have never had this constraint. The design patterns that are successful on a browser are usually overkill in application development. Android has baked a few of these stateless design patterns into their core frameworks and then spent years coming up with various support libraries to overcome them.
  - uryga 6y ago
    > html documents inside browser windows are naturally stateless content systems what about inputs? or do you consider them stateless because their entire¹ "state" is reflected in the DOM, i.e. <input type="checkbox"/> // *click* <input type="checkbox" checked=""/> --- ¹ - well, except focus, open/closed for <select>, and probably a bunch of other things
    - seanalltogether 6y ago
Techasura 6y ago
I would honestly throw entire salary on this if its built in the direction it claims. Only downside for Vue Developers would be to switch between frameworks(React Native) to develop a native app.
deleted 6y ago
[deleted]
aphextron 6y ago
Two way data binding tends to obscure the rendering process and add a lot of "black box" side effects, which in browser based applications leads to serious performance issues that bog things down at scale. I would like to know how they're going to avoid this.
ignoramous 6y ago
Looks like the project is seeing very little in terms of contributions of late: https://github.com/GeekyAnts/vue-native-core/graphs/contributors https://github.com/GeekyAnts/vue-native-core/graphs/contribu...
- j45 6y ago
  Definitely slow
frusciante19 6y ago
Is Vue Native really building on top of React Native? a framework currently at version 0.63.4 after almost 6 years since it was outsourced, with no v1.0 in sight, all but abandoned by Facebook, in the hands of a community that's struggling to support it?
vlz 6y ago
It should be noted that this is a wrapper around React Native.[1] I am a bit in doubt if one can use Vue Native knowing only Vue and never having to learn any React. [1]: https://github.com/GeekyAnts/vue-native-core https://github.com/GeekyAnts/vue-native-core says as much.
- M4v3R 6y ago
  That's a dealbreaker for me. Not only you need to deal with quirks, bugs and feature-parity with lates OSes of Vue Native, now you also need to deal with the same for React Native. This is a bit too much for me, it's nice when it works but sucks when it stops to work and you spend the whole day to nail down some framework-specific issues.
  - um_ya 6y ago
    It allows any react native components to work in vue native. Pretty valuable actually.
    - karmakaze 6y ago
      Is this not correct, can you use React Native components from Vue Native?
  - notsureaboutpg 6y ago
    Yeah and if you have spent any time in React Native you'll know it has lots of puzzling issues that creep up 3-4 months into development / maintenance of an app
- ppeetteerr 6y ago
  I just saw this as well. I realize that some people might be more familiar with Vue than React, but wrapping RN seems overly complicated and adds yet another layer of abstraction.
  - cumwolf 6y ago
    this is super neat that this works but also if someone actually wants to build an app I'd never recommend this. but yeah super cool
j45 6y ago
Just did a deep dive with a group of devs with vue native, nativescript, ionic and more for building a mobile app in vue. We all enjoy building in vue and we're looking to extend that to mobile. However in almost all cases, there were shortcomings and a lack of maturity in support compared to react or angular. A lot of time wasted. Generally, Vue is not a first class citizen in these environments. Yet. Vue Native began with a lot of promise and excitement. Documentation is ultimately sparse and examples either don't exist or are out of date. Compiling the same code on Mac or windows yielded inconsistent build results. Debugging doesn't have much research that is possible. Sometimes you have to compile 4 or 5 times. Still seems early.. Or not developing as quickly as other options. Doesn't seem updated often. Nativescript was next, looked very inviting and welcoming, but trying to reproduce the same resulted in a fair number of issues. It seems nativescript has less of a history with vue than react. Noted the documentation is deeper for other frameworks. Seems to be evolving for vue. Pass for now and check again in 6 to 12 months for progress. Last, but not least, ionic. Right off the bat likely the deepest documentation. It had 2 approaches.. Package a vue.js app for mobile, or use capacitor to try and build more of a native experience. Capacitor is relatively new for vue.js and still maturing. Ran into similar issues as the others. Didn't seem ready for production than using angular or react with ionic or capacitor. Vue supports in ionic are thinner than angular for sure and seemingly react. For now, it was possible to build a vue web app to do what's needed and add ionic to simply package it. No capacitor. It pains a little to say this, but if we were building a more complex app, the react native tooling is what we'd have to consider. It's far more mature and nearly every problem we encountered had a result of how to resolve it in react native.
mrtksn 6y ago
What are the trade offs/Adventages to use cross platform tools for app development in 2021? The advantages of native iOS development, off top of my head: 1) Swift is very pleasant to use and it is fast. 2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there. 3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do. 4) Work environment setup is very easy, no scripts to run no tooling that breaks down. It's as simple as creating an new Word document and start doing actual work, not janitorial tasks. 5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution. 6) The only vendor that I rely on is Apple, as soon as they make something interesting it is available to me. The latest API is there right away. 7) The apps look in place by default, you actually have to work to make UI unconventional and weird. I would imagine that on the Android side of things are also not that different. Edit: I see that you don't like the question being asked and other perspectives being presented but I think it's a fair question and I would like to know if I am missing out on something.
- oakesm9 6y ago
  The advantage is that you can access ~100% of the mobile market with a single codebase for about 10% extra work compared to native on a single platform. Performance is roughly the same and you have access to most of the platform features that most apps need.
  - mrtksn 6y ago
    That's the obvious value proposition but There's a reason why sporks did not make spoons and forks obsolete. I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling. The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.
rk06 6y ago
React native is a fantastic project. I wonder if they could make it framework agnostic, so other js frameworks can use it directly
init0 6y ago
[svelte-native ain't far?]
- eecks 6y ago
  This is what I am interested in. Looking forward to it
- c-smile 6y ago
  Svelte compilations work in Sciter.JS ( https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk ) as they are. And Sciter.JS is an embeddable UI engine for native applications so you probably don't need dedicated svelte-native at all. For that matter Sciter.JS already allows to build native Mithril.JS and PReact.JS applications too.
reinhardt1053 6y ago
2018 should be in the title
donmb 6y ago
I was using Cordova with VUE.js and had fantastic results in both iOs and Android, using "Buefy" as my UI framework. I started with Nativescript and ended up in building a WebView which I then simply included. I haven't tested Vue Native yet but wanted to know why Cordova seems to be on the decrease :( I feel like I have to develop in Vue Native or Nativescript soon to not lose track. However, I always liked the Cordova/Vue combination and I could realise fantastic apps with it.
- holtalanm 6y ago
  honestly, not sure about this either. Cordova works great without having to support two separate codebases for your views, which is what we all want. Vue Native, while sporting a nice HTML syntax, is just wrapping native components, which means you have to write your app specifically for native.
sgt 6y ago
Flutter web is also becoming a viable option for web apps. I recently wrote a new app in Flutter and it works surprisingly well on the web, not just in native iOS and Android. It has some quirks though but I did not find anything serious.
- realusername 6y ago
  I have a large Flutter codebase and I don't have the same opinion, Flutter web is still an alpha quality and it would take way too much work to make my codebase work with the web version. For desktop though, it's pretty good.
  - ignoramous 6y ago
    Have you by any chance also evaluated / considered https://platform.uno/ https://platform.uno/ ? If so, I am interested in your take on it versus Flutter.
  - sgt 6y ago
    I've built a new Flutter web app this week and I've hit some gotchas like improper rendering of text form fields (SVG flags were incorrectly set when displaying on the web, regardless of HTML or Canvas rendering it seems). However, Google engineers are actively working on problems like these and it seems like the dev branch is fairly stable and usable as of right now. I'd say 30 days ago it would not have been the case.
- kaba0 6y ago
  Isn’t it still just a canvas with basically no accessibility, and all the negatives of a flash app?
  - sofixa 6y ago
    The negatives of Flash are: * closed source * requires ag extra plugin to render * slow * fake sandbox that had too many bugs Flutter has none of these.
npmn 6y ago
Currently down due to hug of Death HN (Error 522 Ray ID: 6182f97eb9cb3bfb • 2021-01-27 13:56:00 UTC Connection timed out)
laptop-man 6y ago
whats the down side of plopping your vue app into a webview then making interfaces to call kotlin code from vuejs? thats what I've been doing to rapids app prototyping...
punnerud 6y ago
Archive updated today: http://web.archive.org/web/20210127141756/https://vue-native.io/ http://web.archive.org/web/20210127141756/https://vue-native... (If you also get error visiting the page now)
rkangel 6y ago
Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going. The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing. Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.
- mikece 6y ago
  Just like JavaScript: it's bad but it is the only thing that works everywhere so it's won.
  - pjmlp 6y ago
    Just like C: it's bad but it is the only thing that works everywhere so it's won.
    - warent 6y ago
      Thanks for pointing this out. I've made a respectable living off web technologies, and the products I've built create value for many people. Maybe it's not the sharpest knife in the kitchen and I'm not Gordon Ramsay, but the final consumer product is still pretty close to being regarded as Michelin Star quality, not as a boast but just a point of fact. Giving an flip "XYZ technology bad!" remark usually comes across as a meme or as uninformed and snobbish. The fact is these "bad" technologies do a whole lot of good.
mikece 6y ago
While this is nice, for mobile -- and even desktop -- apps I find hybrid/electron to be a far more compelling use case. On mobile, if you're stuck in a situation where you need the full power and speed of vendor native then, if you're using Ionic Capacitor, you can spin up an Activity/UIView and code that part in Java or Kotlin for Android and Swift or Obj-C for iOS (or C++ for both if you really want to). Do everything in HTML,CSS,JS that you can and only use the heavy duty tools where absolutely necessary... and the truth is, they aren't nearly as necessary as they used to be.
game_the0ry 6y ago
I see: - "react": "^15.5.4", - "react-dom": "^15.5.4" as npm dependencies. Dumb question - why does it need react as dependencies?
mpurham 6y ago
I use to frown upon cross-platform js solutions until I built a cross platform app. While the initial app building part was no problem, packaging them for various platforms (macos, windows) was pure h*l.
bfrog 6y ago
Yeah I dunno, react native is a neat idea, in practice it was all pain all the time. Updating, debugging, building, ensuring it worked on all devices, then add in something like Bluetooth LE and the pain grew even more. Would have been easier to create two apps in their native platforms.
albru123 6y ago
To be honest, I don't see any reason not to use Flutter if you want to make a cross-platform app these days. Any other cross-platform framework I tried seemed somehow lacking, slow, unpleasant to use etc.
ncrmro 6y ago
Lots of comments on HTML/CSS being hard or non optimal but learning to use things like grid (grid template areas plus designing first for mobile) and flex together really allow all sorts of layouts one would create.
Taylor_OD 6y ago
Maybe I just wasnt giving it my full devotion but I spent a day or two just trying to get Vue Native up and running late last year and no success. Maybe if I had more Reactive Native knowledge it would have been easier.

Vue Native (2018)

205 points by alokrai 6y ago

I’ve been putting off switching my native apps to cross-platform simply because I’m too busy to learn react, so it’s great to see that vue is finally an option. Of course it’s probably a little too soon to completely switch live apps to this, at least until it stabilizes a little bit. Edit: never realized this existed for the past two years and is simply a wrapper for react native.. any reason it’s being posted now?

The_rationalist 6y ago
Ionic and quasar already allow you to make Vue on smartphones
- sarabad2021 6y ago
  Quasar and Ionic aren’t native though. They give you the JS app in a browser packaged into an app. React/Vue native give you a real native byte code app.
  - The_rationalist 6y ago
    Ionic capacitor seamlessly integrate with native plugins and you can write your own. Btw the react native js engine is much slower than the one on Ionic, at least on IOS.
- dstick 6y ago
  Shoutout for Framework7. I built a test app in both Ionic and Framework7 and vastly enjoyed the experience of F7 over Ionic. For Ionic Vue is still in beta, poorly documented and had some vague errors with obtuse solutions. It didn't have all the components you might want in an app either, so less boiler plate. Framework7 has full Vue documentation, and the handful of components that aren't Vueified (Calendar, Toasts) are easily integrated using native JS and the this.$f7 helper. Their creator is highly active and responds to almost all (non-idiot) questions on their forum. Downsides of F7: no SCSS but CSS variables which clutters the inspector, a lot. You can always overwrite these with a scss file but the variables are always there.
  - The_rationalist 6y ago
    Ionic vue is no longer in beta, though it will take ~a year before it reach full parity support vs other VDOMs
    - dstick 6y ago
      I stand corrected, thank you :) https://ionicframework.com/blog/announcing-ionic-vue/ https://ionicframework.com/blog/announcing-ionic-vue/ Will give it another spin. Because UI wise, it was faster.
- IgorPartola 6y ago
  Ionic screwed me like a deck screw with their update path being more of a secret way into Mordor. Perfectly good app that can’t be compiled anymore without a full rewrite in what is effectively a completely different framework.
  - The_rationalist 6y ago
    You had to upgrade from which version to which one?
    - IgorPartola 6y ago
      I initially used it with version 1/Angular 1.x. Then when Angular 2 was basically a complete rewrite from scratch Ionic did the same. For a little bit I was still able to compile the code but quickly their tools became unavailable and unusable.
      - The_rationalist 6y ago
        You were very early in the history of Ionic, I understand you :( but such breaking change should not happen anymore at this scale
        IgorPartola 6y ago
        It's true. But also I consider Angular 2+ to be inferior to other similar frameworks. It was overengineered to no end had as much to do with Angular 1.x as a space shuttle has to do with a horse buggy. I remember looking at how they proposed to specify templates via `` template strings as part of the JS code, making their template language completely unreadable and thinking how that's such a step back in usability compared to how Angular 1.x did it, which was basically what Vue.js does. And I do still have some scars that haven't fully healed from that transition. Look at Vue's evolution from 1.x to 2.x to 3.x. The new way to create components in Vue 3 is what Douglas Crockford proposed way back in like 2008. Except it's reasonably worse for code readability compared to Vue 2.x because it is completely unstructured. And at one point the Vue team was talking about taking out half the features that I routinely use in Vue 2.x such as $emit()/$on(), watchers, etc. I don't have as much experience with React, but from what I understand they break compatibility much more frequently than Vue does. Plus, JSX is a very polarizing tech and I am firmly on the side that dislikes it. Compare all of the above with a project like Django where backwards compatibility is maintained for years and developers consider it a big cost to break features. It's a much more carefully developed project and it makes running the code much easier. The template syntax has not changed in what, 10 years at least? In the meantime how many JS frameworks have we seen rise and fall? As far as I am concerned, every time a framework or library update breaks my application, the framework is imposing a cost on me. Adding new features and refining existing features? Fine. Breaking the world because someone didn't like how $emit()/$on() worked? That's like if the Linux kernel decided tomorrow to switch to using Windows syscalls because they got a Windows developer on the team.
MatekCopatek 6y ago
FYI - NativeScript has had Vue support for a few years now and is production ready (in my limited experience). Don't know now it compares to this though.
- string 6y ago
  NativeScript unfortunately just can't compare with React Native in my experience. I've been a Vue dev/consultant for several years, I wanted to love NativeScript, but every single time I try to build something with it (last attempt was about 2 weeks ago) I come across a missing feature and end up begrudgingly switching to React Native.
  - simik 6y ago
    Could you give a couple examples of such missing features?
user-the-name 6y ago
If your goal is to actually put out high-quality apps, do not switch away from doing them natively. No cross-platform kit can compete. You are making sacrifices, sometimes big ones, in order to get the cross-platformness.
- Malfunction92 6y ago
  I've thought a lot about this. My biggest problem is that I'm the only one maintaining the project, and using something like vue + cross-platform would make things a lot easier than maintaining 3 different code bases (ios, android, web). My understanding is that cross-platform tools have matured enough to be used as replacements to native implementations. Is that not the case?
  - stall84 6y ago
    From the (limited) work I've done building React Native app's.. In most cases, the user is not going to be able to tell any difference from a native app.
  - user-the-name 6y ago
    For simple apps, you can get away with it. If you are aiming for more than the basics, you'll run into trouble or impassable roadblocks.

bsaul 6y ago

is there any project that would us the same js - native bridge as react native, except with wasm. The idea would be to let us write cross-platform business level code in any language targeting wasm, while using a native UI framework

jamil7 6y ago
Not exactly the implementation you described but Kotlin Multiplatform is targeting this workflow. Shared business logic in Kotlin and Native UI on each platform. You can currently compile to iOS/Android/Web and Desktops. I imagine the could support wasm at some point too. Edit: Kotlin Multiplatform not Kotlin Native
- aceisnotmycard 6y ago
  I think you meant Kotlin Multiplatform: https://kotlinlang.org/docs/reference/mpp-intro.html https://kotlinlang.org/docs/reference/mpp-intro.html. Kotlin/Native is a LLVM-based backend which is used in case of Kotlin Multiplatform for iOS part.
  - jamil7 6y ago
    I absolutely did! thanks. Regarding OPs point I just double checked and it does indeed support WASM as a target now.
- bsaul 6y ago
  kotlin multiplatform looks nice, but my idea of using wasm is to support any PL able to target wasm (and the number seems to grow every day)

ktpsns 6y ago

I love functional concepts such as stateless systems, but young folks should acknowledge that two way event binding is something graphical desktop toolkits are doing since decades. For instance, Qt signal-slot mechanism https://doc.qt.io/qt-5/signalsandslots.html https://doc.qt.io/qt-5/signalsandslots.html or https://libsigcplusplus.github.io/libsigcplusplus https://libsigcplusplus.github.io/libsigcplusplus Furthermore, MVC is, when done correctly, a sane two way data-GUI binding. However, I have never seen a sane implementation ;-)

m463 6y ago
I wish I could figure out the openwrt MVC gui stuff
keyle 6y ago
Yes and yes. And I think that as a whole the industry moved towards MVVM which is a lot more achievable than MVC for the better.
seanalltogether 6y ago
Additionally, html documents inside browser windows are naturally stateless content systems, but applications have never had this constraint. The design patterns that are successful on a browser are usually overkill in application development. Android has baked a few of these stateless design patterns into their core frameworks and then spent years coming up with various support libraries to overcome them.
- uryga 6y ago
  > html documents inside browser windows are naturally stateless content systems what about inputs? or do you consider them stateless because their entire¹ "state" is reflected in the DOM, i.e. <input type="checkbox"/> // *click* <input type="checkbox" checked=""/> --- ¹ - well, except focus, open/closed for <select>, and probably a bunch of other things
  - seanalltogether 6y ago

Techasura 6y ago

I would honestly throw entire salary on this if its built in the direction it claims. Only downside for Vue Developers would be to switch between frameworks(React Native) to develop a native app.

deleted 6y ago

[deleted]

aphextron 6y ago

Two way data binding tends to obscure the rendering process and add a lot of "black box" side effects, which in browser based applications leads to serious performance issues that bog things down at scale. I would like to know how they're going to avoid this.

ignoramous 6y ago

Looks like the project is seeing very little in terms of contributions of late: https://github.com/GeekyAnts/vue-native-core/graphs/contributors https://github.com/GeekyAnts/vue-native-core/graphs/contribu...

j45 6y ago
Definitely slow

frusciante19 6y ago

Is Vue Native really building on top of React Native? a framework currently at version 0.63.4 after almost 6 years since it was outsourced, with no v1.0 in sight, all but abandoned by Facebook, in the hands of a community that's struggling to support it?

vlz 6y ago

It should be noted that this is a wrapper around React Native.[1] I am a bit in doubt if one can use Vue Native knowing only Vue and never having to learn any React. [1]: https://github.com/GeekyAnts/vue-native-core https://github.com/GeekyAnts/vue-native-core says as much.

M4v3R 6y ago
That's a dealbreaker for me. Not only you need to deal with quirks, bugs and feature-parity with lates OSes of Vue Native, now you also need to deal with the same for React Native. This is a bit too much for me, it's nice when it works but sucks when it stops to work and you spend the whole day to nail down some framework-specific issues.
- um_ya 6y ago
  It allows any react native components to work in vue native. Pretty valuable actually.
  - karmakaze 6y ago
    Is this not correct, can you use React Native components from Vue Native?
- notsureaboutpg 6y ago
  Yeah and if you have spent any time in React Native you'll know it has lots of puzzling issues that creep up 3-4 months into development / maintenance of an app
ppeetteerr 6y ago
I just saw this as well. I realize that some people might be more familiar with Vue than React, but wrapping RN seems overly complicated and adds yet another layer of abstraction.
- cumwolf 6y ago
  this is super neat that this works but also if someone actually wants to build an app I'd never recommend this. but yeah super cool

j45 6y ago

Just did a deep dive with a group of devs with vue native, nativescript, ionic and more for building a mobile app in vue. We all enjoy building in vue and we're looking to extend that to mobile. However in almost all cases, there were shortcomings and a lack of maturity in support compared to react or angular. A lot of time wasted. Generally, Vue is not a first class citizen in these environments. Yet. Vue Native began with a lot of promise and excitement. Documentation is ultimately sparse and examples either don't exist or are out of date. Compiling the same code on Mac or windows yielded inconsistent build results. Debugging doesn't have much research that is possible. Sometimes you have to compile 4 or 5 times. Still seems early.. Or not developing as quickly as other options. Doesn't seem updated often. Nativescript was next, looked very inviting and welcoming, but trying to reproduce the same resulted in a fair number of issues. It seems nativescript has less of a history with vue than react. Noted the documentation is deeper for other frameworks. Seems to be evolving for vue. Pass for now and check again in 6 to 12 months for progress. Last, but not least, ionic. Right off the bat likely the deepest documentation. It had 2 approaches.. Package a vue.js app for mobile, or use capacitor to try and build more of a native experience. Capacitor is relatively new for vue.js and still maturing. Ran into similar issues as the others. Didn't seem ready for production than using angular or react with ionic or capacitor. Vue supports in ionic are thinner than angular for sure and seemingly react. For now, it was possible to build a vue web app to do what's needed and add ionic to simply package it. No capacitor. It pains a little to say this, but if we were building a more complex app, the react native tooling is what we'd have to consider. It's far more mature and nearly every problem we encountered had a result of how to resolve it in react native.

mrtksn 6y ago

What are the trade offs/Adventages to use cross platform tools for app development in 2021? The advantages of native iOS development, off top of my head: 1) Swift is very pleasant to use and it is fast. 2) The UI libraries that I need to learn: UIKit and SwiftUI. SwiftUI is also very pleasant to use and it is getting there. 3) No hoops to jump for integrating API that makes an App do things that WebApp cannot do. 4) Work environment setup is very easy, no scripts to run no tooling that breaks down. It's as simple as creating an new Word document and start doing actual work, not janitorial tasks. 5) Despite its bugs, Xcode is a good IDE that natively understand all the tooling I use. Autocomplete might break down sometimes but it can handle project creation, asset management, project configurations and the distribution. 6) The only vendor that I rely on is Apple, as soon as they make something interesting it is available to me. The latest API is there right away. 7) The apps look in place by default, you actually have to work to make UI unconventional and weird. I would imagine that on the Android side of things are also not that different. Edit: I see that you don't like the question being asked and other perspectives being presented but I think it's a fair question and I would like to know if I am missing out on something.

oakesm9 6y ago
The advantage is that you can access ~100% of the mobile market with a single codebase for about 10% extra work compared to native on a single platform. Performance is roughly the same and you have access to most of the platform features that most apps need.
- mrtksn 6y ago
  That's the obvious value proposition but There's a reason why sporks did not make spoons and forks obsolete. I messed around with a few cross platform tools a bit and my impression is that if you want to make something that is better than a WebApp you actually have to learn a lot more tools and frameworks and everything feels like falling apart and you are depended on multiple vendors to upkeep the tooling. The moment you say that your app is more than an UI to access a database, native on multiple platforms is actually easier.

rk06 6y ago

React native is a fantastic project. I wonder if they could make it framework agnostic, so other js frameworks can use it directly

init0 6y ago

[svelte-native ain't far?]

eecks 6y ago
This is what I am interested in. Looking forward to it
c-smile 6y ago
Svelte compilations work in Sciter.JS ( https://github.com/c-smile/sciter-js-sdk https://github.com/c-smile/sciter-js-sdk ) as they are. And Sciter.JS is an embeddable UI engine for native applications so you probably don't need dedicated svelte-native at all. For that matter Sciter.JS already allows to build native Mithril.JS and PReact.JS applications too.

reinhardt1053 6y ago

2018 should be in the title

donmb 6y ago

I was using Cordova with VUE.js and had fantastic results in both iOs and Android, using "Buefy" as my UI framework. I started with Nativescript and ended up in building a WebView which I then simply included. I haven't tested Vue Native yet but wanted to know why Cordova seems to be on the decrease :( I feel like I have to develop in Vue Native or Nativescript soon to not lose track. However, I always liked the Cordova/Vue combination and I could realise fantastic apps with it.

holtalanm 6y ago
honestly, not sure about this either. Cordova works great without having to support two separate codebases for your views, which is what we all want. Vue Native, while sporting a nice HTML syntax, is just wrapping native components, which means you have to write your app specifically for native.

sgt 6y ago

Flutter web is also becoming a viable option for web apps. I recently wrote a new app in Flutter and it works surprisingly well on the web, not just in native iOS and Android. It has some quirks though but I did not find anything serious.

realusername 6y ago
I have a large Flutter codebase and I don't have the same opinion, Flutter web is still an alpha quality and it would take way too much work to make my codebase work with the web version. For desktop though, it's pretty good.
- ignoramous 6y ago
  Have you by any chance also evaluated / considered https://platform.uno/ https://platform.uno/ ? If so, I am interested in your take on it versus Flutter.
- sgt 6y ago
  I've built a new Flutter web app this week and I've hit some gotchas like improper rendering of text form fields (SVG flags were incorrectly set when displaying on the web, regardless of HTML or Canvas rendering it seems). However, Google engineers are actively working on problems like these and it seems like the dev branch is fairly stable and usable as of right now. I'd say 30 days ago it would not have been the case.
kaba0 6y ago
Isn’t it still just a canvas with basically no accessibility, and all the negatives of a flash app?
- sofixa 6y ago
  The negatives of Flash are: * closed source * requires ag extra plugin to render * slow * fake sandbox that had too many bugs Flutter has none of these.

npmn 6y ago

Currently down due to hug of Death HN (Error 522 Ray ID: 6182f97eb9cb3bfb • 2021-01-27 13:56:00 UTC Connection timed out)

laptop-man 6y ago

whats the down side of plopping your vue app into a webview then making interfaces to call kotlin code from vuejs? thats what I've been doing to rapids app prototyping...

punnerud 6y ago

Archive updated today: http://web.archive.org/web/20210127141756/https://vue-native.io/ http://web.archive.org/web/20210127141756/https://vue-native... (If you also get error visiting the page now)

rkangel 6y ago

Is anyone else sad that we have adopted HTML/CSS as the universal lingua franca for describing views? I understand why (or at least I believe I do): HTML/CSS is an inevitable part of the ecosystem because the web is an important target. A lot of devs will know at least some, and your organisation may already have loads of them because you also need to target the web. Maybe you even already have some view code written for the web platform that you want to re-use. This means that HTML/CSS gives you a head-start due to existing skillsets. It's familiar for some people and they can get going. The problem is that it's bad. I say this as someone who comes from the outside, and isn't an expert ("barely competent" in HTML/CSS is probably accurate). Basic layout of things in a way that copes with different screen sizes/orientations is a surprisingly black art sometimes. There's a lot of history confusing the issue and three ways of doing each thing. Coming at it fresh, it's a lot to learn to build a desktop/mobile UI. Flutter (for example) has its issues, but getting things to lay out correctly did not take a lot of learning. Once you've got the basics (3 days to a week for me, including learning Dart) things behaved predictably - it seems to take a lot of HTML/CSS knowledge before that is the case.

mikece 6y ago
Just like JavaScript: it's bad but it is the only thing that works everywhere so it's won.
- pjmlp 6y ago
  Just like C: it's bad but it is the only thing that works everywhere so it's won.
  - warent 6y ago
    Thanks for pointing this out. I've made a respectable living off web technologies, and the products I've built create value for many people. Maybe it's not the sharpest knife in the kitchen and I'm not Gordon Ramsay, but the final consumer product is still pretty close to being regarded as Michelin Star quality, not as a boast but just a point of fact. Giving an flip "XYZ technology bad!" remark usually comes across as a meme or as uninformed and snobbish. The fact is these "bad" technologies do a whole lot of good.

mikece 6y ago

While this is nice, for mobile -- and even desktop -- apps I find hybrid/electron to be a far more compelling use case. On mobile, if you're stuck in a situation where you need the full power and speed of vendor native then, if you're using Ionic Capacitor, you can spin up an Activity/UIView and code that part in Java or Kotlin for Android and Swift or Obj-C for iOS (or C++ for both if you really want to). Do everything in HTML,CSS,JS that you can and only use the heavy duty tools where absolutely necessary... and the truth is, they aren't nearly as necessary as they used to be.

game_the0ry 6y ago

I see: - "react": "^15.5.4", - "react-dom": "^15.5.4" as npm dependencies. Dumb question - why does it need react as dependencies?

mpurham 6y ago

I use to frown upon cross-platform js solutions until I built a cross platform app. While the initial app building part was no problem, packaging them for various platforms (macos, windows) was pure h*l.

bfrog 6y ago

Yeah I dunno, react native is a neat idea, in practice it was all pain all the time. Updating, debugging, building, ensuring it worked on all devices, then add in something like Bluetooth LE and the pain grew even more. Would have been easier to create two apps in their native platforms.

albru123 6y ago

To be honest, I don't see any reason not to use Flutter if you want to make a cross-platform app these days. Any other cross-platform framework I tried seemed somehow lacking, slow, unpleasant to use etc.

ncrmro 6y ago

Lots of comments on HTML/CSS being hard or non optimal but learning to use things like grid (grid template areas plus designing first for mobile) and flex together really allow all sorts of layouts one would create.

Taylor_OD 6y ago

Maybe I just wasnt giving it my full devotion but I spent a day or two just trying to get Vue Native up and running late last year and no success. Maybe if I had more Reactive Native knowledge it would have been easier.