Symptomatic, LLC

We were long time users of TravisCI, but switched to CircleCI because of the better user interface and pricing. Version 2.0 has had a couple of trips and hiccups; but overall we've been very happy with the continuous integration it provides. Continuous Integration is a must-have for building software, and CircleCI continues to surprise as they roll out ideas and features. It's leading the industry in terms of innovation and new ideas, and it's exciting to see what new things they keep rolling out.

We use XCode for compiling our Javascript to iOS. We do that using Cordova/PhoneGap, a bridge technology that runs the javascript in a dedicated UIWebView on iOS. Doing so suffers a performance penalty because we're running interpreted code instead of native, so it's often a bit sluggish compared to native apps. We're looking forward to see how much WebAssembly can improve on things; and until then, we focus on having real clean UI code. If all the components are functional, tested, don't have side-effects, and are non-blocking, then even the interpret code can feel like a native app. It takes a lot of discipline to write clean Javascript code that can do that, though. Lastly, we use the Meteor pipeline to launch XCode as a build step.

React was a very contentious decision among the Meteor community. We started off with Blazejs, which itself was based off of Handlebars. We liked the HTML-like syntax of Blaze and how nurses, doctors, and other clinicians could become familiar with it. However, the code wasn't very reusable and it was neither modular nor composeable nor testable, and became a major headache to maintain. React solves the problems of composeability and reusability and testing isolation, at the price of having worked the problem backwards and having wound up with a quirky syntax that runs within Javascript that looks similar to HTML but isn't. Nonetheless, React is quickly become a classic example of functional programming techniques, what with its' pure components. All in all, an enjoyable technology to work with that brings some sanity to front-end user interfaces.

We mostly use rollup to publish package onto NPM. For most all other use cases, we use the Meteor build tool (probably 99% of the time) for publishing packages. If you're using Node on FHIR you probably won't need to know rollup, unless you are somehow working on helping us publish front end user interface components using FHIR. That being said, we have been migrating away from Atmosphere package manager towards NPM. As we continue to migrate away, we may publish other NPM packages using rollup.