It’s very easy, especially for an “evolving” web application, to end up with a user interface that is buggy and difficult to maintain, particularly if you are incrementally making changes to an outdated app, without a full redesign. This is a challenge that I’ve faced on many occasions, as I have often worked on applications that were built using an outdated software paradigm or have subsequently failed to keep up with the advances in software technology and methodology. This is not uncommon at all, in fact most, if not all, software engineers have had to deal with this on many occasions during their career.
Working through these challenges has taught me a great deal about the evolution of software applications. It’s something that I’ve had to learn, while balancing the day-to-day demands for the support/upkeep of an existing codebase. This process can teach a developer a great deal, as they research best practices and gain experience; but most importantly, it can teach developers what not to do, as you see how the process unfolds over time.
10 Principles of Front-End Web Application Design
The principles outlined here are those that have worked best for me. Given the situations and experiences I’ve had to deal with. Hopefully they will be useful for your project too. I’d be interested in hearing your suggestions and criticisms, so these principles can be improved.
Separate your JavaScript code from your user interface.
Given how flexible JavaScript and HTML are, you can easily pepper your code with JavaScript functions, making it very easy to implement the solution poorly and causing great difficulty in maintaining and improving the code in the future. Keep the two worlds as separate as possible and avoid, at all costs, putting JavaScript functions throughout your HTML code. It will be difficult to read, difficult to maintain and will ultimately waste your time.
Design your JavaScript code in modules and encapsulate your JavaScript modules in objects.
When you think of your JavaScript code as an entire module and apply Object Oriented design principles, you will generally write better code. This also makes it possible to cleanly separate the HTML code from the JavaScript code and JavaScript code from other JavaScript code. If you encapsulate your code in modules and avoid using global variables, you also eliminate the chance that naming conflicts will arise, improve the readability of the code and make the code easier to maintain and improve over time.
Write reusable JavaScript modules for frequently used functionality.
If you have a feature of moderate to high complexity, which is used frequently throughout your front-end codebase, write it as a module and ensure this module can easily be instantiated in all of the various use cases. When you do this, you can simply include the module’s JavaScript file, call the constructor, run any necessary initializations, then your code can be simpler and easier to maintain.
Avoid using tables in the HTML layout.
Tables were first used, because they were a way to create layouts that couldn’t be created with the standard HTML tags in early browsers. Tables are, however, a terrible way to organize your layouts for a variety of reasons. Many better methods have been implemented since the table heyday in the 1990’s, still many developers haven’t gotten the memo and continue to use tables, which severely constrains the flexibility and the stability of their layouts. If part of your front-end uses tables, take the time to implement a better layout.
Use naming conventions
At the very least, when you’re writing a module, keep the naming consistent and meaningful throughout the module, Ideally this should be done throughout the application as well. Make the names so understandable that someone who isn’t even familiar with the code can see the pattern and understand the meaning, without even needing to read comments or documentation.
Comment the code
It’s very important to provide explanation for the purposes of your JavaScript modules, their member functions, parameters, etc. You may even want to provide usage examples somewhere in documentation for your code for reusable modules. Be consistent in your commenting too, if you comment the header of one module, comment them all in the same way, the same goes for functions. Spend some time prior to implementing your system to think about what would work best for your situation over the long-run. When you make changes, update your comments accordingly.
If you learn a better way of doing something, set aside some time to apply it to existing code where feasible.
Inevitably, as you grow in your understanding and incorporate the latest methodologies and software technologies, you are going to have some modules become out of date. It’s important to put in the time to keep things up-to-date on a regular basis. It will make your application look/behave more consistently and will eliminate the kinds of nightmares that can happen if parts of your application become severely out of date.
Re-evaluate your technologies and methodologies on a regular basis, to find areas to improve
If you regularly improve, your technique and the technology which supports your technique, will continue to improve; your system will stay in good shape and remain adaptable. On the other hand, if you become locked in your ways and unchanging, you will eventually find that what you are doing, while it may still technically work, is obsolete and can be done better and more efficiently in another way. Then you’ll be forced to take more risk by having to potentially rewrite your application, if it becomes too far out of date.
Be scientific in your evaluation of potential new technologies and methodologies.
When you’re making decisions about the future of your application, don’t make them based on whim or hearsay. Do extensive research, utilizing several different sources. Encourage your team to do research as well and share the results. If you spend a few hours up-front making the best decision, in a scientific and rigorous way, you will save yourself a great deal of time down the road. If you ignore this advice, don’t be surprised if you have to rewrite your application again.
Be decisive and follow through.
Once you have applied the principles and made informed decisions, follow through with it until you have a good reason not to. It’s often tempting to want to try new things or change conventions and methodologies; but if you change your mind too much your project will have no direction, time will be wasted and the quality of your application will suffer. If you’ve made a good decision with all of the available information in the first place, you should have no reason to change your mind. If however, you are changing your mind frequently, it likely indicates that you are making decisions hastily, without considering the available information. Those who follow through write better products which are more professional, lower maintenance and more appealing to users.