In the early 1990s, I worked on an project that paired third-level students from Northern Ireland - most attending university - with colleges and universities in the United States. Funding came in part from the Training and Employment Agency in Northern Ireland and in part from associations of religiously-affiliated colleges and universities in the US, such as the Association of Presbyterian Colleges and Universities.
The project was an interesting one on a number of levels. Though the Troubles weren't in the news on a nearly daily basis, this was before Stormont, and even before the cease-fire. The participants were both Catholic and Protestant, so there was a lot of discussion and work around matching participants and US schools...and it was very interesting to learn in a newspaper years later the degree to which various politicians (including POTUS) were (supposedly) involved.
One of the challenges we faced early and consistently in the project was communication. As the old saying goes, we were two groups separated by a common language. Each conversation had to be decompiled from its native language (either US English or NI English) and recompiled into the language of the audience. After a few calls, our US-English/NI-English transpiler ran (almost) flawlessly and pretty quickly.
There's the rub though...it ran almost flawlessly and pretty quickly.
In a conversation between people, a small gap of a few seconds is easily overlooked, especially when each side experiences the other as listening and engaged because we measure performance differently than we do in other environments.
How does this apply to you, dear reader?
If you're a UI engineer, building web interfaces, you're dealing with one of those other environments - one where fractions of seconds matter. In that environment, here's the thing you must keep in mind...transpilers always decrease performance...always.
Yes, ES6 is cool. No, ES6 does not have enough browser support to justify writing public-facing apps that use it. Yes, you can add a transpiler (like Babel) to your code to fix it. No, this is not a good thing to do. Why? Transpilers always decrease performance.
As we know, performance is a multifaceted problem. So far I've only talked about transpilers affecting performance in execution, but if that's all we see, we haven't really looked at how they affect performance, because any discussion about performance must also include a discussion about how performance is affected by increasing page weight.
I sense a disturbance in the Force, as if millions of voices suddenly cried out in terror as people say "why are you worried about page weight when we all have LTE on mobile, and broadband to our desktops?". That thinking focuses only US urban centers. Rural areas - those areas that one might argue are prime targets for online services - might not have broadband and while they might have LTE, they might not have unlimited data on their mobile plan.
It doesn't end there, of course. We also must consider the probability of writing "bad code".
Robert's Rule #33 The probability of writing bad code is proportional to the complexity of the tool(s) used to write it.
There are many ways in which you could be killing your performance, and if you're not testing on a throttled connection (to simulate less than 4G/LTE) and on low-power devices, you'll never know. Testing in excellent conditions - simulating only a 4G with a high-powered device - gives a false impression. Much like our experience after several months of conversations between the US and NI groups in which our 'transpilers' were fully functional, your testing is under nearly optimal conditions.
How much does bad performance cost? That's a difficult question to answer. On a large site - one the size of etsy or eBay, for example - performance will typically be measured in fractions of a second and a 500ms delay can cost millions of dollars in lost revenue. On a smaller site it's typically more difficult to quantify because of the relative lack of volume of traffic. All sites - both large and small - can be adversely affected by significant performance problems that result in poor brand image and lost visits and sales.
Performance, baby. Performance matters, and you could be killing yours without even knowing it, but you can change that, even if it means your developers work a little harder.
Happy coding.
No comments:
Post a Comment