App Development

Technology Radar Takeaways – Part 3: Languages and Frameworks

Let’s wrap up our review of the April ‘16 edition of the ThoughtWorks Technology Radar by looking at Languages & Frameworks.

Note: The recommendations listed below (Adopt, Trial, Assess, Hold) are from the Technology Radar.
Languages & Frameworks

React.js (Adopt)

Tucker Legard weighs in again, agreeing with React.js’s placement under Adopt:

" React.js revolutionizes the front end web paradigm with its virtual DOM abstraction. Web app developers no longer have to manipulate the DOM directly in order to render views exactly as desired. React.js allows for views to be completely declarative, and rendering performance goes through the roof. The web apps team finds it a joy to work with React.js whenever we can."

Swift (Adopt)

There isn’t much to say about Swift that hasn’t already been said. Just like ThoughtWorks, it’s now our default language for new iOS apps. Our own Robert Thompson has even been contributing to the project. The iOS team is excited for the release of Swift 3, scheduled to come out later this year.

React Native (Trial)

WillowTree has always held that native apps deliver a superior user experience than apps written with cross-platform frameworks, like Apache Cordova and Ionic. However, two new frameworks on the block, Xamarin and React Native, have proven to be so much better that we’ve been writing apps in both of them. Matt O’Connell, one of our web apps engineers, shares his experience with the latter:

“When React Native was released in May of last year, the team over at Facebook stated that they were not chasing a “write once, run anywhere” solution. Instead, they wanted to create a “consistent developer experience.” Three weeks into our first React Native project, I can safely say that the engineers at Facebook did just that. Our team was able to port a vast majority of our knowledge and tooling from working with React over to Native with ease. Ramp up time was minimal and the development experience was familiar.”

Butterknife (Trial)

Dagger (Trial)

Robolectric (Trial)

OkHttp (Assess)

Virtually all of our new Android apps use some combination of these libraries. Butterknife cuts down on boilerplate code. Dagger gives us dependency injection using generated code, which is much more performant than reflection on resource-constrained Android devices. Robolectric makes it possible to use the JVM to unit test code that depends on Android components. And OkHttp’s simple API and low footprint have made it an easy choice over other HTTP client libraries. These libraries have proven so useful that we would have put them all under Adopt. We also would have included Retrofit and Picasso, two other libraries we commonly see in our Android apps.

Alamofire (Assess)

The iOS team has been trying to rely less on third-party dependencies, and Alamofire doesn’t provide anything beyond the official APIs that make it worth using. Our iOS engineers have used AFNetworking for a lot of projects, but haven’t had a reason to use its successor.

JSPatch (Hold)

ThoughtWorks highly discourages the practice of “monkey-patching” live apps, and we tend to agree. None of our projects have used JSPatch or any other tool like it, and for good reason. It has been found to be a dangerous security vulnerability. Its placement in Hold seems appropriate.

I hope you’ve enjoyed going through the Technology Radar as much as I have! I’m already looking forward to the next one!

What do you think? Do you disagree with us? Did we miss something? Let us know in the comments!

Thanks to Tucker Legard and Matt O’Connell for contributing to this post.

Moving from Monolith to Microservices Architecture

When a client decides to move from a monolith platform to microservice architecture,...

Read the article