Live data from Hacker News

Vue Native

vue-native.io

31–40 of 208 posts

Re: Vue Native

#31

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 b…

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 - 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/

Re: Vue Native

#32

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 b…

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 .

Re: Vue Native

#33
post #17

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.

Re: Vue Native

#34

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

Yes, but as opposed to a traditional GUI SDK, it's manipulating those widgets with JS, within a Vue.js architecture.

Re: Vue Native

#36

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 b…

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.

Re: Vue Native

#37

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 b…

because people who only know JS have no interest in CS.

Re: Vue Native

#38
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/

Re: Vue Native

#39
post #4

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!

Re: Vue Native

#40
post #29

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 b…

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 libra…

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?
Post reply on HN