Clients often ask us what stack we’d recommend for them to build their application on. With the opinions increasingly growing, it’s a valid question. Just look at this post to get an idea of where frontend Javascript is at the moment and you’ll get an indication of the complexity, confusion, and misinformation around technology choices in 2016.
When your technology choice is more important than ever, but the ecosystem more complex than ever, how do you decide what to use?
Well, with plenty of experience in making both the right, and wrong technology choices, there are three questions we like to ask:
Is the technology fit for purpose?
Making sure your application is future proof is near impossible — the rate technology changes is too fast. Where AngularJS was once the hot ticket, then came ReactJS, and who knows what’s next. The question to ask in this situation is: is the technology fit for purpose?
Imagine you need a live chat module in your application. The key to a chat module is making it fast and responsive. This means that you need to pick frontend and backend technologies that target performance in the area that your feature needs to support.
A general purpose, jack of all trades, server-side application framework such as Symfony can be made performant but in most cases it will prove too slow, and may lack helpful features such as Websockets. You could certainly implement a chat server in Symfony, repeatedly having the browser request any updates, but this will more than likely be slow, heavy and difficult to scale.
A non-blocking technology such as the Express framework on NodeJS does things differently. Rather than load lots of features into memory that aren’t required you can write small, tight services that do one thing, and do it well — thus providing a much more responsive feature.
This is a prime example of choosing a technology that is fit for purpose. As long as you can justify its use, and that’s fit for purpose then you’re on the right track.
Do your research and due diligence, the technology you choose might not be the most exciting to work with but if it’s fit for purpose then it’s by all account the right choice.
What’s my team’s technical capability?
Working in a team gives you so much flexibility when it comes to choosing which technologies to use. But, bear in mind that your application will only ever be as good as your team’s technical capability.
If your lead developer begins building a key module in EmberJS then falls sick for two weeks, what happens to your application’s development — will your junior developer able to take the lead with confidence, are they capable?
If you’re fortunate enough to be working in a team then perhaps assess what your team’s technical strengths are and the potential risk involved in choosing a less familiar technology. Business continuity is an important factor, if progress is halted because of a particular skill-set dependence then that can be detrimental to the development of your application, and more importantly the business.
Whether it’s a hack-day, pair programming or being mentored by a co-worker, there are plenty of ways to learn new technologies — knowledge sharing will help to avoid any bottlenecks in development. This article on encouraging knowledge sharing at your company gives you a handful of basic pointers to get you started.
Will the technology allow me to scale?
What happens when your user base increases from 100 to 100,000 users?
Scalability leans more towards the overall design and architecture of your application rather than the technology used, per se.
However, how efficiently your application can scale will depend on the technology that has been chosen. Knowing how a particular technology will perform if things change can make or break for your application (and potentially your business).
For example, one of our main applications includes a people picker module built in AngularJS. It loads a list of people and allows you to paginate, filter and search for the people you want. For the vast majority of users, this means a very fast and responsive experience, as the results would update instantly as you typed a query.
One problem… it doesn’t scale. Add another 100,000 people to search and the slowdown is very noticeable because of the delay in updates while typing a search term. In the end, we decided to replace the module with something that allowed us to scale and run multiple concurrent queries — we chose Google’s systems development language Go. A necessary, but timely expense to the business.
Research and development in the form of rapid prototyping can prove to be a cost-efficient way of testing the feasibility of a particular technology and its use within your application. Dedicating time for research and development has helped us stay abreast of how the latest technology can assist with maximising each of our application’s potential.
Conclusion
With the myriad of options out there, making the right technology choice is no easy task, and when you’re working in one of the most exciting industry’s in the world, the temptation to experiment can be unforgiving. However, giving yourself and your team the opportunity to sense-check your technology choice really can mean make or break your application’s success. Make sure you choose wisely.
About Browser
We create enterprise web apps for a better, more productive workplace. We’ve helped clients such as Shell, British Airways and UK Gov improve efficiency and streamline their business. Visit us at Browser London.
Originally published at www.browserlondon.com on December 29, 2016.
