DEV Community: Alexander Nenashev

Myopia, Exotropia, and Code: Developing a Vision Training Tool for Near-Sighted Professionals

Alexander Nenashev — Tue, 03 Mar 2026 14:41:00 +0000

Target audience: people whose work is mostly near-sight (developers, etc.), with myopia or other eye focusing–related problems, or those willing to keep their vision sharp regardless of near-sight work strain.

Disclaimer: the following text does not make any medical claims; it only assumes the existing possibility of improving vision with eye muscle exercises.

Being myopic (-4.5d), in 2023 I started doing simple eye exercises for 5–10 minutes before falling asleep. Since then, my vision improved to some degree, which I considered worth sharing, so I created a YouTube channel in Russian to share my experience. By that time, due to regular exercises, I had acquired pretty good eye muscle sensitivity, so I could feel which eye muscles contract and relax, given that I had learned eye muscle anatomy in detail. This allowed me to develop my own precise view of what causes myopia. This is a logical continuation of the Bates method. Regardless of the mainstream consensus that it is false, the main idea—that coarse focusing is done by extraocular muscles and final focusing by the eye lens—allowed many people who shared their experiences with me to get rid of myopia and other eye focusing problems. I even read a 2018 article in an ophthalmological journal claiming that the Bates theory is not entirely without merit and that further studies should be conducted on the matter (unfortunately, I cannot find it now).

My experience suggested that myopia happens due to shortening of the eye rectus muscles, especially the medial ones (internal, near the nose), which converge the eyes for near focusing. In July 2025, I began stereo reading—reading text in two columns in parallel view—where the eyes diverge to the point of exotropia, a state in which the eyes diverge beyond parallel alignment. I also found that my myopic audience has very poor ability to diverge and achieve any significant exotropia, whereas people without myopia have strong exotropia ability. Since then, exotropia and stereo reading have become my main tools for training my eyes. Reading alone is used in many vision improvement systems, including Bates’.

So I started in June 2025 being able to read (in non-stereo mode, just regular text) 2 mm lowercase letters from a 33-centimeter distance and ended on December 31 being able to read 7 mm lowercase letters from a 3-meter distance. That was a 2.6× improvement in angular letter size, which also corresponded to significant improvement in my everyday vision. Since then, I have been convinced that eye muscle exercises can be a working tool to mitigate eye focusing problems such as myopia.

In June 2025, I started the Stereo Reader web app as my tool for stereo reading. Vue/TypeScript/PWA were selected for the implementation. What seemed like an easy project soon became a challenge.

After I shared the app with my eye training audience, it became clear that support for many e-book formats was required, including those with large amounts of text. Moreover, when adjusting reading settings such as font size, gap between text columns, and the span of the reading area, the currently visible text on the screen should not be lost.

So I developed a simple semantic system where any text document format is split into paragraphs (called “chunks” for brevity), each with its own font style, with lines calculated dynamically character by character based on the text column width. Since I had spent a lot of time benchmarking JavaScript and avoiding any extra string/array allocation, I achieved fairly fast text layout calculation. However, it still takes 300–400 ms to process a huge novel like Asimov’s Forward the Foundation (about 140,000 words) on mid-range mobile devices (I tested on Snapdragon 720G). The issue is that layout recalculation occurs on any setting change that affects text column width. In any case, the UX is acceptable.

Having the text layout available, I implemented virtual scrolling while maintaining the full text container’s real height. This allows the text to appear as if it were loaded into a single DOM element with scrolling. Further improvements could include rethinking how users interact with partial scrolling and using Web Workers to process text in parallel.

Further work included adding stereo image viewing and introducing games, such as a moving ball to train exotropia in motion, and so on.

In any case, this project seems to have become my ongoing lifelong journey, and I welcome anyone to join.

The website will include documentation on usage, the application can be tried here. You can also join its YouTube channel and Telegram channel for future tutorials and news, and ask any questions in the community or via telegram or email.

Avoid intermediate arrays (parsing strings) to make you Javascript fast

Alexander Nenashev — Sat, 18 May 2024 16:42:30 +0000

In the previous post there was argued why we should avoid intermediate arrays for performance in cases like filter/map chains.

I'd say String#split() is heavily overused when parsing strings. A common scenario is to get the first word in a string. The first thought is to split a string into words and get the first one. Again, an intermediate array is created, worse, only the first element is used, the rest is just waste of space and time. Use String#indexOf() and String#slice() instead:

let $length = 1;
const str = Array.from({length: $length + 1}, () => 'test').join(' ');

// @benchmark Array#split
str.split(' ')[0];

// @benchmark String#indexOf
str.slice(0, str.indexOf(' '));

// @benchmark regex
str.match(/^\S+/)[0];

` Chrome/125
-----------------------------------------------------------------------------------------------
>                       n=1        |       n=10        |       n=100       |       n=1000      
String#indexOf   ■ 1.00x x100m 972 | ■ 1.00x x100m 959 | ■ 1.00x  x10m  94 |  ■ 1.00x x100m 967
regex              2.99x  x10m 291 |   3.06x  x10m 293 |   3.07x  x10m 289 |    2.96x  x10m 286
Array#split        6.49x  x10m 631 |  22.52x   x1m 216 | 165.96x x100k 156 | 1509.82x  x10k 146
----------------------------------------------------------------------------------------------- `
` Firefox/126
------------------------------------------------------------------------------------------------
>                       n=1        |       n=10        |       n=100       |       n=1000       
String#indexOf   ■ 1.00x x100m 105 | ■ 1.00x x100m 120 | ■ 1.00x x100m 108 |   ■ 1.00x x100m 109
regex             35.90x  x10m 377 |  27.83x  x10m 334 |  33.15x  x10m 358 |    32.11x  x10m 350
Array#split       39.05x  x10m 410 | 105.00x   x1m 126 | 944.44x x100k 102 | 10000.00x  x10k 109
------------------------------------------------------------------------------------------------ `

Open in the playground

Pre-allocate arrays to make Javascript fast

Alexander Nenashev — Sat, 18 May 2024 14:05:11 +0000

If you ever implemented a dynamic array in low level languages like C++ you allocate a chunk of memory for several elements at once, when there's no more space for new elements you allocate a new chunk. I guess this is valid and for Javascript arrays. Allocation of a memory on the heap is an expensive operation.

Let's try in Chrome's console (several times, the output is the most frequent):

const start = performance.memory.usedJSHeapSize;
const arr = new Array(1);
setTimeout(() => {
    const diff = performance.memory.usedJSHeapSize - start;
    console.log('heap allocated', diff);
}, 100);

> heap allocated 1688

const start = performance.memory.usedJSHeapSize;
const arr = new Array(1_000_000);
setTimeout(() => {
    const diff = performance.memory.usedJSHeapSize - start;
    console.log('heap allocated', diff);
}, 100);

> heap allocated 4001684

As we see with 1_000_000 array length we have 3.8Mb allocated.

Of course the reason behind the optimization could be different or composite, I'm not a developer of any current JS engines, but it seems that changing the length of an array is generally an expensive operation.

Regardless of the actual JS implementation if we follow the rule:

When the final size of an array is known during creation of the array - allocate it:

const arr = Array(knownSize);

This immediately boosts your Javascript speed:

let $length = 10;
const arr = Array.from({length: $length}, (_, i) => i);

// @benchmark non pre-allocated
{
  const result = [];
  for(let i = 0; i < arr.length; i++){
    result.push(arr[i]);
  }
  result;
}

// @benchmark pre-allocated
{
  const result = Array(arr.length);
  for(let i = 0; i < arr.length; i++){
    result[i] = arr[i];
  }
  result;
}

// @benchmark Array#map
arr.map(i => i);

` Chrome/125
-----------------------------------------------------------------------------------------------
>                         n=10       |      n=100       |      n=1000       |      n=10000     
pre-allocated       ■ 1.00x x10m  85 | ■ 1.00x x10m 669 | ■ 1.00x   x1m 474 | ■ 1.00x x100k 560
Array#map             1.69x x10m 144 |   1.79x  x1m 120 |   2.15x x100k 102 |   3.20x  x10k 179
non pre-allocated     3.22x x10m 274 |   3.57x  x1m 239 |   4.11x x100k 195 |   3.66x  x10k 205
----------------------------------------------------------------------------------------------- `
` Firefox/126
---------------------------------------------------------------------------------------------
>                         n=10       |      n=100      |      n=1000       |     n=10000     
pre-allocated       ■ 1.00x x10m 227 | ■ 1.00x x1m 162 | ■ 1.00x x100k 192 | ■ 1.00x x10k 208
non pre-allocated     1.44x x10m 327 |   1.45x x1m 235 |   1.16x x100k 222 |   1.53x x10k 319
Array#map             1.46x x10m 332 |   1.06x x1m 172 |   1.73x x100k 333 |   2.17x x10k 452
--------------------------------------------------------------------------------------------- `

Open in the playground

Keep in mind though that you create a sparse array with Array(size) so some methods like map(), forEach() wouldn't work as expected, but the iterators works fine like [...arr].

Avoid iterators/generators to make Javascript fast

Alexander Nenashev — Fri, 17 May 2024 12:09:43 +0000

If we look at the iterator protocol we'd notice it comes at a cost of creating {value, done} objects, accessing their props, and calls of next() (a function call is generally is an expensive operation).

Given all the hurdles we have a quite inefficient tool to iterate our data. Moreover when we implement an iterator with a generator we suddenly notice that performance got even worse. I guess that's because of the cost of keeping a generator's scope and its state between calls.

Don't get me wrong, iterators and generators are good abstractions, for await is exceptionally amazing when dealing with async data and abstracting backend API calls, so generally used in business logic they bring benefits but when we descend into the realm of transforming data, generic data handling functions and algorithms we should care to avoid them when possible.

Here's a benchmark of several ways to iterate an array and you see the iterator and generator fail considerably. I'm not the only one complaining, I've seen several comments that generators' speed keeps people from using them widely.

class Iter {
  *gen(arr) {
    for (let i = 0; i < arr.length; i++) {
      yield arr[i];
    }
  }
  iter(arr) {
    let i = 0;
    const out = { value: null, done: false };
    const iter = {
      [Symbol.iterator]: () => iter,
      next: () => {
        if (i === arr.length) out.done = true, out.value = null;
        else out.value = arr[i++];
        return out;
      }
    };
    return iter;
  }
}

const $chunk = () => Array.from({length: 10}, (_, i) => i);
const $input = [], arr = $input;
const iter = new Iter;

// @benchmark generator
for(const e of iter.gen(arr));

// @benchmark iterator
for(const e of iter.iter(arr));

// @benchmark for..of
for(const e of arr);

// @benchmark for
for(let i = 0; i < arr.length; i++) arr[i];

// @benchmark forEach
arr.forEach(e => {});

` Chrome/125
-----------------------------------------------------------------------------------------
>                 n=10        |       n=100       |      n=1000       |      n=10000     
for           1.17x x100m 336 |   1.20x  x10m 354 |   1.01x   x1m 235 | ■ 1.00x x100k 218
for..of       1.19x x100m 340 |   1.21x  x10m 355 | ■ 1.00x   x1m 232 |   1.00x x100k 219
forEach     ■ 1.00x x100m 286 | ■ 1.00x  x10m 294 |   1.00x   x1m 233 |   4.54x  x10k  99
iterator     64.34x   x1m 184 |  13.71x   x1m 403 |  10.86x x100k 252 |  10.96x  x10k 239
generator    43.01x   x1m 123 |  36.05x x100k 106 |  45.69x  x10k 106 |  43.58x   x1k  95
----------------------------------------------------------------------------------------- `
` Firefox/126
-----------------------------------------------------------------------------------------
>                 n=10        |       n=100       |      n=1000       |      n=10000     
for         ■ 1.00x x100m 512 | ■ 1.00x  x10m 505 | ■ 1.00x   x1m 453 | ■ 1.00x x100k 449
forEach       1.62x x100m 828 |   1.48x  x10m 746 |   4.26x x100k 193 |   6.57x  x10k 295
for..of      11.07x  x10m 567 |   9.35x   x1m 472 |   9.98x x100k 452 |  10.11x  x10k 454
iterator     23.44x   x1m 120 |  10.93x   x1m 552 |  11.24x x100k 509 |  10.71x  x10k 481
generator    82.62x   x1m 423 |  64.75x x100k 327 |  66.67x  x10k 302 |  68.37x   x1k 307
----------------------------------------------------------------------------------------- `

Open in the playground

One would argue that for..of in Chrome performs nice despite of using an array's iterator but that's an optimization of using a native iterator. Firefox is generally more honest in benchmarks if we want generic evaluation of Javascript code, but about that is in the next post.

Avoid intermediate arrays (filter/map) to make Javascript fast

Alexander Nenashev — Wed, 15 May 2024 08:21:51 +0000

If you aim to write fast Javascript avoid intermediate arrays when transforming data or making an algorithm. This could happen both with imperative and functional code. Always ask yourself a question while writing code - are there any intermediate arrays I could avoid.

Often I see a common pattern filter + map:

const arr = Array.from({length: 100}, () => ({num: Math.random()}));

arr.filter(n => n.num > .5).map(n => n.num * 2);

Sometimes the chain is quite long, hosting several filter/map/sort in various configurations.

Replace the chain with Array#reduce() which in mostly all cases will give you better performance over any chain of other methods, since you remove the array created by Array#filter():

arr.reduce((r, n) => (n.num > .5 && r.push(n.num * 2), r), []);

@tracygjg asked in a comment why not to use:

arr.reduce((r, n) => n.num > .5 ? [...r, n.num * 2] : r, []);

Thank @tracygjg for this one, that's another great example where you create an intermediate array, moreover an array is created for every element in the result array!

So basically each time we want to add an element to the result, a bigger array is created thus the bigger the source array the slower the solution.

Moreover the spread syntax is used which should be avoided too if you want a performant solution (my next post is about that). Let's benchmark all the 3 options:

const $chunk = Array.from({length: 10}, () => ({num: Math.random()}));
const $input = []; 

// @benchmark filter + map
$input.filter(n => n.num > .5).map(n => n.num * 2);

// @benchmark reduce
$input.reduce((r, n) => (n.num > .5 && r.push(n.num * 2), r), []);

// @benchmark Tracy Gilmore
$input.reduce((r, n) => n.num > .5 ? [...r, n.num * 2] : r, []);

` Chrome/124
-------------------------------------------------------------------------------------------
>                     n=10       |       n=100       |      n=1000       |     n=10000     
reduce          ■ 1.00x x10m 355 | ■ 1.00x   x1m 155 | ■ 1.00x x100k 263 | ■ 1.00x x10k 431
filter + map      1.88x x10m 669 |   1.74x   x1m 269 |   1.41x x100k 370 |   1.55x  x1k  67
Tracy Gilmore     3.32x  x1m 118 |  20.13x x100k 312 | 196.20x   x1k 516 | 893.27x  x10 385
------------------------------------------------------------------------------------------- `
` Firefox/126
-------------------------------------------------------------------------------------------
>                     n=10       |       n=100       |      n=1000       |     n=10000     
reduce          ■ 1.00x x10m 647 | ■ 1.00x   x1m 433 | ■ 1.00x x100k 390 | ■ 1.00x x10k 470
filter + map      1.41x  x1m  91 |   1.27x x100k  55 |   2.51x  x10k  98 |   1.32x x10k 620
Tracy Gilmore     1.90x  x1m 123 |   9.70x  x10k  42 | 175.64x   x1k 685 | 359.57x  x10 169
------------------------------------------------------------------------------------------- `

Open in the playground

As you can see with 10000 array items we could have a hundreds of times slower solution if we don't care enough about avoiding intermediate arrays.

In the next post we will discuss how to avoid intermediate arrays while parsing strings.

Every millisecond matters in Javascript

Alexander Nenashev — Tue, 14 May 2024 11:05:51 +0000

Premature optimization is the root of all evil -- Donald Knuth

In light of modern trends of increasing complexity of modern JS frameworks, high end developer hardware and the premature optimization mantra we ended up with some performance problems with modern web and especially modern mobile web (deserves a separate article).

Probably you can't comfortably use modern web sites on a 5 year old mid/low budget device, at least the most people don't expect to upgrade their PCs used just for web surfing every year. I've ended up buying a high end android phone just to use social sites comfortably.

One could tell that a user couldn't tell a difference between 1 and 5 ms, but given the fact we could have hundreds of operations on page or data loading, all these small overheads lead to a noticeable performance hit and poor user experience.

So I'd say that every millisecond matters in Javascript. Premature optimization is bad when you spend significant amount of time on a code piece that is thrown away later due refactoring. But what if you could write highly performant Javascript code from the beginning? You just don't need to optimize later and the whole premature optimization thing isn't relevant anymore. So learn how to write fast Javascript, I believe it will pay off.

In the next posts that would form a series I will be collecting tips how to write fast Javascript.

Conditional wrap component in Vue 3 pt.3

Alexander Nenashev — Fri, 10 May 2024 17:09:41 +0000

Previously we observed 2 options to create a conditional wrap component in Vue 3. Now it's time for the most complex one which exploits vnodes in a deeper way.

On the client side it's pretty ordinary with the wrapper provided in a wrapper slot and the wrapped content in the default one. But we do some magic inside the wrap component:

We collect all leaf vnodes in the wrapper slot's vnode tree
We inject our content into the leaves like they'd support a default slot. For that we should set shapeFlag of the leaves as ShapeFlags.ARRAY_CHILDREN | ShapeFlags.ELEMENT.

See on Vue SFC Playground

import { ShapeFlags } from "@vue/shared";
import { cloneVNode} from "vue";

const findLeaves = (vnode, cb) => 
  vnode.children?.length ? 
    vnode.children.forEach(vnode => findLeaves(vnode, cb)) : 
    cb(vnode)
;

export default function Wrap({isWrapped}, {slots}){

  if (!isWrapped) return slots.default();

  const wrapper = slots.wrapper().map(vnode => cloneVNode(vnode));
  findLeaves({children: wrapper}, vnode => {
    vnode.shapeFlag = ShapeFlags.ARRAY_CHILDREN | ShapeFlags.ELEMENT;
    (vnode.children ??= []).push(...slots.default());
  });

  return wrapper;
}

Wrap.props = { isWrapped: Boolean };

Usage:

  <wrap :is-wrapped>
    <template #wrapper>
      <div class="wrapper">
        <div class="inner-wrapper"></div>
      </div>
    </template>
    <p>
      I'm wrapped
    </p>
  </wrap>

As you see the DX is pretty good, with full ability to define our wrapper with any nesting fully inside a template.

Now you have a choice to select a wrap component from 3 options or probably combine them into one ultimate component.

Conditional wrap component in Vue 3 pt.2

Alexander Nenashev — Fri, 10 May 2024 14:14:32 +0000

In the previous post we create a pretty idiomatic component that would work well for simple cases. Let's explore more options. What can be done to present our wrapper as a template as more DX friendly? Of course we could compile it runtime, but for a simple 1 level wrapper we could use the following:

See on Vue SFC Playground

export default function Wrap({isWrapped}, {slots}){
  return isWrapped? 
    slots.default() : 
    slots.default().flatMap(vnode => vnode.children);
}

Wrap.props = { isWrapped: Boolean };

Usage:

  <wrap :is-wrapped>
    <div class="wrapper">
      <p>
        I'm wrapped
      </p>
    </div>
  </wrap>

Yes, it looks non idiomatic, also it generates the wrapper's vnode every time even it's discarded, but it was an interesting case to explore for better DX.

In the next post we'll explore a more idiomatic option with using 2 slots for the content and wrapper.

Conditional wrap component in Vue 3

Alexander Nenashev — Fri, 10 May 2024 08:45:37 +0000

Often it's needed to wrap some part of a template in a wrapper <div> for example. It seems easy using v-if but we have a duplication we'd like to avoid:

<div v-if="isWrapped" class="wrapper">
  <!-- some big chunk of markup -->
</div>
<template v-else>
  <!-- the same big chunk -->
</template>

Let's explore our options how we can solve this task without the duplication. Let's call our component <wrap> and our component that wraps the content a wrapper. Our wrap component is stateless so let's make it functional.

Our first option would be simple. We support a wrapper component and its props:

See on Vue SFC Playground

import { h } from 'vue';
export default function Wrap({wrapper}, {slots, attrs}){
  return wrapper ? h(wrapper, attrs, slots.default()) : slots.default();
}

Wrap.props = ['wrapper'];

Usage:

  <wrap :wrapper="isWrapped && 'div'" class="wrapper">
    <p>
      I'm wrapped
    </p>
  </wrap>

The result is pretty sufficient, you can use any wrapper component with a default slot. But a problem here is that for more complex cases like having multiple nested wrappers we should define the wrapper outside our markup since having a functional wrapper component inside :wrapper property looks pretty messy. In the next posts of this series we'll explore other options of defining our conditional wrap component.

Memoized getters in ES6 classes

Alexander Nenashev — Tue, 23 Apr 2024 12:21:58 +0000

We've already seen that attaching prototypes could greatly enhance our data, for example we could add a lot of derived data with getters. The problem is that some of calculated properties could be costly and in most cases we'd want to cache them since usually backend data is pretty static, we update it with POSTing to a backend.

Thanks to class inheritance we can provide a base class for our data classes and add any class or/and instance utilities we need:

class BaseObject {
    static defineCachedGetters(getters, options = null) {
        for (const name in getters) {
            Object.defineProperty(this.prototype, name, {
                get() {
                    const value = getters[name].call(this);
                    Object.defineProperty(this, name, Object.assign({
                        value, configurable: true, writable: true
                    }, options));
                    return value;
                },
                configurable: true
            });
        }
    }
};

class User extends BaseObject {

}

User.defineCachedGetters({
    discounts(){
        const out = [];
        /*  
            here we do some expensive calculations and transformations, 
            the result is an array of the user's discounts
        */
        return out;
    }
});

Here we cache a getter's result in an own property of an instance. We make it non enumerable since derived data shouldn't be potentially serialized in a state (JSON.stringify). Later we can delete the property to allow the getter to be evaluated again.

Enhance your backend data with ES6 classes

Alexander Nenashev — Mon, 22 Apr 2024 13:48:34 +0000

A traditional way of handling backend data on a frontend is to feed it to services, controllers, components and the like. But when I started binding ES6 classes to backend data and all business logic went into classes, my components got much cleaner, and I got a lot of possibilities to handle and transform data inside classes. It was a big shift to make my frontend code cleaner and shorter. You just simply use Object.setPrototypeOf:

classes.mjs

export class User{
  get fullName(){
    return `${this.firstName} ${this.lastName}`;
  }
}

import { User } from './classes.mjs';
// fetch some users then attach the class
users.forEach(user => Object.setPrototypeOf(user, User.prototype));
// now you can use `user.fullName` anywhere

Another reason to bind class prototypes is performance. You don't need to create a new copy of data consisting of class instances, copy data into instance properties and so on and thus you save precious CPU time and memory providing faster user experience.