Insights and Inspiration

THOUGHT BOX

BACK
Frontend: Satisfying Code Is Scalable Code

Frontend: Satisfying Code Is Scalable Code

Seán Healy | Engineer at Webio

In 1989, Tim Berners-Lee wrote a proposal for what would become HTML, the language every browser understands.  For decades afterwards, HTML was the glue that held the web together.  The flagship skill for any frontend dev was how much HTML and CSS they could write, and in how little time.  JavaScript came in the mid-nineties as a bootstrapped way to deal with HTML’s shortcomings in the areas of dropdown menus and the like.

Frontend devs, working with Berners-Lee’s creation and Netscape’s JavaScript, soon started to get very sticky fingers.  Dealing with the ‘view’ has always been a pet-peeve for many coders.  PHP, one of the most hated languages out there, has an opaque line between view and model.  Up until recently, frontend JavaScript was written in a similar way.  Web developers facing tight schedules would opt for embedding code right into the page they were working on.  Not only is this approach unscalable, it is unsatisfying.  Future iterations become choresome.

Frontend development speed is a function of how much fun the frontend team is having

Many of the reasons people give for software being unscalable are organisational or related to code comprehension.  The usual argument goes:  the application is delayed because the developers need time to reason about the codebase, or to restructure.  It’s actually more personal than that though; a coder can provide a dozen temporary fixes a day, writing quick and dirty code.  What we’d be doing, however, is condemning real solutions to being implemented only at the end of the rainbow, because the return journey to those real solutions would now be so tedious, many would simply choose to focus on new problems rather than the old ones.  That’s why we separate view and model from the start: not because better structure means faster coding, but because it means funner coding.  Among many things, frontend development speed is a function of how much fun the frontend team is having.

What makes frontend fun?  For the optimists, there’s unit and e2e testing.  For the perfectionists, there’s static typing (TypeScript and Flow).  For the realists, that static typing is actually optional.  The tendency to separate ‘view’ and ‘model’ are rooted in the time-tested ‘divide-and-conquer’ approach, an approach so fun it spawned a whole genre of games: strategy.  TypeScript and selenium (for e2e testing) are now used heavily in the production of Webio’s unified frontend for business.

TypeScript’s object-oriented paradigm has not only slashed the length of our codebase, but it has really helped us achieve a system of modular and distinct behaviours that aligns with how we picture things in an abstract way.  Frontend behaviour relating to bots is related to a Bot object, and so on.  The reason coders employ MVC or MVVM or whatever new approach people concoct, is the same reason we like to have separate sections for forks, knives and spoons in the cutlery drawer, why we eat starter, main and desert separately rather than in one big bowl.  Not only must a developer understand their code, and know their way around, to be as effective as possible they should be having fun writing it.


 Back to Blogs

 

 

Tell us your challenge and let us
help you tackle it

If you want to improve your customer communications, take advantage of our experience and let us show you what we can do.

DEMO REQUEST

Register for a personalized demo where our team will review how Webio's intelligent customer engagement solutions can positively impact inbound and outbound customer engagement in your business.

METRICS WE’VE ACHIEVED

64%
Decrease Unwanted Inbound Calls
42%
Increase in Agent Productivity
57%
Decrease in Operational Costs
48%
Increase in Customer Engagement

YOUR DETAILS