
React Native for Ubuntu - bpierre
https://github.com/CanonicalLtd/react-native/blob/ubuntu/README.ubuntu
======
grandalf
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
Could you explain how React Native relates to React?

~~~
grandalf
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.

------
tronje
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.

~~~
CannisterFlux
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
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.

~~~
blacksmith_tb
It seems like if you install a package via a Launchpad PPA, you can be
confident it will receive updates along with the rest of your installed
packages; if it was from github, you'd have to add a cronjob to pull updates
or something else along those lines, which would be more prone to (silently)
fail. Though my general experience of PPAs is that they are fairly failure-
prone themselves...

------
pluma
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.

~~~
mountaineer22
This was cross-platform too:

[https://en.wikipedia.org/wiki/Swing_(Java)](https://en.wikipedia.org/wiki/Swing_\(Java\))

~~~
mtrimpe
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.

~~~
DoubleMalt
In that React Native is more like SWT (also not entirely joyfult to work with)

------
m45t3r
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
> This is a pretty fragile ecosystem

Bad from a security point of view, too.

Linux distribution packages are digitally signed and reviewed.

~~~
mikegerwitz
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
Is there a simple way to convert npm dependencies into signed debs?

~~~
om42
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
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.

~~~
grandalf
> distro-level packaging and development-dependency-level packaging are
> semantically different acts

This is a good point, but it also seems that distros have a fairly clunky
naming convention that makes many useful cases of multiple side-by-side
versions seem more clunky than they actually are.

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

~~~
oakesm9
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.

~~~
vmateixeira
My main concern is about the performance and overhead that whole node
ecosystem brings.

Despite that, it's nice to read a positive feedback :)

~~~
blahi
Isn't javascript really really really fast?

The Julia websites has a benchmark for various languages performing some
tasks. Javascript seemed pretty comparable to Java.

~~~
Illniyar
Every language has it's pros and cons in terms of performance and benchmarks
are notoriously inadequate to compare but my general probing of people in the
industry result in the following regarding language speed:

1\. c/c++ is the fastest.

2\. modern java is either the same as c/c++ or about 2x slower

3\. modern javascript (i.e. v8) is about 4x slower then java.

4\. python/ruby and most other dynamic languages are about 10x slower then
java.

Never seen C# really compared with others because it's rarely ran on the same
systems.

Go, Rust and all the new shiny languages are still far away from when we can
infer about their performance, but they are probably somewhere around the Java
level.

~~~
sanbor
Source? According to this Rust is faster than Java
[http://benchmarksgame.alioth.debian.org/u32/performance.php?...](http://benchmarksgame.alioth.debian.org/u32/performance.php?test=nbody)
Here you can see that it wins in almost every benchmark compared to Java
[http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...](http://benchmarksgame.alioth.debian.org/u64q/compare.php?lang=rust&lang2=java)

~~~
igouy
>> is faster than Java

You seem to have cherry-picked that _single-core-x86_ n-body measurement just
because the _quad-core-x64_ n-body program measurements are _slower than_ the
Java program measurements.

[http://benchmarksgame.alioth.debian.org/u64q/performance.php...](http://benchmarksgame.alioth.debian.org/u64q/performance.php?test=nbody)

------
methyl
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
Is this sentence machine-generated?

~~~
fit2rule
Isn't everything?

~~~
m_mueller
Now this (d?)evolved into a philosophical discussion pretty fast...

------
Tergmap
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
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.

------
amelius
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.

~~~
Illniyar
I'm of the opposite opinion, finally someone is getting a replacement for html
and the web api that will actually fit with the design and implementation of
applications.

I'm tired of websites trying to be apps just so they'll have a better
distribution model or once in a lifetime use site that wants me to install
it's app.

The fact that they are making all this with Open Source is even better.

Besides, the standard protocol bodies we know from the web today (and that
many of us don't like at all) were created after Netscape or IE created the
foundation upon which they work on alone.

~~~
levbrie
I think this misses the point. React Native is not a replacement for the web
in any meaningful sense. I think React Native can be a really useful platform
to develop on, but it was developed precisely because iPhone and Android made
it so difficult to build robust mobile applications with web technologies. The
proliferation of apps that you have to download just to use it "once in a
lifetime", as you say, is a consequence of trying to convert what can be done
just as well on a free and open web into an isolated application. The web has
plenty of problems - every open, standardized system does, and aging ones tend
to have far more problems. But abandoning the web would be a complete
disaster. I'm glad to see better options for building apps than what exists
today. I think being able to use JavaScript to build the client side of native
applications can be a tremendous boost to productivity, and I think native
applications have and will always have their place. I love electron and I
applaud the efforts of the React Native team for making otherwise
unnecessarily isolated proprietary development platforms easier to integrate
with and more accessible. But rooting for the end of the web is like rooting
for the downfall of a free and democratic society - I'm pretty sure it's not
something any of us actually want.

~~~
amelius
> [React] was developed precisely because iPhone and Android made it so
> difficult to build robust mobile applications with web technologies

Exactly. Therefore, in my opinion, Facebook should instead try to get the web
back on track of being the application delivery standard. If this is not
possible (google/apple not cooperating), they should imho give ReactNative an
API that is compatible with the web. Of course, they can build their virtual
dom etcetera on top of that (but it should be optional).

~~~
rubyrain
React Native is here to help us build apps today with performance in mind.
Leveraging web won't have similar performance because it will always have a
layer (browser). And it will take who-knows-how-long to implement whatever API
that's available on native but not in browsers. React Native allows accessing
native API today.

And as far as I know, FB actually tries hard to improve web by participating
TC 39 actively. Web is still big part of them.

------
iamleppert
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
The whole point of react native is to not have to deal with a browser. React
native is not for cross-platform development.

~~~
Illniyar
It is. Just in a different way.

Its cross platform development of logic, with per platform development of ui.

~~~
madeofpalk
Not "Write once, run everywhere" but "learn once, write everywhere"

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

~~~
Tergmap
Should be for Unity 8, therefore for desktop as well.

~~~
PudgePacket
Ah, thanks.

------
hitlin37
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
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
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.

------
Marazan
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
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...](https://facebook.github.io/react/blog/2016/07/22/create-apps-with-no-
configuration.html)

~~~
Marazan
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.

~~~
vjeux
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....](http://facebook.github.io/react-
native/docs/getting-started.html)

~~~
Marazan
That is so much better than when I last looked!

Great job.

------
crudbug
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.

------
crudbug
Does this render QT/QML components ?

------
Marazan
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
Once again I mention that JavaScript technologies are converging on recreating
Flex and I get down votes without discussion.

Weird.

