10 Principles to Consider When Evolving Your Web Application’s Front End

It’s very easy, espe­cial­ly for an “evolv­ing” web appli­ca­tion, to end up with a user inter­face that is bug­gy and dif­fi­cult to main­tain, par­tic­u­lar­ly if you are incre­men­tal­ly mak­ing changes to an out­dat­ed app, with­out a full redesign. This is a chal­lenge that I’ve faced on many occa­sions, as I have often worked on appli­ca­tions that were built using an out­dat­ed soft­ware par­a­digm or have sub­se­quent­ly failed to keep up with the advances in soft­ware tech­nol­o­gy and method­ol­o­gy. This is not uncom­mon at all, in fact most, if not all, soft­ware engi­neers have had to deal with this on many occa­sions dur­ing their career.

Work­ing through the­se chal­lenges has taught me a great deal about the evo­lu­tion of soft­ware appli­ca­tions. It’s some­thing that I’ve had to learn, while bal­anc­ing the day-to-day demands for the support/upkeep of an exist­ing code­base. This process can teach a devel­op­er a great deal, as they research best prac­tices and gain expe­ri­ence; but most impor­tant­ly, it can teach devel­op­ers what not to do, as you see how the process unfolds over time.

10 Principles of Front-End Web Application Design

The prin­ci­ples out­lined here are those that have worked best for me. Given the sit­u­a­tions and expe­ri­ences I’ve had to deal with. Hope­ful­ly they will be use­ful for your project too. I’d be inter­est­ed in hear­ing your sug­ges­tions and crit­i­cisms, so the­se prin­ci­ples can be improved.

Separate your JavaScript code from your user interface.

Given how flex­i­ble JavaScript and HTML are, you can eas­i­ly pep­per your code with JavaScript func­tions, mak­ing it very easy to imple­ment the solu­tion poor­ly and caus­ing great dif­fi­cul­ty in main­tain­ing and improv­ing the code in the future. Keep the two worlds as sep­a­rate as pos­si­ble and avoid, at all costs, putting JavaScript func­tions through­out your HTML code. It will be dif­fi­cult to read, dif­fi­cult to main­tain and will ulti­mate­ly 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 mod­ule and apply Object Ori­ent­ed design prin­ci­ples, you will gen­er­al­ly write bet­ter code. This also makes it pos­si­ble to clean­ly sep­a­rate the HTML code from the JavaScript code and JavaScript code from oth­er JavaScript code. If you encap­su­late your code in mod­ules and avoid using glob­al vari­ables, you also elim­i­nate the chance that nam­ing con­flicts will arise, improve the read­abil­i­ty of the code and make the code eas­ier to main­tain and improve over time.

Write reusable JavaScript modules for frequently used functionality.

If you have a fea­ture of mod­er­ate to high com­plex­i­ty, which is used fre­quent­ly through­out your front-end code­base, write it as a mod­ule and ensure this mod­ule can eas­i­ly be instan­ti­at­ed in all of the var­i­ous use cas­es. When you do this, you can sim­ply include the module’s JavaScript file, call the con­struc­tor, run any nec­es­sary ini­tial­iza­tions, then your code can be sim­pler and eas­ier to main­tain.

Avoid using tables in the HTML layout.

Tables were first used, because they were a way to cre­ate lay­outs that couldn’t be cre­at­ed with the stan­dard HTML tags in ear­ly browsers. Tables are, how­ev­er, a ter­ri­ble way to orga­nize your lay­outs for a vari­ety of rea­sons. Many bet­ter meth­ods have been imple­ment­ed since the table hey­day in the 1990’s, still many devel­op­ers haven’t got­ten the memo and con­tin­ue to use tables, which severe­ly con­strains the flex­i­bil­i­ty and the sta­bil­i­ty of their lay­outs. If part of your front-end uses tables, take the time to imple­ment a bet­ter lay­out.

Use naming conventions

At the very least, when you’re writ­ing a mod­ule, keep the nam­ing con­sis­tent and mean­ing­ful through­out the mod­ule, Ide­al­ly this should be done through­out the appli­ca­tion as well. Make the names so under­stand­able that some­one who isn’t even famil­iar with the code can see the pat­tern and under­stand the mean­ing, with­out even need­ing to read com­ments or doc­u­men­ta­tion.

Comment the code

It’s very impor­tant to provide expla­na­tion for the pur­pos­es of your JavaScript mod­ules, their mem­ber func­tions, para­me­ters, etc. You may even want to provide usage exam­ples some­where in doc­u­men­ta­tion for your code for reusable mod­ules. Be con­sis­tent in your com­ment­ing too, if you com­ment the head­er of one mod­ule, com­ment them all in the same way, the same goes for func­tions. Spend some time pri­or to imple­ment­ing your sys­tem to think about what would work best for your sit­u­a­tion over the long-run. When you make changes, update your com­ments accord­ing­ly.

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 under­stand­ing and incor­po­rate the lat­est method­olo­gies and soft­ware tech­nolo­gies, you are going to have some mod­ules become out of date. It’s impor­tant to put in the time to keep things up-to-date on a reg­u­lar basis. It will make your appli­ca­tion look/behave more con­sis­tent­ly and will elim­i­nate the kinds of night­mares that can hap­pen if parts of your appli­ca­tion become severe­ly out of date.

Re-evaluate your technologies and methodologies on a regular basis, to find areas to improve

If you reg­u­lar­ly improve, your tech­nique and the tech­nol­o­gy which sup­ports your tech­nique, will con­tin­ue to improve; your sys­tem will stay in good shape and remain adapt­able. On the oth­er hand, if you become locked in your ways and unchang­ing, you will even­tu­al­ly find that what you are doing, while it may still tech­ni­cal­ly work, is obso­lete and can be done bet­ter and more effi­cient­ly in anoth­er way. Then you’ll be forced to take more risk by hav­ing to poten­tial­ly rewrite your appli­ca­tion, if it becomes too far out of date.

Be scientific in your evaluation of potential new technologies and methodologies.

When you’re mak­ing deci­sions about the future of your appli­ca­tion, don’t make them based on whim or hearsay. Do exten­sive research, uti­liz­ing sev­er­al dif­fer­ent sources. Encour­age your team to do research as well and share the results. If you spend a few hours up-front mak­ing the best deci­sion, in a sci­en­tific and rig­or­ous way, you will save your­self a great deal of time down the road. If you ignore this advice, don’t be sur­prised if you have to rewrite your appli­ca­tion again.

Be decisive and follow through.

Once you have applied the prin­ci­ples and made informed deci­sions, fol­low through with it until you have a good rea­son not to. It’s often tempt­ing to want to try new things or change con­ven­tions and method­olo­gies; but if you change your mind too much your project will have no direc­tion, time will be wast­ed and the qual­i­ty of your appli­ca­tion will suf­fer. If you’ve made a good deci­sion with all of the avail­able infor­ma­tion in the first place, you should have no rea­son to change your mind. If how­ev­er, you are chang­ing your mind fre­quent­ly, it like­ly indi­cates that you are mak­ing deci­sions hasti­ly, with­out con­sid­er­ing the avail­able infor­ma­tion. Those who fol­low through write bet­ter prod­ucts which are more pro­fes­sion­al, low­er main­te­nance and more appeal­ing to users.

Leave a Reply

Your email address will not be published. Required fields are marked *