When you're running out of Angular, use React instead!

How do you choose the proper technology for creating web apps out of all the plethora of frameworks and libraries? Who will win: the client’s wish, common sense, or our pride?

In this article I will discuss the current technological trends regarding creating web apps. In today’s world of komputerzz we have a huge advantage when developing web apps independently of the backend/database/API modules because it allows us to focus purely on the frontend.

There are a bunch of new goodies on the market with frameworks, libraries, and building blocks that lead programmers to constantly change or hard reset their dev stacks. Lately I’ve been asking myself: “Is it even a good thing?.” It’s a hard question to answer. Top developers shall always be up-to-date and hanker after new technologies, but how do you keep up when there are more people on your team or the client doesn’t want to pay for extra hours spent on testing all that cool new stuff?

If you’re reading this to get an ultimate answer, I am going to disappoint you. Regardless, let’s have a look under the hood of this gastronomical delight.

Many programmers (myself included) strive to learn and use brand new technologies and incorporate them immediately into their development. Is it actually a good idea to use your favorite solutions for apps not suitable for that very technology just to be damn proud of your modern creation? It’s damn hard to decide on a design when simultaneously working for both Bob the Lumberjack and the banking system of a robust, colossal corporation.

A client’s requirement analysis is the cornerstone of every app. If done incorrectly, and in addition if the wrong technology is chosen, the app won’t be able to utilize the full potential of the web, which is enormous nowadays (e.g. different browsers, SEO, and so on).

We develop tons of web apps and unfortunately (or fortunately?), the more clients we have, the more diverse ideas, requirements, and solution possibilities come to the surface. Such circumstances obviously don’t let us concentrate all our power on consuming thousands of tools and developing the one and only unique and unbeatable dev stack. We are genuinely trying to acquire all of the possibilities and divide them among the scope. To be more specific, the same way Squirtle and his water fellas can extinguish any fire at an instant, we can use Middleman, proudly generating a set of static web pages with multi-language support in a matter of minutes. To conclude: collect, save, and don’t forget about how seemingly unusable helper tools are. You never know when they’ll be there to help!

When we dive deeper into our problem, we can break down our pipeline into a few basic locations the app goes through during its life pilgrimage.

Requirement Analysis
We process all of our clients’ wishes in detail, examine wireframes or pre-prepared designs, and thoroughly review all functional and non-functional requirements. Web browsers’ compatibility, SEO, and code obfuscation are especially important.

Choosing the right technology/stack
After the analysis, we should be prepared for any circumstance, ready to reach into the magic pocket of our tested and prepared tools to choose a specific package.

I recommend at this step to consult with other/senior colleagues, as the wrong decision could have fatal consequences.

We possess several larger sets of tools as a basis for different types of applications on which we build specific applications later:

• Static websites,
• Static websites with support of multiple languages or dynamic elements or SEO,
• Dynamic websites with fast communication with API,
• Nonpublic administration (internal) systems.

Implementation
Implementation is the only part where we can afford to use various tools for smaller parts. For instance, suppose we have a React & Redux based core and I need to visualize statistical data in the form of charts on a page. If I want to use a brand new great D3.js library, nothing prevents me from testing it and incorporating it into the chosen core. Later, if it is proven efficient and passes the approval of other colleagues, it can even become part of the dev stack.

Build Tools and Techniques
It doesn’t matter if we have one single-page static website or a robust web app containing communication with API, lots of dynamic elements, graphs, and more. Every possible addition mentioned had to have been built somehow. Typically, the building process assembles (compiles) the app, translates the code from an easily-readable or simply more powerful language to one that the browser can work with (transpilation), optimizes the app’s code size (minification), and finally prevents unwanted code theft (obfuscation). Nowadays we only use webpack to execute these kinds of operations on our code. Read more info about modern web development with Webpack.

Application Testing
Testing is yet another stop on the app’s pilgrimage. This can be a review and approval of the final product by a designer, checking the results of unit tests, or a detailed walk-through of pre-prepared UI test cases.

I also highly recommend continuous evaluation of app users’ behavior. Our tools include analyzing data traffic from Google Analytics and examining the Hotjar thermal map and video behavior.

Application Deployment
The way the application is deployed differs depending on the technology or infrastructure on which the application is running. You can read our next blog post to find out how we deploy static websites at Ackee.

Conclusion

Just a few words for the end. Take care of your client, take into account your experience, use modern technology, but do not overdo it! Otherwise, it can end-up like a lot of projects you probably haven’t heard of!