I wonder if our attempt to have a single unified REST API with different sized representations depending on the use case, and support for custom ones, was misguided. Maybe we’d be better off if we had two different REST APIs, one for browser apps, and another for bandwidth-constrained mobile apps. (Having representations represented by POJOs, rather than the complex set of abstract classes we use that are descriptor-driven, would be much simpler.)
I get the sense that people now prefer React.js and Flux, over AngularJS. There isn’t a significant enough advantage for us to make a strategic shift in OpenMRS, but I do hope that the one-way data binding approach eventually comes to the AngularJS world, because I can see a lot of benefit there.
It would be neat if someone did a POC of writing an OpenMRS module with the latest version of the JS language, and transpiling to something browser-supported as part of the build process.
Refactoring the UI to Angular has just started if I’m not wrong, so if a shift is needed better now than later right? But of course in a couple of years it could exist a new kid on the block better (or more fashionable) than React. It’s a tough call.
While I think the simplicity of React + Flux is awesome, it is clearly not the first to do that. Knockout could do very similar things. ES6 along with Web components is what is most exciting to me. Clearly, a page with more than 50 angular directives is excruciatingly slow. I also feel developer productivity is much better with React than Angular.
I think we should build reusable components in whatever HTML/JS framework hiding the complexity out for other devs. The Polymer polyfill is pretty good and by the time ES6 will be released, we should have definitive take from Mozilla on whether they will continue to depend on a polyfill or build it in the browser.
I urge everyone to look at the Polymer designer - https://polymer-designer.appspot.com/
If our platform allows people to customize their EMR in this way, it will solve a lot of implementation headaches in OpenMRS customization that need module development at the moment.
Angular is good (and a quantum leap over what we were doing before), and
there is a good amount of OpenMRS momentum and investment behind it (though
@lluismf is right that it’s still early days for us)
we shouldn’t jump ship until there is something that is compellingly much
better
flux+react may be (arguably) better, but not so much better to be worth
switching
@sunbiz is right that we should keep a close eye on polymer and
webcomponents, because when these are mature/ready/supported, these are the
most likely next generation path for us.
I think we should wait for the ecosystem around them to play out a bit
first, because we are not in a great position to be early adopters
but if anyone who can do some proofs of concept to show that we could
actually do things better than Angular by starting to use these
technologies today, if love to see it!