6 ms·

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?

• tmh79 8y ago
  there is some react-vr code for occulus
  • ehnto 8y ago
    It just seems like an odd tooling choice. The rest of the VR ecosystem uses completely different tooling and languages. Why not build a good GUI library in one of those? I just don't see what React brings to the table I guess.
• omeid2 8y ago
  I think it basically boils down to the prominence of what I call Universal User Experience, which is basically an attempt to give users a similar experience across different device and form factors. I believe this UUX is the powerhouse behind this second(?) weave of Write Once Run Anywhere and why we have so many libraries with web/html and iOS, Android, and various desktop frontends.
  • danielrhodes 8y ago
    I've been down this road: it did not end well. Facebook also went down this road and seems to have realized something similar (and hence why they pulled back on HTML5 on mobile and have not attempted to make React Native fully cross platform). The reason why is essentially every platform (iOS/Android/web) has its own characteristics, charms, quirks, habits, and behaviors. Trying to smush these all into one unified UX experience is producing something that feels and acts weird on every platform, and people notice. Trying to unify is a solution for a developer problem, not a solution for a user problem -- and thus it's not really a problem. What this comes down to is focus. Developing across multiple platforms is a hard problem and requires a lot of work. It's really only suitable for larger teams. As a small team, it is better to focus on one platform, do really well, and then later when you can afford it, go to other platforms.
    • ldng 8y ago
      I kind of disagree, the argument back then (6 years ago) was that the rendering was slow. That argument has not been revisited since. And new ones were made along the way. IMHO, Facebook was just looking for developers mindshare. If the core of your app is bloated, speeding up rendering is pretty moot. I'd love to see the argument revisited today.
      • vlozko 8y ago
        React native to this day is not performant. On iOS the difference may not be as noticeable for most UIs as most iPhones have pretty powerful processors, even for devices 3-4 years old. However, on Android, it’s a crapshoot.
• foota 8y ago
  React native afaik is more about the native components, written in the target language, that receive information from the javascript code. This allows for smooth animations and in general a more responsive interface, as well as a more native look and feel than components made from html.
• jdminhbg 8y ago
  > Why this instead of say Electron The major difference is that Electron is a way of wrapping a webapp with access to the filesystem, etc. via Node, and React Native is a way of instantiating, styling, and manipulating actual native components with JavaScript.
• ehnto 8y ago
  It's normally in an attempt to "build once deploy everywhere" using tools first built as web technologies. The same selling point as the JVM for Java. In some ways Electron serves as a bit of a JVM for web, but then, that is also the utility of a browser. You can see it as an artifact of the web technology coming first and trying to port it backward to other devices. I wish we had ported some of the awesome GUI libraries from native languages forward to the web instead, perhaps when Web Assembly is ubiquitous we can finally have some coherence in tooling.
  • chacham15 8y ago
    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?
    • woah 8y ago
      Lots of times the people on HN advocating for native ui toolkits just have fond memories of a form builder on Windows 95 when you didn't have to worry about all these different screen sizes and stuff.
      • mirkules 8y ago
        And yet not a single valid reason is given. "Because it's the old way of doing things" is completely inadequate as a technical reason to not use a technology.
        • BjoernKW 8y ago
          Having to worry about all these different screen sizes, devices, browsers and OS is a completely valid reason for not using a Windows 95 era form builder anymore.
          • deaddodo 8y ago
            As pointed out in other responses, pretty much every native kit nowadays offers sizing. Hell, it was one of the selling points for GTK+ back in 1998. What desktop apps are people using today that still have static sizes (outside of dialog/info boxes)?
• hardwaresofton 8y ago
  I'll try and boil it down to some points that hopefully build on each other: - In the mobile development there are a few approaches, including but not limited to: full-native, near-native, and webview (these aren't official terms, I just made them up) - "full-native" is using Java on Android, Swift/ObjC on iOS, generally implying using all the tooling/patterns/etc that come. This is the hardest in terms of learning curve, Swift concepts often do not translate to android, so it's like two steep climbs. - "near-native" is using some library/tool that compiles down to JVM bytecode/native code but usually implies bringing in new/alternative tooling (integration levels vary) that holds the promise of having less warts. This is where tools like React Native[0], Vue Native[1], NativeScript[2] fit in (I'll explain how later). - "webview" is when you just make a mobile-friendly webpage and embed it inside an app by simply displaying it fullscreen. Android/iOS also has features these days where you can pin webpages that act like mobile apps to screens, and IIRC android "instant" apps are the same concept. These have been criticized heavily for performance/platform integration issues. This is where tools like Cordova[3] and Ionic[4] fit in. SIDENOTE: FirefoxOS (RIP) was a mobile OS that took this to the extreme, having everything just be a webview and investing in the browser ecosystem heavily. - In terms of difficulty/ramp-up-time/vendor-lockin, webview < near-native < native -- assuming that you know web tech already, and that the near-native toolchain is indeed easier. - While React[7] started by targeting the web exclusively (though I think it might have always been a goal to branch out), they built in enough generalization to support react-native, whose feature is that it moved the boundaries a bit -- it works using native platform code to run a JS processing thread, and offers interop to native features directly. So it's not a webview, and not completely native, it belongs in the near-native camp but it uses concepts that allows you to treat it almost like a webview app. - The existence of React Native is a huge difference-maker for react. If you want to sell your team on react, the ability for a frontend developer to easily handle mobile application development is a strong selling point. - Since react native's near-native mechanism is well known, other projects have started to incorporate it -- Angular[5] proponents (and actually any js app in general) can use NativeScript[2] and Vue[6] proponents has been working on Vue Native[1] for a while. - React Native, Vue Native, NativeScript are all attempts to bring the render-in-a-thread, shim-to-native-code-where-possible paradigm to different frontend frameworks that have existed. - There are differences between Angular, React, and Vue that make it difficult for one project to interface with all of them (theoretically NativeScript could do it, as it supports any old JS app), and those differences are often opportunities for tight integration and developer ergonomics/features. - In the end, all this is meant to enable native-feeling application development with minimal vendor/SDK lock-in and difficulty. - There are other interesting approaches in the near-native space like https://flutter.io/ https://flutter.io/ (almost like web view except natively by drawing every pixel on the screen) and http://www.lambdanative.org/ 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/ https://facebook.github.io/react-native/ [1]: https://vue-native.io/ https://vue-native.io/ [2]: https://www.nativescript.org/ https://www.nativescript.org/ [3]: https://cordova.apache.org/ https://cordova.apache.org/ [4]: https://ionicframework.com/ https://ionicframework.com/ [5]: https://angularjs.org/ https://angularjs.org/ [6]: https://vuejs.org/ https://vuejs.org/ [7]: https://facebook.github.io/react https://facebook.github.io/react [8]: https://nativescript-vue.org/ https://nativescript-vue.org/
• dikaiosune 8y ago
  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 .
• filleduchaos 8y ago
  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.
  • berti 8y ago
    Well, those excuses are garbage everywhere. :/ All the extra electricity burned around the world would easily pay for more highly skilled devs to write a native application (source: plucked from thin air ;) ).
    • pnloyd 8y ago
      I'll admit making desktop applications in electron seems just as crazy to me as it does many others, but.. after using Vscode I've questioned that there must be something to it. Vscode has pretty great performance and is a serious pleasure to use with the right customizations. Should some of that success be credited to electron? (I'm just asking, not implying)
      • berti 8y ago
        I've been using it a bit at work.. The thing that stops me fully adopting it is how long it takes to start, and then it's very laggy for the first few seconds after that. It is a very nice editor once it's running though for sure!
      • filleduchaos 8y ago
        VSCode's success is due to the team that builds it using Electron as a tool, not as a crutch.
  • notamy 8y ago
    > 32 to 64GB of onboard storage. If only. Probably a lot closer to 4-16GB for a lot of Android phones.
• axaxs 8y ago
  because people who only know JS have no interest in CS.
• laurentl 8y ago
  Let me chime in with my perspective. (TL;DR : I can see the use for the lazy or otherwise-occupied developer who already knows vue and needs to dabble in mobile dev) I'm the CTO of a start-up whose core product is a set of APIs. We have a little bit of front-end we had to build in a hurry for a "special" customer (as in, special enough to not know how to interface with an API). We used vue.js because frankly that's the framework the dev with the most front experience was comfortable with. So we're starting to get up to speed on vue.js, which honestly is a pretty good framework. But let me emphasize once again that building customer-facing front-ends is not our business. I dread the day when we bring in another "extra special" customer who absolutely needs an app to use our products... vue-native, if it's robust and stable enough, might just be a quick way to build such an app without having to learn an entire stack (on another platform, no less) for a quick one-off.
• Illniyar 8y ago
  Cordova is the "electron" equivalent for mobile. I.E. running a browser rendering engine embedded inside an app. There are 2 main reasons for making (or using) the *-native libraries as opposed to using a browser rendering approach - 1- performance. Html and CSS are insanely bloated specification for making an app. There is really no way for a browser to rival the performance of a native app. This comes into play in mobile more then desktop and is really visible when dealing with animations and very large lists/tables. 2- native looking UI. using electron you can fake a webapp to look like a native app, but it will never have all of the edge cases (for example some keyboards don't open in a browser. Web inputs behave differently then native inputs. And of-course animations). You can think of the Native part in react-native or native-script etc... as native ui components. Which is what all of these technologies are attempting to achieve - having the look and feel of the native components of each OS while keeping the logic and layout code the same. As to why vue-native, react-native, nativescript (angular) etc... rather then having a single base where you can use multiple different frameworks on top - nativescript is trying to do that. react-native is built in such a way that only virtual dom diffing based frameworks can work with it (which is why vue can while angular can't)