FinDEVr: Q&A with Rangle

Written by Douglas Riches

Doug Riches presenting at FinDEVr London 2017

On June 12, Doug Riches headed to London, England to present How JavaScript is Radically Changing The Way Financial Institutions Create Enhanced Customer Experiences Fostering Creativity to an eager audience at FinDEVr, part of London’s Tech Week. The Q&A portion was full of engaging questions, here’s some of the highlights:

Would you recommend AngularJs or ReactJs for a banking app interface development?

Angular and React can solve the same problem in different ways.

Angular is an opinionated JavaScript framework, which allows for large distributed teams to build and contribute to the code base, minimizing the concern of many coding styles.

ReactJS is a library UI render library, which allows business logic to be separate from UI logic; business logic isn’t necessarily locked into a framework where libraries can be added or removed. Leveraging ReactJS as a library does mean features such as Server Side Rendering can easily be implemented on a NodeJS application.

Both ReactJS and Angular have their mobile app counterparts; Angular has NativeScript, and ReactJS has React Native. React Native has a larger adoption in the development community.

What are Financial Institutions (FIs) biggest pain point in their services right now?

FIs are struggling to keep up with the fast-paced, startup type product development and release cycles. FinTech companies have applied lean and agile development methodologies to their development strategy, allowing them to pivot quickly, developing using the latest technology and frameworks.

What are some of the ways FIs are trying to stay current with startups offering similar services?

FIs are starting to implement lean, agile development, but still struggle to pivot quickly. There has been a movement towards an omnichannel strategy, which has pushed FIs towards JavaScript as the primary development language.

Do you really think that weekly releases are equal to pure continuous delivery process?

Absolutely not. When a story we work on is marked as done, it's shippable software. We group efforts into weekly sprints to make things more predictable and time effective for our clients.

What problems do you run into when implementing your technology? FIs have a lot of legacy systems.

Usually the problems are more people related than technology related. We work to separate the legacy systems that can't change from the front-end code, Middleware layer (Node based other otherwise) that composes data into a modern restful interface.

How do you ensure quality for the different operating systems and browsers?

Unit tests first and foremost. Automated E2E tests to make sure things are working using Selenium / Protractor etc.

I have a legacy system in Java and I am comfortable on that? Why would I need to change that to JS?

The question should be: how comfortable are your clients with the user experience? How coupled are the frontend and backend changes/deployments? What is the release cycle?

Most of the latest JS libraries do not support old browsers (like ie8). Most banks prefer to support old browsers (including ie8). How do you bridge that gap?

The modern frameworks don't support IE8 for good reason. Microsoft does not support it for security updates. Building software and supporting IE8 opens you up to potential security problems. Angular 1 has some support for IE8 in older versions but it's again not recommended mainly for security reasons.

Would you suggest React Native for a large banking mobile application?

Yes. Many FIs are moving to use React Native and NativeScript for their mobile experiences. The great thing about these technologies is you can start implementing them alongside existing native code and integrate them as it makes sense.

How to compare that to Xamarin from Microsoft, especially for Microsoft-oriented companies?

The key difference is that Xamarin compiles C# code into a iOS/Android/Windows compatible binary. The problem with this approach is if the Xamarain framework is not updated to reflect SDK changes from Apple, Google etc it can lead to incompatible binaries that can't be submitted to the app store. React Native and Native Script have a smaller footprint against the SDK as they use JavaScript to control native components over a JavaScript Bridge that is built directly into the SDKs from Apple and Google. This is powerful because it allows you to have the same power as Xamarin with less risk/reliance on updates from the vendor.

Doug’s full presentation can be viewed below or here.