12 ms·

React Native for Ubuntu

380 points by bpierre 10y ago

deleted 10y ago
[deleted]
pluma 10y ago
So iOS, Android, macOS, UWP and now Ubuntu. Awesome to see vendors like MS and Canonical jump in to bring React Native to their platform. I'm looking forward to seeing universal component sets that make it easy to develop cross-platform desktop apps.
- cel1ne 10y ago
  I wrote a library, react-native-style-tachyons[0] (based on tachyons.css), which makes it easy to have at least consistent styling for react-native. I think this is a good thing for shareable components, as they would have consistent spacing etc. [0] https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons
  - pluma 10y ago
    I'm not really talking about styling, more about the same kind of abstraction you get for Android vs iOS: common components are exposed as the same "universal" component that will render as the specific one on each OS and OS-specific ones are instead used directly.
- mountaineer22 10y ago
  This was cross-platform too: https://en.wikipedia.org/wiki/Swing_(Java) https://en.wikipedia.org/wiki/Swing_(Java)
  - mtrimpe 10y ago
    Not in the same way though. Swing drew and managed its own widgets using cross-platform Java. React Native uses native widgets and drives them from cross-platform JavaScript.
    - mountaineer22 10y ago
      I find your comment incredibly insightful. Wonderful. Thank you.
    - DoubleMalt 10y ago
      In that React Native is more like SWT (also not entirely joyfult to work with)
  - _asummers 10y ago
    It was also highly stateful and was unpleasant to use, neither of which are problems with React. I do mostly backend, but I do code review on all our front end code, and it really seems to be close to the right abstractions for building good UIs.
    - Drdrdrq 10y ago
      IMHO it was actually quite easy to use and had very sensible abstractions, however it failed to look good anywhere. SWT was much better in this regard (but much less fun to use).
      - duaneb 10y ago
        It was straightforward to use. I wouldn't call it easy by any stretch of the imagination--you're still trapped into Java-style callbacks. It also has all the classic problems of event loop oriented frameworks, meaning you're manually managing massive state machines. IIRC there was no attempt to assist organizing the data flow across user actions except via traditional threading coordination mechanisms.
        beagle3 10y ago
        What other coordination mechanisms do you have in mind? (assuming closureless/continuationless languages like Java or C++ pre 14)
        duaneb 10y ago
        Well, I wouldn't use a closureless/continuationless language for a UI except as a platform for a higher language. This is 2016 and the lack of such primitives are absurd. For the time, Swing was pretty good. Things have moved on and now data flow and state management are primary selling points—see things like CoreData (I'm not really aware of anything like it in other languages) or two-way binding that's prevalent in javascript libraries. This by no means solves state management but I think the primitives are easier to reason with.
      - 10y ago
  - pluma 10y ago
    Swing is cross-platform in the sense that "HTML5" (i.e. HTML-plus-JS-plus-CSS-plus-Web APIs in a browser) is cross-platform. The "Native" part about React Native refers to React Native using native components of the operating system (like SWT, I think?).
- dfabulich 10y ago
  It still doesn't work on older Windows, which seems like a glaring omission to me. Windows 7 remains the most popular version of Windows; UWP runs on Windows 10+ only.
  - mwcampbell 10y ago
    All of the official ports of React Native are targeted at mobile or touch-first platforms. (I consider the UWP and Ubuntu ports official in that they come from Microsoft and Canonical, respectively.) Only the unofficial Mac port can truly be said to target a desktop platform. What underlying toolkit would a Windows desktop port of React Native use, anyway? WPF? Old Win32?
    - JaRail 10y ago
      Microsoft has already answered this. Their React Native target for the windows desktop uses UWP. Microsoft is pushing UWP as a capable desktop platform. AFAIK, they aren't ending support for their other platforms just yet. WPF is still being worked on last I heard. If you look at win10+, UWP is a perfectly valid choice for React Native. You could have React Native targets for WPF, win32, etc etc if you wanted.. I'm not sure what use cases could benefit from that though. Keep in mind, if they're missing something in UWP that they need for React Native, they can add it to UWP.
methyl 10y ago
Is this guy rather platform allowing to develop React Native apps on Ubuntu or developing React Native apps FOR Ubuntu Touch? Or maybe both? The README is pretty vague.
- jabbernotty 10y ago
  Is this sentence machine-generated?
  - fit2rule 10y ago
    Isn't everything?
    - m_mueller 10y ago
      Now this (d?)evolved into a philosophical discussion pretty fast...
  - methyl 10y ago
    Is this question machine-generated?
- owaislone 10y ago
  For Ubuntu and Ubuntu Touch
deleted 10y ago
[deleted]
vmateixeira 10y ago
Am I the only one who feels like this is anything but native?
- oakesm9 10y ago
  I've worked as a "real" native Android and iOS developer for a fair few years and just started working on a project which is built using React Native (Android and iOS). You're right that the development experience is nothing like "real" native. It's using lots of web tech so it's never going to feel like Java or Swift, however, that comes with its own advantages such as code reuse and libraries. I'm actually really impressed with the quality of the apps you can create with it. They feel native and feel really smooth, but you need to be aware of the limitations. The major one is that the apps are essentially single threaded so you need to be aware what work you're doing to avoid UI stutters. That does make it less suited for very data heavy apps, but you can work around it if needed. Overall, as a "real" native developer I'm pleasantly surprised.
  - caleblloyd 10y ago
    Can you use React Native for the UI thread and talk to another thread to get data or perform long running calculations?
    - kcorbitt 10y ago
      Yes, I do this in my app. It's well-supported by the platform and quite easy -- there are built-in primitives to call a native function from javascript that returns a promise, which can then be fulfilled/returned asynchronously on the native side once your long-running calculation or transfer is finished.
  - vmateixeira 10y ago
    My main concern is about the performance and overhead that whole node ecosystem brings. Despite that, it's nice to read a positive feedback :)
    - 10y ago
amelius 10y ago
So they are basically rewriting the concept of a web-browser (which already is an application delivery platform)? Personally, I think this is crazy, and it saddens me. Why not cooperate with the browser vendors. Given their position, they should be able to pull some strings here and there.
- owaislone 10y ago
  This has got nothing to do with browsers. This is just a set of APIs that allows developers to use ReactJS (not web, just javascript) to write Ubuntu apps. I didn't read the ReadMe in detail but judging from React Native for Android, iOS, Windows and OS X, this will use QT UI toolkit under the hood, not web tech.
  - amelius 10y ago
    This has everything to do with browsers. What React Native does comes very close to what a browser is doing. React is just a very thin layer on top of JS/HTML that makes the browser a little more efficient and pleasant to program for (they are not the only ones by the way, there are many virtual dom implementations). But that layer is getting thicker and thicker. You can say "react native" and "browser" are different things, but they really aren't. Both are application delivery platforms. My problems with React: - They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms. - They put too much functionality into a single framework. - Frameworks are a bad idea anyway. It is much better to divide functionality into self-contained libraries. - They try to redo what the web, a huge standardization effort, is doing. - React does not fully support all HTML/CSS constructs. Now all of this isn't really a problem right now. But if React grows and gains more traction, then it could become a problem (just like Internet Explorer became a problem after a while).
    - Benjamin_Dobell 10y ago
      Have you ever used React Native, or read anything about it for that matter? It's just JavaScript wrappers for native UI toolkits. Much in the same way there are Python wrappers, Ruby wrappers etc. The only difference between React Native and someone else's JS bindings is that React Native makes use of a virtual view hierarchy and several other React-isms - which have absolutely nothing to do with the web except in-so-far as that they were first implemented on the web. Yes, React Native supports an API based on the web's Flexbox API, and view styling similar to CSS - but these are applied to native views. React Native doesn't implement any rendering of its own. However, if anything this is bringing web technologies to native development, they're in no way conflicting with browsers - React Native has nothing to do with a web browser. As I said, React Native provides bindings for native UI development. Now, whether or not you think that's a good idea is up to you. Swift and Cocoa are generally pretty good, so I can see why iOS devs might steer clear. However, the Android SDK is a complete joke, React Native is significantly more efficient to develop with.
PudgePacket 10y ago
Perhaps change to the title to ubuntu mobile? It's a little ambiguous.
- Tergmap 10y ago
  Should be for Unity 8, therefore for desktop as well.
  - PudgePacket 10y ago
    Ah, thanks.
iamleppert 10y ago
Why wouldn't you use something like Electron in this case and leverage a real browser? This strikes me as a really bad idea to make a native-like app in a cross-platform way. Not everything needs to be react these days, guys.
- geon 10y ago
  The whole point of react native is to not have to deal with a browser. React native is not for cross-platform development.
  - Illniyar 10y ago
    It is. Just in a different way. Its cross platform development of logic, with per platform development of ui.
    - madeofpalk 10y ago
      Not "Write once, run everywhere" but "learn once, write everywhere"
- owaislone 10y ago
  Electron is more like phonegap. React native is nothing like Electron. React Native's aim is not to bring HTML and web technologies to other platforms. The idea is to allow developers to write UIs in native UI toolkits using the react API. The end result is not a webpage wrapped in a browser window like electron or phonegap but actual platform native widgets controlled by JS code instead of objective-c, Java or C++.
Tergmap 10y ago
React Native is just React using native components instead of the typical web components. All this is about React Native also supporting native components in Ubuntu, namely the phone and the new desktop.
- JaRail 10y ago
  There's more to it than that. React Native has a lot of things that aren't in React/ReactDOM. The most obvious is the bridge between javascript and native code. React Native has supporting tools like the packager which you wouldn't hear too much about in high-level comparisons. But when you compare targets like iOS, Android, and Windows, they are all using different javascript engines. There is a lot of platform-specific work that needs to happen before you can write native components. Conversely, ReactDOM has the code to create/update DOM. ReactDOMServer outputs static HTML. What we used to call React.JS (or simply react) is now the combination of React, ReactDOM, and ReactDOMServer. React (the "react" npm package) doesn't target anything.
m45t3r 10y ago
I find it is strange that a supported development plataform for Ubuntu on Ubuntu uses dependencies outside the main repositories (ppa seems fine, however they even use npm directly to download some dependencies). This is a pretty fragile ecosystem. Yesterday I saw one colleague having build problems from a Maven project because one dependency changed hosts. Seemingly an easy fix, however in the new host they didn't include the version used by this specific program. My colleague ended up blindly using a newer version that seemed to work, however this is pretty fragily.
- lima 10y ago
  > This is a pretty fragile ecosystem Bad from a security point of view, too. Linux distribution packages are digitally signed and reviewed.
  - mikegerwitz 10y ago
    This is one of the most important points. And an issue for it has been open since Jan 2015: https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29 It's, imo, negligent.
    - grandalf 10y ago
      Is there a simple way to convert npm dependencies into signed debs?
      - om42 10y ago
        Seems to be a npm module called npm2debian for converting npm modules to debs. Never used it myself though. Source: https://www.npmjs.com/package/npm2debian https://www.npmjs.com/package/npm2debian
        derefr 10y ago
        Individual NPM modules seem way too granular for individual distro packaging. apt(1) et al are just not built to handle sources with 10mm packages, or systems that want 100k packages installed. Also, Node's require() works in such a way that you can require(foo-1.0) and require(bar-1.0), and then bar can require(foo-1.1) and that works, and you end up with your module and the bar module each having their own version of the foo module loaded into the Node runtime. Distros really aren't set up to handle that: a distro expects a package should be able to be upgraded independently by the sysadmin to whatever the newest version is. There are one-off hacks done for each of the (very few) packages that are set up to run "beside themselves", like python2 and python3, by making them entirely separate packages; but having "foo-1.0" and "foo-1.1" together is basically impossible. Both of those problems are basically pointing in the same direction: that distro-level packaging and development-dependency-level packaging are semantically different acts and trying to map a package-hierarchy 1:1 from one to the other just doesn't make sense. It makes far more sense to me, personally, to vendor all the development-time deps of an app or framework into that app or framework, and then package that whole release bundle into a distro package and sign that. --- Or, to put that another way: npm(1) is meant to be a build tool, in the same way that make(1) is a build tool. It makes perfect sense for building a Debian package to require calling npm(1), just like it makes sense for it to require calling make(1). But npm(1) shouldn't need to be there on the deployed system, just like make(1) or any other part of the compilation toolchain shouldn't need to be installed just to install and use binary packages.
hitlin37 10y ago
Interesting. But what are the available ubuntu UI components devs have at their hand as of today? Is it based on unity 7 or ubuntu mobile components? How different it is for a dev from developing an electron based app on ubuntu.
sktrdie 10y ago
Wouldn't it make more sense to build React Native on top of already cross platform frameworks such as wxWidgets/Qt? So it's cross-platform right off the bat.
- chrisrhoden 10y ago
  The point is to use UI components that are native to the platform. There are lots of existing cross-platform technologies you can use if you don't care about the UI looking "native". React Native is specifically set up so that everything but the widgets are cross platform.
tronje 10y ago
Offtopic, just a nitpick: Is there a convention in the Ubuntu eco-system to use .ubuntu as an extension? Otherwise it would be nice to change the name of this file to something like README-ubuntu.md so that GitHub displays it as prettily as other markdown files.
- Tergmap 10y ago
  The very unofficial convention is to write README.something. Indeed, it should have been README.Ubuntu.md
  - ChristianBundy 10y ago
    Personally, I like `ubuntu/README.md`, with a mention in the regular `README.md` for the Ubuntu-specific version.
    - 0942v8653 10y ago
      This is great for GitHub, because when you go into the ubuntu/ subdirectory it shows the README in there just like it would for the repository root.
- CannisterFlux 10y ago
  Someone has sent a pull request to do just that, so it'll probably be fixed soon. Off-topic a bit, but I'm surprised it is on github and not launchpad. Having it on launchpad would stop all this pesky collaboration ;-)
  - derefr 10y ago
    I've always wondered about who exactly prefers to use Launchpad. I've had to use it for PPAs, and it seems terrible. I feel like the median FOSS developer would see no benefit in hosting a new project on Launchpad vs. Github or anywhere else.
    - 10y ago
grandalf 10y ago
Many of the comments seem to misunderstand what react-native is, and why Ubuntu might want to do this: React Native is a variation of React, which is a framework for building UI components. It supports stateless components and stateful components. Compared to many paradigms for designing elaborate UI, React often offers lower levels of complexity and easier to understand performance characteristics. An ecosystem around react has built up with various approaches to data storage and data flow. This project has great potential because it means that a developer can learn one set of skills and develop native quality UI for a variety of platforms. Try building something simple (with a few components, and perhaps redux) using react, and you'll get what's interesting about it.
- joelthelion 10y ago
  Could you explain how React Native relates to React?
  - landr0id 10y ago
    I've never used it and don't really know much about it but from a quick reading it seems that React is about building reusable components in HTML, CSS, and JavaScript. React Native provides bindings to native components that you'd use in Objective-C/Swift on iOS or Java on Android.
  - glifchits 10y ago
    React is a conceptual framework which lays out how UIs are specified and how they behave (via the component model). Then when it comes to rendering the UI, the React framework allows several rendering targets (the classic one is React-DOM, which renders a DOM for web pages). React Native is a React renderer for iOS and Android apps.
  - grandalf 10y ago
    React began targeting the browser DOM. Now, React is actually the shared library used by both react-native and react-dom. In React (in general) you build components out of other components. Thus react-dom contains pre-defined components named after HTML dom elements. They behave like a very standards-compliant and consistent dom implementation. So if you want to build a name badge component in React for web, you'd define a "render" method that used the dom-oriented components. With React-Native, there was no reason to implement a component called Div. Instead, the authors created one called View. Instead of copying the browser DOM's behavior they created simple components that are fairly direct abstractions of native UI toolkit components... Things like ListView, Modal, etc. To build something using React Native, you just compose these existing components to make your own components. Tangent: Interestingly, you can use a library called react-native-web to render React Native components in a browser, which makes it very elegant to share code between web and mobile versions of an app. There are a few differences, but it lets your pure js components designed for native work perfectly on the web, so it's actually not a bad approach for building for the web... in some cases React Native's components contain behavior you'd end up implementing for web anyway.
Marazan 10y ago
I love React and want to be excited about React Native but the process of getting your dev environment setup for it is painfully long with way to many steps. I know this seems like a silly thing to bitch about but it kills my idle curiosity when I have to set aside a significant chunk of time just to get to the starting line.
- ben174 10y ago
  create-react-app finally got me beyond that roadblock and I'm deep into creating my first production React UI. Obviously this doesn't solve the problem for React Native, but it's worth mentioning, since it's an official release. https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html https://facebook.github.io/react/blog/2016/07/22/create-apps...
  - Marazan 10y ago
    I'm actually okay with the process for normal React, it's just downloading npm and then typing a long list of packages after npm install. It's React Native then I find the 'from zero' to working dev environment process faintly ludicrous.
    - easong 10y ago
      What are you having problems with? I remember setting up react-native to be a total breeze the first time around, especially compared to html react.
    - vjeux 10y ago
      We completely revamped the React Native getting started experience a month ago. Let me know if it's easier now: http://facebook.github.io/react-native/docs/getting-started.html http://facebook.github.io/react-native/docs/getting-started....
      - Marazan 10y ago
        That is so much better than when I last looked! Great job.
Marazan 10y ago
I'm still loving that Adobe Flex won the war. Remaking the web in its image even as it fades into irrelevance. JSX was instantly understandable and desirable to me due to its close philosophical connection to MXML.
- Marazan 10y ago
  Once again I mention that JavaScript technologies are converging on recreating Flex and I get down votes without discussion. Weird.
crudbug 10y ago
Does this render QT/QML components ?
crudbug 10y ago
Does porting react-core/base from JS runtime to native runtimes like C/Rust have any merits. The UI abstraction with libreact-core + libreact-{platform} is the holygrail for native UI development. Samsung & MS have previously committed on bring RN to Tizen & Windows. I would love to see react-core ported to LuaJIT.

380 points by bpierre 10y ago

deleted 10y ago

[deleted]

pluma 10y ago

So iOS, Android, macOS, UWP and now Ubuntu. Awesome to see vendors like MS and Canonical jump in to bring React Native to their platform. I'm looking forward to seeing universal component sets that make it easy to develop cross-platform desktop apps.

cel1ne 10y ago
I wrote a library, react-native-style-tachyons[0] (based on tachyons.css), which makes it easy to have at least consistent styling for react-native. I think this is a good thing for shareable components, as they would have consistent spacing etc. [0] https://github.com/tachyons-css/react-native-style-tachyons https://github.com/tachyons-css/react-native-style-tachyons
- pluma 10y ago
  I'm not really talking about styling, more about the same kind of abstraction you get for Android vs iOS: common components are exposed as the same "universal" component that will render as the specific one on each OS and OS-specific ones are instead used directly.
mountaineer22 10y ago
This was cross-platform too: https://en.wikipedia.org/wiki/Swing_(Java) https://en.wikipedia.org/wiki/Swing_(Java)
- mtrimpe 10y ago
  Not in the same way though. Swing drew and managed its own widgets using cross-platform Java. React Native uses native widgets and drives them from cross-platform JavaScript.
  - mountaineer22 10y ago
    I find your comment incredibly insightful. Wonderful. Thank you.
  - DoubleMalt 10y ago
    In that React Native is more like SWT (also not entirely joyfult to work with)
- _asummers 10y ago
  It was also highly stateful and was unpleasant to use, neither of which are problems with React. I do mostly backend, but I do code review on all our front end code, and it really seems to be close to the right abstractions for building good UIs.
  - Drdrdrq 10y ago
    IMHO it was actually quite easy to use and had very sensible abstractions, however it failed to look good anywhere. SWT was much better in this regard (but much less fun to use).
    - duaneb 10y ago
      It was straightforward to use. I wouldn't call it easy by any stretch of the imagination--you're still trapped into Java-style callbacks. It also has all the classic problems of event loop oriented frameworks, meaning you're manually managing massive state machines. IIRC there was no attempt to assist organizing the data flow across user actions except via traditional threading coordination mechanisms.
      - beagle3 10y ago
        What other coordination mechanisms do you have in mind? (assuming closureless/continuationless languages like Java or C++ pre 14)
        duaneb 10y ago
        Well, I wouldn't use a closureless/continuationless language for a UI except as a platform for a higher language. This is 2016 and the lack of such primitives are absurd. For the time, Swing was pretty good. Things have moved on and now data flow and state management are primary selling points—see things like CoreData (I'm not really aware of anything like it in other languages) or two-way binding that's prevalent in javascript libraries. This by no means solves state management but I think the primitives are easier to reason with.
    - 10y ago
- pluma 10y ago
  Swing is cross-platform in the sense that "HTML5" (i.e. HTML-plus-JS-plus-CSS-plus-Web APIs in a browser) is cross-platform. The "Native" part about React Native refers to React Native using native components of the operating system (like SWT, I think?).
dfabulich 10y ago
It still doesn't work on older Windows, which seems like a glaring omission to me. Windows 7 remains the most popular version of Windows; UWP runs on Windows 10+ only.
- mwcampbell 10y ago
  All of the official ports of React Native are targeted at mobile or touch-first platforms. (I consider the UWP and Ubuntu ports official in that they come from Microsoft and Canonical, respectively.) Only the unofficial Mac port can truly be said to target a desktop platform. What underlying toolkit would a Windows desktop port of React Native use, anyway? WPF? Old Win32?
  - JaRail 10y ago
    Microsoft has already answered this. Their React Native target for the windows desktop uses UWP. Microsoft is pushing UWP as a capable desktop platform. AFAIK, they aren't ending support for their other platforms just yet. WPF is still being worked on last I heard. If you look at win10+, UWP is a perfectly valid choice for React Native. You could have React Native targets for WPF, win32, etc etc if you wanted.. I'm not sure what use cases could benefit from that though. Keep in mind, if they're missing something in UWP that they need for React Native, they can add it to UWP.

methyl 10y ago

Is this guy rather platform allowing to develop React Native apps on Ubuntu or developing React Native apps FOR Ubuntu Touch? Or maybe both? The README is pretty vague.

jabbernotty 10y ago
Is this sentence machine-generated?
- fit2rule 10y ago
  Isn't everything?
  - m_mueller 10y ago
    Now this (d?)evolved into a philosophical discussion pretty fast...
- methyl 10y ago
  Is this question machine-generated?
owaislone 10y ago
For Ubuntu and Ubuntu Touch

deleted 10y ago

[deleted]

vmateixeira 10y ago

Am I the only one who feels like this is anything but native?

oakesm9 10y ago
I've worked as a "real" native Android and iOS developer for a fair few years and just started working on a project which is built using React Native (Android and iOS). You're right that the development experience is nothing like "real" native. It's using lots of web tech so it's never going to feel like Java or Swift, however, that comes with its own advantages such as code reuse and libraries. I'm actually really impressed with the quality of the apps you can create with it. They feel native and feel really smooth, but you need to be aware of the limitations. The major one is that the apps are essentially single threaded so you need to be aware what work you're doing to avoid UI stutters. That does make it less suited for very data heavy apps, but you can work around it if needed. Overall, as a "real" native developer I'm pleasantly surprised.
- caleblloyd 10y ago
  Can you use React Native for the UI thread and talk to another thread to get data or perform long running calculations?
  - kcorbitt 10y ago
    Yes, I do this in my app. It's well-supported by the platform and quite easy -- there are built-in primitives to call a native function from javascript that returns a promise, which can then be fulfilled/returned asynchronously on the native side once your long-running calculation or transfer is finished.
- vmateixeira 10y ago
  My main concern is about the performance and overhead that whole node ecosystem brings. Despite that, it's nice to read a positive feedback :)
  - 10y ago

amelius 10y ago

So they are basically rewriting the concept of a web-browser (which already is an application delivery platform)? Personally, I think this is crazy, and it saddens me. Why not cooperate with the browser vendors. Given their position, they should be able to pull some strings here and there.

owaislone 10y ago
This has got nothing to do with browsers. This is just a set of APIs that allows developers to use ReactJS (not web, just javascript) to write Ubuntu apps. I didn't read the ReadMe in detail but judging from React Native for Android, iOS, Windows and OS X, this will use QT UI toolkit under the hood, not web tech.
- amelius 10y ago
  This has everything to do with browsers. What React Native does comes very close to what a browser is doing. React is just a very thin layer on top of JS/HTML that makes the browser a little more efficient and pleasant to program for (they are not the only ones by the way, there are many virtual dom implementations). But that layer is getting thicker and thicker. You can say "react native" and "browser" are different things, but they really aren't. Both are application delivery platforms. My problems with React: - They try to push a programming paradigm, without considering that other programmers may have different or even better paradigms. - They put too much functionality into a single framework. - Frameworks are a bad idea anyway. It is much better to divide functionality into self-contained libraries. - They try to redo what the web, a huge standardization effort, is doing. - React does not fully support all HTML/CSS constructs. Now all of this isn't really a problem right now. But if React grows and gains more traction, then it could become a problem (just like Internet Explorer became a problem after a while).
  - Benjamin_Dobell 10y ago
    Have you ever used React Native, or read anything about it for that matter? It's just JavaScript wrappers for native UI toolkits. Much in the same way there are Python wrappers, Ruby wrappers etc. The only difference between React Native and someone else's JS bindings is that React Native makes use of a virtual view hierarchy and several other React-isms - which have absolutely nothing to do with the web except in-so-far as that they were first implemented on the web. Yes, React Native supports an API based on the web's Flexbox API, and view styling similar to CSS - but these are applied to native views. React Native doesn't implement any rendering of its own. However, if anything this is bringing web technologies to native development, they're in no way conflicting with browsers - React Native has nothing to do with a web browser. As I said, React Native provides bindings for native UI development. Now, whether or not you think that's a good idea is up to you. Swift and Cocoa are generally pretty good, so I can see why iOS devs might steer clear. However, the Android SDK is a complete joke, React Native is significantly more efficient to develop with.

PudgePacket 10y ago

Perhaps change to the title to ubuntu mobile? It's a little ambiguous.

Tergmap 10y ago
Should be for Unity 8, therefore for desktop as well.
- PudgePacket 10y ago
  Ah, thanks.

iamleppert 10y ago

Why wouldn't you use something like Electron in this case and leverage a real browser? This strikes me as a really bad idea to make a native-like app in a cross-platform way. Not everything needs to be react these days, guys.

geon 10y ago
The whole point of react native is to not have to deal with a browser. React native is not for cross-platform development.
- Illniyar 10y ago
  It is. Just in a different way. Its cross platform development of logic, with per platform development of ui.
  - madeofpalk 10y ago
    Not "Write once, run everywhere" but "learn once, write everywhere"
owaislone 10y ago
Electron is more like phonegap. React native is nothing like Electron. React Native's aim is not to bring HTML and web technologies to other platforms. The idea is to allow developers to write UIs in native UI toolkits using the react API. The end result is not a webpage wrapped in a browser window like electron or phonegap but actual platform native widgets controlled by JS code instead of objective-c, Java or C++.

Tergmap 10y ago

React Native is just React using native components instead of the typical web components. All this is about React Native also supporting native components in Ubuntu, namely the phone and the new desktop.

JaRail 10y ago
There's more to it than that. React Native has a lot of things that aren't in React/ReactDOM. The most obvious is the bridge between javascript and native code. React Native has supporting tools like the packager which you wouldn't hear too much about in high-level comparisons. But when you compare targets like iOS, Android, and Windows, they are all using different javascript engines. There is a lot of platform-specific work that needs to happen before you can write native components. Conversely, ReactDOM has the code to create/update DOM. ReactDOMServer outputs static HTML. What we used to call React.JS (or simply react) is now the combination of React, ReactDOM, and ReactDOMServer. React (the "react" npm package) doesn't target anything.

m45t3r 10y ago

I find it is strange that a supported development plataform for Ubuntu on Ubuntu uses dependencies outside the main repositories (ppa seems fine, however they even use npm directly to download some dependencies). This is a pretty fragile ecosystem. Yesterday I saw one colleague having build problems from a Maven project because one dependency changed hosts. Seemingly an easy fix, however in the new host they didn't include the version used by this specific program. My colleague ended up blindly using a newer version that seemed to work, however this is pretty fragily.

lima 10y ago
> This is a pretty fragile ecosystem Bad from a security point of view, too. Linux distribution packages are digitally signed and reviewed.
- mikegerwitz 10y ago
  This is one of the most important points. And an issue for it has been open since Jan 2015: https://github.com/node-forward/discussions/issues/29 https://github.com/node-forward/discussions/issues/29 It's, imo, negligent.
  - grandalf 10y ago
    Is there a simple way to convert npm dependencies into signed debs?
    - om42 10y ago
      Seems to be a npm module called npm2debian for converting npm modules to debs. Never used it myself though. Source: https://www.npmjs.com/package/npm2debian https://www.npmjs.com/package/npm2debian
      - derefr 10y ago
        Individual NPM modules seem way too granular for individual distro packaging. apt(1) et al are just not built to handle sources with 10mm packages, or systems that want 100k packages installed. Also, Node's require() works in such a way that you can require(foo-1.0) and require(bar-1.0), and then bar can require(foo-1.1) and that works, and you end up with your module and the bar module each having their own version of the foo module loaded into the Node runtime. Distros really aren't set up to handle that: a distro expects a package should be able to be upgraded independently by the sysadmin to whatever the newest version is. There are one-off hacks done for each of the (very few) packages that are set up to run "beside themselves", like python2 and python3, by making them entirely separate packages; but having "foo-1.0" and "foo-1.1" together is basically impossible. Both of those problems are basically pointing in the same direction: that distro-level packaging and development-dependency-level packaging are semantically different acts and trying to map a package-hierarchy 1:1 from one to the other just doesn't make sense. It makes far more sense to me, personally, to vendor all the development-time deps of an app or framework into that app or framework, and then package that whole release bundle into a distro package and sign that. --- Or, to put that another way: npm(1) is meant to be a build tool, in the same way that make(1) is a build tool. It makes perfect sense for building a Debian package to require calling npm(1), just like it makes sense for it to require calling make(1). But npm(1) shouldn't need to be there on the deployed system, just like make(1) or any other part of the compilation toolchain shouldn't need to be installed just to install and use binary packages.

hitlin37 10y ago

Interesting. But what are the available ubuntu UI components devs have at their hand as of today? Is it based on unity 7 or ubuntu mobile components? How different it is for a dev from developing an electron based app on ubuntu.

sktrdie 10y ago

Wouldn't it make more sense to build React Native on top of already cross platform frameworks such as wxWidgets/Qt? So it's cross-platform right off the bat.

chrisrhoden 10y ago
The point is to use UI components that are native to the platform. There are lots of existing cross-platform technologies you can use if you don't care about the UI looking "native". React Native is specifically set up so that everything but the widgets are cross platform.

tronje 10y ago

Offtopic, just a nitpick: Is there a convention in the Ubuntu eco-system to use .ubuntu as an extension? Otherwise it would be nice to change the name of this file to something like README-ubuntu.md so that GitHub displays it as prettily as other markdown files.

Tergmap 10y ago
The very unofficial convention is to write README.something. Indeed, it should have been README.Ubuntu.md
- ChristianBundy 10y ago
  Personally, I like `ubuntu/README.md`, with a mention in the regular `README.md` for the Ubuntu-specific version.
  - 0942v8653 10y ago
    This is great for GitHub, because when you go into the ubuntu/ subdirectory it shows the README in there just like it would for the repository root.
CannisterFlux 10y ago
Someone has sent a pull request to do just that, so it'll probably be fixed soon. Off-topic a bit, but I'm surprised it is on github and not launchpad. Having it on launchpad would stop all this pesky collaboration ;-)
- derefr 10y ago
  I've always wondered about who exactly prefers to use Launchpad. I've had to use it for PPAs, and it seems terrible. I feel like the median FOSS developer would see no benefit in hosting a new project on Launchpad vs. Github or anywhere else.
  - 10y ago

grandalf 10y ago

Many of the comments seem to misunderstand what react-native is, and why Ubuntu might want to do this: React Native is a variation of React, which is a framework for building UI components. It supports stateless components and stateful components. Compared to many paradigms for designing elaborate UI, React often offers lower levels of complexity and easier to understand performance characteristics. An ecosystem around react has built up with various approaches to data storage and data flow. This project has great potential because it means that a developer can learn one set of skills and develop native quality UI for a variety of platforms. Try building something simple (with a few components, and perhaps redux) using react, and you'll get what's interesting about it.

joelthelion 10y ago
Could you explain how React Native relates to React?
- landr0id 10y ago
  I've never used it and don't really know much about it but from a quick reading it seems that React is about building reusable components in HTML, CSS, and JavaScript. React Native provides bindings to native components that you'd use in Objective-C/Swift on iOS or Java on Android.
- glifchits 10y ago
  React is a conceptual framework which lays out how UIs are specified and how they behave (via the component model). Then when it comes to rendering the UI, the React framework allows several rendering targets (the classic one is React-DOM, which renders a DOM for web pages). React Native is a React renderer for iOS and Android apps.
- grandalf 10y ago
  React began targeting the browser DOM. Now, React is actually the shared library used by both react-native and react-dom. In React (in general) you build components out of other components. Thus react-dom contains pre-defined components named after HTML dom elements. They behave like a very standards-compliant and consistent dom implementation. So if you want to build a name badge component in React for web, you'd define a "render" method that used the dom-oriented components. With React-Native, there was no reason to implement a component called Div. Instead, the authors created one called View. Instead of copying the browser DOM's behavior they created simple components that are fairly direct abstractions of native UI toolkit components... Things like ListView, Modal, etc. To build something using React Native, you just compose these existing components to make your own components. Tangent: Interestingly, you can use a library called react-native-web to render React Native components in a browser, which makes it very elegant to share code between web and mobile versions of an app. There are a few differences, but it lets your pure js components designed for native work perfectly on the web, so it's actually not a bad approach for building for the web... in some cases React Native's components contain behavior you'd end up implementing for web anyway.

Marazan 10y ago

I love React and want to be excited about React Native but the process of getting your dev environment setup for it is painfully long with way to many steps. I know this seems like a silly thing to bitch about but it kills my idle curiosity when I have to set aside a significant chunk of time just to get to the starting line.

ben174 10y ago
create-react-app finally got me beyond that roadblock and I'm deep into creating my first production React UI. Obviously this doesn't solve the problem for React Native, but it's worth mentioning, since it's an official release. https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-configuration.html https://facebook.github.io/react/blog/2016/07/22/create-apps...
- Marazan 10y ago
  I'm actually okay with the process for normal React, it's just downloading npm and then typing a long list of packages after npm install. It's React Native then I find the 'from zero' to working dev environment process faintly ludicrous.
  - easong 10y ago
    What are you having problems with? I remember setting up react-native to be a total breeze the first time around, especially compared to html react.
  - vjeux 10y ago
    We completely revamped the React Native getting started experience a month ago. Let me know if it's easier now: http://facebook.github.io/react-native/docs/getting-started.html http://facebook.github.io/react-native/docs/getting-started....
    - Marazan 10y ago
      That is so much better than when I last looked! Great job.

Marazan 10y ago

I'm still loving that Adobe Flex won the war. Remaking the web in its image even as it fades into irrelevance. JSX was instantly understandable and desirable to me due to its close philosophical connection to MXML.

Marazan 10y ago
Once again I mention that JavaScript technologies are converging on recreating Flex and I get down votes without discussion. Weird.

crudbug 10y ago

Does this render QT/QML components ?

crudbug 10y ago

Does porting react-core/base from JS runtime to native runtimes like C/Rust have any merits. The UI abstraction with libreact-core + libreact-{platform} is the holygrail for native UI development. Samsung & MS have previously committed on bring RN to Tizen & Windows. I would love to see react-core ported to LuaJIT.