9 ms·

A mobile, desktop and website app with the same code

193 points by benoitvallon 11y ago

mafellows 11y ago
As a native mobile developer... How is react-native (or something similar) not the future?
- dabit3 11y ago
  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 11y ago
    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 11y ago
      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 11y ago
        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.
  - mtw 11y ago
    From what you've seen, what's recommended, flux or redux or relay/graphql? I have trouble keeping up with those
  - rymate1234 11y ago
    Does it still only support OS X for building apps?
  - Fradow 11y ago
    Well, we can't know the future, but I'd like to draw a parallel. A few years ago, Java offered the promise "write once, run anywhere". It worked pretty well until a major OS decided "nah, not gonna happen here". What's different this time? It is popular (Java was and still is), it is backed by a big company (Java too), it only needs Javascript, which all devices have (Java only needs a JVM, which all devices used to have). Well, I sure hope for all the folks involved it really is the future. At least, it may well be for the next few years.
    - e12e 11y ago
      > It worked pretty well until a major OS decided "nah, not gonna happen here". No, it really didn't. For a time after "Java Web Start" was introduced in 2001, java had (has) a pretty decent story for distributing application (big run time dependency, problematic java updater non withstanding). But I think the biggest problem java had/has is the mix of java being a hopelessly verbose, and arguably rather primitive language that's a bad fit for both AWT and (to a lesser degree) Swing. It's almost comical to contrast "hello world" with swing/java and with swing/jython (or jruby) - it's not that the UI toolkit is unusable, but it's not a good fit for the biggest use-case: simple business applications. I should add that I think kotlin looks like a pretty perfect match for "the good parts of java without any added complexity". > What's different this time? Modern JS is arguably a better fit for simple GUI programming than modern java is.
- cageface 11y ago
  Just like on the desktop, true native apps will always have their place on mobile. But for a very large majority of apps React Native will be more than good enough and much faster to work with. Personally I've switched my focus from native iOS to React & React Native.
  - cballard 11y ago
    I don't think I could deal with losing Swift's type system and working in JavaScript, plus the whole Optional vs null issue.
    - cageface 11y ago
      I can't say I don't miss types, but if you use ESLint and FlowType it's not as bad as you might think. Hopefully I'll be able to start using Typescript on React projects soon.
- saosebastiao 11y ago
  It totally sounds like the future, but I can't help but hate the fact that it is tied to javascript. React-native with WASM would be a dream come true :)
  - cies 11y ago
    Many language compile to JS nowadays! (PureScript, ClojureScript and GHCJS are a few I personally would really like to use) I think currently there are more languages compiling to JS then to JVM. :)
    - saosebastiao 11y ago
      I personally use scala.js and clojurescript quite a bit, but in every case of an existing non-JS language compiling to JS, there is a semantic mismatch coming from the runtime mismatch. This results from various things like the lack of static types, threads, 64 bit integers, etc. Furthermore, the performance still leaves a lot to be desired. WASM holds a lot more promise for all of these problems.
    - IshKebab 11y ago
      Yeah but just because you can...
cheez 11y ago
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.
toyg 11y ago
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 11y ago
  The mobile app uses native components.
  - TuringTest 11y ago
    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.
benoitvallon 11y ago
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.
- bryanlarsen 11y ago
  Why do you say one should be careful using this approach in a large project? I'm not sure how much value your paradigm will bring to a project -- 90+% of the non-boilerplate code in most React components is inside the render function, so I'll probably just deal with the very small amount of duplicated code rather than adding the complication of the paradigm you're using. However in a larger project, duplicated code is much more expensive, so I think your paradigm would be useful there...
  - benoitvallon 11y ago
    I think for bigger projects you really have to think about what your UX is going to be. Sometimes you want UX and features so different for devices that looking to share code at all costs can result in a lot of useless code in the builds but if your project is going to use a similar UX I think this paradigm works. About the 90% of code inside the render functions, it made me think about the time where people were complaining about huge Angular controllers. I agree that render function can be large sometimes but I think that if 90% of code component is in the render function, you should probably move some code to the stores.
    - bryanlarsen 11y ago
      The reason that 90% of the component code is in the render function is because everything else has been moved out to actions & reducers. Sorry I didn't make that clear. And I'm firmly in the "lots of tiny little components" camp, so I don't have any large render functions. That's also another reason I'm not going to adopt the pattern the OP suggests -- that pattern uses 3 files per component.
whistlerbrk 11y ago
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 11y ago
  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.
Flux159 11y ago
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 11y ago
  Very few large multi-platform applications use separate code bases. Why should it be different for a javascript/React app?
  - Flux159 11y ago
    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.
    - bryanlarsen 11y ago
woah 11y ago
This is somewhat silly. By this logic, any website could be billed as "A mobile, desktop and website App with the same code".
brokentone 11y ago
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!
SchizoDuckie 11y ago
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 11y ago
  That doesn't sound the same. PhoneGap uses a web view to render your layouts, React Native uses native platform components to render layouts.
ridiculous_fish 11y ago
I don't know much about React. When poking through the code I found this: https://github.com/benoitvallon/react-native-nw-react-calculator/blob/master/src/common/stores/CalculatorStore.js https://github.com/benoitvallon/react-native-nw-react-calcul... Lots of ad-hoc global variables like _lastPressedWasEqual. Is this idiomatic?
- CGamesPlay 11y ago
  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.
  - cballard 11y ago
    > You could think of them as static variables in a singleton class. So... global variables?
  - ridiculous_fish 11y ago
    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 11y ago
      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.
- ravishi 11y ago
prezjordan 11y ago
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-calculator/blob/master/src/common/components/KeyboardRender.ios.js https://github.com/benoitvallon/react-native-nw-react-calcul... KeyboardRender.js: https://github.com/benoitvallon/react-native-nw-react-calculator/blob/master/src/common/components/KeyboardRender.js https://github.com/benoitvallon/react-native-nw-react-calcul... 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 11y ago
  > 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.
flanbiscuit 11y ago
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
elchief 11y ago
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 11y ago
  Probably yes.
  - benoitvallon 11y ago
    Exactly
qrohlf 11y ago
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-native-for-android-how-we-built-the-first-cross-platform-react-native-app/ https://code.facebook.com/posts/1189117404435352/react-nativ...
mrmondo 11y ago
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.
- perucoder 11y ago
  This is a taste of the future. More and more people are creating things using tools and frameworks but not really understanding the underlying concepts. When I pick up a bookshelf at IKEA and put it together, I don't start calling myself a carpenter because of it.
  - nostrademons 11y ago
    Taste of the past too. In my first programming job, there were a few senior programmers who were then in their 50s, meaning they started programming in the 70s (before microcomputers). In those days, the way you became a programmer was to major in electrical engineering. That's why even now, a number of top universities (MIT, Berkeley, Ann Arbor, Rice) have combined departments of "electrical engineering and computer science". How many C++ and Java programmers these days know how to work their way around NAND gates, digital logic, and RCI circuits? How many know how a transistor works? How many know how to build a mux in hardware, or an adder, or what's in a RAM cell? I'm sure there are some, but by and large, I think it's an improvement that we don't think about digital logic and binary representations when we write our program. The cycle of moving up the abstraction hierarchy has been going on since high-level languages were invented in the 50s. Today's tools and frameworks are the low-level building blocks of tomorrow.
- eatonphil 11y ago
  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.
cies 11y ago
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 :)
bikamonki 11y ago
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)

193 points by benoitvallon 11y ago

mafellows 11y ago

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

dabit3 11y ago
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 11y ago
  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 11y ago
    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 11y ago
      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.
- mtw 11y ago
  From what you've seen, what's recommended, flux or redux or relay/graphql? I have trouble keeping up with those
- rymate1234 11y ago
  Does it still only support OS X for building apps?
- Fradow 11y ago
  Well, we can't know the future, but I'd like to draw a parallel. A few years ago, Java offered the promise "write once, run anywhere". It worked pretty well until a major OS decided "nah, not gonna happen here". What's different this time? It is popular (Java was and still is), it is backed by a big company (Java too), it only needs Javascript, which all devices have (Java only needs a JVM, which all devices used to have). Well, I sure hope for all the folks involved it really is the future. At least, it may well be for the next few years.
  - e12e 11y ago
    > It worked pretty well until a major OS decided "nah, not gonna happen here". No, it really didn't. For a time after "Java Web Start" was introduced in 2001, java had (has) a pretty decent story for distributing application (big run time dependency, problematic java updater non withstanding). But I think the biggest problem java had/has is the mix of java being a hopelessly verbose, and arguably rather primitive language that's a bad fit for both AWT and (to a lesser degree) Swing. It's almost comical to contrast "hello world" with swing/java and with swing/jython (or jruby) - it's not that the UI toolkit is unusable, but it's not a good fit for the biggest use-case: simple business applications. I should add that I think kotlin looks like a pretty perfect match for "the good parts of java without any added complexity". > What's different this time? Modern JS is arguably a better fit for simple GUI programming than modern java is.
cageface 11y ago
Just like on the desktop, true native apps will always have their place on mobile. But for a very large majority of apps React Native will be more than good enough and much faster to work with. Personally I've switched my focus from native iOS to React & React Native.
- cballard 11y ago
  I don't think I could deal with losing Swift's type system and working in JavaScript, plus the whole Optional vs null issue.
  - cageface 11y ago
    I can't say I don't miss types, but if you use ESLint and FlowType it's not as bad as you might think. Hopefully I'll be able to start using Typescript on React projects soon.
saosebastiao 11y ago
It totally sounds like the future, but I can't help but hate the fact that it is tied to javascript. React-native with WASM would be a dream come true :)
- cies 11y ago
  Many language compile to JS nowadays! (PureScript, ClojureScript and GHCJS are a few I personally would really like to use) I think currently there are more languages compiling to JS then to JVM. :)
  - saosebastiao 11y ago
    I personally use scala.js and clojurescript quite a bit, but in every case of an existing non-JS language compiling to JS, there is a semantic mismatch coming from the runtime mismatch. This results from various things like the lack of static types, threads, 64 bit integers, etc. Furthermore, the performance still leaves a lot to be desired. WASM holds a lot more promise for all of these problems.
  - IshKebab 11y ago
    Yeah but just because you can...

cheez 11y ago

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.

toyg 11y ago

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 11y ago
The mobile app uses native components.
- TuringTest 11y ago
  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.

benoitvallon 11y ago

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.

bryanlarsen 11y ago
Why do you say one should be careful using this approach in a large project? I'm not sure how much value your paradigm will bring to a project -- 90+% of the non-boilerplate code in most React components is inside the render function, so I'll probably just deal with the very small amount of duplicated code rather than adding the complication of the paradigm you're using. However in a larger project, duplicated code is much more expensive, so I think your paradigm would be useful there...
- benoitvallon 11y ago
  I think for bigger projects you really have to think about what your UX is going to be. Sometimes you want UX and features so different for devices that looking to share code at all costs can result in a lot of useless code in the builds but if your project is going to use a similar UX I think this paradigm works. About the 90% of code inside the render functions, it made me think about the time where people were complaining about huge Angular controllers. I agree that render function can be large sometimes but I think that if 90% of code component is in the render function, you should probably move some code to the stores.
  - bryanlarsen 11y ago
    The reason that 90% of the component code is in the render function is because everything else has been moved out to actions & reducers. Sorry I didn't make that clear. And I'm firmly in the "lots of tiny little components" camp, so I don't have any large render functions. That's also another reason I'm not going to adopt the pattern the OP suggests -- that pattern uses 3 files per component.

whistlerbrk 11y ago

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 11y ago
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.

Flux159 11y ago

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 11y ago
Very few large multi-platform applications use separate code bases. Why should it be different for a javascript/React app?
- Flux159 11y ago
  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.
  - bryanlarsen 11y ago

woah 11y ago

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

brokentone 11y ago

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!

SchizoDuckie 11y ago

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 11y ago
That doesn't sound the same. PhoneGap uses a web view to render your layouts, React Native uses native platform components to render layouts.

ridiculous_fish 11y ago

I don't know much about React. When poking through the code I found this: https://github.com/benoitvallon/react-native-nw-react-calculator/blob/master/src/common/stores/CalculatorStore.js https://github.com/benoitvallon/react-native-nw-react-calcul... Lots of ad-hoc global variables like _lastPressedWasEqual. Is this idiomatic?

CGamesPlay 11y ago
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.
- cballard 11y ago
  > You could think of them as static variables in a singleton class. So... global variables?
- ridiculous_fish 11y ago
  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 11y ago
    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.
ravishi 11y ago

prezjordan 11y ago

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-calculator/blob/master/src/common/components/KeyboardRender.ios.js https://github.com/benoitvallon/react-native-nw-react-calcul... KeyboardRender.js: https://github.com/benoitvallon/react-native-nw-react-calculator/blob/master/src/common/components/KeyboardRender.js https://github.com/benoitvallon/react-native-nw-react-calcul... 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 11y ago
> 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.

flanbiscuit 11y ago

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

elchief 11y ago

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 11y ago
Probably yes.
- benoitvallon 11y ago
  Exactly

qrohlf 11y ago

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-native-for-android-how-we-built-the-first-cross-platform-react-native-app/ https://code.facebook.com/posts/1189117404435352/react-nativ...

mrmondo 11y ago

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.

perucoder 11y ago
This is a taste of the future. More and more people are creating things using tools and frameworks but not really understanding the underlying concepts. When I pick up a bookshelf at IKEA and put it together, I don't start calling myself a carpenter because of it.
- nostrademons 11y ago
  Taste of the past too. In my first programming job, there were a few senior programmers who were then in their 50s, meaning they started programming in the 70s (before microcomputers). In those days, the way you became a programmer was to major in electrical engineering. That's why even now, a number of top universities (MIT, Berkeley, Ann Arbor, Rice) have combined departments of "electrical engineering and computer science". How many C++ and Java programmers these days know how to work their way around NAND gates, digital logic, and RCI circuits? How many know how a transistor works? How many know how to build a mux in hardware, or an adder, or what's in a RAM cell? I'm sure there are some, but by and large, I think it's an improvement that we don't think about digital logic and binary representations when we write our program. The cycle of moving up the abstraction hierarchy has been going on since high-level languages were invented in the 50s. Today's tools and frameworks are the low-level building blocks of tomorrow.
eatonphil 11y ago
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.

cies 11y ago

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 :)

bikamonki 11y ago

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)