I am using ionic for the app. I wanted to test this framework while doing a real app. For the back-end, the API is build with express on AWS and I store my data in mongoDB on Compose.io
So far, I can say that ionic was great to use. I did this project in May of last year even though I didn't push it in the App Store before October. In the meantime I did other App projects with react-native https://github.com/benoitvallon/react-native-nw-react-calcul... and I can say now that I would definitely go with react-native if I had to do it again.
About ionic, I had a few difficulties with performance at the beginning, the app wasn't really smooth but it turned out to be more the Mapbox map that I used as a background than ionic itself. And after rethinking a few parts of the app, the experience for the user was nice.
I also built the API to get the data from that source. So to add more countries I would need to get the data from others environmental agencies and populate my database. It is totally doable, fortunately the data from different agencies are often using the same notation standard. However the APIs are most of the time slightly different and it would take some time.
On the technical point of view, I am using Compose.io as my database is MongoDB and I already need to store 700,000 documents (10 moving days) which is not so much but takes some space anyway and cost me money every month ($36). So if I want to add more data and keep the app free I would need to change my database provider or even my database. I would love to do it, I am thinking of Postgres on AWS but I don't have the time right now.
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.
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...
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.
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.
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.
> 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?
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.
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.
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
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...
