
A mobile, desktop and website app with the same code - benoitvallon
https://github.com/benoitvallon/react-native-nw-react-calculator
======
benoitvallon
I didn't do this project to convince people that the "write once, run
everywhere" is the holy grail but I wanted to explore how it is possible to do
it with the actual tools.

It happened to be really convincing (at least to me) in the case of a small
project like the one I did but I am also convinced that for bigger projects
people should be very careful and think twice before going with this paradigm.

~~~
perucoder
Hasn't this already been done? It's called a web app using html, css and
javascript

~~~
albemuth
Yes it has been done and to a greater extent than your dismissive comment. It
still doesn't detract from the noteworthiness of the OP.

~~~
perucoder
I don't think it was dismissive at all. When a post rises to the front page of
HN people are going to post comments both agreeing or disagreeing. In my case,
I don't see what all the hoopla was about or how this was upvoted to page 1

------
mrmondo
I understand THIS project's intent which is to learn and discover how possible
it is to achieve, However the fact that I'm seeing more and more Javascipt
apps being released for desktops really disappoints and scares me. The
performance, weight and often security concerns that come with JS frameworks
is frightening and while it's fantastic that JS is perhaps lowering the bar as
to who can write an application (perhaps) - it's also making it easy to do the
wrong thing.

~~~
eatonphil
Do you not think a similar thing was said when Cobol came out and young, new
developers started abandoning assembly? I don't think being disappointed or
scared is necessarily the most reasonable reaction to have in light of the
fact that this is just the way technology works. And in the end, it probably
is a good thing.

~~~
johncolanduoni
Except Cobol didn't suddenly gain a lot of popularity after C++ was well
established. There are plenty of languages even more abstract (and I would
argue easy to use) than JavaScript, some of which don't sacrifice nearly as
much performance.

The movement to JavaScript is a product of web developers branching out into
other areas (great!) without taking the time to learn another language (not so
great :/). I don't think performance is an end in and of itself, and I don't
turn my nose up at picking a technology because developers and expensive and
processing power is cheap, but I still think writing everything in JavaScript
is a step backward.

edit: Accidentally wrote developers are cheap and processing power is
expensive :P

------
SchizoDuckie
I'm doing exactly the same with [http://duckie.tv/](http://duckie.tv/)

Runs as: \- Mobile (Phonegap) \- Native (nw.js) \- Website \- Chrome extension

with exactly the same codebase.

~~~
frakkingcylons
That doesn't sound the same. PhoneGap uses a web view to render your layouts,
React Native uses native platform components to render layouts.

------
brokentone
This is a pretty clever implementation. We're demoing out a POC React Native
app this week at Vogue. I initially thought that we could share a lot, but due
to the specific implementation of containers and styles, there is less than I
expected. All helpers, stores, and dataflows should be preserved though.
Breaking this apart at the render methods and having build processes that
chose the right renderer is something I have been theorizing on as the proper
approach. Thanks for sharing this!

------
prezjordan
Way cool! Looks like a common `Keyboard.js` will render either
`KeyboardRender.js` on web/desktop or `KeyboardRender.ios.js` on mobile.

KeyboardRender.ios.js: [https://github.com/benoitvallon/react-native-nw-react-
calcul...](https://github.com/benoitvallon/react-native-nw-react-
calculator/blob/master/src/common/components/KeyboardRender.ios.js)
KeyboardRender.js: [https://github.com/benoitvallon/react-native-nw-react-
calcul...](https://github.com/benoitvallon/react-native-nw-react-
calculator/blob/master/src/common/components/KeyboardRender.js)

I'm wondering, though, if we can take this a step further and write Keyboard
as the _exact_ same code by composing it with more general components like
`<View>` instead of `<div>`. This will require inline styles instead of class
names, though.

I theorize that this will be made a little easier for you with the use of
react-native-web: [https://github.com/necolas/react-native-
web](https://github.com/necolas/react-native-web)

Cool project, though, thanks for sharing. Code is very clean, I'll definitely
be using it as a reference.

~~~
jackweirdy
> This will require inline styles instead of class names, though

That's probably not a bad thing; at the moment there's duplication of inline
styles for the mobile view and styles in a CSS file for the web/desktop.

------
elchief
I'm a little hungover, so a bit stupid today.

So, the mobile app is an actual native app, with no phonegap / webview.

The desktop app is a webkit browser packed as its own application.

And the server app is a single-page app run in the browser and served from a
server.

Correct?

~~~
techaddict009
Probably yes.

~~~
benoitvallon
Exactly

------
qrohlf
Facebook has a pretty solid blog post about how they use a similar
architecture to share code between android & ios apps:

[https://code.facebook.com/posts/1189117404435352/react-
nativ...](https://code.facebook.com/posts/1189117404435352/react-native-for-
android-how-we-built-the-first-cross-platform-react-native-app/)

------
Flux159
I like this as a thought experiment - can I write JS code (specifically using
React) that can be shared across a variety of devices. At the same time, I
would not do this for any sort of non-trivial production application. The main
reason being that you're going to end up writing platform specific logic at
one point or another (basic example: Handling files on the web vs on mobile -
ios / android vs via node webkit). I think that the codebase is already doing
something like this with its .ios.js files.

Eventually you'll end up with some shared code and other platform specific
code and you'll wonder why you don't just split up the codebase into
individual applications (that can easily be worked on by independent teams).
You can still have a shared dependency that handles logic, but you can iterate
on each application independently.

~~~
bryanlarsen
Very few large multi-platform applications use separate code bases. Why should
it be different for a javascript/React app?

~~~
Flux159
I'm assuming that you mean Linux/Windows/MacOS when you say multiplatform. I
agree that for Desktop apps its sometimes okay to use the same codebase
(thinking of Blender, Gimp, other open source apps that work across Desktop
OSes). Other times there are apps that work significantly better because they
utilize an OS's strengths (Pixelmator for MacOS).

The key difference here is that user expectations are completely different
between a mobile app, a desktop app (either native or node webkit), and a web
app - at the moment I would say that its rare to see any app share the same
codebase (not including shared libraries/dependencies) for all of those. As
this post shows, its not impossible, but there are still some tradeoffs.

If I was starting a brand new application that needed to work across all
platforms, I would still consider having independent code bases sharing a
library as a dependency rather than having a single codebase for everything -
especially if I wanted to be sure to have the best possible experience for
each platform.

~~~
ericflo
The whole "write a shared library, and layer your platform-specific UI on top
of it" sounds great in theory and is brought up all the time, but vanishingly
few apps actually do this from what I can tell.

------
flanbiscuit
Any thoughts on adding React Native for Android support? I know it's newer
than the iOS counterpart but would be curious how hard/trivial it would be to
include it

------
mafellows
As a native mobile developer... How is react-native (or something similar) not
the future?

~~~
dabit3
From everything I can tell as well as talking to many people in the industry,
React Native (or something very much like it) is definitely the future.

~~~
wdmeldon
I still live in fear of the day some time down the road when all the people
far smarter than me start writing articles titled "Why
Function/Reactive/Reactifluxidux architecture was a horrible decision". That's
the nature of tech I suppose.

~~~
evook
It is always a horrible decision and often driven by an incompetent management
not to go native. If I'd ask my aces to use react, I am pretty sure at least
one would puke over the desk, another one would jump out of the fifth floor
and the rest would simply decline and start question my competencies. (I know
you'd puke Felix!)

On the other hand we're earning a lot due to all the unnecessary and wasted
resources we have to sell to meet performance expectations of our customers (
and those guys happily buy it ) you could reach with 1/1000 probably 1/100000
of the MIPs by utilizing native C.

Utilizing react is not even programming or engineering. That's assembling.
_rant off_

~~~
findjashua
you're going to get downvoted and you'll think it's because you badmouthed a
popular technology. It's not because of that, it's because you criticized
something on a technical forum without giving any concrete reasons why said
technology is bad.

------
ridiculous_fish
I don't know much about React. When poking through the code I found this:

[https://github.com/benoitvallon/react-native-nw-react-
calcul...](https://github.com/benoitvallon/react-native-nw-react-
calculator/blob/master/src/common/stores/CalculatorStore.js)

Lots of ad-hoc global variables like _lastPressedWasEqual. Is this idiomatic?

~~~
CGamesPlay
They aren't global, they're local to the source file, which represents a
singleton class, so it's not really dangerous. You could think of them as
static variables in a singleton class.

~~~
ridiculous_fish
I'm not sure what justifies using a Singleton here - what if I want more than
one Calculator in my app?

I also noticed that we have a Store (which I interpret to mean model-layer)
handling key events, e.g. "processBackKeyPressed()". Is that common too? From
my outsider's perspective, this looks like a layering violation.

~~~
CGamesPlay
I didn't write this so I am not in a good place to argue in favor or against
any pattern, but the obvious answer here would be the needs of the application
justify a Singleton. The app doesn't support more than one Calculator, adding
additional object management for a feature that isn't necessary is strictly
wasted effort.

I don't think it's a "key event" in the sense you're imagining. The store is a
black box around a calculator device with emulated physical buttons, so "back
key pressed" is one of the store's fundamental actions. I might be wrong about
this.

------
bikamonki
Q: Say you find a bug in a component, do you need to edit both .js and .ios.js
files to fix it? Yes? Not the same code base. No? Quasi the same code base.

IMO same code base is just that, no ambiguities. In this example it would be
the same js, html and css that run inside a different container (browser, nw,
node or webview)

------
toyg
In the past, I would have jumped at these demo apps screaming "but they won't
feel native! They won't integrate well!"... however, these days all major OS
developers are busy knee-capping themselves and making their desktops feel and
act like webpages, so hey, it might actually work.

~~~
bryanlarsen
The mobile app uses native components.

~~~
TuringTest
The GP is talking about look and feel, not native vs multiplatform components.

The point about everybody converging to the flat paradigm that evolved from
the mobile web is a valid one. What is good for small touch devices may not be
for large mouse-driven ones; the removal of affordances and button labels in
particular is a problem in the new style favored by web designers.

However, I would also complaint against developers trying to make web
applications feel like desktop ones, with window management and all, which is
a similarly recurring and worrying trend.

------
whistlerbrk
I'm doing the same within the confines of a Rails app. Works well so far.
It'll be a while to release. I may open source the scaffolding portions of it.

Off topic but does anyone know people hiring freelance React Native? I'd
really like to focus there myself. It's the future.

~~~
bsimpson
If you bill yourself as a mobile dev expert and work for non-technical teams,
you could probably take any mobile dev job.

For instance, if a hospital is looking for someone to build an appointment
management app for their patients, they don't care if you use Obj-C or
JavaScript - they just want an app that works.

------
cies
Very interesting. Really nice stack: allowing extensive re-use, across a huge
range of devices (Android seems to be worked on), fully open source!

For personal taste I'd put a little PureScript or Haskell (with GHCJS) in the
mix :)

------
cheez
History has shown me that "write once, run everywhere" is a holy grail for
internal developers and consultants.

But this web everywhere shit...

That might do it.

------
woah
This is somewhat silly. By this logic, any website could be billed as "A
mobile, desktop and website App with the same code".

