Forem: Vani Shivanand

Assigning [ ] performs better than Array(n) - Reports attached.

Vani Shivanand — Wed, 15 Jul 2020 16:33:24 +0000

Here is a small snippet that was measured using jsperf sit

That means Array(n) is a lot slower than [].

What might be the reason?

In the background there are different types of arrays though for a developer it looks like there is only one Array type.

For the sake of scope, two types can be discussed here.

Holey element type
Packed element type

If we initialize the array with a size, it create an array with Holey element type. Otherwise Packed element type. There are different cases when the javascript engine converts packed element array type into holey.

One of it is a delete operation. Another case is,

const arr = [];
arr[4] = 10;

In the above snippet, though in the first line it creates a packed array. Since there are no elements on index 0,1,2 & 3, the javascript engine converts it into holey array.

That was background. What might be the reason for performance difference?

For a packed array, all that the javascript engine needs to do to find an element is,

To check if the index is in the range (zero to arr.length)
return value if hasOwnProperty of that index is true (as array is stored in exact object format with index as key)

What if it is a holey array?

To check if the index is in the range
hasOwnProperty of that index
hasOwnProperty of Array.prototype
hasOwnProperty of Object.prototype
and the same with any/all extended entities

Because in a holey array, the javascript engine can't decide just based on the range (zero to arr.length)

That's the reason, any operation on holey array takes several more steps than packed array causing performance difference.

Reference : https://www.youtube.com/watch?time_continue=445&v=m9cTaYI95Zc&feature=emb_title

Thanks for reading!

Why did I rewrite Momentjs format method using RegExp?

Vani Shivanand — Sat, 11 Jul 2020 12:24:51 +0000

The popular library momentjs is widely used to any date related calculations. For 10 lines of utility code, we end up using 18kb or 72.5kb gz format minified momentjs file. It's not just download time, it also about the memory that it consumes to operate.

Here is an effort to replace that momentjs format code with the RegExp functions with a very few lines.

If you wish to learn about regEx, visit https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Regular_Expressions

Format date in RegExp

var months = ['jan','feb','mar','apr','may','jun','jul','aug','sep','oct','nov','dec'];

//listing all the possible keys to regular exp
Date.regExMap = {
  MMM: new RegExp("\\" + months.join("|"), "gi"),
  dddd: /\b\w+/,
  dd: /\d{2}/,
  YYYY: /\d{4}/,
  hh: /\d{2}(?=:\d{2}:\d{2})/,
  mm: /\d{2}(?=:\d{2}\s)/,
  ss: /\d{2}(?=.[A-Z]{3})/
};

//creating regular exp to query the string
Date.regExKeys = new RegExp("\\"+Object.keys(Date.regExMap).join("|"),"gi");

//adding it to Date default object & having an optional date param
Date.prototype.tinyDateFormat = function(str,date) {
  //validations
  if(str === null || str === undefined || str.length <= 0) throw "invalid string";
  if(date === undefined || date === null) date = this;
  if(!(date instanceof Date)) throw "invalid date";

  let newStr = str;
  //extracting the matchable words & looping through
  str.match(Date.regExKeys).forEach((regEx) => {
    if (Date.regExMap[regEx]) {
      newStr = newStr.replace(regEx,date.toString().match(Date.regExMap[regEx]));
      //arr.push(this.toString().match(Date.regExMap[regEx]));
     }
  });
  return newStr;
};

Usage

// var date1 = new Date().tinyDateFormat("MMM dd YYYY, hh:mm:ss");
var date = new Date().tinyDateFormat("I am coding on MMM dd YYYY at hh hours & mm minutes");
document.body.innerHTML = date;

Why did I write this?

The companies do interview the people for library/framework knowledge. But if the preference of interview changes to basics or core concepts, everyone would start to get more stability and strength in basics or core. This does helps in the application quality.

For this momentjs format method, it takes the same amount of time to learn the syntax by library as it takes to write the utility using RegExp and get the job done.

The above example may not be covering all the use-cases of momentjs format function. It's not to copy & use it as a small library. But to learn it and to write it again.

In other than date format cases also, try to take time and write your utility functions on your own. Anyway we do spend time on algorithms. The same time can be spent in writing such a utility functions.

It is not considered as re-inventing the wheel but it can be marked as "efficient in writing the code using core concepts for the sake of efficient app".

Heard of tip of ice-berg problem? For a few lines from library, we end up using the entire bundle.

To be efficient may be more beneficial than being knowledgeable. Thanks for reading!

Why don't end products match exact UX design?

Vani Shivanand — Thu, 02 Jul 2020 13:33:11 +0000

After being in UI development for a couple of years, recently I got to explore a designing tool. There by I got to know the reason end products don't match the exact UX.

There is a process that UX designers follow. Starting with developing a component mock-up collections, defining definite set of colors/gradients, constraint alignments, resolutions and more. The UI developers also have to follow the same procedure from developing UI component library(or customizing the existing library according to design), create color constants and respectively.

Second, we should be able to read a design which means some of the css properties are not mapped with the same name in the design. For example, in figma - border is named as stroke with the properties "inside & outside" which we need to map as padding & margin. Though figma gives a css translations to these, some times they need to be re-verified and also we might not use the exact styles. For example, left, top properties are rarely used in development when we are using column layout.

Third, careful observations. Designers take a good amount of time in details. For example, just to see if the shadow settings are looking good. If we just copy the shadow color and ignore the opacity of the shadow, then it may give a totally different look.

Four, analysis of deviation from the CSS library. Design tools are very handy as we all know. Some text might have totally different style applied(may be font), Or may be a random color button has pitched in between. In any such cases, we should discuss again with the designers. May be, it was placed by mistake or may be it was not thought in terms of development constraints. When we discuss with the designers, they have better suggestions or they may even alter the design. So, it is good to not ignore the deviations and to settle with a random alternative. It will be visible in the end product.

Fifth, to focus on view part separately from logic The moment design is provided & there is a demand for estimation, we totally get into implementation details. Divide the estimations into view part(html/css/android look & feel) and logic part. If possible, develop it as two different phases. That convinces the entire team about the progress, also providing a good quality.

This is all I got to share for today. Thanks for reading

Webpack style-loader, what does it cost?

Vani Shivanand — Wed, 01 Jul 2020 18:06:23 +0000

If we are not carefully writing our webpack config file, then may be the css styles are getting loaded via css-loader and style-loader through any default framework configurations.

To revisit, css-loader converts the css file into javascript string. And style-loader injects that string to html dom. The former operation causes no issue as it happens during say, compilation time. But the latter happens during run time which is, every time user loads the page.

This is the link of a very minimal webpack configuration code. Here, bootstrap is considered as it is a pretty large library and for the sake of measuring the numbers. All that displays is a DOM alert message with bootstrap class. When we observe the performance, it causes one layout operation per css file which is shown as below.

Many times, we have one css file per module. That means, if we have 20 modules, we will have 20 additional layout operations.

So, we must carefully bundle the css using any external webpack loader and load it separately.

Thanks for reading

Frontend developer? Pull nodejs code into your plate!

Vani Shivanand — Sun, 21 Jun 2020 16:44:14 +0000

It is very common that nowadays a huge lot of products have a middleware written in node. Writing this node code second time in my career, I would like to say, "why it should belong to a front end developer!"

A simple reason...

In every interview (if none is scheduled, it may even after 5 years), a backend engineer who has written node is going to ask questions on javascript.

So what?, one may say.

We might have coded in UI for say 5 years, 10 year or even 15-20 years. In UI, we follow almost an exact same pattern of javascript code that interacts with 2 more languages html & css. Yes, we covered object oriented concepts, es6 and more.

But what did we not cover?

Front end developers, mostly have not handled the asynchronous behavior(apart from browser engine puts a wait OR for a server call).

Also, we never thought of "how javascript can handle multiple requests at a time without being a multithread". We never had to know about event loop until recent years.

What would a backend developer who has coded node think?

This guy/girl has done javascript for years but yet doesn't know certain concepts which I(backend developer) could learn in a span of say 2-6 months. Something must be missing.

Well, not just that..

Learning node or coding in node, gives us a lot better understanding of javascript through which we can think in terms of patterns better. We can choose a front end framework wisely. Or even code without a framework but by choosing open source tools for template-ing, fast-dom, MVC skeleton and more..

It is also profitable to the company as they are enhancing the knowledge of the right person/team through which their UI also improves.

That was a short write. Thanks for reading! Happy coding :)

PNG Sprites perform a lot better than SVG (Reports Attached)

Vani Shivanand — Sun, 29 Mar 2020 09:45:52 +0000

Back then we have seen the designers giving us image sprites and then the background positions being changed accordingly for each icon and on-hover. There needs no mention that SVGs have captured all the attention as soon they pitched in.

Let's peek into the performance of these. A couple of svg icons were taken and then converted into svg sprite and png sprite.

On svg page, change fill:color for hover color and in png page, change background-position-y.

Two actions were performed while performance was recorded.

Page Reload
Hover out and in for the second icon(bulb) - 4 times

Summary of SVG Performance

Summary of PNG Performance

What's happening?

Apart from scripting time, PNG performance beats loading and rendering(layout).

Why is this?

PNG sprite helped to not load multiple images per icon. Thus there is a better loading time.

An svg is multiple pieces of dom elements where as an image is one dom element. Rendering time will be a lot better due to this single element.

Painting time remains almost the same as the user would see exact same result on hover.

Can a PNG sprite serve equivalent to SVG?

Yes, with a bit more work(at least in case of icons). But the same on-hover effects, responsiveness can be achieved through PNG sprite as well.

One Thing To NOT Miss

Many use content:'\000' for icons. May not be a good way. The reason being, the entire font with many other characters is being downloaded along to achieve this. Always download a minimal font file. In the most optimized sites, one can observe that font files are the largest bundles. The font files should come under 2-3kb.

Find the github link for the exact files that were used to create the performance reports.

svaani / sprite_performance

Entire Screenshot of SVG Sprite performance

Entire Screenshot of PNG Sprite performance

Thanks for reading

Should you ignore scripting time of virtual-dom?

Vani Shivanand — Sat, 21 Mar 2020 19:03:43 +0000

In one of my post's comment section I made a statement saying,

Scripting time will be more because it was considered by any virtual-dom framework that to re-draw the tree should be optimized more than the amount of javascript that is being run.

A straight forward opinion might be to optimize scripting time is as important as it is to optimize Layout or DOM rendering. But we might want to remember web-workers here.

Workers provide multi-threading or a parallel process along with the main thread but they don't have access to DOM and other entities. As we speak about virtual-dom getting overloaded with higher scripting time, the entire operations can be moved there.

That's the reason, why the upcoming new opinion virtual-dom is not needed might not survive longer. Frameworks/libraries with virtual dom should adapt to workers.

Another issue with workers might be Structured Cloning or deep-copying which needs to be worked upon. Because to communicate between them, a huge object needs to be passed. This can be fixed by taking an input from the developer on which part of the tree might be under the scope of change. Thus reducing the tree size that is being communicated between Worker and main thread.

Thanks for reading!

Negotiating For UI Optimization

Vani Shivanand — Fri, 14 Feb 2020 11:46:21 +0000

Speaking about small teams/companies, we hit this stage where we might be discussing with a product manager or a back-end experienced team lead about targets on front end performance optimization. And it is not a week/month's task to improve UI performance. It is a consistent effort and it also needs a parallel work of re-structuring the existing code. It's not that straight forward to negotiate on this with the team.

These are the ways to communicate in a quite successful way.

Explain that JavaScript engine runs only single thread -- Most of the back-end team leads or managers don't think about it as they usually run multiple threads whenever needed in back-end servers. And in JavaScript the usage of Web-workers is not that common.
DOM engine and JavaScript engine don't run in parallel -- unless specified. Though many frameworks might be handling this internally, there is a need to revisit and see wherever we can induce async tasks between these engines.
It's end-user device and performance -- unlike back-end code where the number of servers can be increased for a drop in performance, UI code has this limitation to run in each and every device with the minimal resources available. So there is a huge more work in here.

Saying these, it doesn't mean there is small performance work that needs to be done in back-end. There should be a lot. But the front end performance optimization is a lot different than that of back-end. And to communicate the same holds a higher importance.

Once the team understands this, we can get resources to work on it and there on it helps in breaking down into tasks, learning about the performance, creating reports, A-B testing and a lot more similar plans. Otherwise, the team as a whole will always have a complain on the performance glitch. The performance neither gets addressed nor be ignored. This communication is a step to get rid of that situation.

Thanks for your time in reading this. Humbled! Please say a word in comments if anything needs to be considered or corrected.

If one knows, "how to use a framework" - it doesn't mean one knows the framework

Vani Shivanand — Mon, 03 Feb 2020 15:24:47 +0000

In simple words this post is about, From the excitement of learning a syntax to diving deeper into the internals of frameworks and to make the right decision for each application.

Yes, there are jobs out there that pay if one knows how to use a framework. They are good to start with. But in parallel, if the effort is not put in learning the basics of the language, the engine that runs and the interactivity - it may get hard to build a career by switching to learn the usage of frameworks.

Let's take an instance of jquery vs core-javascript concepts. In my personal observation, jquery experts had more knowledge about jquery than a few javascript developers about javascript. And of course, javascript developers had to leave out a few job options. But in the long run, it is worth it as they get to learn any new framework with much ease and also they feel a lighter loss than a framework expert.

If we take two-way binding or virtual-dom, we should put the effort into learning why they are needed and when. If we get to read, "use redux only when needed", it's good to take the next step in knowing why is it said so.

If we don't do this, frameworks over frameworks will keep the developers rolling from one knowledge base to another.

When enough developers do this, the companies can form a team of core-language developers and not use any frameworks in a lot many scenarios. Many companies take a decision to use a framework because it gives them stability due to the availability of framework-developers.

In the long run, if we create framework developers, it would be an inefficient usage of developer base' learning-time as someone who might have put 4-5 years in a framework might see another framework gaining more attention.

This is not against any frameworks, they are needed because we lack in teams that can build the same with the base knowledge of a language alone. In the past, companies have seen instability with the same. Also, they are very much needed in a few scenarios where the requirements match the need.

It was to remind us(especially myself) to learn any core language in depth.

I am a frontend developer. This may not apply for a few backend scenarios which I might not be aware of. Thanks for reading!

:target Pseudo Selector And Performance

Vani Shivanand — Thu, 30 Jan 2020 12:54:51 +0000

To add an explanation in short on :target, it applies the style to the element that has an id which is same as location.hash

As this post intends to discuss the usage, pros & cons of :target selector, an example to explain the same in-depth is not considered.

Say, there is a need for a slider or a tab, we usually apply the styles to all the slides or tabs. The slides or tabs that are not displayed, need not use the Layout resources of the browser. There is absolutely no necessity to apply the style to the content that is not displayed to the user.

If the particular slide/tab CONTENTS(not the tab title) can be given an id and set the hash, all the styles that need to be applied can be written inside :target.

Yes, the additional styles have to be written to accommodate the changes that happen due to scroll to the element that happens after setting the hash.

Pros - A relevant usage

It's good to consider this when the slide/tab is occupying most space on the screen because there's no scroll that will happen.

Here is a github link for a similar scenario that was tried. The only style that is applied to target in the example is to change the color. But as the relevant styles that are needed to an app are applied, this will be more beneficial.

Cons - Not a successful usage

The same was tried to apply the style only to the content that is displayed on a scrollable content. Here is github link

This is a failed scenario as there will be a flickering that happens on the screen as the user scrolls. Speaking about performance, to set a new id on scroll should not be expensive as it is done not on every scroll event but in batches. Also, for the browser engine to erase the styles that were applied to the sections which the user has already passed, it shouldn't cause a lot of Layout cost.

<div class="block-custom">hello</div>
<div class="block-custom">hello2</div>
<div class="block-custom">hello3</div>

var num = 0;
window.location.hash = "#focused_0";
window.onscroll = function(x,y){
//- only chrome for now
  var range = document.caretRangeFromPoint(0,10); // screen coordinates of upper-left corner of a scolled area (in this case screen itself) 
  var element = range.startContainer.parentElement; // this an upper onscreen element
  console.log(range);
  num++;
  if(Number(window.location.hash.split("_")[1])+10 <num){
    element.setAttribute("id", "focused_"+num);
    //pushState can also be used
    window.location.hash = "#focused_"+num;
  }

}

.block-custom:target {
   background-color:red;
}

If the flickering can be avoided, this can be a good benefit to the long scrolling content such as Facebook feed or similar.

Thanks for reading. Please help me with an update, if any alternatives are known without a flicker to apply style only to the content that is displayed on the screen(scrollable).

Svelte VS ReactJS Performance Report

Vani Shivanand — Sat, 11 Jan 2020 18:24:42 +0000

A few days before a post was made on Svelt Needs A Virtual DOM. Maybe there was a kind of lack of clarity in the same post from my side. To clarify it furthermore, the reports are attached here.

Similar code that was run on both the frameworks was this,
*Not to mind for not using ES6 loops. This is due to switching from jsperf site

  updateString = () => {
    let outerIncrement = 0;
    let increment = 0;
    do {
      do {
        this.longStringPre += "String number:" + increment++;
      } while (increment < 1000);
      outerIncrement++;
   } while (outerIncrement < 1000);
  }

  componentDidMount = function () {
    this.updateString();
    setTimeout(this.setState.bind(this, {
      longString1: this.longStringPre,
    }), 1000);
    setTimeout(this.setState.bind(this, { longString2: this.longStringPre }), 3000);
    setTimeout(this.setState.bind(this, { longString3: this.longStringPre, 2000);
    setTimeout(this.setState.bind(this, { longString4: this.longStringPre }), 1500);
  }

And the HTML as something like this,

<div className="App2">
        <div>hello</div>
        <div><div>{this.state.longString1}</div></div>
        <div><div><div>{this.state.longString2}</div>{this.state.longString3}</div></div>
        <div><span>{this.state.longString4}</span><span>{this.state.longString2.split(":").join("--")}</span></div>
        <div><div><div></div>{this.state.longString2.split(":").join("-")}</div></div>
        <div><div>{this.state.longString2.split(":").join("||")}<div></div>{this.state.longString1}</div></div>
        <p><span>{this.state.longString1.split(":").join("=")}</span></p>
</div>

That was reactjs code and the exact same code with the same timeouts & Html structure was followed with the svelte code.

Why is the test code so complicated?

Because an effort is made to replicate a scenario where multiple ajax calls responding at almost the same time. Most of our applications have a number of ajax calls which will end at the same time especially in a dashboard that contains multiple charts or when there are huge live-updates that happen.

To understand the test code

Four strings longString1, longString2,longString3 & longString4 get updated at different time intervals.
In the Html, for example, longString2 is being updated for every different position on the dom. This is to not allow both the frameworks to consider duplication. Because we usually don't have duplicated data when different ajax calls respond.
Nested DOM with multiple div is because Reactjs alone compares the tree before updating the DOM. If I remove the nested DOM, Svelt performs better. But in our apps, we do have nested DOM.

Here are the consistent results from multiple attempts.
Svelte screenshot1

React screenshot1

Svelte screenshot2

React screenshot2

Since we are speaking about Virtual DOM, we should consider DOM & Layout timings. We can observe that ReactJS has a good advantage over Svelte in the screenshots.

And one thing to remember, DOM read is not expensive but DOM write is. Because on write the tree has to restructure itself.

The entire story is only based on - anything that happens within a javascript engine has a lot less cost than communication with the DOM which is run by another engine(browser engine).

Please feel free to comment to discuss the same. Thank you for your time.

Svelte Needs A Virtual DOM

Vani Shivanand — Thu, 09 Jan 2020 11:49:27 +0000

For decades, we were working without a Virtual DOM and it was accepted widely in the last decade soon after it was introduced mainly because the benefits were seen. If we think that it is not needed, we need to do a lot more performance tests before we decide. Before the performance tests, here is an attempt to understand it through the basics.

Let's consider the code,let number = 1; number++; number=+2; number=+3;
*This is only for the simplified illustration purpose. Please not to consider it as continued four updates. It intends to say four random DOM updates

And HTML(or html alternative) being
<div>{number}</div>

The javascript engine & the browser engine communicate with each other four times as we are updating the number four times. This is in the case of Angularjs & Svelte.

But in the case of Reactjs or Vuejs or any framework with Virtual DOM, the javascript engine & the browser engine communicates only once(which means only one DOM update) and the Virtual DOM is altered four times.

Coming to the user experience, Rich Harris in his video "Rethinking reactivity" shows a text input and demonstrates user typing experience in an input field. It looks great as there is no lag in Svelte. It's mostly perceived performance is spoken about but not real performance. Not exactly like chrome but it can be somewhere compared to chrome which uses most of the resources to perform better.

In Angularjs & Svelte we need to optimize the above code again as below,

let displayNumber = number

And HTML part as,

<div>{displayNumber}</div>

After this optimization, Angularjs & Svelte also have communication between two engines only once. Because every time the variable that's bound to the output is changed, both the engines need to communicate. When we change the bound variable only once as in displayNumber, we have fixed the problem.

Well, we can't have lint rules to watch this. So, this will be difficult to maintain without Virtual DOM.

Back to the user experience as shown in Rich Harris video, while typing letters, the engines communicate on every keystroke without Virtual DOM. But he is right that the user needs to feel that smooth feel of GUI update. The frustration meter metrics should be considered.

The solution may be, the Virtual DOM frameworks should provide an optional entity to update a particular DOM element if anyone wishes to force-update the DOM directly for the chosen blocks. This way is a lot better than not using Virtual DOM at all.

For the point "DOM is not slow", it is not just DOM but it is also about CSSOM which runs after every DOM update. In the case of Virtual DOM, CSSOM never runs unless the DOM is updated.

In the end, it is nothing against Svelte or Angularjs. They are great frameworks with unique features. For lightweight products, one may use them but there is a need to re-think how the product is going to grow before we decide to choose.

What I don't agree with him is when he said, "The only way to speed up your code is to get rid of it". There are obviously a lot many ways to speed up our code and that's why we are observing and working consistently.

Also, please refer to the post that explains Virtual DOM with a very simple example Virtual DOM - A Simplified Example

And I plan to make the next post with performance screenshots with different code blocks on both the ways.

A comment on the above reading would be a lot helpful for me to improve my writings further. Thanks for the time!