Solutions Design > Framework

Q. Looking at today’s trending frameworks – React or Angular – how does one architect solutions?

The market abounds with frameworks. A framework is not a solution; it’s a means to getting to a solution. When we start a project, we design the end-to-end landscape figuring out where the frontend pieces are joining the middle tier and the backend. We retrofit a framework to fit our needs. Today, many people pick a framework and try to fit their solutions in the framework mold, which limits them in the long run. While designing a solution, you can get to a solution by using the raw fundamentals of JavaScript, HTML and CSS. Having an Angular or a React lens helps ease out that process.

Designing a solution is about solving a customer problem. Framework is just a part of this solution. In the case of general solutions, you have to understand what is it you are trying to solve and then go deeper. That involves several other acts before getting to the framework stage – designing the solution, talking to the end users and understanding the real requirements. Only after that we get to the next stage – designing the solution, iterating over it, and building the final iteration that works for us.

Currently, people are not just using Angular for a solution, but also building micro frontends and multiple single page applications. For example, in an e-commerce solution, product landing in details page could be built on Angular, while the entire checkout process is built on React. So the solution is not confined to one particular framework.

 Q. So you can use both together?

Yes, depending on how you architect your solution. The solution is more important, while frameworks can retrofit later. It also makes sense where clients have legacy applications. You could be creating a new version of the same application along with the existing legacy versions. You are transitioning between these two worlds, which could require multiple frameworks.

 Q. How does Sapient build frontend complex applications for domains like financial applications?

 Finance is a complex domain involving sensitive data. It requires extra scrutiny from security experts and the adherence to compliance and regulations set by SEC and other exchanges. While dealing with trading data, it’s critical to use cryptography correctly and ensuring that the right pieces of data have been cryptographically converted and hashed properly. On top of that, we are trying to craft a solution that allows traders or our end users to exchange, do trading, and watch existing financial information. It starts by understanding the space. Often, we go back to the drawing board to understand what are we trying to build. Frameworks come into play at the end.

 Q. Is domain expertise a pre-requisite to a framework?

 Domain experts play a key role throughout the application building process. They help ensure what we are building is accurate and that we are using the right language.

 We consider more factors to understand the solution better. For instance, can we look at data with a completely different view? That’s where data visualization, using frameworks to assess that, and making more meaningful data out of the available data acquire more significance.

 Q. How can a UI developer decide whether they need to learn React or Angular? Do they need to know anything new?

 This question has always involved two sides. Previously, it was probably jQuery versus something else. Then it was Angular versus something else. Now it’s React versus Angular. This will continue into the future.

 If you are a Java Script developer, or a frontend web developer, you use Java Script as the primary language. If you are starting out, you can choose React as your first framework version, which is closer to the bare metal JavaScript. You don’t have to learn a special language like Typescript. Angular requires understanding Typescript as a language and learning the syntax. Once you learn one framework – React or Angular – migrating between the two is easy because the concepts are similar. When you learn one, you don’t have to discard its knowledge to learn the other.

 You are building on not just the framework-specific knowledge but also the computer science in the framework. They carry over as you move to other frameworks. Ultimately, these frameworks are solving the same problem which is abstracting the DOM, and giving a better programing model to build your user interfaces.

 Somebody starting a career still needs to focus on the basics. Starting off with React limits them over a period of time, because we have new frameworks joining the pile every 6 months, and we have a new flavor of something coming out. So if you have your core concepts clear, switching frameworks becomes easier. Most frameworks today have their groundwork done. So the initial filters of how do I choose has gone out. It’s more about adapting to a framework than anything else.

 When you are building applications or solutions for your customers, they already have existing apps in place, which could have been built with their older framework. Hence, knowing the older framework along with the newer one becomes mandatory in some cases. Once you learn the new framework, you can see how the older framework was drastically improved to form something new. That actually works to your advantage.

 Q. Both of you are part of the large team here at Sapient. How do we handle this scale and keep this entire group ramped up on the latest technology? 

We are significantly large in terms of the number of people we have within the domain. We piggybank on that very fact. We typically crowdsource this entire activity. Looking at the number of libraries and frameworks existing in JavaScript today, the count would probably be upwards of thousands. Besides, new frameworks keep getting added frequently. So isolating a few people or delegating the task to a few people to identify and then figure out if it is scalable or not, becomes difficult. So we crowdsource this. We have defined parameters (like performance, scalability, compatibility with other libraries, learning curve, etc.) to evaluate frameworks. They come up with recommendations on something new in the market we should probably invest in. That helps us identify frameworks. We do a lot of internal training and learning. We also have tutorials and hackathons on frameworks, besides internal knowledge-sharing sessions.

 At times, we take a specific use case or a collection of use cases from a finance domain and build the same in 10 to 15 frameworks. We distribute the job of saying what is a developer’s experience of using one framework over the other. Then we collect all the results, see what makes sense, and what we should recommend to our end customers and clients.

 The ask is also certain, and in some cases, it’s also a bit different. People go for a richer UI versus a better performance. These experiments help us decide where a particular framework scores over the other.

 Q. What is your regular workday like? What do you like about Sapient?

 What I like about Sapient is, there are plenty of opportunities to explore almost on a daily basis. Besides, you are working with clients that are top-tier investment banks, hedge funds and private equity firms. They have very unique problems which you may not have seen outside. You are trying to solve their problems and understand this interesting problem space of finance and all other related aspects. So the problems are plenty, and we get to choose varieties of tools. Sometimes, we are constrained based on the environment in which we are working. So applying the technology space we have here, and then constraining it to the client’s domain makes it a very unique set of problems that we are trying to solve here.

 Culturally, we encourage people to go ahead, do research, come back and contribute back to the community. Knowledge-sharing is imbibed in our day-to-day activity. In every project where we design a solution, we try to make it generic enough so we can give it back to the community considering most of our work is open source. For example, I am part of a few open source projects which are under github.com/sapientglobalmarkets. We are exploring these technologies internally as well. Several of our internal projects use them. We share knowledge by attending conferences and events. We have an opensource maintained with the XT brand as well. Besides, we maintain our own XT-branded YouTube, Slideshare, Twitter and Facebook community threads.

 Q. What are some of the important ideas every UI developer should know?

 It’s not mandatory to know everything on day one. You have to gradually acquire this knowledge as you are gaining experience in projects, working and starting off a career. Initially, it’s about learning the basics, which is mostly the language. If you are coming from a web domain, you should know JavaScript very well. Because that language is a medium of expressing your thoughts in code. Knowing it makes that connection faster and easier for everyone else as well. Then there are some computer science aspects. For example, single thread, event loop, compositing, and the performance aspects of making sure that the UI runs smoothly, and there is no lag or jank happening on screen. A lot of this knowledge is already on the internet. I am teaching them at my workshops and training sessions internally. I think you should start with a language and then acquire a few of the computer science skills.

Looking at the realm beyond JavaScript, things like accessibility, how does a particular element render on the browser, re-render, repaint and elements of performance to the nanosecond also make a lot of difference. As you gain more experience, you start focusing on those minor elements that make a significant difference in the long run. As you acquire more, you will enhance your knowledge. Say, you are building a web app and you will automatically understand the networking stack, and start learning about the DevTools inside your browser. All this will come as a natural addition to what you already know. So just get started and I am sure you will figure it out.