4 ms·

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

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.
Reedx 11y ago
Interesting, and thanks for sharing! What kind of paradigm do you think you'd use for a larger project? Also do you think you'd stick with Flux vs Redux/Alt/etc?
- benoitvallon 11y ago
  About the paradigm I already answered before, I think you need to analyse your UX/features in order to avoid useless code in builds. You are right about flux/redux question, I started this project 3 months ago and let it on the side for a long time, but I would definitely go with Redux if I had to redo it now. Same for a bigger project. I have never used Alt so I can't tell.
smpetrey 11y ago
> I am also convinced that for bigger projects people should be very careful and think twice before going with this paradigm. Wise words.
avinassh 11y ago
> 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. How you would have done for a larger project? And also if we remove mobile from the equation, but a cross platform desktop app?
- benoitvallon 11y ago
  If you mean Windows/Mac App by cross platform desktop app, I don't have any experience in doing that. But windows is pushing for app that uses javascript so it is probably something that is not too complicated to do. My guess would be just to use the correct "packager“ for it. I used NW.js which today seems to be overpassed by Electron. I think you need to get the right one to build a windows app.
davidwparker 11y ago
Very cool! Looking forward to diving into the code! Question- how much extra work would it be to add Android and/or Windows Phone support with react-native?
- benoitvallon 11y ago
  I don't know how react for android works and I don't know if the "trick" I used for the builds would work with react for android. Maybe it would need to rethink the build system. But the good news is that people are interesting in making it, so we will see the result.
perucoder 11y ago
Hasn't this already been done? It's called a web app using html, css and javascript
- albemuth 11y ago
  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 11y ago
    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
- readme 11y ago
  It has, but look... It's a good example code base and has lots of notes on what technologies are used incase you are interested in doing the same thing...
- DiThi 11y ago
  The biggest difference in this case is that the mobile version is native instead of using a WebView. Yes, it uses JS in the background but uses native widgets, which results in a much better user experience.

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.

Reedx 11y ago

Interesting, and thanks for sharing! What kind of paradigm do you think you'd use for a larger project? Also do you think you'd stick with Flux vs Redux/Alt/etc?

benoitvallon 11y ago
About the paradigm I already answered before, I think you need to analyse your UX/features in order to avoid useless code in builds. You are right about flux/redux question, I started this project 3 months ago and let it on the side for a long time, but I would definitely go with Redux if I had to redo it now. Same for a bigger project. I have never used Alt so I can't tell.

smpetrey 11y ago

> I am also convinced that for bigger projects people should be very careful and think twice before going with this paradigm. Wise words.

avinassh 11y ago

> 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. How you would have done for a larger project? And also if we remove mobile from the equation, but a cross platform desktop app?

benoitvallon 11y ago
If you mean Windows/Mac App by cross platform desktop app, I don't have any experience in doing that. But windows is pushing for app that uses javascript so it is probably something that is not too complicated to do. My guess would be just to use the correct "packager“ for it. I used NW.js which today seems to be overpassed by Electron. I think you need to get the right one to build a windows app.

davidwparker 11y ago

Very cool! Looking forward to diving into the code! Question- how much extra work would it be to add Android and/or Windows Phone support with react-native?

benoitvallon 11y ago
I don't know how react for android works and I don't know if the "trick" I used for the builds would work with react for android. Maybe it would need to rethink the build system. But the good news is that people are interesting in making it, so we will see the result.

perucoder 11y ago

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

albemuth 11y ago
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 11y ago
  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
readme 11y ago
It has, but look... It's a good example code base and has lots of notes on what technologies are used incase you are interested in doing the same thing...
DiThi 11y ago
The biggest difference in this case is that the mobile version is native instead of using a WebView. Yes, it uses JS in the background but uses native widgets, which results in a much better user experience.