I’ve been interviewing with several large companies for a new role in software development management. I got through to the panel round of interviews with a nationwide retailer to work with their e-commerce presence.

Prior to this, I did a little homework and did what I often to do gauge the maturity level of a company’s website, looking for any obvious issues, the kind of technology used, and evidence of UX/UI consciousness.

The Issues

I found some glaring issues, such as terrible page load times stretching up to 8 seconds, which is a huge problem. In addition, page analytics from GTMetrix gave it a failing mark, as did Google’s Page Speed Insights. A product page required a whopping 180+ HTTP requests to load — a number I’ve never seen before (most sites keep it to under a third of this value).

All are red flags that indicate the need for attention – the page will take time to load, causing a potential speed penalty on Google, not to mention customers will drop off; and the extra load on servers would potentially cause scalability problems.

The interview was with my future (non-technical) boss and with several of their existing web front-end developer team members that would have been my subordinates. After the normal pleasantries, the developers proceeded to fixate on my thoughts about the latest in front-end technology. I’m repeating my thoughts in this blog post.

I stated that frameworks and technology change and by necessity, there is always a need (and desire by developers) to keep trying new frameworks, but there are some issues with the frameworks that exist today that need to be understood.

Framework Code Bloat

These issues have to do a lot with the size of frameworks/libraries. The interviewer was critical about my experience with one of the older UI frameworks that we used in my previous projects. But a framework is just a framework – a simple way to avoid the tedious Javascript programming needed to pop up a dialogue box or a panel or a lightbox – there really isn’t much magic to it. There is nothing that a framework provides that cannot be achieved by a good programmer – just with a lot more time and frustration.

The downside of frameworks is the amount of code required to include a framework, especially if no slimmed-down versions exist. These will typically include a call to the server or CDN to pull the framework javascript includes, plus a call to pull the related CSS and sprites. These calls can introduce extra delays in processing the page, increase browser memory usage. One blog article showed 90% of CSS not being used in the Bootstrap demo pages.

Single Page Applications

I went on further to emphasize that a lot of front-end design is necessitated by having to bow down to Google’s presence, and that several technologies are currently incompatible with good SEO – SPA (single page applications) built on frameworks like Angular are terrible for SEO, and not a good candidate for building out sites that benefit hugely by having their catalogue pages indexable.

I went on to say that a single page product view is enhanced by bringing in other critical information, such as in-stock information through better investment in backend and web service systems and established means such as web service and AJAX calls to bring information to the user; and that the latest UI frameworks, while fun, don’t replace the need to deliver these fundamental features, when the goal is increasing conversions.

 

Don’t Forget the Fundamentals

But do not forget to keep pushing the fundamentals – page speed, functionality, SEO-friendliness, user experience. Not one of these elements would have been improved by plugging in the latest JQuery/Angular/Web Component framework. What is needed in this case was a roll-up-your-sleeves focus on reducing some of the code bloat on these pages. These frameworks may speed up development, but have the downside of slowing down responsiveness for the client.

Using tools such as Google Pagespeed Insights, GTMetrix, the performance profiling developer tools in Chrome, Safari, and Firefox, and making the necessary adjustments to the HTML and server-side are key to helping provide that great first visit impression – before the user has even started interacting with the fancy libraries and frameworks – or, even more fundamentally, showing up in a search in the first place.

 

Regardless of the interview outcome, it was a very, very instructive process. I wish them all the best of luck, of course.