Look at that trend line baby, mm-hmm! I am just as amazed as I was a decade ago when I lost roughly 20kg by maintaining a calorie deficit. It was truly magical for someone who was overweight and obese throughout their childhood. It became a defining feature of my self, something the chatter in my brain would keep affirming.

A decade later, after having maintained that weight, gained it back twice, and lost it again, I have more thoughts on the topic. I feel I was entirely missing a very important aspect, and I would like to revise my position.

There's the mechanics of weight loss, which undoubtedly remains to be a calorie deficit, and then there's the humanity of weight loss, which is often overlooked. A decade later, we have weight loss drugs that essentially "cure" the "illness" of hunger, which definitely work on a mechanical level by simply reducing the calories consumed more than your maintenance needs, but it too, I feel, mistakes hunger for the illness, so to speak.

The real question is not how to lose weight, because today we already have a pill for that, or of course insights from my old blog post, but it is to understand why we feel insatiable hunger and exceed our BMR so easily in the first place? How was I able to overcome it multiple times in the last 10 years? Why was I unable to maintain that and ended up gaining weight back? From normal BMI to obese?

This is exactly what I feel I missed back then, and was forced to confront. This can be a question with a unique answer for everyone, for brain, gut, and hormones are literally not fully understood. However, there are some hypotheses you could have, hormones? obesogenic world? toxic relationships? For me, it was the modern hobby we all share.

🔗stress

Yup. The final boss of most maladaptive behaviors. In my case, the stress is what kept me away from doing the things that guarantee a calorie deficit. You may really optimize every ingredient to be low in calorie density, remove all snacks from your pantry, switch to zero oil or sugar free alternates, but the underlying stress is what made me order a 12-inch pizza at night, quickly stuff embarrassingly huge portions of leftovers straight from the fridge over the sink before even plating or heating it. What brought out this "illness" in me was not lack of understanding of a calorie deficit, but underlying stress. My body was screaming for help. If this feels familiar, it may be worth seeking support. Ironically, the stress of maintaining a calorie deficit in such a state only fuels the stress, so you'll find yourself burned out after a few weeks of diet or gym.

What worked for me a decade ago was the fact that I had moved 2000 kms away from home, which could usually trigger stress, but thanks to my colored childhood, it actually suddenly calmed my nervous system. On top of that, I had joined a new job where I felt overqualified, with a commute of a 10-minute walk, albeit with a dreadful road crossing (remember folks, India is not for beginners). I also had free time to devote to 3 hour-long walks, access to office canteen's affordable and healthy breakfasts and lunches, and still having enough time to cook my own meals. Imagine the luxurious life I was living back then? The 30s me just dreams of that.

🔗so what changed?

I was able to maintain my weight for a good half-decade 2017-2022, but late 22 to 26 have been quite chaotic. As I am writing, I can already remember some major life events that caused bursts of stress, be it the dark clouds of layoffs in the tech industry, my individual discovery of self, the infliction of 30 revolutions around the sun (how does one suddenly start getting injured doing absolutely nothing?) and some major shifts in relationships. That's an enormous amount of stress, that the 20-something me could never have imagined enduring.

These were fires that I needed to fight, as opposed to the second favorite hobby of us all, avoidance. As these got addressed, it became easy to focus on weight loss/muscle gain/health in general. I implore you to focus on these two world-famous hobbies of stress and avoidance, and take it easy even if your diet is not "working". The mechanism might not be faulty, the environment might be, the self that the environment or the mechanism is happening to might just not be in sync.

🔗tldr please?

I wrote about a simple understanding of a calorie deficit and immediately benefiting from it a decade ago, but what I missed was how stress-free my life was, which allowed me to maintain a calorie deficit for years going forward. But life in my 30s brought various anxieties and reflections that made it hard to achieve a deficit. My challenge is anxiety control, not calorie control.

So, I vibe coded a todo app? Yay, big deal. No seriously, this is definitely a big deal for me, or was when I was suffering through what I feel was the biggest anxious phase of my life.

🔗anxiety

This year sucks. Apart from wars, war crimes, loss of life, financial uppending by an orange fart ball, gaming industry crisis, human-caused "natural" disasters, I personally also suddenly felt a historically famous, crisis of purpose. AI Agents have indeed become so good that with enough tokens and relevant context, you can indeed get them to build you whatever software you want. I really felt the pain of being perceived as irrelevant and redundant, despite still having a job (so far) and having institutional knowledge. Not to toot my own horn but I spoke publicly about cool stuff we did at Swiggy and what not. It was very easy to go into spirals of "but then what's the point of it when it can be done by a prompt".

I had briefly read about a talk by a fellow member of the tech community talking about ego coding and without even viewing it, I felt immense pain even thinking about the title. I was indeed suffering from "Ego coding" blues. I wanted MYSELF to write code, and now indeed AI was sometimes, not always, better or faster than me. I was in despair and had lost any will to do anything.

One of my colleagues at work had a different response to this dread. They immersed themselves in work, did so much in a day that one would usually do over a month thanks to this agentic superpower. Man I was super scared to open slack and see their multiple PRs in a day with beautiful screenshots of before/after. It didn't look sloppy, it wasn't coded in a sloppy way either. It was literally their blood, sweat, tears and tokens.

🔗wait, where is this going?

Yeah, so amidst all this, therapy was one place for me to understand why suddenly I had the urge to become a driver, or open up a cafe with my savings, or buy a fleet of cabs and earn my living that could be protected from AI. Now I am not trying to tell you I have cured my anxiety, for it often is a signal of some other underlying fears, but I want to talk about a system that helped me calm down a bit, put my head down and focus on getting work done. This is a coping mechanism, not the ultimate fix.

🔗a todo app?

So to fight the daemon of anxiety triggered by AI, I used AI to create a todo app, like one does. Now this wasn't an ordinary todo app, it was something I really wanted for myself. I wanted to have a list of things I want to do today and see the progress I made, not in comparison to my peers, or the world at large, just what wasn't done at the start of the day, and was indeed done by the end. I also wanted to perceive movement which was getting dimmed in the noise of work slack and doom posts of reddit. So I wanted to write a sentence or two about my reflections of the day, and a rating. Some days were 1/10, some were 9/10, and this granularity helped me answer the loud critic in my head asking me "what have you done?".

I (asked the LLM to write) wrote it in Swift, even though I have 0 clue about how that language works. I wanted it for my mac using mac aesthetics, I didn't want to run electron, so Swift it was. Honestly, I had no cognitive batteries to really learn anything new or do anything, but I wanted a wonky gratitude journal that I would actually use.

I also wanted to have pictures of Marianne North, after being enamored by her art as seen in Kew Gardens. So I got it added too. These calmed me.

BTW, can we just talk about how cool and uber rich Marianne North was? Like she/they traveled 6 continents in her/their 40s, creating immense art and pursuing botany. Why can't the rich of 21st century do that instead?

I then also added more features to it, a 20-minute break reminder to do my ergonomic exercises, a sound mixer coz why not, and so on.

🔗does it work?

I have been using it almost daily, and my daily ratings have definitely improved. I was able to manage my catastrophizing mind, and get things done, irrespective of what my environment felt about it.

It also surprisingly did something different, it also helped me understand what vibe coding can actually feel like. I would never have been able to learn Swift, code the app the way it is, or build all these features overnight, in fact I doubt I would be able to do it using electron either, with this polish or at this pace. It helped me truly experience parts of this tweet, especially the "embrace exponentials". I really understood the devil I was fighting better, and came to some level of acceptance of the new reality. Life is about change, and change is painful, and change also becomes the new normal.

Also, I am sure anyone could vibe code a Swift app, or I could've built this app with enough time and cognitive resources. But something tells me, there is still some degree of analytical and problem-solving skill required to get to a desired end state. To describe a problem and convince a machine to solve it via lexicography doesn't really change, be it tyop rieeden sklloppy engrish or sophisticated arcane assembly language. (No this post is not sponsored by your favorite ClosedThropicPilot, ain't nobody paying me to shill).

🔗fin

I feel less anxious now, I am able to work a bit more peacefully, and I see agentic coding as yet another form of coding, where the syntax is high level system design. Therapy did most of it, this todo app helped a bit, and the rest was growing pains.

Me playing NFS Underground 2 on ROG Ally, a game that is delisted and abandoned by original publisher

I feel incredibly privileged to have been born into a time when video games existed, and to witness their maturity from Pong to pixel art to 3D graphics, and now seamless open worlds with incredibly detailed graphics and interconnected systems. Video games have always pushed hardware to its limits, whether in sound, storage, display, visual trickery, or even immersive narratives.

However, word on the street is that the gaming industry is dying. Never before have we seen layoffs at both successful and unsuccessful studios. Developers and contract workers are rewarded with layoffs, while executives flaunt their luxury car collections. Gamers are playing the same old games, and the top 10 have remained remarkably persistent, whether they are live-service games such as Fortnite, Roblox, and GTA Online, or remasters and remakes.

The fact that we have gone through almost three console generations without a new GTA says a lot about how expensive new games have become to make, and how reluctant mega-studios have grown after seeing the popularity of games-as-a-service. Estimates put GTA Online's average revenue at about $1.3 million a day; most new games fail to reach anything close to that. Cough Concord, cough Highguard, cough Redfall.

While this has been true for quite some time, a new challenger is on the block: an AI-induced hardware crisis. Suddenly everyone wants to build data centres, making everything with RAM or a CPU incredibly expensive. New gamers may stick with their existing devices, or buy fewer games after paying for an expensive console or PC wrapped around RAM and storage.

Analysts worry about sales of the PS6 or the next Xbox Series Z One X Two XTZ. Even Valve has struggled to offer the Steam Machine, a machine much less powerful than a PS5, at a lower price than the PS5.

If you were feeling concerned already, fear not: there is much more to be afraid of. Sony, one of the few bastions of physical games, has reliably shipped games on its discs, unlike Xbox, for which there is a community-crowdsourced site to check whether a disc actually contains a playable game. Yet Sony has announced that it will repurpose its Austrian factory to make microlenses for, you guessed it, data-centre equipment. It chose a fantastic time to announce this: after delisting more than 500 digital movies for UK users without refunds and amid reports that PlayStation physical discs could end in 2028.

Surely you think that's pretty much it. Well, no: Nvidia and AMD have recently announced price hikes, and even Apple, with its insanely good MacBook Neo, is going to raise prices and we might be even looking at financing options for its cheapest laptop soon too.

Let's talk a bit about Nvidia. It has single-handedly ensured that every game is DLSS-pilled with RTX technologies, and has normalised terrible GPU pricing with lopsided VRAM. While it profiteers massively from the AI boom with one hand, it offers a state-of-the-art streaming option with the other: GeForce NOW, at the measly price of ₹2,000 per month. I gave it a shot, and it is insanely good, so good that I am afraid we are headed towards digital-only, cloud-based gaming bundled into a subscription. Surely everyone will otherwise be priced out.

So what does this mean? Will you be able to afford your gaming hobby, or will you own nothing and be happy? To be fair, there is something to be said about the rise of indie games. They now frequently receive Game of the Year nominations (Clair Obscur Expedition 33, my personal favorite while not truly an indie, it is definitely not a Rockstar/Sony/Ubisoft-esque blockbuster game), and even win them, while often costing much less than the standard $70 AAA release. Some run beautifully on older hardware; heck, some are designed with web technologies and get mobile ports too. Vampire Survivors is a good example of that spirit.

It certainly feels like a big reset moment: a transitional phase driven primarily by enshittification and the AI boom. I am not very hopeful about the future, but when I look at my backlog, I feel grateful to the developers of the past who put their time and energy into making these games.

Maybe finally video games might only be made because the developers want to play them, not only to sell them, but going through this Crysis is the price we might pay to learn that lesson.

Without thinking much, my mind instantly thought about my unusual relationship with the music I've been listening to lately. I firmly believe that our choice in music reveals multiple layers about our experiences.

Our choice of music is never objective, there are no objectively perfect lyrics, objectively melodious melodies, objectively perfect cacophony of vibrations and precurssions that can soothe every human mind, at all times. In fact, you'd find people change their taste over the years in unrecognisable ways. For no development of taste in music is also objectively predetermined. Not all roads lead to Jazz.

With this perspective, the question arises why then one chooses to prefer certain music, and why do they prefer to change that taste over life experiences? This blog is my answer to these questions.

I've been raised in a rather orthodox atmosphere of obedience, subservience, unquestionable loyalty, and an unpayable debt towards your parents. The kind of climate where things were either Godly good or Evilly bad, and doing bad things meant you, a child, figuring out this complex world, are bad, disgrace and worthy of abuse.

What does a fairly straightforward upbringing like this, though highly lucrative in psychotherapy spheres, does to the taste of music of a growing human mind?

Naturally, in this very monochromatic world, the cosmic dance of vibrations and the fractal strings of alphabets, becomes objective.

Not only the child develops an acceptable taste in music, and seeks out music that earns validation in the eyes of their caretakers, peers, and every single person they want to impress, silently, a very loud playlist gets developed that the child subjectively enjoys but tries very hard to hide by objectively looking down at people who like such music.

With this background, as I was recovering from what seemed to be fever after a fall from bike on slippery curvy hilly roads of sleeper town of Munduk in Bali, a day before Nyepi, the auspicious Hindu festival of silence, when even airports are shut and almost no hotels provide any service, turned out to be actually entirely unrelated to the fall, and was simply the worst fever I've ever had, for it was the first sign of a very common viral infection of dengue.

In such a catatonic state, the guards of that child lowered, and he finally allowed to be soothed with the music that the algorithm kept recommending but he kept avoiding it coz he learned to believe it was objectively bad music.

And soothed he, the child, was. He can't explain why he loves this music, it makes his stoic persona want to dance, it makes him happy even though the lyrics are far from his acquired personality, but he feels an unexplainable connection to it which his objectivity cannot rationalize.

And that's how I got through a hard time, by learning to let that child enjoy the bliss of subjectivity.

I recently wrote about one of the more satisfying debugging efforts I have been part of at udaan: how we solved a 2s+ stutter caused by re-rendering React components.

The problem looked deceptively small: tapping Add to Cart could leave the UI visibly stuck for more than two seconds. The fun part was getting from that symptom to the underlying cause without turning the fix into a rewrite.

We used simple visual measurements to see the repeated renders, then narrowed the blast radius with smaller hooks, selectors, and batching. Each change was surgical: reduce the work that was actually happening instead of papering over it with a loading state or a new state-management migration.

The result was a much smoother interaction and a reminder I keep coming back to: performance debugging gets much easier once the measurement is concrete enough to make the bottleneck obvious.

Read the full story on udaan engineering.

I also wrote about a much more persistent problem at udaan: improving startup performance for a large React Native app.

Startup performance is an awkward problem because the first question is usually not “how do we fix it?” but “what exactly are we measuring?” The investigation taught me the value of useful telemetry, small experiments, and being honest when the data contradicted an appealing explanation.

It was tempting to reach for a shiny migration or a sweeping upgrade. Instead, the valuable work was simplifying the startup path, validating one hypothesis at a time, and paying attention to how the app felt as well as what the numbers reported.

That approach made the work less glamorous, but much more reliable. It is a lesson I now carry into most performance work: simplify first, measure the change, and earn the complexity only when it is necessary.

Read the full story on udaan engineering.

With Holi coming up and me witnessing a lot of turmoil in my personal life, I was forced to think about Holi in a very specific way. At risk of over-simplifying and appropriating the narrative, here are my unpopular views on the epic of Bhagat Prahlad and how it relates with narcissism and toxic patriarchy.

If you are to believe the ancient epic of Bhagat Prahlad and Hirnaykashyap, AKA Harnaakash in Sikhi, you'll find some interesting things around patriarchal family dynamics. There was an ideological difference between Prahlad and his father. His father felt superior and he felt that he was worthy of worship. This inflated self-view was further exemplified by the fact that his province & society agreed, thanks to his boon of invincibility.

Prahlad, on other hand, by grace of his own wisdom given by Narad, believed Vishnu to be his God. This was completely unacceptable to his narcissist father. Prahlad's defiance was followed by series of attempts by his father to get his son to conform to his ideology.

While the world around Hirnaykashyap believed him to be equivalent of God, Prahlad didn't bow down to his teachers, friends, sister and as well as his mother. He stood against and outright fought the entire world for his right to lead his life his way.

Imagine what a typical patriarchal mindset person in that era would have said. Wouldn't they instruct Prahald to leave his ego and just bow down to his parents? After all, his mother nurtured and nourished him, and his father took care of him, isn't it his moral obligation?

Guru Amardaas Jee, 3rd Guru of Sikhs, in his rendition of the epic, shows how Prahlad talks back to his own mother.

Ultimately, after multiple attempts of coercing Prahlad, including multiple attempts of murder for not agreeing with his father, Prahlad was protected by Narsingh (an avatar of Vishnu) after He killed his father, thanks to some loop-hole in the invincibility spell.

My point over here is that, since bygones we know of narcissism & toxic patriarchy, and this story shows how a minor stood up against something he believed to be false and didn't bow down at all. In the world of obedient Shravan Kumar & Raam, we also have disobedient Prahald.

Whether you believe children should indeed never defy their parents, or that Prahlad was an exception because he was a devotee of Vishnu, truth is that Prahlad wasn't supported by anyone he could rely on (his parents, siblings, friends or school) but he didn't conform to them.

In my opinion, the notion that children must be obedient to their parents is rejected by this story. Whether Prahlad was right or wrong, that's a separate ideological question, but we all can agree that children have been defying parents since bygones & Sikhi even celebrates that.

The number of times Prahlad's story is mentioned in Sikhi, makes me feel that Gurus didn't really want Sikhs to become obedient children of their parents, but rather be autonomous and sovereign. Defiance against old systems is pretty much a norm in Sikhi.

Controlling parents and emotional abuse by narcissistic parents is not a new story, and it even needed intervention by Vishnu themself to save Prahlad.

If you're a victim of such emotional abuse by controlling parents, you may take inspiration from this epic.

🔗Asynchronous Communication

Pretty much all developers know how synchronous blocking code isn't really ideal, especially when multiple actors are involved. The same applies to a team of employees. If every problem requires another employee to stop what they're doing and help you out, it causes a pipeline stall. Because they've stalled what they were doing, dependents of their work would also be stalled. It isn't immediately obvious, but as the team scales without adopting asynchronous communication, productivity counter-intuitively decreases, despite the increase of workforce. In my opinion addition of new members doesn't also mean improvement of efficient communication amongst them.

• Make it easy for other person to reply quickly, for example:
• • A yes/no question can be answered faster than an ambiguous monologue.
• • Scheduling a meeting in advance (after checking their calendar) is better than asking "are you free?" and waiting for hours.
• • Sharing relevant details/attachments is better than waiting for them to ask you for that.
• Sharing a deadline in your ask gives other person time to organize their week plans better.
• Expect delays in replies, that's the norm, not an exception.
• Keep some extra chores at hand while you wait for a reply, so as to not stay blocked until you receive one.

🔗Clear Articulate Communication

Effective written communication becomes critical the more companies embrace remote work. With an aversion to "jumping on calls" at a whim, and a preference for asynchronous communication, most of remote-friendly company's communications are text-based, and so articulate and timely articulation becomes key.

Source

The next problem is that folks prefer to communicate as little as possible about their issue, while expect an immediate fix for their issue. Observe the three scenarios above. The first message is essentially a shoulder tap equivalent of office. You completely break the flow of the other person, without being considerate about their time and their context switch. Please don't do this unless it's basically EMERGENT as well as URGENT. To understand the difference between the two, let's look at this quote:

The main difference between emergency and urgency is that in emergency there is immediate threat to life, health, property or environment; whereas in urgency, there is no immediate danger or threat to life, health, property or environment but if not taken care in a given period of time, then the situation may turn into an emergency situation.

Source

I hope we can all agree that first message should ONLY be reserved for emergencies. If we keep crying foul, like calling a person to help with an unreleased software or upcoming demo, what eventually happens is that employees lose seriousness and start skipping calls. This can be catastrophic when you really have an emergency, like a huge outage or critical crash that's costing millions of dollars.

Now that we've established that the first message is basically reserved for emergencies, let's see why the second message isn't ideal either. The problem is that it's focused only in getting the solution, but with minimum effort. It's basically like asking someone to take over and fix your issue, i.e. spoon feeding. This is detrimental in several ways;

• You don't actually go through the process of reading, debugging, trying, thinking, and learn less.
• You stop someone else from doing their work and making it difficult for them to resume after having disconnected the call.
• The person who you're asking help from has to ask you a bunch of questions which you could've written to avoid extra time spent on the problem. "Did you try this? Did you read this? Can you share the error message? Can you share your branch?", all this could've been avoided and saved everybody's time.
• It negatively effects the mood of the other person because deep down everyone wants to help each other, but they've to make a choice between being polite and slacking off in their job. That's a tough one and not everyone would be assertive enough to triage help.
• Chances are, by the time you read the error message, Google a bit, read documentation and try certain fixes, you might have found the fix.

Even if you are using the third message format, take some time to type out the entire thing, and re-read it yourself once. Not only you'll avoid spamming, you'll also get an opportunity for some self-reflection. Sometimes you just need to see a gist of the whole thing for something to "click".

🔗Open Communication

Now that we understand importance of asynchronous and clear articulate communication, last thing that we need is open communication. There's no need to discuss in small silos when you know there are several of employees who might be facing the same issue, might have fixed it somehow and might have better ideas than the person you're taking help from. So asking for helping to your favorite goto person for xyz type of issue is only going to wear them out and give you less imaginative solutions. Discuss in open as much as possible, albeit in a clear articulate fashion, so as to enable meaningful discussion for systematic solutions.

• Try to discuss in channels & groups, not just DMs.
• Realize that asking questions in open doesn't reflect poorly on you.
• Fear of conflicting opinions is a net negative for a team.
• Sharing your progress timely with the concerned audience helps in avoiding working in isolation.
• Gathering continuous feedback from multiple people helps in adapting to changing requirements.

I hope this post made some sense to you and encourages you to form boundaries for your sanity and that of your team members. I'll highly recommend you to go through the links I've shared in this blog to learn more.

🔗Basic JavaScript syntax

If you want to learn from a book, this is a great one https://exploringjs.com/impatient-js/toc.html

🔗Variable definition

const a = 123;

let b = 123;
b = a;

var c = 123;
c = a;

🔗Function definition

// function definition
function myFunction() {}

// function as a variable
const myFunction = function myFunction() {};

// anonymous function
const myFunction = function () {};

// arrow function
const myFunction = () => {};

🔗Strings

const a = "Hello, world";

a.length; // 12

a.slice(3, -3); // "lo, wo"

a.split(","); // ["Hello", " world]

a.charAt(0); // "H"

a[0]; // "H"

a.replace("world", "you!"); // "Hello, you!"

a.slice(6).trim(); // " world" trims into "world"

const b = a + ". Sup?"; // "Hello, world. Sup?" (single quotes are also accepted)

const c = `${b}`; // Template strings can interpolate variables

🔗Arrays

const a = ["Hello,", "world"]

a.length // 2

a.join(" "); // "Hello, world"

a[0] // "Hello,"

a[a.length -1] // "world"

a.concat("!") // ["Hello,", "world", "!"]

a.find(e ⇒ e === "!") // "!"

a.find(e ⇒ e === "definitely not in array") // undefined

a.indexOf("world") // 1

a.push("Sup?") // returns new length of mutated array ["Hello,", "world", "!", "Sup?"]

a.pop() // removes last item

b.shift() // removes  first item, shifts left, ["world", "!"]

b.unshift("Hello!") // puts new item to beginning ["Hello!", "world", "!"]

// destructuring
const [first, second] = ["Hello", "world"] // first is Hello", second is "world"
const [first, ...rest] = [1, 2, 3, 4] // first is 1, rest is [2, 3, 4]

// spreading
const c = [first, ...rest] // c is [1, 2, 3, 4]

🔗Objects

JSON is first class citizen. The quotes around key aren't necessary.

const o = {

  name: "Human",

  age: 200000,

  greet () {
    console.log(`Hi! I'm ${this.name} and I'm ${this.age} years old`);
  }

}

o.greet(); // prints "Hi! I'm Human and I'm 200000 years old"
[o.name](http://o.name) // "Human"

o['age'] // 200000

const key = condition ? "name" : "age";

o[key] // depending on condition it'll be "Human" or 200000

o.newKey = [1,2,3]; // o now has name, age and newKey

Object.keys(o) // ["name", "age", "newKey"]

Object.entries(o) // [["name", "Human"], ["age", 200000], ["newKey", [1,2,3]]

// destructuring

const {name} = o; // name is Human
const {
  greet,
  ...restOfObject
} = o; // greet is function, restOfObject is {name: "Human", age: 200000}

// spreading
const myNewPerson = {
  ...restOfObject,
  greet () {
    console.log(`Yo! This is ${this.name} over here. Imma ${this.age} year old!`);
  }
}

// property shorthands

const myName = "is khan";

const object = { myName } // same as { myName: myName }

🔗Conditional Constructs

if (condition) {
  a();
} else if (condition2) {
  b();
} else {
  c();
}

condition ? a() : condition2 ? b() : c();

condition && a(); // iff condition is truth-y, a would be executed

a() || b(); // if result of a() is truth-y, b won't be executed

🔗Looping Constructs

// for loop
for (let i = 0; i < arr.length; i++) {}

//while loo
let i = 0;

while (i < arr.length) {
  i++;
}

// do-while
let i = 0;

do {
  i++;
} while (i < arr.length);

// for-in loop to loop through keys of an object

for (let key in object) {
}

// for-of loop to loop through values of an array

for (let value of array) {
}

🔗Functional

// loops through all items of arr array
arr.forEach((index, value, array) => {});

// loops through all items of arr array and returns modified array
arr.map((index, value, array) => modifiedItem);

// returns array with items where cond(value) is true
arr.filter((index, value, array) => cond(value));

// returns true if any item has cond(value) true
arr.some((index, value, array) => cond(value));

// returns true if all items have cond(value) true
arr.every((index, value, array) => cond(value));

// returns undefined or first item matching cond(value)
arr.find((index, value, array) => cond(value));

🔗Classes

class A {
  constructor(name) {
    this.name = name;
  }
  static variable = 123;
  static utilityMethod() {}
  method() {}
}

const a = new A("Human");

a.method();

A.utilityMethod();

A.variable;

// Shorthand for instance variables
class B {
  counter = 0;
  increment = () => {
    this.counter += 1;
    return this.counter;
  };
}
// same as
class B {
  constructor() {
    this.counter = 0;
    this.increment = () => {
      this.counter += 1;
      return this.counter;
    };
  }
}

// Difference between defining instance method and class method (class A#method)
// is that instance methods are created for each instance
// while class method reference is reused between all instances
// so if you're dealing with a lot of instances of same class
// method will be better memory-wise

🔗Asynchronous code

// Callbacks
function executeAfterOneSecond (fn) {
  setTimeout(() => {
    fn();
  }, 1000);
}

executeAfterOneSecond(() => console.log("b"));
console.log("a");

// unlike blocking languages, setTimeout won't block execution
// we'll see "a" and "b" after a second, even if we've b being executed before

// Learn more about event loop: https://www.youtube.com/watch?v=8aGhZQkoFbQ

// In this example we saw setTimeout accepting a function and so did executeAfterOneSecond
// This makes it a higher order function, and fn is called a callback
// as in, once you're done, call [me] back.

// Promises
// Imagine everything being executed via callbacks
callApi(apiUrl, (result) => {
  convertToJson(result, (json) => {
	transformData(json, (data) => {
		callAnotherApi(apiUrl2, data, (finalResult) => {
			notifyUser(finalResult);
		});
        });
  });
});

// While this is good as our code doesn't block any user action like scrolling
// it's hard to read and is usually referred to as "Callback hell"

// Promises were designed to make this pyramid shape more flat

// A promise is an instance of class Promise that has two main methods then & catch

const callApi = apiUrl => new Promise((resolve, reject) => {
  lowLevelFunctionToCallNetwork(apiUrl, (err, data) => {
    if (err) reject(err);
    else resolve(data);
  })
});

callApi(apiUrl)
  .then(convertToJson)
  .then(transformData)
  .then((data) => callAnotheApi(apiUrl2, data))
  .then(notifyUser);

// Async/await makes it even more easier

async function () {
  const result = await callApi(apiUrl);
  const json = await transformData(result);
  const finalResult =  callAnotherApi(apiUrl2, data);
  notifyUser(finalResult);
}();

🔗Module system

In my opinion, frontend code grows much faster than backend code. Not only you deal with calling various APIs and data transformation techniques, you also bind all that to UI, while taking care of navigation, animations, performance, accessibility and so on.

Without the ability of converting code snippets into tiny reusable modules, you'll end up in a great spaghetti code with business logic, API logic, performance optimizations, UI, animations etc. all in one file.

Let's first cover imports

// assuming "react" is in package.json's dependencies
// present in <root>/node_modules

// imports only the the default export.
import React from "react";
// imports all the named and default export as React.
import * as React from "react";

// you can change the name as you find fit
// note: in case of React you really need to name it React for JSX transpilation
import ICanChangeTheNameToAnything from "react";

// you can destructure from modules
import { Component, useState, useEffect } from "react";

// you can rename a destructured value from a module using `as` keyword.
import { Component as ReactComponent } from "react";

// for local imports, you need to give relative path (in context of current file)
import * as mypackage from "./my-package";

// All import paths have to be statically known, so you can't put a variable in there.

Now that we know how to import, let's focus on exports

export const a = 1; // imported as import {a} from './my-package';

export function print(...args) {
  // imported as import {print} from "./my-package";
  console.log(...args);
}

const b = 2;
const c = 3;
const d = 4;

export { b, c, d }; // imported as import { b, c, d } from "./my-package";

export default a; // imported as import a from "./my-package";

export * from "./some-other-package"; // exports evertyhing in some-other-package

Screenshot of official ReactJS website.

🔗Why do we even need React?

• Every frontend application deals with calling APIs, transforming data, listening to user's actions (click, key presses) and updating UI accordingly.
• As you have more and more interactable/dynamic elements in your UI, keeping a reference of each element and manually changing it whenever data (let's call it state of application) changes can be cumbersome. It can also be hard to remember to update all elements that are related to one particular state variable.
• Let's take example of an app like Swiggy. When I click on add item, see how many elements update, and how many calculations are going on.

• Not just that, there are a lot of edge cases that have to be handled. Observe what happens when I try to add item from other restaurant.

• Clearly manually updating each state variable and element is invitation to a messy codebase. And we've not yet seen how hard it can be to update UI code.
• For something as simple as updating text of any element, we've to do the following. Imagine having id's all over your HTML code and writing code to manually mutate every single field, each time one state variable changes.

// pseudo-ish code, just to illustrate how one might tackle the problem
// with imperative procedural approach

const addToCart = document.getElementById("add-to-cart");

addToCart.addEventListener("click", (e) => {
  if (getCartRestaurant() !== getCurrentRestaurant()) {
    showPopup();
    return;
  }

  e.target.innerText = e.target.innerText + 1;

  const itemDetails = itemStore.get(addToCart.data.itemId);
  if (!cartExists()) {
    addCartToUI(); // series of commands to build up cart UI
    addItemToCartUI(itemDetails); // series of commands to update cart UI with new itemDetails
  }

  addItemToCartUI(itemDetails);
});

• This is where React comes handy by abstracting the imperative commands in a declarative API, while also making it reactive to state changes. So whenever our state changes, React will take care of updating the UI as defined by our code.

<button onClick={() => addItemToCartState(itemDetails)}>Add</button>;
{
  cartExists && <Cart items={cart.items} />;
}
{
  cartExists && currentRestaurant !== cart.restaurant && <Popup />;
}

• React takes care of rendering to UI, we just need to make update cart state, the components would react to it naturally. By making reusable components like Cart and Popup, you don't have to duplicate code each time you want to construct UI and behavior around it. Components can naturally compose making it really easy to write code.
• React Native is another platform that uses React in its core. All fundamentals of React are ditto same in React Native, with only differences in some APIs and core components provided. The value proposition of React Native is that unlike native apps, you can use single codebase for iOS, Android and Web, while also bypassing App store/Play store for releasing non-native changes (all UI & business logic majorly). We'll discuss this point later.

🔗JSX - The language of React

import React from "react";

function Person(props) {
  return (
    <div>
      <h1 style={{ color: "red" }}>{props.name}</h1>
    </div>
  );
}

// is transpiled into

import React from "react";

function Person(props) {
  return React.createElement(
    "div",
    null,
    React.createElement("h1", { style: { color: "red" } }, props.name)
  );
}

Before we understand React, we must first take time to understand JSX, the way you describe UI in React Applications. JSX is basically an extension to JavaScript to add support for XML like syntax. While JSX isn't necessary, it does make it much more easy to write code. React's philosophy deviates from traditional template based frameworks (Angular, Vue, Svelte) in the sense that it doesn't mix programming constructs into the template, but rather mixes HTML into JavaScript itself.

This makes writing UI code familiar to HTML, while also having access to entire JavaScript syntax. This IMO reduces a lot of boilerplate and template specific knowledge.

Note: A tool like babel or typescript can be used to do this transformation. Note, as it is JSX won't run on browser, it needs to be converted to JavaScript, hence the need of a build tool.

<MyComponent isActive />;
// is transpiled into
React.createElement(MyComponent, { isActive: true });

<MyComponent isActive {...props} />;
// is loosely transpiled into
React.createElement(MyComponent, { isActive: true, ...props });

🔗A React component

Now that we know how to express UI in a React app efficiently (code readability wise), we can look into an actual React component now.

There are 3 primary parts to a React component. It can have internal state, it can listen to props sent by its parent component, and it can return a sub-tree of UI expressed as JSX.

There are two paradigms you can follow to make a React Component.

• Class based components

  Any class that extends either of React.Component and implements at a bare minimum render method that returns JSX, is a class based component.

// basic example
class MyComponent extends React.Component {
  render() {
    return <h1>Hello!</h1>;
  }
}

• Functional components

  Any function that returns JSX is a functional component.

// basic example
function MyComponent() {
  return <h1>Hello!</h1>;
}

// smoller plz
const MyComponent = () => {
  return <h1>Hello!</h1>;
};

// i sed smolllllll
const MyComponent = () => <h1>Hello!</h1>;

As you can see, functional component seem to be quite simple in their definition. Each component can accept props and can have an internal state. But how do these access props and state?

🔗Props

// functional component
function MyComponent(props) {
  return <h1>{props.title}</h1>;
}

// class based component
class MyComponent extends React.Component {
  render() {
    return <h1>{this.props.title}</h1>;
  }
}

🔗State

// functional component
function MyComponent() {
  const [count, setCount] = useState(0);
  return <button onClick={() => setCount(count + 1)}>{count}</button>;
}

// class based component
class MyComponent extends React.Component {
  constructor(props) {
    super(props);
    this.state = { count: 0 };
  }
  render() {
    return (
      <button onClick={() => this.setState({ count: this.state.count + 1 })}>
        {count}
      </button>
    );
  }
}

// smoller plz
class MyComponent extends React.Component {
  state = { count: 0 };
  render() {
    return (
      <button onClick={() => this.setState({ count: this.state.count + 1 })}>
        {count}
      </button>
    );
  }
}

There's fundamental difference in idea of state in a class component and functional component. In a class component, entire state is part of this.state and each state variable would be a key of it. While in functional component, each state variable is created individually by virtue of useState, a magical-looking function that somehow remembers current state value between renders, and can differentiate one from another. You can also see how state is tightly coupled to the class (it's directly inside the constructor), while in case of function, it is yet another function call. If say you had 3 state variables, you can group 3 useStates in one function call and use it. This isn't quite intuitively obvious when we see class based components.

Originally, we only had class based components as the only viable option as only they supported state and other features. However, React introduced concept of hooks (such as useState), that gives a lot of flexibility to functional components making them not only on-par but actually superior in terms of code re-usability and agility.

Since it's much simpler to understand functional components, we'll go through them first so that you can contribute ASAP. When we discuss lifecycle methods, we'll learn more about the differences.

🔗Lifecycles and Side-effects

Having access to state and props is very powerful to create dynamic UIs. However, you also need to know about the lifecycle of a component. You may want to call an API as soon as the UI is visible to user. Or may want to cancel a polling request as soon as the component is removed from current tree of components. You may want to know when a query prop has been updated by a parent of a <Search query={userQuery} /> component, to fetch new results based on updated query. All these are side effects of component's life cycle. Perform this side effect when some event occurs (component loads, state changes, prop changes, component unloads to name a few).

Let's see how to listen to these events in class based components first.

🔗Class Based Components

🔗When a component loads

class MyComponent extends React.Component {
  state = { loading: true, data: null };

  async componentDidMount() {
    // perform on load side effects
    const data = await callApi();
    this.setState({ data, loading: false });
  }

  render() {
    const { loading, data } = this.state;
    if (loading) return "Loading...";

    return <User data={data.user} />;
  }
}

🔗When a component is removed from tree

class MyComponent extends React.Component {
  state = { timer: 0 };

  // update state.timer every 1000 ms
  poll = () =>
    setInterval(
      () => this.setState((oldState) => ({ timer: oldState.timer + 1 })),
      1000
    );

  componentDidMount() {
    this.timer = poll();
  }

  componentWillUnmount() {
    clearInterval(this.timer);
  }

  render() {
    return <h1>{this.state.timer}</h1>;
  }
}

🔗When a prop is updated

class MyComponent extends React.Component {
  state = {results: [], loading: true}

  componentDidMount() {
      fetchNewResultsAndUpdateState(this.props.query);
  }
  componentDidUpdate(prevProps, prevState) {
    // query updated
    if (prevProps.query !== this.props.query) {
      fetchNewResultsAndUpdateState(this.props.query);
    }
  }
  render() {
    const {results,loading} = this.state;

    if (loading) return "Getting your results...";

    return (
      <>
        {results.map(result => <SearchResult result={result} key={result.id} />)}
      </>;
    )

  }
  async fetchNewResultsAndUpdateState = query => {
     this.setState({loading: true});
     const results = await getResults(query);
     this.setState({loading: false,results});
  }
}

There are several more lifecycle methods provided by React.Component, but I think these 3 are enough for you to build highly dynamic UIs that are memory safe. They're quite powerful and let you know achieve a lot of complex interactions.

However, remember I told how class based components are tightly coupled to the business logic and are hence quite verbose?

• Logic to call API whenever a component loads seems to be a generic problem, but due to the way React classes are designed, it's hard to abstract this out in a neat way. There are several advanced patterns like Render Props and Higher Order Functions to mitigate that. Each time you want to call an API on load of a component, you've to write this logic in one way or another.
• Since we can define componentDidMount, componentDidUpdate and componentWillUnmount only once, they'll keep the logic to call APIs, unsubscribe from intervals and subscriptions, clean up other resources in a one huge block. We can't really abstract it out as they're all interdependent. In our timer example, we need to rely on componentDidMount to set this.timer so that we can clear it in componentWillUnmount.
• The logic to check which prop has been updated can quickly become a mess if you've to listen to changes on multiple props. What we really want to do is "whenever props.query changes, do this" but what we're actually doing is "whenever component updates, check if it updated due to change in query, if that's the case, do this". Also, since componentDidUpdate isn't fired when component is loaded, we need to perform the call in componentDidMount as well.

🔗Functional Components

Now that we've seen the power of lifecycle methods, let's see how functional components achieve that with basically making use useEffect. As you can imagine, useEffect seems to be a hook doing a lot of heavy lifting, so let's spend some time understanding it before going through above use cases.

Let's first see the signature of useEffect.

// a function returning nothing
type CleanupType = () => void;
// a function returning a CleanupType function
type CallbackType = () => CleanupType;

// accepts CallbackType function and Dependency array, returns nothing
type UseEffectType = (CallbackType, Dependency[]) => void;

// example

useEffect(() => {
  doSomething(a);
  return () => doSomethingElse(a);
, [a]);

In above example, we are basically asking react to doSomething whenever a changes (dependency list tells react to listen to changes on that variable). And whenever a transitions from one value to another, before considering the new value, call doSomethingElse. This can be seen as an opportunity to do cleanup. Clear polling functions, unsubscribing event listeners, saving some state to storage etc.

An empty dependency list would imply whenever the component that has invoked this hook mounted and unmounted. If you omit the dependency list altogether, then you're essentially telling React to run your code on each render. You almost never want this.

function MyComponent() {
  useEffect(() => {
    doSomething();
  });

  // is loosely same as
  doSomething();
}

We can already see how the hooks aren't tied to the functional component that is invoking them, and that we can have multiple number of useEffects, just like useState. Lastly, it's just a function call, and multiple such useState and useEffect s could be hidden beneath one useComplexStuff hook call.

Let's go through the use-cases mentioned above but using functional components now.

🔗When a component loads

function MyComponent() {
  // unlike class components, each state variable is individually stored
  const [loading, setLoading] = useState(true);
  const [data, setData] = useState(null);

  useEffect(() => {
    callApi().then((data) => {
      setData(data);
      setLoading(false);
    });
  }, []);

  if (loading) return "Loading...";

  return <User data={data.user} />;
}

Please go through it and let me know if you've any questions. Try to absorb this API.

Now let's see if we can truly abstract out this logic to call API on component load.

// so smoll. much nice.
function MyComponent() {
  const [loading, data] = useUser();

  if (loading) return "Loading...";

  return <User data={data.user} />;
}

// but how do we implement useUser?
function useUser() {
  const [loading, setLoading] = useState(true);
  const [data, setData] = useState(null);

  useEffect(() => {
    callApi().then((data) => {
      setData(data);
      setLoading(false);
    });
  }, []);

  // this is the only extra line i've added to previous code.
  // It's basically copy paste refactoring
  return [loading, data];
}

🔗When a component is removed from tree

Remember how I said componentWillUnmount depends on variables set by componentDidMount. Well, in case of useEffect the cleanup function has access to all variables created by the effect part of the function. So that's convenient.

function MyComponent() {
  const [timer, setTimer] = useState(0);

  useEffect(() => {
    const interval = setInterval(() => setTimer((t) => t + 1), 1000);
    return () => clearInterval(interval);
  }, []);

  return <h1>{timer}</h1>;
}

And again, we can abstract this into a useInterval hook. These custom hooks are called, yup, custom hooks. Prefix them with a use so that it plays nicely with eslint-plugin-react-hooks.

function MyComponent() {
  const timer = useTimer(0);

  return <h1>{timer}</h1>;
}

function useTimer(defaultValue) {
  const [timer, setTimer] = useState(defaultValue);

  useEffect(() => {
    const interval = setInterval(() => setTimer((t) => t + 1), 1000);
    return () => clearInterval(interval);
  }, []);

  return timer;
}

I hope you're now convinced that hooks are really powerful and highly composable. Let's see the final use case now.

🔗When a prop is updated

function MyComponent(props) {
  const [results, setResults] = useState([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    setLoading(true);
    getResults(props.query).then((results) => {
      setResults(results);
      setLoading(false);
    });
  }, [props.query]);

  if (loading) return "Getting your results...";

  return (
    <>
      {results.map((result) => (
        <SearchResult result={result} key={result.id} />
      ))}
    </>
  );
}

You can see how just with one useEffect we can handle both mounting and updating stages. This makes our code less verbose and more declarative. Unlike class example, we're really asking react to get results whenever query updates.

You might have observed how I've not used async/await syntax within a useEffect yet. It's because the CallbackType isn't an async function and it's expecting a callback in return, not a promise. If you really want to use async await syntax, you should try doing this:

useEffect(() => {
  const fetchResults = async () => {
    setLoading(true);
    const results = await getResults(props.query);
    setResults(results);
    setLoading(false);
  };
  fetchResults();
}, [props.query]);

Now that we've seen enough hooks code, I think it's time to go through the Rules of Hooks. Yes, they seem to be magical, but there are some rules that we need to follow to ensure React doesn't end up minimizing into a point of singularity and breaking the universe as we know it.

1. Hooks must be only called from a React Functional Component or a custom hook. You can't use it in a normal business logic function, or a class based component.
2. Hooks must be at top level of wherever it's being called from. Basically, you can't use a hook inside a condition or loop.

Go through the documentation to understand more about this.

🔗Styling

So far you might have this style prop used on various components with an object with style related values in it.

<h1 style={{ color: "red", backgroundColor: "blue", marginRight: 10 }}></h1>

These are actually CSS style rules that React accepts for base components. Rules that have a hyphen are camel cased. So margin-right becomes marginRight. Also, you can pass numbers wherever applicable, px unit would be taken for those. So marginRight: 10 is same as margin-right: 10px;

Note: Unlike CSS you can't define pseudo classes like :hover or pseudo elements like ::after. You can achieve that by defining a CSS class outside of React and using it as className or using CSS-in-JS libraries like styled-components.

🔗React Native

Now that we've covered most of the basic fundamentals of ReactJS, let's see how React Native is different. In all our above examples, we're actually using ReactJS along with ReactDOM. It's the driver that knows what to do when we write a heading like follows.

<h1 style={{ color: "red" }}>Hello</h1>

It converts the h1 to respective HTML DOM element, and applies the styling to it. So we can see that ReactJS (class components, state, lifecycle, props, composability, hooks etc.) is actually host platform agnostic. It can run on any platform as long as you provide a driver for the same. On Native platforms, react-native does that. You can image that we can't use h1 and the like on native as they don't understand HTML. Instead, we've things like TextView on Android and UITextView on iOS and so on for all native UI elements. The driver takes care of mapping a <View style={{backgroundColor: 'red'}}></View> into a UIView object with background property set as "red" for iOS, likewise for Android.

So apart from using components like View Text TextInput Image etc in place of div span input img (respectively), the fundamentals remain the same. There's one more difference however, and that is styling:

• Just like native platforms don't understand HTML, they don't understand CSS either. Authors of React Native made Yoga a flexbox implementation along with a CSS rule subset to native styling translation layer for native platforms.
• Another thing is that unlike HTML where you can basically create any sort of hierarchy of elements, even if it doesn't make sense, React Native is more strict. Strings are only accepted by <Text/> and you can't place strings inside a <View />, similarly rules around text (color, fontSize etc) don't have any effect on a <View />. You need to assign it to the <Text /> directly.
• Also the API of style prop is slightly different. We'll cover it next.

🔗React Native Styling

Unlike react-dom, style prop is slightly different in the sense that it also accepts an array. It can also accept object created by StyleSheet.create

// react-dom
<div style={{margin: 10, backgroundColor: 'red'}} />

// react-native
<View style={{margin: 10, backgroundColor: 'red'}} />
// or
<View style={[{margin: 10}, {backgroundColor: 'red'}]} />
// or
const styles = StyleSheet.create({
  container: {margin: 10, backgroundColor: 'red'}
})
<View style={styles.container} />

🔗React Native Web

We've come full circle with React Native Web, which is basically a component library that has same API as react-native but is implemented with react-dom in mind. A view in react-native-web is essentially a <div /> . This might seem futile, however the power is that you can now write your code in React Native, and use it on web using react-native-web.

🔗Advanced Patterns

These are now not as important with advent of hooks, however it's still important once in a while in your daily job. You can ignore these for now and comeback later whenever you encounter one.

🔗Higher Order Components

Just like Higher Order Functions can accept a function and return a new one, High Order Components are functions that accept a component and return a new one. This can be used as a way to decorate a particular component with extra behavior.

Suppose we want to show a loader if loading prop is true, but we don't want to write this code for all components. We can create a withLoader higher order component to solve this.

function withLoader(Component) {
  return function LoaderContainer(props) {
    if (props.loading) return <Loader />;
    return <Component {...props} />;
  };
}

Now we can wrap our components with withLoader whenever we want to add this behavior.

// UserPage.js
class UserPage extends React.Component {
  ...
}

export default withLoader(UserPage);

// Home.js
function Home () {
  const [loading, data] = useUser();

  return <UserPage loading={loading} data={data} />;
}

Multiple such HOCs can be used to add behavior. react-redux actually exposes one popular HOC connect that lets you connect to the redux store.

There are some caveats though:

• Our React tree will now have a LoaderContainer above each component using this HOC.
• We can't add this behavior dynamically or conditionally, at build time we make the choice either to wrap a component in an HOC or not.
• Passing a ref won't give us ref of our Component, but rather of LoaderContainer. To mitigate this most developers usually manually connect a innerRef prop to the inner component.

function withLoader(Component) {
  return function LoaderContainer({ innerRef, ...props }) {
    if (props.loading) return <Loader />;
    return <Component ref={innerRef} {...props} />;
  };
}

• The static fields on the component won't be accessible from the enhanced component. Suppose UserPage has a MODES field so that you can choose which mode of UserPage you want to render. To mitigate this, you can hoist the non-react statics.

// UserPage.js
class UserPage extends React.Component {
  ...
  static MODES = {LITE: 0, NORMAL: 1};
}

export default withLoader(UserPage);

// Home.js
function Home () {
  const [loading, data] = useUser();

  // ❌ Won't work as withLoader doesn't expose the MODES static field.
  return <UserPage mode={UserPage.MODES.LITE} loading={loading} data={data} />;
}

🔗Render props

While HOCs are highly powerful, they have a lot of caveats that Render Props attempt to solve. Render props are just a fancy name given to a pattern in which makes use of the fact that children field (or any prop for that matter) of a component can actually be a function. Using this, we can put behavior in our Render Prop accepting Component and use it like any other React Component. This is in a way inversion of control, where you decide what you want to render. For an example, let's modify the first class based example of loading data on component load. This helps us extract the behavior out of our initial example and lets us reuse that logic wherever we want.

class UserDataFetcher extends React.Component {
  state = {loading: true, data: null}

  async componentDidMount () {
    const data = await callApi();
    this.setState({data, loading: false});
  }

  render() {
    const {loading, data} = this.state;
    return this.props.children(loading, data);
  }
}

function App () {
  return <UserDataFetcher>{(loading, data) => {
    return <UserPage loading={loading} data={data} />
   }}</WithUserData>
}

I guess you can see why this was so powerful in pre-hooks era.

🔗Optimizations

While React's internal architecture ensures app performance stays top-notch, there are some optimizations we can use to reduce load on user's system by avoiding large re-renders. See, each time reference of state or props of a component changes, React would re-render the component. This is how we achieve reactivity. However, React by default will make no checks and assumptions to see if the update prop or state is actually same as before.

function MyComponent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library version="1" />
    </>
  );
}

const Library = ({ version }) => {
  return <h1>The library version is {version}</h1>;
};

Whenever count state variable updates in MyComponent, MyComponent would re-render. And since it re-renders, it'll cause Library to re-render as well. React wouldn't check if version has actually changed or not. If you wish to avoid a re-render of Library, you can use React.memo

🔗React.memo

function MyComponent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library version="1" />
    </>
  );
}

const Library = React.memo(({ version }) => {
  return <h1>The library version is {version}</h1>;
});

React.memo will see if props passed to a functional component have been updated or not. It loops through all the keys in previous props and next props, and sees if they're referential-ly equal to each other. It accepts a second argument as well to explicit perform this check.

const Library = React.memo(
  ({ version }) => {
    return <h1>The library version is {version}</h1>;
  },
  (prevProps, nextProps) => prevProps.version === nextProps.version
);

Here we are telling React.memo that consider props to be equal if the 2nd argument returns true. So the function is anwering the question are props the same?

One thing to note is that React.memo checks for reference updates and not value update. The "reference" to any variable may change even though the "value" remains same.

let a = { version: 1 };

a = { version: 1 };

In the above code, by virtue of re-assignment, we've caused the reference of a to change, even though the value is identical. React doesn't care for the value, but the reference. This is why we can't mutate variables as React wouldn't be able to tell whether it has been updated or not. And such reassignments can happen a lot of times! Let's consider the following example now.

function MyComponent() {
  const [count, setCount] = useState(0);

  const libraryData = { version: "1" };
  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library data={libraryData} />
    </>
  );
}

const Library = ({ data: { version } }) => {
  return <h1>The library version is {version}</h1>;
};

Just like before, whenever the count state variable updates, MyComponent would re-render, due to which Library would re-render too. Even if we apply React.memo like before, it wouldn't help in this particular case.

function MyComponent() {
  const [count, setCount] = useState(0);

  const libraryData = { version: "1" };
  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library data={libraryData} />
    </>
  );
}

// ❌ Wouldn't work as reference of libraryData changes on each render
const Library = React.memo(({ data: { version } }) => {
  return <h1>The library version is {version}</h1>;
});

The reason for this is that we've passed an object literal, which would be created each time MyComponent updates. Same is true for functions that are created in-line.

function MyComponent() {
  const [count, setCount] = useState(0);

  const onClick = () => alert("You clicked!");

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library version="1" onClick={onClick} />
    </>
  );
}

// ❌ Wouldn't work as reference of onClick changes on each render
const Library = React.memo(({ version, onClick }) => {
  return <h1 onClick={onClick}>The library version is {version}</h1>;
});

Each time MyComponent updates, a new function is created for onClick prop of Library. This can be fixed by some of the following techniques:

1. Moving the said object/function outside of render of MyComponent
2. Somehow memozing the value between renders.
3. Updating the checks performed by React.memo to compare the value and not just reference.

For the first method, we can just move the object to global scope. This way the reference never changes.

const libraryData = { version: "1" };

function MyComponent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library data={libraryData} />
    </>
  );
}

// ✅ Works as reference of libraryData doesn't change
const Library = React.memo(({ data: { version } }) => {
  return <h1>The library version is {version}</h1>;
});

🔗useMemo & useCallback

Or you could update the way Library accepts version. Notice how earlier we were simply passing version as a prop instead of keeping it inside a data prop. Since reference to strings & numbers don't change, our usage of React.memo would work as expected. The insight here is that you can design the way your component accepts props to avoid such pit-falls of referential equality checks. But this might not work always as your data needs might be different.

function MyComponent() {
  const [count, setCount] = useState(0);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library version="1" />
    </>
  );
}

// ✅ Works as reference of strings doesn't change
const Library = React.memo(({ version }) => {
  return <h1>The library version is {version}</h1>;
});

Second method can help in that case. To memoize the value, in functional components we can use advanced hooks like React.useMemo & React.useCallback. Suppose we really need to pass version as a data object. We can ask React to memoize it between renders using useMemo. The second argument is a dependency array, just like useEffect. So here we are telling React to recompute libraryData whenver any item in the array passed as second argument changes. Empty array implies on component mount. So this way we can preserve the reference to libraryData

function MyComponent() {
  const [count, setCount] = useState(0);

  const libraryData = useMemo(() => ({ version: 1 }), []);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library data={libraryData} />
    </>
  );
}

// ✅ Works as reference of libraryData is now memoized.
const Library = React.memo(({ data: { version } }) => {
  return <h1>The library version is {version}</h1>;
});

useCallback is similar to useMemo, just that it returns a callable function instead. We can use this for functions.

function MyComponent() {
  const [count, setCount] = useState(0);

  const onClick = useCallback(() => alert("You clicked!"), []);

  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library version="1" onClick={onClick} />
    </>
  );
}

// ✅ Works as reference of onClick is now memoized.
const Library = React.memo(({ version, onClick }) => {
  return <h1 onClick={onClick}>The library version is {version}</h1>;
});

In fact, you can implement useCallback using useMemo as the latter works for any type of value.

const useCallback = (fn, dependencyArray) => useMemo(() => fn, dependencyArray);

The last method is to just change the way React.memo performs the check. Though this can go pretty nasty as the number of props increase and nesting of the keys increase. And there's no neat way to do it for functions.

function MyComponent() {
  const [count, setCount] = useState(0);

  const libraryData = { version: "1" };
  return (
    <>
      <button onClick={() => setCount((c) => c + 1)}>{count}</button>
      <Library data={libraryData} />
    </>
  );
}

// ✅ Works as we're now comparing individual key of object
const Library = React.memo(
  ({ data: { version } }) => {
    return <h1>The library version is {version}</h1>;
  },
  (prevProps, nextProps) => prevProps.data.version !== nextProps.data.version
);

NOTE: These are advanced optimizations and you should use them only if you've an actual performance regression. More often than not, the extra work done in these optimizations might give very little gains with the cost of code complexity and potential to introduce bugs. Each memoization technique described here requries extra computation (React.memo loops throught all props and checks their reference change), memory usage (To memoize is to store data) between renders, so the benefit would only come if the value you're trying to memozie is too expensive to calculate (some highly complicated data manipulation on an array of 1000 items) or the component you're planning to prevent re-renders for has a complicated deeply nested UI to render. In above cases it makes no sense as <h1 /> is fairly simple component and libraryData is a very small object. So unless you have a performance problem caused by re-renders, you shouldn't wrap variables in useMemo and components in React.memo

🔗React.PureComponent

React.memo and the hooks like useMemo and useCallback only work for functional components. What about class components?

Let's first take our above example to a class-y world.

class MyComponent extends React.Component {
  state = { count: 0 };

  render () {
   const libraryData = { version: "1" };
    return (
      <>
        <button
          onClick={() => this.setState(s => ({ count: s.count + 1 })}
        >
          {count}
        </button>
        <Library data={libraryData} />
      </>
    );
  }
}

class Library extends React.Component {
  render () {
    const { version } = this.props.data;
    return <h1>The library version is {version}</h1>;
  }
);

Class based components have access to a life cycle method shouldComponentUpdate. We can guess from the name that it's similar to the second argument of React.memo above.

class MyComponent extends React.Component {
  state = { count: 0 };

  render () {
   const libraryData = { version: "1" };
    return (
      <>
        <button
          onClick={() => this.setState(s => ({ count: s.count + 1 })}
        >
          {count}
        </button>
        <Library data={libraryData} />
      </>
    );
  }
}

class Library extends React.Component {
  shouldComponentUpdate(nextProps, nextState) {
    return this.props.data.version !== nextProps.data.version;
  }
  render () {
    const { version } = this.props.data;
    return <h1>The library version is {version}</h1>;
  }
);

It's different in two ways than React.memo. Firstly, it has access to nextState so we can add checks for state changes. This can be helpful if a key in this.state is an object or function and you can't determine whether a state update is needed whenever you set it. Secondly, it is expecting answer to should component update? and not are props the same?. Other than that it's pretty much the same. You can imagine writing it by hand and having a dozen of checks for a large component can be tedious and error-prone. If only we had a default behaviour of React.memo for classes. Enter React.PureComponent

Just like React.Component, React.PureComponent is another class you can extend from to create your component. It behaves just like a regular component, but has a shouldComponentUpdate lifecycle method implemented for you.

class MyComponent extends React.Component {
  state = { count: 0 };

  render () {
    return (
      <>
        <button
          onClick={() => this.setState(s => ({ count: s.count + 1 })}
        >
          {count}
        </button>
        <Library version="1" />
      </>
    );
  }
}

// ✅ Works as reference of this.props.version doesn't change as it's a string
class Library extends React.PureComponent {
  render () {
    const { version } = this.props;
    return <h1>The library version is {version}</h1>;
  }
);

And just like React.memo it would fail if the said prop is an object or function that updates in each render. However, we don't really have a simple way to memoize these variables like useMemo. You can instead define a class property to move it out of scope render method.

class MyComponent extends React.Component {
  state = { count: 0 };

  libraryData = { version: "1" };

  render () {
    return (
      <>
        <button
          onClick={() => this.setState(s => ({ count: s.count + 1 })}
        >
          {count}
        </button>
        <Library data={this.libraryData} />
      </>
    );
  }
}

class Library extends React.Component {
  render () {
    const { version } = this.props.data;
    return <h1>The library version is {version}</h1>;
  }
);

NOTE: Writing shouldComponentUpdate by hand can cause more harm if a bug in logic prevents component from re-rendering. Relying on PureComponent is preferred, however if the component is simple, a re-render might be as good as comparison checks before render.

🔗Preferences

I dislike macOS's fullscreen mode, so in order to get maximum screen real estate, I autohide menu bar and dock.

🔗Autohide menu bar

Refer to this article.

🔗Autohide dock & disable recent applications

I also like a clean setup, so I keep only essential items in the dock for quick access, for rest I use spotlight.

Refer to this article.

🔗Git default push to current branch

git config push.default current --global

🔗Oh My ZSH with Auto Suggest

Oh my ZSH

zsh-autosuggestions plugin

🔗Keyboard stuff

• Disable cmd+option+space for spotlight history (System Preferences -> Spotlight -> Keyboard Shortcuts)

Spotlight history is of no good use really, and that key combination can be utilized for a better purpose that we'll talk about later.

• Use Caps lock as Escape (System Preferences -> Keyboard -> Modifier Keys)

As a vim user, I'm used to keeping Caps Lock as Escape key.

• Turn on key repeating

# Open Terminal.app and past the following command.
defaults write -g ApplePressAndHoldEnabled -bool false

I don't know why this isn't the default behaviour. I don't have much use for macOS's character suggestions on holding a key.

🔗Expanded TouchBar

I prefer expanded touch bar over app specific touchbar. System Preferences > Keyboard > "Touch Bar shows" - Expanded Control Strip.

🔗Trackpad stuff

🔗Enable tap to click (System Preferences -> Trackpad)

I prefer tap over physical clicks.

🔗Increase cursor size (System Preferences -> Accessibility -> Display)

A big cursor is easier to find and makes things easy to move around.

• Enable dragging with three fingers (System Preferences -> Accessibility -> Trackpad -> Trackpad Options)
• Click and hold is worse experience in my opinion.

🔗Application stuff

🔗Configure spotlight to not index a lot of stuff.

In my setup, I don't need use spotlight to open files, so indexing them (cough node_modules cough) is unnecessary waste of resources.

🔗Install Rectangle

This window management utility works with newer versions of macOS (even though now macOS supports tiling, it still sucks). Configure it to use cmd+option+arrow-key for top/left/right/bottom and cmd+option+space for maximize

🔗Install Maccy

Clipboard management of my choice. I've started accepting the default options for my peace of mind.

🔗dot-files

If you're interested in my dot-files, you can view them here.

Recall the days when you were just introduced to git or a similar type of version control system. I’m guessing you must have faced some friction initially, how it breaks your flow, how you just can’t merge to master without rebasing/merging changes in first.

Despite that, you might agree today that it’s actually very helpful in collaborating with the team, and those pain points were necessary to get here.

Monorepos are somewhat similar.

While git was solving problems around managing single codebase with multiple team members or just better versioning, Monorepo kind of does the same but for multiple projects/codebases.

🔗The what.

Is Monorepo that cool font I see on Twitter?

Before diving into the topic, let’s first understand what Monorepo truly means. This is what Wikipedia has to say:

In revision control systems, a Monorepo is a software development strategy where code for many projects are stored in the same repository.

In other words, your ‘Work’ folder is close to what a Monorepo would look like. It would have packages that deal with server, web app, native app, documentation, etc.

This is different from a ‘monolith’ where all your application logic is
centralized to one entry point as opposed to distributed services (microservices).

While code for various services would sit in a single repository, it doesn’t mean it would be deployed as a single entity, just like your ‘Work’ folder. Individual projects have separate life-cycles.

🔗The why.

So, do I just git add my entire ‘Work’ folder?

“Why would you want to do this? Whatever happened to separation of concern?”

There are several arguments both in favour and against Monorepos. And I don’t mean “Oh Google uses it” kind of arguments. This blog will give a sneak-peek into our problems and Monorepo’s solutions to them.

Regardless, I recommend that you identify the problems your codebase is facing, and see if Monorepo is truly the answer to those.

🔗The story.

Before moving to Monorepo, we as a team worked on 3 codebases at the same time;

• dweb (Desktop website of Swiggy)
• mweb (Mobile website of Swiggy)
• service (API proxy NodeJS middleware, used by dweb and mweb)

When I say work, I mean writing features, updating build pipeline, reviewing code and fixing bugs.

As the codebases grew, we recognized some patterns:

• Features written on mweb, while dissimilar enough to not to be dragged and dropped to dweb, held enough similarities to be broken into reusable parts.
• Fixes that go on mweb are also needed on dweb.
• Code reviewers often ended up reviewing the same code (between mweb and dweb) in a slightly different context.
• Code review changes on dweb are also relevant to mweb
• Changes to contracts of service, a common dependency, are also needed to be individually coded, tested, and reviewed.
• Updating dependencies like React/Webpack/Babel becomes cumbersome between the two codebases.
• Conventions are difficult to enforce between the three repositories. One has an older version of ESLint, one hasn’t been updated when new lint rules were added, one is still using old test runner.
• Attempts to make a new repository to keep common code failed due to the amount of setup and code management. Imagine working with multiple team members on multiple repositories with multiple Pull Requests.

As you can see, while the projects are very different (check out swiggy.com on your desktop and mobile to realize that), they still have quite a lot of common code interactions.

Bike-shedding: Have you tried Swiggy website on your desktop or mobile browser? We would love to hear your feedback!

🔗The how.

https://lerna.js.org/

Depending on your ecosystem, there will be different tools to help you with maintaining a Monorepo. You can obviously go vanilla and just use different folders per project. We use Lerna for maintaining our JavaScript codebase.

Thanks to its community, there’s a lot of documentation and help for Lerna related queries.

# Install lerna globally
npm i -g lerna

# Change directory to your work folder
cd ~/Work

# Make the folder you want to keep your monorepo in
mkdir portal-web

# Change directory to monorepo folder
cd portal-web

# Initialize lerna (it will handle `git init`)
lerna init

# Commit the changes
git add . && git commit -m "Initial commit"

# Import other packages (https://github.com/lerna/lerna/tree/master/commands/import)
lerna import ~/Work/portal-mweb

# That's pretty much it!

# Fun fact: If you want to rename your package, simply rename the folder before importing.
# Fun fact 2: You might need to flatten out the commits in most cases (https://github.com/lerna/lerna/tree/master/commands/import#--flatten)

You may use above scripts to import existing repositories to a lerna based monorepo.

Running scripts from the root has been made simpler using these handy npm scripts.

These scripts allow for convenient way to invoke package scripts from root folder

Since our packages are hosted in internal npm registry, we inject a .npmrc in our Jenkins build the pipeline to avoid committing the authToken.

A script to find all scoped dependencies of a project

# Install monorepo dependencies from internal npm registry
npm i `../../scripts/scope-packages.js @portal`

# Fun fact:
# `npm i <package-name>` would also install other dependencies if they aren't present in node_modules,
# along with the mentioned <package-name>

# Fun fact 2:
# In presence of package-lock.json, `npm i` would use those version numbers instead of fetching the latest ones
# This essentially makes it a hybrid of `npm i` and `npm ci`

One interesting thing about Lerna is that it doesn’t want private packages to be part of the package-lock.json. This means we can’t just simply use npm ci. We use this bash script to get past that.

🔗The happy part.

Within a few months of making this change, we tippled the number of packages in our Monorepo. We also saw much more work done on the linting front, leading to a more consistent codebase.

The linter is common to entire Monorepo, and each new rule affects all the packages.

• config (webpack config as a package, reused by mweb and dweb)
• ui (a package to create common patterns of design to be used in mobile and desktop, thus enabling us to work on creating a Swiggy’s design system)
• payments (a package of Swiggy’s payments page, used by multiple tenants)
• reviews (a package of Swiggy’s Ratings and Reviews page and components, used by mweb and dweb)
• helpers (a package of common reusable logic, something like lodash)
• daily (swiggydaily.com, reuses 2 components from mweb)
• cache (a caching module used by mweb and dweb)
• restaurant-url (a restaurant slug generator, multiple tenants)

I think that giving the option to easily create a new package incentivizes developers to think in more modular terms. They don’t think in the context of an app but rather in a more general way.

It also discourages them from touching modules that are used by multiple tenants, and use semantic versioning appropriately.

The benefits we are seeing out of this are just amazing:

• Writing the same fix for dweb and mweb is faster, as it’s just one commit.
• No more npm link mess.
• Reviewing a fix for both dweb and mweb is faster, as it’s just one Pull Request on one repository by one team member.
• Reusing and updating build pipeline is much more seamless.
• Updating major dependencies/lint rules is super easy.
• The collocation of code encourages developers to copy-paste less and reuse more.
• Writing reusable modules becomes easier, leading to better software engineering.

🔗The sad part.

But it ain’t all fun. Our PR section is a bit noisier. It’s not like we’re somehow writing more code, but that changes to any package comes to spotlight and doesn’t get silently updated.

• Too many packages lead to longer bootstrap times.
• Leveraging the benefits of Monorepo takes time.
• The code navigation is slightly slower. Developers are now opening individual packages to work around that.

Update: There’s one more point I would like to touch upon. Our approach currently colocates applications with libraries. ‘mweb’ is a private package in the sense it isn’t published to our npm registry, however ‘ui’ is a public package that can be consumed by mulitple tenants. This leads to heterogeneity in the monorepo. We are okay with this mix as

• it reduces friction of local development (no npm links).
• colocation leads to easy refactors and library creations.
• code review is simpler when it’s all one repository.

🔗The verdict.

So far we’re seeing Monorepo architecture a better fit for our growing codebase and team. It also impacts the way we design new libraries and components, often promoting clearer separations of concerns.

Should you use monorepo? Like all things, it depends on TM! I hope this blog gave enough insight to you as to why we started using a Monorepo, and how it’s benefiting us.

DISCLAIMER: We don’t advocate for any of the tools, libraries, coding practices or software development philosophies mentioned here. You are welcome to read, learn, accept, reject and critique however you see fit.

With growing mobile usage, performance and leanness (yeah, that’s a word) is becoming top priority for web apps. Oddly enough, sharing has never worked out well for web, until now (hopefully).

🔗History time

Since the social network explosion, ad revenue on page views and obsession with digg-ing websites, social sharing “widgets” have polluted our browsing experience with numerous flaws:

• They came with a dozen of JavaScript SDK files for every-single-social-network.
• They were usually “sticky”, because that’s so cool.
• They were hard to style, always looking pretty off from your website’s look and feel.
• They almost always lacked one social network which was big in your region or for your audience.

All these flaws became more prominent with rise of smartphones. SDKs burdened (and still do) the network and CPU, “sticky” widgets janked scrolling, and became unsurprisingly very annoying at smaller resolutions (like they weren’t otherwise). And they certainly weren’t meant for everyone.

While solutions like lazy-loading and simpler designs helped a lot, it still is a painful job to find the right widget for your website, tweak it till the point it isn’t an eye-sore, only to find out that the users aren’t digg-ing it anymore (shameless pun-intended), and want to share it on XYZ messenger, which doesn’t have an intent URL yet.

1990s called and it wants you to reply back.

Sadly, browsers haven’t cared enough to innovate much in this space lately. There were several attempts by Mozilla, Chrome and even Windows 8. While they still let you “email” your website on Desktop, and share to your favorite app on mobile, but that’s about it. Developer has no control over the shared title, content or the URL, which is a bigger problem when we talk about SPAs with fancy URLs.

🔗tl;dr

And this changes with Web Share API. Wow, that’s quite a lot of build up for a simple API, isn’t it ? But this API is remarkable !

And that’s it ! In order to use it, you need to meet following conditions though:

Your site must be served over HTTPS.

You can only invoke the API in response to a user action, such as a click (e.g., you can’t call navigator.share as part of the page load).

You can also share any URL, not just URLs under your website’s current scope: and you may also share text without a URL.

You should feature-detect it in case it’s not available on your users’ platform (e.g., via 'share' in navigator)

The API is still a proposal, however it’s implemented in Chrome 61, which is the latest stable version at time of writing. Which means, in next 6 weeks, this API would be available on almost every other Android phone. If you’re still not sold and think intents are the way to go, you can head over to the FAQ section of the proposal to learn about some decent arguments.

The awesome PWA of Twitter already uses

🔗Future

Did I say that’s it? Because that isn’t it yet.

• The share data (title, url and text presently) isn’t just limited to current set. There would be additions to it in future, image being one for example.
• There’s a sibling API, Web Share Target, which allows a PWA to be listed in the native app share drawer. This brings web apps way closer to the native experience. Learn more about that proposal here.

🔗Contribute

So start adding support to this awesome API right now, and if you would like to have this API well supported please follow/vote/share/contribute to the bug numbers I’m listing below;

• Firefox Bug 1402369
• Webkit Bug 171100
• Edge User Voice

So coming to my story, I didn’t quite intend to lose weight, or follow any diet, or did a rigorous workout. I believe that it’s basically the result of negative-feedback in my brain. Sounds weird right? I’ll explain.

🔗Before

I’ll first go through initial state variables;

• Age: 22 years and 9 months
• Weight: 87 kilograms | 191 pounds
• Height: 174 centimeters | 5 feet 8.5 inches
• Waist: 91 centimeters | 36 inches
• BMI: 28.7 (Overweight, 4 kilograms from being obese)
• Waist to Height: 0.52 (Males at increased risk)
• Vegetarian? ✔
• Very low sugar intake? ✔
• Significant workout throughout the day? ✗

Depending on where you come from, this might not look bad enough, and which was the exact attitude that kept me from doing anything significant about it (and I never did!). I tried the gym, but I always felt it wasn’t quite a sustainable solution, I wanted something that I could do in my daily routine.

It’s like, you can starve for 2 months and lose plenty, but that one day when you decide to eat something good, you just lose your control. Similarly, you might work out well for 2 months, but a long vacation to grandma’s might be enough to make you lousy again. These are very fragile methods in my opinion, for my sort of lifestyle in which work, commute, *cough* Netflix take most of the time.

🔗The Change

So what started the chain of events was this app called Google Fit. It’s a basic fitness app that uses your phone sensors to calculate steps/calories burnt/distance covered. That’s pretty much it.

23rd of February is when I installed the app, though it took 3 days to get me to work on my goal.

Annnnd I forgot about it for three days. I opened it one day to see that I actually completed the goal of 10,000 steps on a Saturday when I went for a walk by the lake. That was easy! What I also observed was that I roughly burnt 1,700 ~ 2,000 calories by doing nothing throughout the day. Even if the data isn’t accurate, the sensor and environment conditions remain the same, making it a reliable way to observe variations and not the absolute values.

My brain was intrigued by these numbers. It’s almost how you add hashtags to Instagram posts to get more likes, and once you do get more, you overdo it, and the cycle continues. Just that, here you get likes from health!

VERY TECHNICAL. MUCH SCIENCE.

So the first thing I did was that I reduced the goal to 9,000 steps to make myself feel better. And every week I increased it by 500–1000 steps as and when I started getting a good rhythm.

The other thing that I did was that I took interest in knowing calories of things I ate daily. By learning that a spoon of oil has as many calories as a bowl of corn flakes, which in turn has as many calories as a can of cola, I somehow started making food at home to avoid the extra cheese/butter/oil the chefs put in.

Remember, one is a breakfast, one is a drink with a snack, and other is added to your lunch just like that!

Again, didn’t intend to, it’s just my brain trying to optimize calorie intake.

Not only I became more aware of the calories that I put it, I also started reducing them by simply cooking at home with better alternatives.

This number was insightful in an indirect way. Knowing that I was burning say 2000 calories daily, by ensuring low-calorie diet (without compromises), and burning more than the usual 2000, there was no way for me to not lose weight. And I did.

MILLIONS OF CALORIES

Losing weight is really no rocket-science. Either take in lesser calories or burn more than you eat or BOTH!

Adding to these two numbers, I also bought a nice digital weighing scale, only to get depressed every morning, which again helped me complete those extra 500 steps or choose fruits overs chips for snacks.

So to summarize, all I did was;

• Ensure I complete my steps daily, and increase them ever-so-slightly every week. I stopped increasing beyond 15,000 steps though.
• Count calories of random food that I regularly ate, and replaced with better non-processed alternatives.
• Eat out less often.
• Check my weight regularly. The more aware I became of how previous day’s activity resulted in lower weight, the more my brain took it as a reward and probably released Oxytocin to give a sense of contentment and incompleteness at the same time. Negative feedback.

🔗The Results

• Age: 23 years and 1 month
• Weight: 72 kilograms | 158.7 pounds
• Height: 174 centimeters | 5 feet 8.5 inches
• Waist: 84 centimeters | 33 inches
• BMI: 23.8 (Normal weight, 4 kilograms from being overweight)
• Waist to Height: 0.48 (OK)
• Pseudo-Vegan? ✔
• Very low sugar intake? ✔
• Significant workout throughout the day? ✔

🔗Conclusion

I basically lost roughly 1 kilogram a week. At the same time I also went to grandma’s house (= fat rich food), ate out and ate heavy items (= too many calories), and even fall ill (= very little walk). I simply increased my steps for those days or did extra steps later. Basically, I didn’t change my lifestyle at all, apart from dedicating 2–3 hours to walk and cooking daily.

I meet my goals daily, and compensate whenever I eat outside.

So by minor changes in my lifestyle, I found myself becoming less lethargic, which only helped me improve it more and more. I could work for long hours, walk for 2 hours, then cook food and still feel active!

Over time, I also found myself leaning towards a vegan diet. Watching Cowspiracy and What the Health helped me with it greatly. I still have milk in coffee (creamer as it’s called in the west) & ice creams on some days though. Still working on it. YouTube Channels like Raw. Vegan. Not Gross & Cheap Lazy Vegan help me a lot with non-dairy experiments. It’s simply unavailability of vegan alternatives in India that make me lose to coffee creamer.

Some clarifications I want to make here;

• I didn’t starve. I just ate better alternatives. I still had plenty of cheat days, but with reduced quantities and compensation for same.
• I didn’t exhaust myself. Walking is the most basic exercise which is good for general health and doesn’t quite focus on any one body part. I lost weight not only from my calves & thighs, but also from my face, arms, and waist. I also did push-ups to ensure muscle growth in torso region.
• Girls are still not interested in me. Sigh.
• Men on other hand compliment, saying I’ve become leaner. PROFIT???

As always, it worked for me, but might not work for you. However, I’ve seen people reduce weight just by, say, getting rid of sugar, or meat, or dairy. In my case, these were already pretty much absent. Apparently, dieting wasn’t enough to pull this off alone, which is why I believe basic exercise like walking together with a better diet helped me overall. My advice would be to not look at long term gains, but to compare between days and weeks.

My quest is still on. I intend to sit in the middle of the ideal BMI range, and also improve on my Vegan skills.

Here’s a before (Feb 2017, 87kg | 192lb) & after (Oct 2017, 69kg | 152 lb) picture.

Update Nov 2017: I lost even more weight since the time I posted this blog, about 3–4 kgs (6.6–8.8 lbs). And I also turned full vegan.

PS:

• BMI and other such metrics have flaws. Don’t be too serious about them.
• Losing weight doesn’t always mean better health. Consult a dietitian or whatever.
• Feel free to analyze my case & give remarks.

Update Oct 2017: Since the release of v2 (March 2017), we saw a 9.3x increase in our monthly active users (~8k to 75k). We also observed 35% jump in the rating. Thank you so much for using & liking our extension, stay tuned for more updates!

Today we are very glad to release the much awaited version 2 of our Chrome Extension. Install it today to sync bookmarks across your Chrome browser on PC and Samsung Internet.

The Samsung Internet extension, earlier known as Samsung Sync (v1.4), not only sports a new name but also comes with tonnes of features and a massive UI overhaul. I’ll walk-through the new additions in the article.

Drastic improvements to first-sync performance.

First-sync performance was the number one complaint in our web store reviews, usually leaving users to never actually getting around to use our extension. We hit the heart of the issue with a dagger by rewriting several modules and chaining network requests, database queries and DOM updates in a much more optimized manner. With this release, you can now not only see the progress of sync, but also the fetched bookmarks as and when they arrive. We feel this will solve the top complaint and allow users to enjoy the extension.

Consistent UI with Samsung Internet on Android.

We are proud of our UX team’s efforts in offering a very modern look and feel to the extension. The small 600 x 400 screen real estate makes it much harder to add features while keeping the interface user-friendly. After several iterations, I think we’ve pretty much nailed it. From a progress bar to show sync status to modals for bookmark management, the UI even though offering several functionalities doesn’t overwhelm the user.

Live loading of bookmarks, top requested feature.

Enhanced bookmark management.

The previous version (1.4) was bit limiting in the sense users could only edit title or delete a bookmark. We felt that the extension can offer much more than that and with today’s release, not only basic create / update / delete / move is supported, but users can also import Chrome bookmarks into their Samsung account. We feel that this brings the control back to the user.

Improved Bookmark Management

And much more…

The feature list just doesn’t stop here ! Some of the other miscellaneous changes:

• Context menu support to bookmark current tab with a single click.
  Pro tip: You can use Ctrl/Cmd + Shift + Y combination to bookmark instantly.
• Improved internationalization for supported languages.
• Improved keyboard accessibility, you can tab your way through all items.

Update April 2017: Version 2.0.5 is now released to Chrome Web Store that fixes login related issues faced by certain users with the previous version (2.0.3).

Let us know if you run into issues, or just want to give us some feedback. We’ll follow up soon with our plans for releasing the extension for other browsers. Make sure you follow Samsung Internet Developers on twitter.

Note: The Sync functionality is only available for phones logged in with a Samsung Account on a stable release of Samsung Internet, which means that it won’t work with Samsung Internet Beta (v5.4) on non-samsung phones, just yet.

🔗Me

A Sikh Male rocking sick beard with a Punjabi Turban, and Orange Gaatra that holds a long Kirpan.

I’m a Sikh male who graduated from NSIT, New Delhi in Computer Engineering discipline in 2016. Before starting off my engineering career, I’d developed horrible Visual Basic applications and knew exactly what I wanted to do in my life; create stupid UIs with no knowledge of design. After joining the college, I made a very sane unintentional decision of learning JavaScript to make websites/webapps. Back then, JavaScript wasn’t even looked upon as a serious language, NodeJS was in its baby years of popularity, and using jQuery was cool. But I don’t know why, I kept coding in it. And this very thing and some luck landed me up in a summer internship at Samsung R&D Institute, Bangalore where I worked on a NodeJS project. And that lead me to,,, wait, I need to start a Samsung heading.

🔗Samsung

Samsung Digital City, Suwon

Yeah, so that lead me to a full time job at SRIB, which again lead me to Suwon, the place where HQ of Samsung Electronics resides. I’m part of Web Team in SRIB, that is also responsible for Samsung Internet, and I am currently overhauling the Samsung Sync extension. Expect a major update soon!

It’s funny how the ship of JavaScript sailed me across from one island to another. And now, I’m typing this from Suwon as my last week of business trip is about to start.

I love the wide range of technologies that exist within Samsung Electronics. This provides a great canvas for freshers to try and experiment with all domains without having to switch jobs.

🔗Korea

This last week has brought several memories of this 2 month stay in Korea, which in turn encouraged me to write this post on a Sunday evening.

Somewhere in Suwon

The country is amazing, it’s a developed nation, which is a thing a citizen of a developing nation would observe first. The racial and social security is really great here, in contrast to west where Islamophobia is a big deal. And the people are really humble. I love how everyone greets you and bows down a little, they take out time to wish you well, and that’s heart warming for a foreigner.

Hotel staff at DreamVill

I was lucky enough to witness both falls; fall fall and first snowfall, former being a phenomenon that doesn’t really exist in India.

Fall Leaves

Snow Falls

However, as a vegetarian I found myself at great discomfort in finding food outside DreamVill that serves Indian cuisine. So for vegetarian/vegan visitors, please bring some packaged food if you’re planning a long visit.

Hwaseong Fortress]

Imagee of Hwaseong Fortress

Some places like Paris Baguette, Tous Les Jours etc. are good to look for vegan/vegetarian bread or salad sandwiches. If you’re lucky enough, you can find meat-free salads at bakeries and eateries of the like however.

Early Christmas Decorations in Seoul

There are various tourist places that you can visit, though I primarily remained near the city. As a Sikh, it was pleasant surprise to find a Gurdwara in the country however. Run by primarily the Punjabi community, the Gurdwara is well maintained and open to all. I visited it during lunch time and it was lovely to find everyone enjoying Langar together on a Sunday noon.

Gurdwara Shri Singh Sabha Sahib

🔗Closing Note

So as I begin packing for my return flight to India, I wish to thank every Korean that has helped me find my way and replied with an arm cross to my search of vegetarian food. Your country is amazing, and I definitely wish to visit it again, hopefully after learning Korean. Gamsahamnida :)

Stick around to see more random blog posts from this idiot.