Dani Akash’s Blog

Minimum Release Age is an Underrated Supply Chain Defense

Mon, 30 Mar 2026 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

On March 31, 2026, axios got compromised.

Axios, the HTTP library that lives in basically every JavaScript project on the planet. Someone stole a maintainer's npm token, published two poisoned versions, and within 2 seconds of running npm install, a cross-platform RAT was phoning home to a command-and-control server. macOS, Windows, Linux. All of them. The malicious code even deleted itself after execution and swapped its own package.json to cover its tracks.

100 million weekly downloads. Present in 80% of cloud environments. And the poisoned versions were live for about 4 hours before npm pulled them.

Here's the thing though. My default package policy would have rejected those compromised versions. Not because of any fancy scanning tool, but because of one line in my config:

# ~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # 7 days in seconds

My package manager simply refuses to install any package version that was published less than 7 days ago. By the time 7 days pass, compromised versions like those axios releases are long gone. Detected, reported, and yanked from the registry.

One line. No scanning tools. No enterprise subscription. Just... patience.

<PostImage src="/supply-chain-security/hour-glass.jpg" alt="hourglass-on-stones"> Photo by Aron Visuals on Unsplash </PostImage>

How well does this actually work?

I got curious. If a 7-day delay would have filtered out the axios compromise, how many other attacks would it have caught?

So I went through 21 widely discussed supply chain incidents from the last 8 years, from the SolarWinds breach in December 2020 to the March 2026 axios compromise. For each one, I looked at the exposure window: how long was the malicious code live before someone caught it and pulled it down?

Here's what I found:

Attack	Exposure Window	7-Day Delay?
Axios (Mar 2026)	~4 hours	Would have blocked
Trivy-Action (Mar 2026)	~12 hours	Would have blocked
Nx / S1ngularity (Aug 2025)	~1 day	Would have blocked
Gluestack / React Native ARIA (Jun 2025)	~days	Would have blocked
tj-actions/changed-files (Mar 2025)	~3 days	Would have blocked
reviewdog/action-setup (Mar 2025)	~2 hours	Would have blocked
Ultralytics YOLO (Dec 2024)	~1-2 days	Would have blocked
Solana web3.js (Dec 2024)	~5 hours	Would have blocked
Polyfill.io (Jun 2024)	~4 months	Not helped
XZ Utils (Mar 2024)	2+ years	Not helped
Ledger Connect Kit (Dec 2023)	~5 hours	Would have blocked
3CX (Mar 2023)	Weeks	Not helped
PyTorch torchtriton (Dec 2022)	~5 days	Would have blocked
node-ipc (Mar 2022)	Weeks+	Not helped
colors/faker (Jan 2022)	Days to weeks	Reduced window
Log4Shell (Dec 2021)	N/A (vulnerability, not injection)	Not helped
ua-parser-js (Oct 2021)	~4 hours	Would have blocked
Codecov (Apr 2021)	~2 months	Not helped
Dependency Confusion (Feb 2021)	Varied	Reduced window
SolarWinds (Dec 2020)	~9 months	Not helped
event-stream (Nov 2018)	~2 months	Not helped

In this sample, a 7-day release-age gate would likely have blocked installs in 11 short-lived malicious publish cases, while doing little against long-running infiltrations, maintainer sabotage, or build-system compromises. Two more incidents would have had a narrowed exposure window.

A note on methodology

This isn't a controlled study. It's a survey of 21 incidents that were widely reported across security advisories, CISA alerts, and vendor blogs between 2018 and 2026. I picked them because they're the ones developers are most likely to have heard of.

"Exposure window" means the time between the malicious version being published and it being removed or flagged by the registry. I classified an attack as "would have blocked" if the compromised release was yanked within 7 days, meaning a release-age policy would have filtered it out during normal install or update resolution. "Not helped" means the attack either persisted longer than 7 days, wasn't a registry package at all, or was a vulnerability in legitimate code rather than a malicious injection.

The sample deliberately includes non-registry incidents (SolarWinds, 3CX, Polyfill.io, Codecov) and a pure vulnerability (Log4Shell) for completeness. These inflate the denominator against the release-age policy. If you only look at malicious package publish attacks, the hit rate is higher.

Why does this work so well?

Most malicious package attacks follow the same playbook. An attacker steals a maintainer's credentials (phishing, leaked tokens, compromised CI), publishes a malicious version, and then it's a race. The community notices something weird. Security tools flag it. The registry pulls the package.

This whole cycle, from poison to cleanup, almost always completes within hours to days. The axios attack lasted 4 hours. Solana web3.js was 5 hours. ua-parser-js was 4 hours. Ledger Connect Kit was 5 hours.

These are smash-and-grab operations. The attacker knows the clock is ticking.

A 7-day delay means you're always installing packages that have already survived a week of community scrutiny. If something was malicious, it's been caught and removed. You never even see it.

Think of it like this. You're not the first person to walk through the door. You're letting thousands of other developers go first. If the floor is trapped, someone else will find out before you step on it.

When this helps, and when it's annoying

Before I get into the setup, some honest caveats. This isn't a universal fix.

It works best when:

You regularly update dependencies (the delay applies during resolution, so it catches you at install and update time)
You use semver ranges (^ or ~) where your package manager resolves the latest matching version
You're pulling from public registries where the community is actively watching for compromises

It's less relevant when:

You rely entirely on pinned lockfiles and only update on a deliberate schedule (though the delay still protects you at update time)
You publish and consume your own internal packages (you'll want an allowlist/bypass for those)
You need emergency security patches immediately (all tools that support this also support a bypass for exactly this reason)

It's not a substitute for:

Lockfiles and npm ci / pnpm install --frozen-lockfile
--ignore-scripts in CI/CD to block postinstall hooks
SHA-pinned GitHub Actions
Provenance verification and artifact attestations
Behavioral analysis tools like Socket.dev

Think of release-age as one layer in defense-in-depth. It happens to be the layer that's trivially easy to add and surprisingly effective against the most common attack pattern.

So how do I set this up?

Here's where it gets both exciting and slightly absurd. Most major JavaScript package managers now support this. But they couldn't agree on a name. Or a unit. Or anything really.

Bun (seconds):

# bunfig.toml
[install]
minimumReleaseAge = 604800

npm (v11.10+, days):

# .npmrc
min-release-age=7

pnpm (v10.16+, minutes):

# pnpm-workspace.yaml
minimumReleaseAge: 10080

Yarn 4 (v4.10+, duration string):

# .yarnrc.yml
npmMinimalAgeGate: "7d"

Same concept. Four different config names. Four different units. minimumReleaseAge, min-release-age, minimumReleaseAge (again but in minutes this time), npmMinimalAgeGate. Seconds, days, minutes, duration strings.

I wish I was making this up.

Beyond JavaScript

The Python ecosystem has caught on too.

uv (v0.9.17+):

# pyproject.toml
[tool.uv]
exclude-newer = "7d"

pip (v26.0+):

pip install --uploaded-prior-to=2026-03-24T00:00:00Z package-name

pip only supports absolute timestamps though, not relative durations. So you'd have to update the date manually each time. Not ideal.

Deno has it as a CLI flag:

deno update --minimum-dependency-age=7d

Cargo (Rust) has an experimental unstable flag, and there's a third-party tool called cargo-cooldown.

Go, Maven, Gradle, Composer, Bundler? Nothing. No support. No proposals for some of them. If you're in the Java, Go, or PHP ecosystems, you're out of luck at the package manager level.

Don't forget your dependency bots

If you use Renovate or Dependabot to keep dependencies up to date, they have their own delay mechanisms:

Renovate:

{
  "minimumReleaseAge": "7 days",
  "packageRules": [
    {
      "matchPackageNames": ["*"],
      "minimumReleaseAge": "14 days"
    }
  ]
}

Dependabot:

# .github/dependabot.yml
cooldown:
  default-days: 7
  semver-major-days: 14
  semver-minor-days: 7
  semver-patch-days: 3

Both of them bypass the delay for security updates, which is the right call. If a CVE patch drops, you want it immediately.

What this doesn't catch

8 out of 21 incidents in my sample wouldn't have been helped by a release age policy. These fall into a few distinct categories:

Long-running infiltrations. The XZ Utils backdoor was planted by someone who spent 2 years building trust as a maintainer. The event-stream attack took 2 months to discover. When the attacker is patient enough to wait, a 7-day hold doesn't help.

Maintainer sabotage. When the legitimate owner of colors.js decided to break it in protest, or when node-ipc's maintainer added code that wiped files on Russian machines, no delay would have caught that. The maintainer IS the trusted party.

Build system compromises. SolarWinds and 3CX weren't attacks on package registries. The malware was injected during the build process of proprietary software. No package manager config can help there.

CDN and infrastructure attacks. Polyfill.io was a domain takeover. Codecov was a modified bash script on their own servers. These aren't registry packages at all.

Vulnerabilities in legitimate code. Log4Shell was a bug in a real library that had been there since 2013. The release wasn't malicious. The code was just broken.

For these categories, you need different tools: lockfile pinning, behavioral analysis from tools like Socket.dev, SBOM generation, SHA-pinned GitHub Actions, and reproducible builds.

Half the ecosystem is still unprotected

JavaScript and Python developers can set this up today. But if you're writing Go, Java, PHP, or Ruby? You're out of luck.

Ecosystem	Support
npm, pnpm, Yarn 4, Bun, Deno	Full support
uv, pip	Supported (pip is clunky)
Cargo (Rust)	Experimental / third-party
RubyGems	Community registry beta only
Go modules	Nothing
Maven / Gradle	Nothing
Composer	Nothing

Go doesn't even have an open proposal. Maven and Gradle have no known discussions. Composer has a feature request sitting in the repo. These are ecosystems powering massive production infrastructure, and they have zero built-in protection against the most common attack pattern in supply chain security.

If you maintain a package manager that's missing from the "supported" list, this is the feature request to prioritize. Not another scanning integration. Not another attestation spec. A simple, configurable delay on fresh packages.

Can we at least agree on a name?

Even among the tools that support this, the naming situation is genuinely painful:

Tool	Config	Unit
Bun	`minimumReleaseAge`	seconds
pnpm	`minimumReleaseAge`	minutes
npm	`min-release-age`	days
Yarn 4	`npmMinimalAgeGate`	duration string
uv	`exclude-newer`	duration / absolute date
pip	`--uploaded-prior-to`	absolute timestamp
Renovate	`minimumReleaseAge`	duration string
Dependabot	`cooldown`	days

Bun and pnpm use the same config name but different units. npm uses the same concept but kebab-case. Yarn went with npmMinimalAgeGate for some reason. pip requires you to manually calculate a date instead of just saying "7 days."

If you're configuring this across a polyglot monorepo, you have to mentally convert between seconds, minutes, days, and duration strings. For the same feature. That does the same thing.

There's room for a lightweight spec here. Even just an informal convention. Call it minimumReleaseAge, use ISO 8601 durations or plain day counts, and move on.

Why isn't this the default?

npm actually has an open proposal to make 7 days the default. That makes sense. The vast majority of developers don't need packages the instant they're published. They can wait a week. For the rare cases where you genuinely need a fresh release (a critical hotfix, a security patch), every tool that supports this also supports a bypass.

But defaults matter. Right now, every package manager ships with an implicit minimumReleaseAge = 0. You get whatever was published 30 seconds ago, no questions asked. The entire security posture of the ecosystem is opt-in, and most developers have never heard of these settings.

We've been building increasingly sophisticated scanning tools, provenance systems, and attestation frameworks. And those are important. But we've also been overlooking one of the simplest defenses available: just wait a bit.

The axios attacker had a window of 4 hours. The Solana web3.js attacker had 5 hours. The Ledger Connect Kit attacker had 5 hours. ua-parser-js was 4 hours.

Every single one of those windows closes before day 7. Every single time.

If your package manager supports it, consider defaulting to a 3-7 day release age for third-party packages. Keep an escape hatch for emergency updates. Treat it as one layer in defense-in-depth.

And if your package manager doesn't support it yet, go open that issue.

The best security isn't always the most complex. Sometimes it's just giving the world enough time to notice something's wrong before you install it.

When The Bill Comes Due

Sat, 28 Mar 2026 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

<PostImage src="/bill-comes-due/cover.jpg" alt="when-the-bill-comes-due"> Photo by Towfiqu barbhuiya on Unsplash </PostImage>

I fired up Claude Code this morning, gave it a rough idea for a feature, and watched it read through my codebase, plan the implementation, write the code, run the tests, and fix the errors, all while I was making coffee. Fifteen minutes later, I had a working feature that would've taken me half a day to build manually. And this entire thing cost me... well, somewhere between nothing and nothing. It's all covered under my $200/month subscription.

I do this every day now. On a typical morning I'll have Claude Code, Codex, and Gemini CLI all running at the same time, each building different features in different worktrees. Sometimes I lose track of what's even happening across all of them. "Wait, what are the active tasks again?" is something I ask more often than I'd like to admit. I'll use one agent to review the code another agent wrote, because honestly, I don't trust any of them until I've understood the logic myself. And half the projects I spin up with these tools? They never make it past the first couple of screens before I move on to the next idea.

And here's the thing. I know the math doesn't add up. I've seen the API pricing pages. I've done the napkin math on how many tokens (the units AI companies use to measure and bill for every chunk of text the model reads or writes) a single coding session actually consumes. The number I'm paying and the number it actually costs to serve me are not the same number. Not even close.

We're living in the golden age of subsidized AI. And like every golden age before it, there's a bill somewhere with our name on it.

The $200 illusion

Let's start with what we know.

Sam Altman, CEO of OpenAI, said this about their $200/month ChatGPT Pro plan back in January 2025: "People use it much more than we expected." He confirmed the plan was losing money. Not breaking even, not slim margins. Losing money. On every single user.

This wasn't a slip. OpenAI lost $5 billion in 2024 on $3.7 billion in revenue. $2.25 spent for every $1 earned. Read that again.

Their inference costs on Azure alone hit $3.7 billion in 2024, and then nearly doubled to $8.67 billion in just the first nine months of 2025. That's $12.4 billion spent on inference in under two years. And that's just one company.

Anthropic, the company behind Claude (the tool I was just raving about), tells a slightly different story but the same punchline. They went from $1 billion in annual revenue in December 2024 to roughly $20 billion by March 2026. But they also burned $5.6 billion in cash in 2024 and have $80 billion in projected cloud infrastructure costs through 2029. That's not product revenue funding the business. That's investor money.

And GitHub Copilot? When it launched at $10/month, Microsoft was losing an average of $20 per user per month. Some heavy users were costing them $80/month. A $10 product that costs $30 to serve. That's not a business model. That's a subsidy.

Then there's Cursor, which hit $2 billion in annualized revenue by March 2026. Sounds healthy until you hear what an investor told Newcomer's Tom Dotan: "Cursor is spending 100% of its revenue on Anthropic." Every dollar coming in goes straight to API costs. Zero gross margin. They've raised billions in funding and are now racing to build proprietary models just to escape the economics.

"Almost each time you or I ordered a pizza or hailed a taxi, the company behind that app lost money. In effect, these start-ups, backed by venture capital, were paying us, the consumers, to buy their products.", The Atlantic

That quote was about Uber and DoorDash. But it fits AI coding tools perfectly.

We've seen this movie before

If you were an adult in any major city between 2012 and 2020, you lived through the millennial lifestyle subsidy, a period where venture capital quietly underwrote the cost of urban living. Your Uber rides, your Netflix subscription, your food delivery, your Spotify. All priced below cost, funded by investors betting that growth would eventually turn into profit.

The pattern is always the same:

A VC-backed company prices its product below cost to acquire users
Users build habits around the artificially cheap service
The subsidy becomes unsustainable
Prices correct upward
Users grumble, some leave, but most stay, and the company becomes profitable

Let me show you how this played out.

Uber: In 2015, riders were paying only 41% of the actual cost of their trips. Investors covered the other 59%. Uber accumulated $30 billion in losses before finally turning a profit in 2023. Prices rose 92% between 2018 and 2021. People complained. People also kept using Uber.

Spotify: This one is my favourite. Spotify held its Premium price at $9.99/month for 13 years. Thirteen years! Never once profitable. Then they raised the price three times in two and a half years, from $9.99 to $12.99, a 30% increase. They swung from losing EUR 500 million in 2023 to earning EUR 1.1 billion in 2024. A $2 price increase literally turned the entire company profitable. Premium subscribers kept growing at 10% year-over-year. Turns out when the product is good enough, people don't leave over a couple of dollars.

AWS: And then there's the outlier, the optimistic precedent. AWS has cut prices 134 times since 2006. The correction never came. Why? Because the efficiency gains were real. Hardware got cheaper, software got better, scale economics kicked in. The cloud market grew from $6 billion to over $600 billion without prices ever going up.

And then there's MoviePass, which offered one movie per day for $9.95/month when a single ticket cost up to $17. They burned through $200 million and went bankrupt. That's what happens when there is no path to efficiency gains. The subsidy is pure loss with no mechanism to ever close the gap.

<PostImage src="/bill-comes-due/bill-comes-due-crossroads.jpg" alt="crossroads"> Photo by Jens Lelie on Unsplash </PostImage>

So the question for AI coding tools is: Are we in an AWS situation, where real efficiency gains will keep prices low? Or an Uber situation, where the subsidy is masking unsustainable economics?

The honest answer is: probably both. And to understand why, we need to do some math.

The true cost of a coding session

Here's where it gets concrete. Let me walk through what a typical AI coding session actually costs in tokens and what those tokens are worth at API rates.

A median Claude Code session involves about 592,000 tokens across 24 API requests. That's 5 user messages and 19 tool call responses (file reads, searches, terminal commands). Just the system prompt and tool definitions eat about 22,000 tokens on every single turn, before you even ask your question.

But here's the thing that makes this less scary than it sounds: over 90% of those tokens are cache reads. The AI re-reading context it's already seen, which providers charge at a fraction of the normal price. Caching is the unsung hero of AI coding economics. Without it, every session would cost 5-10x more.

With caching, a typical session on Claude Sonnet costs about $0.20 to $0.65 at API rates (that's the per-token price you'd pay if you used the AI directly instead of through a subscription). Not bad. But here's where vibe coding changes the equation. When you start using AI agents for everything, exploring codebases, regenerating entire files, running multi-step workflows with retries, the token usage explodes. A single code exploration query can burn 45,000 to 120,000 tokens, most of it reading files that turn out to be irrelevant.

A heavy power user can easily hit $15-20 per day at API rates. That's $400-480/month of actual compute, served for $200. An analysis of Claude Code economics estimated actual compute costs of around $500/month for extreme power users. Meanwhile, Anthropic is adjusting usage limits to "manage growing demand". The throttling, the peak-hour limits, the usage meters jumping unpredictably. These aren't bugs. They're the system groaning under the weight of the subsidy.

<PostImage src="/bill-comes-due/bill-comes-due-pressure.jpg" alt="pressure-gauge"> Photo by Crystal Kwok on Unsplash </PostImage>

Three developers walk into a post-subsidy world

So what happens when the subsidy ends? Or more precisely, what would development look like if every token cost what it actually costs? Let me paint three pictures. And I'll be honest, I see myself in all three.

The Unlimited Prompter

You know this developer. Maybe you are this developer. (I definitely am this developer.)

Three agents running simultaneously in different worktrees. Spinning up new projects on a whim, most of which never make it past the second screen before the next idea hits. Half-formed thought? Fire off a prompt. Code doesn't compile? "Try again." Not sure about the architecture? "Just build it both ways and I'll pick one."

I've literally lost track of what my agents are doing and had to ask one of them: "Wait, what are all the active worktrees and tasks right now?" That's how casually I treat the compute.

At true cost? A single feature built this way, with the explorations, the regenerations, the "actually, let's try a different approach" pivots, could easily cost $50 to $200+ in tokens. Do that a few times a week and you're looking at a monthly AI bill that rivals a junior developer's salary.

The Intentional Builder

This developer plans before prompting. Clear spec, well-defined steps, precise instructions. They write the simple stuff themselves and bring in the AI for the hard parts: architectural decisions, complex algorithms, unfamiliar APIs.

They don't trust a line of AI-generated code until they've understood the logic themselves. Not because they're paranoid, because they've been burned. They might even use a second agent to review the first agent's work, catching common mistakes before they compound.

At true cost, the same feature costs $2-10 instead of $50-200. Not because they're using AI less, but because they're using it better. And here's the thing. This developer actually writes better software, subsidy or no subsidy.

The Hybrid Pragmatist

This is where most experienced developers will land. AI for the 20% of tasks where it provides 80% of the value: debugging weird edge cases, generating boilerplate, exploring unfamiliar codebases. Everything else? They write it themselves.

At true cost, their monthly spend is modest, maybe $30-80/month, and the ROI is obvious because every dollar of compute goes toward work where AI genuinely saves time.

The cultural shift nobody wants to talk about

I'll be honest, I've been as guilty of this as anyone. I've spun up projects on a whim, let three agents run wild across worktrees, and abandoned half of them before they had a functioning homepage. Vibe coding is intoxicating. You just... go with the flow, let the model figure it out, and something appears on screen. It feels like a superpower.

But vibe coding is a product of a very specific economic moment. It exists because the compute feels unlimited. The flat-rate subscription creates an illusion of infinite resources, and we've all rationally adapted our workflows to match.

When cost becomes visible, behaviour changes. We've seen this everywhere:

When Uber prices doubled, people started checking transit schedules again
When streaming got expensive, people started being pickier about what they watched
When food delivery fees hit $13, people started cooking more

The same thing will happen with AI coding. Not because the technology gets worse, but because the economics become real.

And here's the part nobody wants to hear: that's actually a good thing.

I know that because I've seen it in my own workflow. The times I've produced the best work with AI are the times I've been intentional: planning before prompting, reviewing the output critically, not trusting the code until I understood it. The times I've wasted the most tokens are the times I threw half-baked thoughts at an agent and hoped for the best. Those abandoned side projects? Mostly vibes, very little intention.

When the bill comes due, the waste gets squeezed out. What remains is the stuff that actually matters: AI as a force multiplier for human expertise, not a replacement for thinking.

I don't think that's a regression. If anything, it might be the opposite.

<PostImage src="/bill-comes-due/bill-comes-due-dawn.jpg" alt="dawn-sunrise"> Photo by Dori on Wikimedia Commons, CC BY-SA 3.0 </PostImage>

But here's why I'm not worried

Everything I just described sounds concerning. And if the story ended here, it would be. But there's a second force at play that changes everything, and it's moving even faster than the subsidy problem.

Token prices are falling off a cliff.

Not gradually. Not linearly. Exponentially. In March 2023, GPT-4 input tokens cost $30 per million tokens. Today, GPT-5 Nano offers comparable performance for $0.05 per million tokens. That's a 99.8% price drop in three years. Six hundred times cheaper.

Andreessen Horowitz calls this "LLMflation", the rate at which the cost of equivalent AI capability falls. Their analysis shows roughly a 10x cost reduction per year. Epoch AI's research is even more aggressive, finding a median of 50x per year across benchmarks. LLM inference costs are dropping several times faster than Moore's Law. And there's a good reason for that. Moore's Law had one driver (transistor density). The AI cost curve has at least six, all pushing in the same direction at the same time:

Hardware: Every major cloud provider now has custom AI silicon, delivering 30-60% savings over equivalent GPUs.
Quantization: Running models at lower precision cuts costs significantly with minimal quality loss.
Software optimization: GPU utilization improved from 30-40% to 70-80% through better batching. A 2x gain from software alone.
Smaller models, same quality: Llama 4 has 400 billion parameters but only 17 billion are active per token.
Distillation: Small specialized models replacing large general ones.
Open-source competition: DeepSeek V3 rivals frontier models at a fraction of the cost. Meta releases Llama for free specifically to commoditize inference.

Each of these drivers contributes independently. And they compound. The combined result: GPT-4-equivalent performance cost $20 per million tokens in late 2022. By early 2026, the same performance costs $0.40 per million tokens. That's a 50x reduction in about three years.

What does that mean for those three developers? At a conservative 5-10x cost reduction per year, the Intentional Builder's $5-10 per feature becomes $0.50-$1.00 within two years. That's less than the electricity your laptop uses while you're coding. The Hybrid Pragmatist's $30-80/month drops to $3-16/month. Less than a Spotify subscription. Even the Unlimited Prompter's $50-200 per feature lands at $5-20 by 2028. Not free, but firmly within "reasonable professional tool" territory.

By 2028-2029, even unsubsidized AI coding at aggressive usage levels may genuinely cost less than today's subsidized subscription prices. The subsidy isn't permanent. But it doesn't need to be. It just needs to last long enough for the cost curve to catch up.

Is AI coding more like AWS or more like Uber? I think it's becoming clear: it's more like AWS. Unlike Uber, which had no mechanism to make rides fundamentally cheaper, AI inference has multiple independent cost drivers all pushing in the same direction. Google has already crossed the threshold. Google Cloud is now profitable. They reduced serving costs by 78% through 2025 alone. Anthropic projects cash-flow break-even by 2027.

There's a nuance though. Reasoning models, the ones that coding agents need most, haven't followed the same steep cost curve as standard inference. The price of raw intelligence is falling fast, but the price of deep reasoning is falling slower. So the future probably isn't "everything becomes free." It's more like: routine AI coding becomes essentially free, while the hard stuff (complex architecture, deep debugging, multi-step reasoning) settles at a modest but real cost.

That's not a bad world. That's actually a pretty great world.

<PostImage src="/bill-comes-due/bill-comes-due-open-road.jpg" alt="open-road-ahead"> Photo by King of Hearts on Wikimedia Commons, CC BY-SA 4.0 </PostImage>

So, what's the move?

There's a period coming, maybe we're already in it, where the subsidy starts to thin but the cost curve hasn't fully caught up yet. A transition window. The developers who navigate it well won't be the ones who panic and stop using AI. And they won't be the ones who ignore the economics and hope it'll be fine. They'll be the ones who understand what's happening and adjust accordingly.

They'll know when to use the frontier reasoning model and when the small fast model is good enough. They'll write better prompts because each prompt costs something. They'll plan before they prompt. They'll maintain their core skills so they're never fully dependent on a service they don't control.

And here's the beautiful irony: the habits that make you cost-efficient with AI also make you a better developer. Planning before coding, being specific about what you want, understanding the code well enough to know when the AI is wrong. These are just good engineering practices that we dressed up in flat-rate subscriptions and forgot about.

I've started doing this more myself. Using one agent to review another's code. Not trusting the output until I can explain the logic back to myself. Breaking tasks into smaller, clearer prompts instead of throwing a vague idea at the model and hoping. The code is better for it. And honestly, I'm learning more this way than I was during the "just let the AI figure it out" phase.

The bill will come due. It always does. Spotify charged $9.99 for 13 years and then raised it to $12.99 and everyone survived. Uber rides cost 8x what they used to and people still use Uber. But AI has something none of those had: a cost curve that's falling faster than any technology in history. I could be wrong about this. Ask me again in two years. But the trajectory is hard to argue with. The bill comes due, but it doesn't stay high for long.

Build the skill. Not just the habit.

Wrapping up 2024

Sat, 21 Dec 2024 11:02:41 GMT

Hey there, 🌟

As 2024 comes to a close, I want to take a moment to thank you for being part of this journey. Whether you've been a loyal reader since the beginning or just joined the adventure, your support has meant the world to me. 💌

Reflecting on 2024 🌍

This year has been a whirlwind of innovation, challenges, and opportunities:

We saw AI evolve in ways we could only dream of. 🤖
Climate change stayed at the forefront, reminding us of the importance of collective action. 🌱
Developers built faster, smarter, and more connected tools, proving that creativity has no bounds. 💻✨

Through it all, this newsletter has been my way of sharing stories that matter—and you’ve been the reason I keep going. 🙌

Looking Ahead 🚀

As we step into 2025, here’s to:

Building a world where tech empowers everyone.
Tackling challenges with resilience and hope.
Celebrating progress, big or small.

The future is bright, and I’m thrilled to keep exploring it with you! 🌈

A Little Gratitude 🌟

Thank you for:

Reading my ramblings. 📖
Sharing your thoughts and feedback. 💭
Inspiring me to do better, learn more, and stay curious. 🔍

This community means everything to me, and I can’t wait to see where the next year takes us.

Here’s to a joyful, fulfilling, and inspiring new year for all of us. 🥂✨
Stay curious, stay kind, and keep dreaming big!

With gratitude and excitement,
Dani Akash
✌️

The Developer Edition

Fri, 06 Dec 2024 09:02:32 GMT

Yo! Happy Friday! 🎉

This week, there’s so much happening for developers that I’m skipping the general news to focus entirely on dev updates! Buckle up! 🚀

🚀 Firebase AI-Powered Goodies

Firebase hosted a Demo Day packed with AI-powered tools, including an AI-driven E2E test generator! 🤖 Check out the highlights—it's a must-watch for any Firebase enthusiast.

✨ React 19 is Stable

React 19 is now officially stable, and the React team dropped an excellent blog post detailing all the new goodies. Go on, treat yourself to some shiny new features! ✨

🌐 Vite 6 Arrives

The wait is over: Vite 6 is here! While it introduces many new features, the dev community is especially hyped about the new Experimental Environment API, which simplifies building SSR-friendly frameworks. 🛠️

🧑🏽‍🚀 Astro 5.0 Blasts Off

The framework behind my website and this newsletter's homepage—Astro—has released version 5.0. It already adopts Vite 6 under the hood. Gosh, they’re quick! 🚀

🏷️ CSS Wrapped 2024

For those who just finished checking their Spotify Wrapped, the Chrome team published CSS Wrapped 2024, highlighting all the shiny new features added to CSS this year. I’m testing some of them and prepping for a talk on one (details below ⬇️). 🖌️✨

💡 OpenAI’s Launch Week

OpenAI kicked off its 12 days of live streams and product launches with a new $200 ChatGPT Pro subscription. 😶 Check it out to see what’s coming next.

🛠️ Prisma 6 Speeds Ahead

Prisma V6 dropped, focusing on performance and flexibility. Their benchmarks look great—things are speeding up! ☀️

🤖 AI Makes Dev Skills More Valuable

Builder.io shared a reassuring read on Why AI Makes Dev Skills More Valuable. Huge sigh of relief—our skills are still in demand. 😮‍💨

✨ Personal Updates & Talks

🏢 AI for Frontend Developers

Last week, I was in Bangalore to give a talk on AI for Frontend Developers at Thoughtworks, organized by React Bangalore. The reception was fantastic, and the interest in AI among devs was incredible. 🤩

🎤 Upcoming Talk in Chennai

I’m speaking on CSS Animations with the View Transitions API this month—Dec 19th—at Geeknight Chennai 102nd Edition. If you’re in Chennai, let’s connect at the event! 👋

P.S. The topic I skipped this week was how 2024 is on track to be the hottest year on record. ♨️ A hot take for another time...

Thanks for reading, and happy coding! ✌️✨

Swimming Robots in Space

Sun, 24 Nov 2024 09:26:11 GMT

I’ve been delaying this newsletter ever since the COP29 conference went into overtime, only to deliver some less-than-happy results. If you remember, I wrote about the $1 Trillion dollar climate finance goal in my previous issue. Well, we’re now looking at a disappointing ~$300B deal, with the rest expected to come from “potential new sources of money.” Seriously... that’s what they said. 🤷🏽

For all the gritty details, check out the timeline of events at the conference.

If words could express frustration better than mine, I encourage you to listen to Mrs. Chandni Raina, India’s representative at COP29. Meanwhile, let’s move on to brighter, more spacey news! 🌠

(the one I wrote in the email subject ☝🏼)

The Robots That Swim Before They Fly 🐟🤖🚀

For all you space enthusiasts, NASA is diving into the cosmos with a project called SWIM—short for Sensing With Independent Micro-swimmers. This cutting-edge tech is designed to explore the mysterious Ocean Worlds of our solar system.

Image via NASA.

If you’ve been following along, you’ll remember that the Europa Clipper is headed to Jupiter’s icy moon Europa, where vast subsurface oceans might be hiding. 🌊🌌 Here’s what NASA has planned:

These SWIM robots will be deployed as swarms—tiny, independent micro-swimmers covering vast areas of extraterrestrial oceans. This increases efficiency and improves the chances of detecting signs of life. 🤯
NASA’s Jet Propulsion Laboratory (JPL) is already testing these micro-robots in underwater labs to fine-tune their tech. 🔬🌊

The future of space exploration is swimming closer than ever! 🌟

Quick Bites 🍿

🛍️ Amazon’s “Haul”: Amazon has launched Haul, a rival to Shein/Temu where everything is under $20—because we definitely needed more reasons to shop. 🙃
🎥 Netflix’s “Buy Now”: Netflix released Buy Now, a documentary exposing modern consumerism and its environmental consequences. Coincidence? I think not… 😅
🦋 Bluesky Booms: Bluesky, the open-source Twitter alternative, has reached 20 million users! If you’re there, give me a follow. ✌️
🌍 Arctic Meltdown: Meltwater from Greenland and the Arctic is weakening ocean circulation and speeding up warming in the Global South. If only COP29 had delivered a better deal… 😩

For the Developers 💻

React Router V7: Version 7 is here—and it’s basically Remix! 💿
Tailwind 4: The beta release is out, and rumor has it you won’t need a JavaScript config file anymore. 🤯
React Scan: A new tool to "scan" your React app for problematic renders—check it out! 🕵️‍♀️
Vercel AI SDK V4: Major updates to an already powerful SDK. 🚀
Tanstack Start: Now in Beta, and I heard the news first on Bluesky. 🦋
Angular V19: Angular 19 is out. Still one of the best frameworks I haven’t tried yet. 🙃

🎥 Video of the Week:

The Physics That Doomed Amelia Earhart—The mistakes of Amelia Earhart’s final flight, and the physics that could have saved her, by Veritasium

AI needs water — a lot!

Fri, 15 Nov 2024 18:02:01 GMT

Yo! Happy Friday! 🎉

Or, depending on when this email reaches you, happy day! 🌞

Looks like I’ve hit a “mailfunction” with my newsletter provider, so this issue might be a bit post-poned! 🥁 But hey, we’re here now—let’s dive in

AI is Thirstier Than We Thought 🤖💧

AI isn’t just energy-hungry—it’s downright thirsty! 🥤 Recent studies reveal that it’s consuming four times more water than previously expected. Here’s a quick breakdown:

Data centers use water to cool the servers, which are heating up faster due to intensive AI workloads.
Asking just 10 to 50 queries in an AI chatbot consumes about 2 liters of water!
While alternate cooling approaches are being explored, the silver lining is that tech giants have pledged to become “water positive” by 2030, aiming to replenish more water than they consume.

Want the nitty-gritty details? I highly recommend checking out the full article.

Delhi’s Smog Crisis 🌫️

Delhi is facing a serious smog crisis, and things aren’t looking good… (literally)

Image via The Guardian.

Remember during the 2020 lockdown when people in Punjab saw the Himalayas for the first time? Fast forward to now… it seems like things have only gotten worse 😔

Meanwhile... 🌍💸💻

Bitcoin Breaks Records: Bitcoin just hit a new all-time high. As someone who doesn’t invest in crypto anymore, I’m not sure why I’m sharing this… 🤷🏽
Hottest Year Yet: 2024 is virtually certain to be the hottest year on record 🔥 according to the EU Space Programme. Didn’t know they covered climate news, but it still sucks 😵‍💫
Visualizing WWII: Check out this fascinating piece on visualizing WWII through maps from newspapers of the time, by Nathan Goldwag 🗺️📰

For the Developers 🚀

ESLint Meets CSS: ESLint now has a CSS language plugin—time to uninstall that Prettier plugin! 💅🏼
New Package Manager: Introducing vlt—a fresh JavaScript package manager and serverless registry
Framer Motion Rebrands: Framer Motion is now independent and rebranded as Motion!
State of JS 2024: The State of JS 2024 survey is live! And yes, I’ve definitely heard of everything listed there 😎

🎥 Video of the Week:

Cost of Living Compilation - a satire that feels too real - by Viva La Dirt League

$1 Trillion Dollar Goal

Fri, 08 Nov 2024 08:25:36 GMT

Yo! My Twitter feed has been a total mess lately, filled with random stuff I couldn’t care less about. I wonder why? 🇺🇸🗳️

Anyway, I’ve started the great migration over to Bluesky 🦋. If any of you are there too, give me a follow! ✌️

Meanwhile, the 2024 United Nations Climate Change Conference－COP 29－kicks off Monday in Azerbaijan, and one major aim is to secure a whopping $1 Trillion 💰 in climate finance. That’s “Trillion” with a T! 💸

For context, climate finance is the support provided by wealthier nations to help developing countries fund projects that reduce pollution, protect natural resources, and adapt to climate change impacts. The idea is to tackle challenges together—because it’s a big ask for poorer countries to handle solo.

Sure, $1T sounds enormous, but keep in mind, it’s pocket change next to the $2.8 billion per day profit that the oil & gas industry has raked in over the last 50 years! 😵‍💫

One of the proposed methods to meet this goal? A wealth tax on the ultra-wealthy. It could work wonders for climate finance and affect only a few… 🙈

The cost of inaction is steep: climate damages are projected to hit $38 trillion per year by 2050 🔥—not to mention the toll on human lives ☠️

For a visual dive, check out the Global Landscape of Climate Finance 2024 report from the Climate Policy Initiative. It’s full of cool charts 📈✨ and reveals that while climate finance is growing each year, we need 3x the current growth rate to hit the target ☹️

Full report here.

In other news, ChatGPT Search launched last week, and it’s a game-changer! Plus, OpenAI’s CEO Sam Altman just bought the domain— chat.com from HubSpot co-founder Dharmesh for a cool $15.5 million+. 🤑 (Reminds me of that wealth tax… 🙏)

For Developers:

pqoqubbw/icons - A slick collection of animated icons for the web
next-forge - A production-grade Turborepo template for Next.js apps
React Navigation v7 is here!
GitHub Universe happened last week, and the highlight was definitely all the new Copilot features.

🎥 Video of the Week:

Is there ANY optimistic climate news? YES. There is... by Just Have a Think

Splitting Atoms for Smarter AI

Fri, 01 Nov 2024 10:48:33 GMT

Yo! It’s been a festive week with Diwali celebrations 🪔🧨✨🎆❤️

Speaking of things that pollute our environment, it turns out AI is very energy-hungry, and our current energy infrastructure is not exactly eco-friendly 🌍💨

But big tech has a solution – they’re turning to nuclear energy. Yes, you heard that right! They’re going Nuclear ☢️

Deals are already in motion, with Microsoft, Google, and Amazon all ordering nuclear energy for their AI data centers ⚡🖥️
This shift helps align with their net-zero goals while ensuring continued progress in AI research ♻️🤖
The fact that some of the world’s largest tech companies are opting for nuclear energy speaks volumes about the advancements in nuclear safety and infrastructure over the years 🚀

🧠 What’s So Special About the Human Brain?

Nature.com created an amazing visual guide to show us just how unique our brains really are. Check it out! 🧠✨

🌱 COP16 and Biodiversity Concerns

COP16 has raised alarms over the lack of progress in stopping human-caused biodiversity loss, an issue agreed upon back in COP15 ☹️. It’s a critical reminder of the work that still needs to be done.

For Developers

Node v22.11.0 (LTS) has been released. Time to upgrade your engines! 🏎️
The GitHub Octoverse report dropped a bombshell: Python has overtaken JavaScript as the most popular programming language, all cuz of AI 🤖
Missed out on Next.js Conf? Here’s your recap! 📚🔥

🎥 Video of the Week

AI is dangerous, but not for the reasons you think – a thought-provoking talk on TED

Europa Clipper Sails Toward Europa

Sat, 26 Oct 2024 01:49:41 GMT

Bonjour! 👨🏻‍🚀

NASA’s Europa Clipper 🛰️ just kicked off its epic journey to Jupiter (which, like Mars, still doesn’t have an emoji) to study Europa, one of the 95 moons orbiting the gas giant. It’s set to travel a casual 2.9 billion kilometers, and the trajectory looks… wild.

From Wikipedia. Yup, the math checks out ✅

NASA’s got some big plans for this mission:

Oceans under ice? 🌊 Europa might have them beneath its icy shell ❄️, and where there’s water, there’s a good chance of ~~fish~~ life!
Radiation alert! 🚨 Jupiter isn't very probe-friendly, bombarding them with intense radiation. But don’t worry—NASA’s got cool countermeasures 🛡️ to protect the Clipper.
Europa Clipper is set to arrive in April 2030. Hopefully by then, we’ll have either hit the Net Zero emission goals (45% reduction by 2030) or we’ll need a beach resort 🏖️ on Europa...

🎬 Meanwhile, back on Earth: Turns out making movies is bad for the planet. And no, it’s not because of disaster movies 🌋

An ex-Nvidia programmer just discovered the largest prime number ever—40 million digits long! 🤯 Want to find your own? Check out Numberphile for a crash course in prime-hunting

For Developers

Framework frenzy: Next.js 15, Svelte 5, React Compiler Beta, and the new React Native architecture have all landed. But the real hero? Express.js 5 🎉, updated quietly after 10 years since Express.js 4.
State of React Survey 2024 is now live! And yes, I’ve heard of all the items mentioned in it 😎.
Good news for JetBrains fans: WebStorm and Rider IDEs just went free for non-commercial use. Now all you need to buy is more RAM 💸.

🎥 Video of the Month

The Insane Engineering of Europa Clipper by Real Engineering

Less on the Client, more on the Edge

Sun, 01 Jan 2023 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

<PostImage src="/lessonclient/less-on-client.avif" alt="monolith-design"> Photo by Joshua Rawson-Harris on Unsplash </PostImage>

I was a developer till 2020 mostly contributing to products as an IC. Managing a team is something I started in mid-2021 & from then on, I have been traversing a big learning curve.

2022 - I had to build a team that will build & maintain a complex web application. The challenges were completely different from the problems I solved as a developer. Here's my retrospective on what I learnt from things that went wrong & things that went well

We built a SPA that's purely rendered on the client

SPA frameworks have evolved a lot. We have plenty of options & so many libraries, we often forget that not every piece of logic needs to be written on the client side. As we grew the team from 2 to 5 engineers & the product evolved into 3 separate entities, the limitations of pure client-side hydration started showing up

Authenticated/protected routes had to render once because the logic was written in useEffect which could not run before the application starts
Logic wrote to logout the users often ran into race conditions because we had no control over what APIs are getting called & what part of the application is currently writing to the local-storage
The user signup & onboarding flows had many redirecting branches leading to the components built for them often having multi-level if-else statements

Whatever approach we took often resulted in so much messy logic on our client-side & as we often kept building more UI Components & adding UI changes, this led to serious scaling issues to our codebase. Until we arrived at one final solution...

Moving logic to the edge instead

The crux of most of our issues was there was so much running on the client side of the application, we had to figure out a way to write a critical piece of logic that doesn't have to deal with race conditions or delay in hydration.

Enter: Edge functions, I came across this first when I was reading up on a new feature released by vercel. Basically, instead of running the code on the client side, edge functions side-step the whole problem by running logic very close to the users on edge locations using lightweight runtimes, which means - we now have a way to execute logic even before the whole application loads. With next.js middlewares, we could even run logic while a client-side routing is happening.

Soon, we were knocking off all the technical debts & bugs by writing simple logic on the edge functions without compromising the performance for our users.

Fate-sharing across different services

While building a web app that offers multiple services, with multiple teams working on each service, the whole fate-sharing problem starts to blow up. This is the first time I came across this problem in my career.

We had a GraphQL server that is built on top of AWS AppSync & a Next.js App deployed to vercel. Things were great when we first built the product last year. We were moving fast & shipping new features at breakneck speed. But as we started scaling up our team & started offering many services, we noticed the following problems:

Some teams wanted to build APIs that are deployed purely to the edge for fast performance
Some of the teams working on specific services had use cases where they had to try different frameworks on the web app outside of Next.js
An issue in specific modules like authentication or common layouts had the potential to bring the entire app down, even though, the services themselves worked fine

Soon I'll realize, this is the time to adopt the microservices architecture.

Turning our GraphQL server into microservices

After reading various articles online from different engineering teams, Netflix's GraphQL Federation architecture was something exactly what we were looking for. This idea requires hosting a GraphQL Gateway (Supergraph) using Apollo federation & building all the other services as a collection of mini graphql servers (subgraphs) However, to ensure performance is great since supergraph receives the request first & calls the subgraph, we wanted the supergraph to be hosted on the edge powered by Cloudflare workers.

Soon we built our GraphQL gateway with GraphQL Mesh - The folks at The Guild were nice enough to build a Cloudflare runtime version of their open-source library for us ❤️

The teams are now free to build the APIs for their services independently using the technology of their choice with no friction between each other. We also built a lot of tooling around how to develop & test locally using preview environments & also our in-house edge cache setup on our gateway. But I might write about them on a later day.

Adopting Micro Frontends

At this point, our architecture looked something like this:

<PostImage src="/less-on-client/1.png" alt="monolith-design"> Image from Micro Frontends </PostImage>

However, we needed something like this:

<PostImage src="/less-on-client/2.png" alt="micro-fe-design"> Micro Frontends design </PostImage>

Unlike microservices for our APIs, building micro frontends had a whole different set of problems & a whole community of developers working on how to solve them using tools like Webpack Module Federation, bit, single-spa etc.

But they all came with their own set of challenges for adoption & we were quite happy with the developer experience we were getting with Next.js. We also wanted to try Astro & its Islands architecture which couldn't co-exist with our Next app. So with a little bit of effort, we set up routing on our application so that visiting /new-service loads the whole new project written in Astro.

Not exactly the best approach to solving micro frontends however, we reduced our javascript payload by over 60% thanks to Astro Islands & we were very happy with the performance.

I mostly played the role of figuring out an approach that will help the rest of the engineering team move faster. It was thanks to the wonderful engineering team that I worked with, that we were able to implement all the solutions quickly as per the plan & helped ship a high-quality product.

So much more to learn in 2023!

The race to better batteries!

Sun, 14 Mar 2021 07:29:16 GMT

Yo! This week’s mail was delayed by a day. But as the saying goes... Better late than never! Hope you are enjoying your weekend, we’ll keep today’s story simple.

💸 Recently, petrol prices have been shooting straight up! 📈 It went so high, my friend decided to indefinitely postpone his plans to buy a car 🚗 But on the other hand, the electric vehicle market is growing really fast. Also, many countries are focusing on investing highly in green energy sources 🌳

⁉️ But what do we really need to make the switch fully to green energy? The answer is simple... We Need Better Batteries! 💡 Cuz unlike fossil fuels, solar energy can’t run 24x7 ⏲ ☹️

🎐 Windmills need the wind, 🌊 tidal energy needs tides & ☀️ the solar panels need the sun all of which are available for free but not 24x7. How do we solve this problem?

🔋 We collect energy when they are available & store them in batteries when they are not available. As the number of renewable energy needs grows, the race has been going on to figure out how to build better, more energy-efficient & higher capacity batteries.

Someday, we'll be storing electricity the same way we are keeping our digital data fingers crossed

🎥 Video of the week

The world's biggest battery looks nothing like a battery by TED-Ed

The Vaccines are here!

Sat, 06 Mar 2021 02:30:00 GMT

Yo! Time to take a break from your busy schedules, maybe go for a trip? Time to tick some items off your bucket list cuz the vaccine rollout is finally happening!! 🎉

💉 So far there are 12 vaccines that have passed the clinical trials & are available to use, while about 57 vaccine candidates are under development. Make sure you keep an eye on the 🚨 COVID-19 vaccine tracker 🚨

The mRNA vaccines developed for COVID-19 basically tells our cells to create proteins that resemble the virus (a fake virus!). Then our immune system attacks these virus look-alikes to create immunity. Pretty smart 😎
This also opens up many possibilities as we can customize mRNA to produce vaccine suitable for an individual's cancer cells. Yes, you heard it right! they opened up a possible treatment for cancer! 🤯
India started Phase 2 of the COVID-19 vaccine rollout which targets over 10 crore people. Especially people in the age brackets above 60 years & people between 45 to 59 years with some pre-existing health conditions. Make sure you check the eligibility criteria & get your family members registered!

🔭 Two astronomers went looking for a supermassive black hole but ended up finding over five dozen small black holes packed together in a tight space as small as our solar system. Now the biggest question is, are all supermassive black holes formed by the merger of such small black holes? If we waited a few million years, we might find out!

🚀 Apollo in Real-Time lets you experience the events of the three Apollo missions (including the first moon landing 🌕) that happened between 1969 - 1972 in real-time directly in your browser. I almost felt like an astronaut 🧑🏽‍🚀

💰 A 10-second video was sold for 6.6 million dollars last week... wonder why someone would buy a digital video that can be easily copied? Well introducing non-fungible token (NFT) which is a token powered by blockchain that uniquely identifies a digital asset. Art collectors can now buy ownership of famous TikTok videos 📈

🏎 Electric cars accounted for 1/3rd of all US vehicles in the US back in 1900! Yeah you heard it right! in the 1900's! Read about the timeline of electric vehicles or watch this video by Our Changing Climate

🎥 Video of the week

mRNA vaccines, explained by Vox

This newsletter is new & I’m still learning how to properly send newsletters, so if you got some feedbacks, tweet it to me @dani_akash_

Mars rover got a microphone

Sat, 27 Feb 2021 02:30:00 GMT

Yo! Awesome work making it to the weekend! This is an exciting week since NASA's new rover has started sending images back to Earth. Gosh I really need a Mars planet emoji 😫

Here's what You might wanna read today...

🕹Perseverance rover has so many new things to be excited about -

It is the first rover with a microphone 🎤 so we can finally hear what Mars sounds like! May be listen to some martian podcast 🎙
It also carries the first martian helicopter Ingenuity 🚁 which is going to perform the first controlled flight outside earth 🛸
It landed close to what appears to be a lake that's been dried out in Mars. So there's a better chance of finding new lifeform 🤩

🎨 The pre-landing simulation for the whole Mars mission was built with Three.js! ✨ JavaScript developers get ready for a job with NASA! 🚀

🚃 The canadians used a train to generate electricity back in 1998 when ice storms caused a blackout. Maybe the people of Texas might wanna take notes...

⌨️ The famous ctrl+alt+del shortcut in windows was actually built as a system reset tool for developers!

🧬 Scientists cloned an endangered species successfully! Someday we might actually meet the dodos & passenger pigeons...

🎥 Video of the week

The insane engineering of the Perseverance Rover by the amazing Real Engineering channel

This newsletter is new & I'm still learning how to properly send newsletters, so if you got some feedbacks, tweet it to me @dani_akash_

Maintaining a React Native Library

Tue, 15 Sep 2020 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

React Native is an excellent framework for building mobile apps. The best thing about React Native is how it provides the developers with a solid set of primitive UI components. This means there's plenty of opportunities for you to build your own library and publish it to the open-source community.

The Problem

Building & maintaining quality open-source libraries is hard work. Especially React Native libraries are harder since they often need to be verified on both Android & iOS platforms.

I ran into this exact issue when I started working on open-sourcing the libraries I built for my personal use. I created an organization that holds the collection of the libraries. It's called React Native Toolkit

<PostImage src="/maintaining-react-native-lib/1.png" alt="react-native-toolkit"> React Native Toolkit on Github </PostImage>

I wanted to ensure developers get to try out all my libraries, at the same time, I should be able to quickly make small updates and bug fixes without having to spend too much time.

In summary, I wanted to ensure I covered all the following 6 items for my open-source libraries,

Proper Linting of code & commit messages
A working example in an actual app
Unit tests
Detailed documentation that covers all the use cases
Visual testing after code changes
Easily review PRs

Solution

Once I have created a list of things needed for my open source projects, I started exploring various tools that'll help me achieve the individual targets.

So I started working on my library react-native-better-image while evaluating the various options. I had two major tasks

Picking the right tools
Automate as many tasks as possible

Picking the right tools

React Native Community's Bob - Linting + Example App

This almost felt like a no-brainer. React Native Community which hosts a collection of quality libraries already had a tool which would make building react native libraries so much simpler.

Bob had almost everything I needed in terms of Proper Linting & having a working example app using the library.

The example app is also pre-linked with the library's source so you can just start writing code and you probably won't have to worry about anything. Just import your library inside the app & setup your working example!

That's 2 out of 6 items covered

Alternatives

One other alternative I tried in this category is create-react-native-module. This one is good but bob is just too better.

React Native Testing Library - Unit Tests

I'm a big fan of the testing library in general. It encourages you to write tests in the way your software is being used rather than being implemented. Which is why I immediately picked up the React Native Testing Library that brings all the best parts to the native side of development.

If your library uses native iOS or Android code, then you'll have to write tests that run on the native side. However, since all my libraries are pure JavaScript, I didn't explore any on the native side. Suggest the tools you use for this purpose in the comments :)

That's 3 out of 6 items covered

Alternatives

If your library requires an end to end testing, then you can add detox to your project. You can use the example app created by Bob to run the test cases.

Another common library for writing unit tests is Enzyme. If you are already familiar with enzyme then you can use it for your library.

Storybook - Documentation

Storybook v6.0 was recently released with improved documentation. While storybook already has a React Native version, the react version is much more powerful & better suited for our documentation.

The documentation can be hosted a static site & it will showcase your library in real-time. Check out my react-native-better-image documentation.

To get storybook working with your React Native library, you can add it to your example expo app following this example from the expo team.

I only had to change the webpack config in my .storybook/main.js file and it worked well using react-native-web

4 out of 6 now covered

Alternatives

I haven't personally tried any alternatives to storybook yet. Maybe you can read about it in this blog post by logrocket.

Chromatic - Visual Testing

One other reason I was firmly sticking to storybooks is their integration with chromatic. Chromatic lets you quickly do visual tests on your stories. You can also easily share stories & get feedback from others.

They have a generous free tier & their team is kind enough to provide me support when I ran into issues with my react-native + storybook setup.

I'll be using chromatic for reviewing PRs, will explain about it in the automation section.

Chromatic makes visual testing a breeze! That makes 5 out of 6 items handled

Expo Cli - Reviewing PRs

Reviewing PRs is the most important thing in Open Source projects. I have been struggling to review PRs in some of my old projects as I have to manually clone & run the code to check how it affects my library. Many times I just don't have the bandwidth to do so...

This time, however, I have decided to make the reviewing process as easy as possible. The trick is to have a good example application in your library that covers almost all use cases. Once someone raises a PR, you can generate a build using the Expo CLI. Expo team has been making this process a lot easier by creating a Github Action that can easily publish a review version of your library.

Along with this, the stories in the PR are also pushed to chromatic. This means I should be able to review a PR fairly faster. I haven't yet received any PRs yet, so fingers crossed 🤞

Automating stuff with Github Actions

Now that we have all the right tools in place, it is time to automate the Build, Review & Publishing process for your new React Native library. Which will be covered in the next part of this series!

All open-source Github repositories have free Github Actions available with which we can automate most of our workflows. I'll be using Github Actions throughout the automation process.

The library's build consists of the following items ﹣

Linting
Running Tests
Publishing the test coverage
Publishing the example app to expo
Publishing the stories to chromatic
Publish the storybook which contains documentation as a static site

You can find my build workflow in the .github/workflows/build.yml file of my react-native-better-image project. This is how the build process should look like ﹣

<PostImage src="/maintaining-react-native-lib/2.png" alt="build-plan"> Library Build Plan </PostImage>

When to trigger the workflow

I wanted the build workflow to ensure the master branch is always stable. Hence it will run on all the pushes to master. But it will not run for tags, as I have planned another release workflow for this

name: build
on:
  push:
    branches:
      - master
    tags:
      - "!*" # Do not execute on tags
    paths:
      - example/*
      - src/*
      - test/*
      - __tests__/*
      - "*.json"
      - yarn.lock
      - .github/**/*.yml

Linting

Since we are using react-native-community/bob in our project, we can run both lint & typescript scripts in the package.json file which is enough to complete the lint process

lint:
  name: lint
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn typescript
    - run: npx yarn lint

Testing & Coverage

For displaying the test coverage, I decided to use code climate for open source projects. They also have a nice action available at paambaati/codeclimate-action.

Code climate checks your code for best practices and provides you with maintainability metrics. Along with that, you'll also get code coverage reports. Once you setup code climate you can add their badges to your repo that gives everyone a live code quality score ﹣

<PostImage src="/maintaining-react-native-lib/3.png" alt="rex-state"> Rex State badges </PostImage>

The following configuration is used for running tests ﹣

test:
  strategy:
    matrix:
      platform: [ubuntu-latest, macOS-latest]
      node: ["12.x"]
  name: test/node ${{ matrix.node }}/${{ matrix.platform }}
  runs-on: ${{ matrix.platform }}
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: ${{ matrix.node }}
    - run: npx yarn bootstrap
    - run: npx yarn test

Once both linting & testing jobs are completed, you have to push your code coverage to code climate. Following their docs you need to create a secret in your repository with name CC_TEST_REPORTER_ID after which add the following configuration

coverage:
  needs: [test, lint]
  name: coverage
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - uses: paambaati/codeclimate-action@v2.5.3
      env:
        CC_TEST_REPORTER_ID: ${{secrets.CC_TEST_REPORTER_ID}}
      with:
        coverageCommand: npx yarn test --coverage
        debug: true

Publish example app to expo

Publish should also happen after the lint & test jobs. This time we will be using the expo/expo-github-action. As per the action's docs, you'll have to add your expo username & password to your repo's secrets under the name EXPO_CLI_USERNAME & EXPO_CLI_PASSWORD.

If you have an organization, you can add it under the organization secrets and share it with all your repositories!

The first step to publish is to run yarn bootstrap command. However, the next step expo run should run inside the example directory. For this we will use the working-directory config

publish:
  needs: [test, lint]
  name: Publish example app to Expo 🚀
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
      with:
        node-version: 12.x
    - uses: expo/expo-github-action@v5
      with:
        expo-version: 3.x
        expo-username: ${{ secrets.EXPO_CLI_USERNAME }}
        expo-password: ${{ secrets.EXPO_CLI_PASSWORD }}
    - run: npx yarn bootstrap
    - working-directory: example
      run: expo publish

You'll get a published page for your library's example app. You can check out the page for my react-native-better-image library's example app.

Publish stories to chromatic

Similar to expo, chromatic also have a GitHub action available in chromaui/action. You have to create a new project in chromatic and get your project token. Then add it to your repository's secrets under the name CHROMATIC_PROJECT_TOKEN

We need to run chromatic action inside the example directory since our storybook lives in this directory. The chromaui/action didn't have an option to run it inside a specific directory. So I had to manually add the following script in my example app's package.json file ﹣

"chromatic": "npx chromatic"

Then added the following workflow configuration which manually runs chromatic ﹣

chromatic:
  needs: [test, lint]
  name: Publish storybook to chromatic 🧪
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn chromatic
      working-directory: example
      env:
        CHROMATIC_PROJECT_TOKEN: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}

Publish storybook as a static site

I used Netlify to publish my storybook as a static site. I was initially planning to use GH Pages, but I needed the 1-click rollback & Deploy Previews offered by netlify. I installed the Netlify app which automatically takes care of the building the repo & deploy previews so I didn't have to write any actions config.

If you are interested to use GitHub pages for your library, you can use the Deploy to GitHub Pages action for this purpose.

You can also try Netlify CLI if you want to configure deploys with netlify through GitHub Actions.

This build workflow is actively used in two of my libraries rex-state & react-native-better-image

In the next part, I'll explain how to set up the review workflow!

Reviewing PRs are an important part of managing Open Source libraries. However, they might require a considerable amount of time & effort from your busy life which means, you need to be as efficient as possible.

My whole toolchain was set up around making the review process as easy as possible. This time we'll create Github Action workflows to make the review process a whole lot simpler.

Every PR raised to the library will have the following checks performed automatically

Linting & Testing
Code coverage report
Deploy preview of the updated storybook docs
Build a review version of the example mobile app with link to quickly test it
Send all stories to chromatic to do a visual review

As soon as the PR is sent, you should be able to see the progress of the review workflow ﹣

<PostImage src="/maintaining-react-native-lib/4.png" alt="rex-state-workflow"> Rex State workflow checks </PostImage>

The above image is from a PR of my rex-state library. Let's look into how we can implement this effectively.

You can find my working review workflow at .github/workflows/review.yml file of my rex-state library.

Triggering the workflow

This workflow will run on all pull requests

name: review
on: pull_request

Linting & Testing

This step is the same as what we did for our build workflow. All the other jobs will run only after Linting & Testing are complete.

lint:
  name: lint
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn typescript
    - run: npx yarn lint

test:
  strategy:
    matrix:
      platform: [ubuntu-latest, macOS-latest]
      node: ["12.x"]
  name: test/node ${{ matrix.node }}/${{ matrix.platform }}
  runs-on: ${{ matrix.platform }}
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: ${{ matrix.node }}
    - run: npx yarn bootstrap
    - run: npx yarn test

Coverage report

Previously on the build step, we used Code Climate to store our test coverage reports. However, on PRs we need a way to quickly check the test coverage for the incoming code.

For this, we can use the romeovs/lcov-reporter-action which will post a nice comment on the PR with the test coverage details. You'd get a report like this following comment ﹣

<PostImage src="/maintaining-react-native-lib/5.png" alt="rex-state-coverage"> Rex State code coverage </PostImage>

Add the following configuration for receiving the coverage as a comment ﹣

coverage:
  needs: [test, lint]
  name: coverage
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn test --coverage
    - uses: romeovs/lcov-reporter-action@v0.2.16
      with:
        github-token: ${{ secrets.GITHUB_TOKEN }}

Deploy preview of the updated storybook docs

Since I was using the Netlify Github App, I'm getting the deploy previews out of the box without any kind of additional setup. You can try the Netlify CLI if you want to manually enable deploy previews with Github Actions.

Review Version of the Example App

This is where the power of expo toolchain shines. You can use the expo-cli to publish the app in a separate channel which you can use for your review purpose.

The expo team have also provided detailed documentation on their expo-github-action. Add the following configuration to your workflow (replace the URL in the msg with your application's URL)﹣

expo-publish:
  needs: [test, lint]
  name: Publish to Expo 🚀
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
      with:
        node-version: 12.x
    - uses: expo/expo-github-action@v5
      with:
        expo-version: 3.x
        expo-username: ${{ secrets.EXPO_CLI_USERNAME }}
        expo-password: ${{ secrets.EXPO_CLI_PASSWORD }}
    - run: npx yarn bootstrap
    - run: expo publish --release-channel=pr-${{ github.event.number }}
      working-directory: example
    - uses: unsplash/comment-on-pr@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
      with:
        msg: App is ready for review, you can [see it here](https://expo.io/@daniakash/rex-state-example?release-channel=pr-${{ github.event.number }}).

From now on, for every PRs you'll get a comment just like this one ﹣

<PostImage src="/maintaining-react-native-lib/6.png" alt="rex-state-review-link"

Rex State app review link </PostImage>

Sending stories to chromatic

Finally to do a visual review if the PR has affected your stories you can send the stories to chromatic. The configuration is the same as our last one, chromatic is smart enough to figure out that the data is from a PR!

chromatic:
  needs: [test, lint]
  name: Publish storybook to chromatic 🧪
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v2
    - uses: actions/setup-node@v1
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn chromatic
      working-directory: example
      env:
        CHROMATIC_PROJECT_TOKEN: ${{ secrets.CHROMATIC_PROJECT_TOKEN }}

Once you have everything ready, Your PRs will now have detailed information on the things you'd otherwise have to check manually every time ﹣

<PostImage src="/maintaining-react-native-lib/7.png" alt="rex-state-detailed-checks"

Rex State detailed checks </PostImage>

We got a powerful review workflow now. In the next part, let's publish the library to NPM every time you create a new release in GitHub!

This workflow is used in the .github/workflows/publish.yml file of my library rex-state

GitHub Releases

Releases section allows us to tag individual commits with proper version numbers & a detailed changelog.

I use it as my source of truth for managing versions. Which means, every tag should be automatically published to GitHub.

Trigger

This workflow will run on release when the the type is published

name: publish
on:
  release:
    types: [published]

Jobs

This workflow has three jobs. First two are linting & testing to ensure the code is stable.

lint:
  name: lint
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - run: npx yarn typescript
    - run: npx yarn lint

test:
  strategy:
    matrix:
      platform: [ubuntu-latest, macOS-latest]
      node: ["12.x"]
  name: test/node ${{ matrix.node }}/${{ matrix.platform }}
  runs-on: ${{ matrix.platform }}
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: ${{ matrix.node }}
    - run: npx yarn bootstrap
    - run: npx yarn test

Once the above two jobs are over, we'll now use the JS-DevTools/npm-publish Action to publish an update to NPM.

You need to create an NPM Auth token and add it to your repository or organization secret under the name NPM_TOKEN

Then add the publish the job to your workflow ﹣

publish:
  needs: [test, lint]
  name: Publish to npm 🚢📦
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@master
    - uses: actions/setup-node@master
      with:
        node-version: 12.x
    - run: npx yarn bootstrap
    - uses: JS-DevTools/npm-publish@v1
      with:
        token: ${{ secrets.NPM_TOKEN }}

Whenever you create a release in your repository from now onwards, you'll have an update published to your npm package.

This completes our React Native Library setup, you can use the setup + workflows you learnt in this 4 part series to publish both your React Native & React.js libraries.

I have been using it for both react-native-better-image which is for React Native & rex-state which works with both React.js & React Native.

In future, I'll be moving all my libraries in React Native Toolkit to this workflow which will help me maintain all my current 10+ libraries & some upcoming ones efficiently.

If this series helped you or you have any feedback feel free to post a comment or reach out to me on twitter. I'd be happy to help! :D

Rex State - a handy utility to convert your hooks into shared states

Fri, 11 Sep 2020 18:30:00 GMT

Introducing Rex State v1.0

I initially built rex-state as a state management library, however, since it was using the Context API it wasn't very efficient with handling re-renders.

But then its another feature became more prominent. It can easily convert any hook into a shared state!

Focusing on this functionality, Today I'm releasing Rex State 1.0. This tool is easy to use and will work with your existing hooks.

Usage

Add rex-state to your project

yarn add rex-state

# or

npm i rex-state

Consider you have the following counter hook ﹣

const useCounterHook = (initialCount) => {
  const [count, setCount] = useState(initialCount || 0);

  const increaseCount = () => setCount(count + 1);
  const decreaseCount = () => setCount(count - 1);

  return {
    count,
    increaseCount,
    decreaseCount,
  };
};

You can use rex-state to create a provider and a shared hook using the following code ﹣

import { createRexStore } from "rex-state";

const { useStore: useCounter, RexProvider: CountProvider } =
  createRexStore(useCounterHook);

Wrap your application inside the CountProvider ﹣

export default function App() {
  // Starting off with an initial count of 10
  return (
    <CountProvider value={10}>
      <CountDisplay />
      <Controls />
    </CountProvider>
  );
}

Now you can use useCounter hook inside both <CountDisplay/> & <Controls/> components. When the count changes in the <Controls/> component, it will cause the <CountProvider/> to re-render & will also update the <CountDisplay/> component.

This is based on the React.Context API. I have written a detailed page on its performance & when to use it in your application.

Following is a working codesandbox of the counter app ﹣

</iframe>

Read about it detail on Github

Share your thoughts about using this library. I'm open to feedbacks & ideas ✌🏽

A better Image component for React Native

Fri, 04 Sep 2020 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

Introducing a better image component for React Native!

<PostImage src="/toolkit-logos/better-image-loading.gif" alt="better-image-loading"

Image loading with better-image library </PostImage>

React Native only includes a basic image component. However, I always needed two very important functionalities on the Image component:

A fallback image if the original source fails to load
Progressive image loading (especially for banners & cover images)

So I customized the existing <Image/> component and have been using this <BetterImage/> component in my projects. Today, I'm open-sourcing my component to receive feedbacks & ideas from the community.

Do try it out at react-native-toolkit/react-native-better-image

I have also created a storybook with detailed docs at betterimage.netlify.app

What other features do you think are essential for the Image component? Share your ideas & I'll be happy to help 👍

Drawing Triangles in React Native

Thu, 04 Jun 2020 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

<PostImage src="/toolkit-logos/triangle.png" alt="better-image-loading"> React Native Triangle </PostImage>

<blockquote class="twitter-tweet"> <p lang="en" dir="ltr"> I have decided to focus on open-sourcing all the components I have built for React Native. Starting with the Triangle! <a href="https://t.co/F1ohUA9poE">https://t.co/F1ohUA9poE</a> </p> — Dani Akash 🧪💥 (@dani_akash_){" "} <a href="https://twitter.com/dani_akash_/status/1268744578305110019?ref_src=twsrc%5Etfw"> June 5, 2020 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

I always come across a scenario where my UI needs a triangle view. Also I needed fine control over all aspects of the triangle view. Hence I built @react-native-toolkit/triangle view based on the well known CSS trick to create triangles on the web.

As my requirements grew, I was adding more features to the library and now it supports almost all possible triangles you need. Hence I'm open sourcing it today for general use.

</iframe>

I initially used react-native-triangle but it's configuration is fairly limited and I couldn't control many of the triangle properties. Hence this library became a necessity.

Also, I have started to work on open sourcing all the libraries I built for react native over the years for my personal projects. Will be slowly moving them over to React Native Toolkit. Stay tuned for future updates!

I recreated React's class component lifecycle methods with hooks

Thu, 21 May 2020 18:30:00 GMT

<blockquote class="twitter-tweet"> <p lang="en" dir="ltr"> felt evil, so created this 😈{" "} <a href="https://t.co/etX0sFJbVl">pic.twitter.com/etX0sFJbVl</a> </p> — Dani Akash 🧪💥 (@dani_akash_){" "} <a href="https://twitter.com/dani_akash_/status/1263327984640946177?ref_src=twsrc%5Etfw"> May 21, 2020 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

Project - lifecycle-hooks, also available in npm

I recently started working on an old react native project where I had to upgrade react-navigation from v3 to v5.

To take advantage of the new navigation hooks in version 5, I had to migrate existing class components to react hooks.

At first, it seemed like a straight forward case of refactoring some bit of code. However, I quickly realized how difficult the task at hand is...

Class component to hooks conversion is just not straight forward. Hooks are awesome when you are building new components but they are definitely not created with migrating class components in mind.

As react documentation says, class components aren't going away, so you probably won't have to migrate your project to functional components in most cases.

But if you run into a situation like me where you need the powerful hooks from react-navigation, react-spring or any other similar library, lifecycle-hooks will make your migration a lot easier.

traditional class state

// Initialization
this.state = {
  name: "",
  email: "",
};

// updating name
this.setState({
  name: "John Doe",
});

lifecycle-hook's `useState`

import { useState } from "@daniakash/lifecycle-hooks";

// Initialization
const [state, setState] = useState({
  name: "",
  email: "",
});

// updating name
setState({
  name: "John Doe",
});

Likewise, I have also created hooks for componentDidMount, componentDidUpdate & componentWillUnmount which will let you quickly move code without having to worry about dependency arrays of useEffect

You can try these hooks in the following codesandbox playground. Let me know your thoughts! Feedbacks & PRs welcome ✨

</iframe>

UX friendly loading indicators

Wed, 08 Apr 2020 18:30:00 GMT

I love loading indicators. Especially ever since lottie animations came out, I have been playing around with different kinds of animations as loading indicators. However, these loading indicators often pose a huge UX Issue when used to display "waiting" for fetch requests.

Let's say you have a nice loading indicator like this one & a webpage that makes a network request to fetch quote of the day.

If you use this loading indicator directly, on a super-fast connection, where the request resolves in 200ms, then you'll notice that the loading indicator basically flashes in between the old & new content ﹣

</iframe>

The loading indicator is nice for content that takes 1000ms+ response time. However, it is not suitable for content that takes very small time like 200ms. But the content, however, is loaded over the network which means for users with fast 5G 🛰 connection the response time is going to be 200ms 🚀 while for users with slow 3G/2G connections the response time might be higher for the same content ☹️

<blockquote class="twitter-tweet"> <p lang="en" dir="ltr"> Collectively -<br /> <br /> Given the different kinds of network speeds there are three speeds in which a fetch will complete <br /> <br /> 1) short <br /> 2) medium <br /> 3) long </p> — Dani Akash 🧪💥 (@dani_akash_){" "} <a href="https://twitter.com/dani_akash_/status/1247617453795840000?ref_src=twsrc%5Etfw"> April 7, 2020 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

To provide optimal user experience in this scenario, we need different loading indicators for each type of network speeds and we have to maintain a separate "loading-state" that ensures we are displaying the proper loading indicator.

On digging deep into this topic, React team has done a great deal of research in the suspense module which does optimistic rendering and doesn't display any loading indicators if the request is resolved quickly!

I have written a summary of my learnings in a separate tweet thread which you can also read using thread reader

For an ideal UX for a scenario such as the one in the above codesandbox sample,

if the request resolves in 200ms
- no loading indicator is needed
if the request resolves in 500ms
- no loading indicator is needed till 200ms
- a loading indicator appears at 300ms (something non-intrusive)
- the loading indicator is visible till 600ms (even though the data is retrieved at 500ms) to ensure the UI doesn't appear as if it is stuttering/flashing for the user
if the request resolves in 1200ms
- following above timeline, a loading indicator is displayed till 600ms
- after 1000ms, another loading indicator appears (seems like the user is in a slow network region)
- this loading indicator will remain visible till 1300ms (to prevent the users from seeing a flashing screen)

Applying this logic, try the following example ﹣

</iframe>

This time, at

200ms no loading indicators are needed.
300ms+ we have a loading indicator which a gentle opacity that is mandatorily visible for 300ms before displaying the data
1000ms+ we have another animated loading indicator which is also visible for 300ms before displaying the data

For the second example, I have built a javascript library ﹣ "loading-state" which maintains the loading state internally using setTimeout and provides an easy to use API to display the loading indicators.

import loader from "loading-state";

loader(
  new Promise((resolve, reject) => resolve("cool!")),
  {
    shortLoading: () => {}, // callback to display first loading indicator
    longLoading: () => {}, // callback to display the second indicator
    done: (result) => {}, // success callback with the result of the promise
    error: (e) => {}, // error callback with the thrown error
  },
  {
    busyDelayMs: 300, // how long to wait till displaying first indicator
    longBusyDelayMs: 1000, // how long to wait till displaying second indicator
    shortIndicatorVisibilityMs: 300, // how long to display first indicator
    longIndicatorVisibilityMs: 300, // how long to display second indicator
  },
);

With this, we can effectively maintain the loading state of our network request & ensure that the UX is not affected for the user based on their network speeds!

React Native Responsive Dimensions updated to 3.1.0

Fri, 20 Mar 2020 18:30:00 GMT

React Native Responsive Dimensions have been updated to version 3.1.0 with full typescript support & a whole bunch of new utilities quickly check out the new release at github

First published three years ago as a simple utility to resize some views based on the device's screen size, responsive dimensions quickly became one of the favourite tools for my colleagues and many react native developers. I was updating it once a year with a few new things like the responsive hooks last year. But this update is quite important!

I recently worked with Rachel Nabors on React Native Component Docs Drive where while documenting the actual react native's inbuilt dimensions module, I realized Responsive Dimensions has a great potential to simplify application development for foldables and react-native-web apps.

With this new update, Responsive Dimensions now have

Separate utilities for Responsive "window" & "screen" sizes (screen sizes will be useful while working with foldables)
New responsive screen size hooks
useDimensionsChange hook to let your application respond to dimension changes

See the release notes for a full list of changes and also checkout the example projects at Snack & CodeSandbox

Do let me know if you have any feature requests or feedbacks ﹣ always happy to help 😁👍

Introducing Rex State 🦖

Wed, 18 Mar 2020 18:30:00 GMT

⚠️ As nice as this tool was, I have moved on from this project. I recommend using tools like Zustand, Jotai, or use-context-selector for managing states in your React projects.

The simplest way to manage your React States! Check out the demo app

I have been using Redux and Mobx for managing states in my react projects. Ever since React Hooks were introduced I had been playing around with the Context API experimenting different ways to manage states.

I finally came up with Rex State, a tool that I have been using in my personal projects for creating re-usable hooks as well as state management.

The idea behind Rex State is making your states more declarative and providing an easy to use API to connect with the React Components. A classic example ﹣

import React from "react";
import useRex from "rex-state";

const useInput = () => {
  const [state, setState] = useRex({ value: "" });

  return {
    get value() {
      return state.value;
    },
    updateValue(value) {
      setState({ value });
    },
  };
};

const InputField = () => {
  const { value, updateValue } = useInput();

  return (
    <input
      type="text"
      value={value}
      placeholder="Add Text here..."
      onChange={(event) => updateValue(event.target.value)}
    />
  );
};

export default InputField;

Rex State can also be used as a state management tool. A 400 bytes replacement to redux or mobx ✨

Follow this tutorial to see how to manage states with Rex State.

Feedbacks & PRs welcome! 😁

Github

The 10 things I learnt (or) tried learning in 2019

Sat, 04 Jan 2020 00:00:00 GMT

import PostImage from "../../components/PostImage.astro";

<PostImage src="/tried-learning/spider-man.webp" alt="learning"> Photo by Road Trip with Raj on Unsplash </PostImage>

I started my career in 2016 as a Javascript developer. Since then, I took a resolution to myself that I'd learn at least 3 new things every year. It is supposed to be part of my life-long learning exercise and to prevent myself hitting a wall down my career path.

First year it was quite difficult as I was just starting my career and there were just too many things to learn. Once you realize there's too much to learn it creates an endless cycle of procrastination and a mental barrier whenever you pick up some topic. In my first year of this process, I wasted the whole first 6 months running after superficial targets like blockchain, AR, VR, ML etc. They were relatively new at that time and as a beginner they were pretty overwhelming. I ended up in a paradoxical state where I'm trying to learn something but end up going after another topic without actually making any progress on the first one.

Overcoming the block

The year of 2016 was moving fast and I'm trying to establish a solid foundation for my career all while trying to learn something new for personal growth. It was when I realized that I'm not making any progress. Comparing me with myself from the past 6 months ﹣ nothing much has changed except for the experience I gained at work as a Node.js developer. I knew it's probably time for me to stop and think about it for a while. After a week of long self evaluation on how I'm approaching things, I decided to dedicate the rest of the year (which was just 4 months now) to learn only one new topic with a condition that the topic should be easy and straight forward to learn.

Guess what? by the end of 2016, I ended up learning React.js and I had very little idea that it will later end up defining many of my future career milestones. For learning react I had to learn a lot Javascript fundamentals, new programming paradigms (like functional programming) and tools like webpack, babel etc. I realized two things that are essential for the learning process.

Whatever you learn,

Ensure you learn everything properly
The rest of the universe can wait

Javascript By Example

Learning React is one thing but the true knowledge I gained in 2016 was how to learn. I dedicated my entire 2017 on learning and further refining my Javascript skill-set. After spending almost a year on the learning process I decided it was time I shared a few things with the world and luckily I got an opportunity with Packt to write and publish my first book ﹣ "Javascript By Example". It was a great experience. I got to learn how to approach things from a writer's perspective and plan chapters on different topics. The entire year of 2017 was spent on learning and writing about Javascript.

Learning doesn't always need a reason

The first two years of my learning process were focused entirely on career growth. At the end of each year I spend a considerable amount of time thinking back on all the things I learnt and the things I wanted to learn. I love science. But in the past two years I haven't spent much time on learning anything new on science except watching a few documentaries (like particle fever) perhaps. Starting 2018, I decided to include a topic on Science (it can be anything) into my learning process. It should be now 3 topics on tech and 1 on science.

I have listed below all the topics I picked up to learn and a ✔️ indicates that I have been successful in learning the concepts associated with the topic and a ❌ indicates I just messed up badly.

This is how my 2018 went:

Reactive Programming & ReactiveX ﹣ ❌
Machine Learning ﹣ ❌
MobX ﹣ ✔️
React Native Reanimated ﹣ ❌
GraphQL ﹣ ❌
JAMstack ﹣ ✔️
Rocket Science ﹣ ❌

Oh wait did I just mess up badly again? Maybe... The topics aren't tough to learn except for the Rocket Science part (It's literally Rocket Science). I did manage to learn a few things from all the topics I decided to learn last year but the problem is, on an implementation level, I didn't put much effort into building stuff that uses these concepts. Even though I understood what these things do, I decided I ain't marking them complete until I build stuff that uses these concepts. For the Rocket Science part ﹣ it isn't complete till I could derive those equations by myself. I was a bit too strict on myself but I had to... cuz nobody else will!

2K19 - Time for a blast! 🚀

I know what I needed to learn. I know how I'm supposed to learn. With these two things in my mind, I stepped into 2019 with the same target ﹣ 3 topics from tech, 1 from science. This year I am at a good position in my career path so I had very less to worry about and I had the complete freedom to pick up topics that were interesting rather than helping my career growth. I'll be listing out the 10 items I focused primarily throughout the year and how each of them went. This year is different, supposed to be different, should be different.

1. Machine Learning ﹣ ❌

Did I say different? cuz I just messed up the first and the most important topic I was supposed to be learning this year! I initially planned on learning machine learning back in 2016, when I started my career. But every year I just kept hitting several blocks whenever I pick up this topic. Machine learning isn't a tough thing to learn in 2019. In fact, now is the best time to learn this given how we have a diverse collection of libraries like Tensorflow, Scikit learn etc. But what exactly went wrong here?

For starters, my selection of starter materials were too deep. I started off with the famous Hands-On Machine Learning with Scikit-Learn and TensorFlow book and it was a slow process. I wanted to do this right, too right for my own good and I ended up back in the procrastination loop. Before I waste much more of my time in this, I decided to look for shorter, more quicker ways to learn this topic later. And that later never happened.

2. Fundamentals of Quantum Mechanics ﹣ ✔️

Inspired by the Particle Fever documentary and the hype created around quantum computers, I realized I had to learn this one. I have been passively reading about quantum mechanics concepts like quantum entanglement, quantum tunneling etc. but I had to ensure I'm ready by the time humans reach Quantum Supremacy (which Google did achieve later this year).

Quantum mechanics is the study of the fundamental particles that make up the universe, except, no on has any clue how the world works down there. Almost any kind of laws of physics we apply in the real world doesn't work there and We cannot observe that world as observing the particles changes the particles (Heisenberg uncertainty principle).

So, How do you learn a topic that is only taught at major universities like MIT? You simply watch the classes on YouTube and follow along like regular students do ✌️. This of course takes a lot of time given there are 115 videos in that playlist, but I managed to sit through 45 videos and it only took me 3 months! (And it's already March 😶). No wonder I didn't had the time for Machine Learning. I was also passively going through OpenLearn course-ware and the awesome How to Teach Quantum Physics to Your Dog book which you might wanna checkout, if you are interested...

3. Testing Library ﹣ ✔️

I don't remember when I last build some user interfaces without relying on React. It has become such an integral part of my developer life that I'm constantly building and modifying React components every day. However, traditional testing tools like snapshot testing and enzyme weren't keeping up with the fast paced development modes. Most of the test cases often end up breaking badly for trivial changes and many scenarios feel like unnecessary burden on the developer's shoulders. This all leads to some very poor test coverage at the end of the day (0 in my case 😅)

Enter ﹣ Testing Library where you test how users interact with your components rather than how these components are actually implemented. This encourages a lot of good programming and testing practices. This was a topic that was picked up due to the need for having a proper test framework in place for all the projects i'm working with and I have no regrets. The best part of testing library is that it works very nicely with React and has a wide collection of recipes which you might need a lot!

4. Quantum Computing ﹣ ⚠️

Quantum Computers are the next big thing happening to computers ever since transistors arrived. We are heading into a severe limitation of computing power with the traditional computers so I totally wanted to be able to program quantum computers by the end of this year! However, there's one small problem... Like Graphene, quantum computers can do just about anything except leave the lab.

The best resource I'd recommend for anyone starting off with quantum computers is obviously learning a bit of quantum mechanics but once those particle physics terms start making sense to you, head over to the amazing Microsoft Quantum Documentation where you can learn the essentials of quantum computing with the nice C# eco-system or the from the comfort of python. They have a nice Quantum Development Kit that lets you run your code inside a quantum simulator. There's also a nice book that I have been reading (still reading) which you might find coming in handy ﹣ Programming Quantum Computers

I'm kicking off 2020 with Quantum Computing so I'm not done with it yet. Might write a few blog posts or give some tech talks on my experience so far. Gotta be ready when those Qubits are ready to be manufactured!

5. String Theory ﹣ ✔️

String Theory is simply hands down the best thing I decided to learn in 2019. It is by far the theory closest to explaining everything in the Universe. I wanted to clearly understand how it explains every single thing in the nature and of course understand the famous derivation Sheldon used while he was explaining string theory to Penny (the actual scene). I started off with buying a kindle edition of The Elegant Universe by Brain Greene. (You might love his direct explanation)

As usual like every topic in science, string theory requires a lot of pre-requisites that includes understanding how theories before it failed to explain the nature of Universe. First of all I had to understand the special theory of relativity (refer ﹣ minutephysics). Then I learnt about the forces of nature, additional dimensions and how sum of all positive natural numbers add up to -1/12 😶

<blockquote class="twitter-tweet" data-dnt="true" data-theme="dark"> <p lang="en" dir="ltr"> <a href="https://twitter.com/hashtag/Maths?src=hash&ref_src=twsrc%5Etfw"> #Maths </a>{" "} is all fun and games until you realize the sum of all positive natural numbers is a negative number <br /> <br /> 1+2+3+4+....+∞ = -0.0833333 <br /> <a href="https://twitter.com/hashtag/Ramanujan?src=hash&ref_src=twsrc%5Etfw"> #Ramanujan </a>{" "} <a href="https://twitter.com/hashtag/Summation?src=hash&ref_src=twsrc%5Etfw"> #Summation </a> </p> — Dani Akash (<a href="https://twitter.com/dani_akash_">@dani_akash_</a> ){" "} <a href="https://twitter.com/dani_akash_/status/1148293397775413248?ref_src=twsrc%5Etfw"> July 8, 2019 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

Before I knew it, I was watching ted talks after ted talks, running behind the easiest explanations for confusing concepts in YouTube. But I kept making steady progress with the book thanks to my curiosity to understand the nature of the Universe and the need to understand the Sheldon's side of conversation.

After 6 months of reading, watching, tweeting, creating memes and scribbling, I finally went back to watch the scene and when Sheldon said "if you consider them sheets" I could totally visualize it in my mind. That right there is a huge sense of accomplishment I'll never forget. If you wanna learn about String Theory the best starting point will be ﹣ "String Theory Explained" video by Kurzgesagt.

6. Finite State Machines & XState ﹣ ✔️

Meanwhile, as I spent almost half of the year learning String Theory over the night, during the day my career was moving forward facing more new challenges. As a part of React application development, state management proved to be a huge challenge as the team size kept increasing. We couldn't set a standard to define states and how to properly handle state transitions. That led me to search for newer ways of application state management.

I'm a big fan of Turing Machine ever since I watched The Imitation Game. I had already put in considerable effort on understanding the concept behind Alan's turing machine which falls under a class of Automata Theory. One of the sub classes involved in Turing Machine is Finite-state Machine (FSM). I didn't pay much attention to it until I came across XState ﹣ a library for building FSM in Javascript. Turns out XState holds the key to solve all my worries about state management. Its based on one of the most fundamental concepts of computer science after all!

I spent a few days building a react app based on Reddit API integration from the docs. Then I went on to check out few open source projects that were built on top of XState. These are pretty much the standard steps for learning any new Javascript framework at this point. The official docs have some good examples. Also, if you want to stay up-to-date, you can follow the related accounts on Twitter. (Follow David K.🎹 creator of XState)

Instead of defining states and managing them separately XState makes state definition and management a single entity simplifying the application logic to a great extend. I have also tried using it with Node.js and it works seamlessly with the backend frameworks too!

7. TypeScript - ✔️

TypeScript was picked up as more of a tech debt that I didn't pay attention to for the past couple of years. Given how much the JavaScript ecosystem has grown and the complexity of the apps we are building with it, having a safe type system is very important. Of course It took me two of my senior folks pushing me to use it in my project at work to get started. But once I got into it, I realized there's no turning back. It will make you wonder how you survived this long without having proper type definitions.

For starters, you can try TypeScript in 5 minutes from the official docs to get an idea of what TypeScript is all about. React Native folks are in luck as it comes with typescript support out of the box (lucky me!) and you can directly convert a file from .js to .ts or .tsx and start writing types right away! Setting up typescript with other bundlers is relatively easy and I'd recommend you to use Parcel if you are starting a new project.

I just decided to dive right in after reading a couple of blogs and watching an YouTube video over night. Sometimes you just gotta go for it! This cheatsheet had me covered throughout my initial steps. But if you need in-depth knowledge, you should be reading this free book by Basarat ﹣ "TypeScript Deep Dive".

8. Neural Networks ﹣ ❌

That was the end of my 7 month success streak, but there's lot to learn from mistakes so I'd consider Neural Networks a win-win challenge. While I was travelling to Bangalore for a tech conference on June, I was listening to an audio-book based on a non-fiction book by David Eagleman ﹣ "The Brain: The Story of You". It's about the working of the Human Brain and the way the author explained the things made me develop an overwhelming interest on learning more about the process of thinking itself.

Our brain is a network of millions of neurons. To understand how the process of thinking works, what better way there is than to build our own Artificial Neural Networks (ANN). So, I decided to build my own neural network. There are abundant resources for learning ANN. There are also plenty of frameworks like TensorFlow, Keras and Caffe that make adding neural networks into your project a breeze. However, before I go out and use third party libraries to do the heavy lifting, I wanted to build my own network without any fancy tools.

Luckily, I found the Neural Networks Playlist by 3Blue1Brown on YouTube which had exactly what I needed to learn about neural networks. It provided a good launchpad to learn more on the topic. But then, before I realized, I ended up watching more videos from this channel and my mind diverted into more fun ideas like Calculus and Linear Algebra putting an halt to my journey on learning ANN. By the time I realized I was supposed to be building my own network, it was the mid of December and I was infected by a common cold which would later put me in bed for the next two weeks ruining all my travel plans for the holidays.

9. Swift UI ﹣ ❌

####Building iOS Apps ﹣ Dani's Journal entries

Sometime in 2016 ﹣ Dani realizes the potential of Apple's iOS & macOS Devices and the Swift programming language and starts learning iOS App development

Again sometime in 2016 ﹣ Dani builds some iOS apps with poor designs convincing himself that he is now an iOS Developer

October 2017 ﹣ Dani becomes a mobile app developer but on React Native instead of iOS and builds totally cool apps due to his natural aptitude in JS

2017-2018 ﹣ Despite building beautiful & successful apps on React Native (thanks to flexbox and the UI/UX designers he worked with), Dani still tries to build apps with swift on iOS but he couldn't cuz he has the designing skills of a potato

3 June 2019 ﹣ Dani watches Apple's WWDC 2019 to create memes about apple & apple devices, but was surprised when they announced SwiftUI. It's like someone in Apple listened to his worries and decided to make the design process much simpler! He decides to learn SwiftUI. (He still created tons of memes after the event since they also introduced an expensive cheese grater)

October 2019 ﹣ Dani successfully builds a simple iOS App with SwiftUI and runs it on his iPhone SE. Feeling accomplished, he decides to build more advanced apps hoping to learn more about SwiftUI

December 2019 ﹣ By this time, Dani has already forgotten that he was supposed to learn SwiftUI and also that he owned an iPhone

####End of the Journal entries

10. Vim & Tmux ﹣ ✔️

Finally, it's time to introduce my new terminal workflow. After using iTerm2, Hyper and Terminator, I was tired of looking for a terminal that can be used consistently between mac and linux. Turns out I was looking at the problem in a wrong way. I was looking for better terminals but what I actually wanted was a workflow that can taken to any operating system easily.

I use a 15 inch Macbook pro at work and a easy to carry 13 inch hp laptop running ubuntu MATE when I'm travelling. I also have two Amazon Ec2 instances that I always ssh into for quickly deploying and running personal projects. Also I always edit the code directly in the server (Please don't try this at work!). Given that most of my work requires a terminal and multiple tabs, I decided to pay two old friends a visit. The friends from my childhood I never understood properly before I started hanging out with all the cool guys ﹣ Vim & Tmux.

The main problem with Vim & Tmux is there was a big learning curve. But with my experience of learning TypeScript using a cheat-sheet, I understood I can overcome any learning curve if I lived dangerously (Again! Please don't try this at work!!). I took my ubuntu laptop and uninstalled Terminator, VSCode & WebStorm leaving behind gedit as my only text editor for backup. Then I installed Neovim and added some of the essentials like amix/vimrc and the Ben Awad's VSCode vim setup. After which I installed tmux along with Oh my Tmux.

For the cheat sheets, I got this amazing wallpaper from reddit that contains all the essential vim keybindings. Given my terminal is transparent, the keybindings never leave my sight! It's surprising how fast I got used to the new vim + tmux setup once I removed all the other text editors from my system (Most of this post was written from vim). Finally, after a couple of weeks I got well used to my setup and decided to move the workflow to all my systems. With a quick setup based this answer, I was able to sync my config across all my devices. Will write a separate blog post regarding my setup since the size of the current post keeps increasing.

It's 2020

I'm glad I took the time to reflect on all the things I have been learning in the past year. Also, pretty happy that I took the time to write my experience in my personal blog. I usually don't plan too much and simply learn as I find interesting stuff but I have a pretty good idea how 2020 is going to be ﹣ tech talks, blog posts, fluid animations and SwiftUI cuz why not? 😜

<blockquote class="twitter-tweet" data-theme="dark"> <p lang="en" dir="ltr"> Please ensure whatever you learn, you have plenty of fun, otherwise, it ain’t worth learning </p> — 𝙳𝚊𝚗𝚒 𝙰𝚔𝚊𝚜𝚑 (@dani_akash_){" "} <a href="https://twitter.com/dani_akash_/status/1213503169113681921?ref_src=twsrc%5Etfw"> January 4, 2020 </a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

This post marks the launch of Dani's personal website & his personal blog daniakash.com which was initially planned to go live on last December. Not a great start but as the saying goes... better late than never!

The Periodic Table & The Stars

Sat, 14 Dec 2019 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

Humanity is progressing faster than ever before. We have smartwatches, VR goggles, electric vehicles and all the cool gadgets thanks to all the developments in science & research over the last decade. But how exactly did these things became possible?

A planet rich in resources

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_photo-1518770660439-4636190af475.jpg" alt="post-cover"

Photo by Alexandre Debiève on Unsplash </PostImage>

Unlike most planets of our solar system, which are filled with gases, we live in one of the rockiest planets ﹣ The Earth. And within our planet, we have an abundance of elements such as silicon, copper, lithium, gold, etc. which enables us to build complex buildings, machinery and circuits.

These elements are vital to the progress of the modern mankind. They are formed by different combination of protons and neutrons held together by strong nuclear force and electrons that move around them attracted by the positive charge of the protons.

This difference in structures of various elements gives them unique properties, making them suitable for building different components of our technology. They all follow a common pattern in their structure we decided to organize them based on their atomic structure in a table called ﹣ "The Periodic Table"

Periodic Table

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_2880px-Simple_Periodic_Table_Chart-en.svg.png" alt="periodic-table"

Image from Wikipedia </PostImage>

A quick search in google returns an interesting definition for the periodic table ﹣

A table of the chemical elements arranged in order of atomic number, usually in rows, so that elements with similar atomic structure (and hence similar chemical properties) appear in vertical columns.

Elements are built by the combination of atoms and these atoms are made of protons, neutrons and electrons. In 1869, Russian chemist Dimitri Mendeleev decided to organize the different elements into a system by arranging these elements in the order of increasing atomic weight and also grouped them in such a way that the elements with similar properties are placed together. He realized a pattern began to form in his arrangement system. Back then, when only about 60 elements were known to man, he had left blank placeholders in his system for the future generations to fill in.

This system of organization was later known to be the Periodic Table. The places that were left blank were eventually filled up with new elements that were discovered later. This system works so well that we can predict the existence & properties of elements before we can even discover them.

Modern periodic table has elements organized by their atomic number ﹣ sum of protons and neutrons in their nuclei instead of the atomic weight and has about 118 elements. The rows in the table are called periods and there are 7 periods. The vertical columns are called groups or families. The periods 6 (lanthanoid series) & 7 (actinoid series) are too long that they have been moved into two separate rows at the bottom of the table so that they can be printed on paper easily.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_periodic-properties.jpg" alt="periodic-table"

Image from Britannica </PostImage>

The most interesting thing about the periodic table is that the elements belonging to the same group have similar characteristic properties. The protons in the atomic nuclei attract the electrons around it and when we move across the periodic table, the number of protons & neutrons in the atomic nuclei increases which in-turn attracts more electrons. Now these electrons are not always well balanced. Think of electrons as moving in multiple orbits around the nuclei. Then the electrons in the outermost orbit are called valence electrons. These electrons determine the chemical reactivity of the element (the chemical bond the element can establish with other elements)

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_Nucleus-valence-electron.jpg-.jpg" alt="valence-electrons"

Image from ScienceABC </PostImage>

Valence Electrons & Chemical Bonding

An element may have an arrangement of electrons where it's valence electrons are not stable and can either readily lose them or accept more electrons. When an element that can readily accept electrons comes in contact with element that can easily lose electrons, they form a chemical bonding.

Ever wondered why iron easily rusts? Iron has an electron arrangement that can readily accept 3 electrons while oxygen has an electron arrangement that it can lose 2 electrons. So by basic mathematics, 2 iron atoms can bond with 3 oxygen atoms and form iron oxide

Group Properties

Just like how iron has an oxidation state, all the metals that belong to its group has multiple oxidation states and they are commonly referred to as Transition Metals (Group 3 - 12). Some groups however, are very stable. For example, the Group 18 of the periodic table are all noble gases. The number of electrons in their atoms are well balanced that they don't need to gain or lose any extra electrons. Which makes them chemically stable and generally non-reactive to other elements

These noble gases have various applications. For example, Argon (Ar), an inert gas is used to fill electric light bulbs as they are highly non-reactive and don't react with the Tungsten filament used in these bulbs.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_lightbulb-1875255_1280.jpg" alt="electric-bulb"

Image from Pixabay </PostImage>

Semiconductors

Another interesting group of elements we can find in the periodic table are the semiconductors, a special set of elements that can either conduct electricity or not conduct electricity depending on the availability of free electrons. There are different types of semiconductors. But let's look at elemental semiconductors present in Group 14 (also knows as the carbon group). Silicon (Si) ﹣ a Group 14 elemental semiconductor is so widely used in modern computing, the famous Silicon Valley is named after it.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_silicon-valley.jpg" alt="silicon-valley"

Image from Wikipedia </PostImage>

Elements conduct electricity by letting electrons flow through them when electric current is passed. For this to happen they should be able to readily lose their valence electrons. A good conductor has only 1 valence electron which it can readily lose and hence let electricity flow through. A bad conductor (or insulator) however has a stable 8 valence electrons in which case, it will not allow electricity to flow. The semiconductors however have 4 valence electrons in which we can control if it should or should not conduct electricity.

Silicon as it's own doesn't conduct electricity. But if we add some Phosphorous to the silicon atoms, it will form a bond but leaves an extra free electron. This creates the excess negative charge and makes the material conduct electricity. This type of conducting electricity using additional negative charge is called N-type semiconductor.

Likewise, if you add Boron atoms to the mix, then it creates excess positive charge and then creates a P-type semiconductor. By arranging N-type and P-type semiconductors in specific ways we can allow either current to flow through them or completely block the current. This corresponds to 0's & 1's we use in modern computers and yes they form the basis of all the modern devices ﹣ Transistors. All the modern processors be it mobile, desktop or any smart IoT device, they have transistors as their base. For example, the latest Apple's A13 bionic chip has about 8.5 billion transistors built into it.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_apple-transistors.png" alt="a13-bionic-transistors"

Image from Apple. From September, 2019 event </PostImage>

Need more?

There are still a wide variety of elements available in the periodic table that we can use to build various pieces of modern technology. Elements like Gold, Silver, Platinum, Copper to name a few. And these elements form the foundation of modern human society.

As we move forward in the periodic table, the atomic number keeps on increasing. Which means the number of protons in the atomic nuclei is increasing. As it does, the repulsive force of the protons grow stronger against the strong nuclear force that is holding the atoms together.

Radioactivity

At atomic weight 145 we find an element called Promethium (Pm). The protons in the nuclei of this element is too heavy that it's strong nuclear force could not hold them together. This element undergoes a phenomena known as Radioactive decay where it decays to elements of smaller atomic number by emitting energy in the form of radiation.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_512px-Radioactive.svg.png" alt="radioactive-warning"

Image from Wikipedia </PostImage>

As we move forward, we find more and more elements that are very unstable due to large number of protons in their atomic nuclei and undergo radioactive decay with the emission of harmful radiations ﹣ elements like Uranium (U). However, as dangerous as they sound, they form the primary power source of nuclear fission reactors, which capitalize on the energy released when these elements split into elements of smaller atomic numbers.

Heavier Elements

As elements get heavier with increased atomic weight, they tend to become rare to find on our planet. And elements heavier than Uranium doesn't exist naturally at all. It is primarily due to two main factors.

The elements decay too fast and weren't observable
There weren't enough natural events that create these elements

The first part can be easily understood. Since they are highly unstable, they simply decay. The second part, however, holds something much more important to learn. There is a natural event that has been creating all the elements we so far listed in the periodic table. It is essential that we learn about this event before we go into details about the heavier elements.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_something-happening.gif" alt="something-happening"

via Giphy </PostImage>

All the patterns, the precision in the atomic structure, have been put into these elements through a natural process that has been happening for almost billions of years! If you are wondering what the process actually is, here's a clue ﹣ It starts with a bang!

At the beginning of everything

The most accurate theory we have about the beginning of the Universe is the Big Bang hypothesis. It states that the universe was once a singularity at very high temperature & pressure which then exploded and stared to expanding indefinitely. As the expansion began, the universe also started cooling eventually, letting the initial fundamental particles to interact with each other. These led to the creation of protons, neutrons and electrons.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_big-bang.gif" alt="big-bang"

_via via Giphy </PostImage>

The positively charged protons attracted the electrons, which led to the formation of the first and the simplest element in the periodic table ﹣ Hydrogen (H). Hydrogen has only one proton and one electron. Given the amount of temperature and pressure, the conditions were also favorable for the formation of the first few elements in the table, such as Helium and Lithium. However, the rest of the elements in the periodic table haven't been produced yet.

Enter - Gravity!

Once the universe started expanding, one of the most fundamental forces came into play. Gravity started attracting matter together. This included all the newly formed Hydrogen. Once matter started gathering, they attracted more matter and eventually they started pressing on each other so hard that they started to press multiple Hydrogen atoms over each other. This gave rise to a naturally occurring nuclear fusion in which Hydrogen atoms got fused into Helium with a release of huge amount of energy.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_fusion-star.gif" alt="fusion-star"

via Giphy </PostImage>

This nuclear fusion was self sustaining as the massive amount of matter kept pushing at each other continuously due to gravity, leading to release of large amount of heat and light. They formed giant balls of burning gases which will later be known to the humanity as the Primordial Stars.

During a star's life cycle, it fights the gravity which is trying to push all it's matter into a single point by fusing hydrogen (H) into helium (He) and pushing back with the energy released in the process. The process can continue for over billions of years in it's core until eventually all the Hydrogen atoms are completely exhausted.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_pushing.gif" alt="pushing"

via Giphy </PostImage>

Once the Hydrogen is gone, the star will fuse Helium into heavier elements. The helium atom has 1 proton, 1 neutron and 2 electrons. The stars will push multiple helium atoms together, forcing the atomic nuclei to merge into a new element. This will create the elements that are further up the periodic table. Elements like Lithium, Beryllium, Boron etc. starts to form in the Star. This process will continue creating more elements from the periodic table as the fusion continues until it reaches Iron(Fe). Iron does not fuse inside a star into heavier elements in the periodic table and this leads to the death of the star.

Supernova

When Iron is formed in the Star's core, it can no longer fight back against gravity. Smaller stars like our Sun eventually starts increasing in size when it runs out of Hydrogen and fusion of heavier nuclei starts turning into a red giant. But once Iron is formed, the Sun will burn out and will become a small white dwarf.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_red-giant-white-dwarf.gif" alt="red-giant-white-dwarf"

via Giphy </PostImage>

However, when a star several times massive as our Sun runs out of Hydrogen, an interesting phenomenon happens. The Star's gravity will be too strong and it will continue fusion till it reaches Iron. But the gravity continues to push the star inwards. Think of it as an Iron ball size of Earth being pushed into a sphere in the size of a small city. The entire star gets pulled into it's center at 1/4 times the speed of light and the elements will bounce off the Iron core producing a huge explosion of shockwaves, energy and light brighter than a whole galaxy.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_supernova.gif" alt="supernova"

via Giphy </PostImage>

This big explosion is called a Supernova and this will scatter all the elements throughout space. The conditions during a supernova are so severe that it creates elements heavier than iron in the periodic table. Luckily all of them are scattered throughout the galaxy for millions of kilometers. After the supernova, very massive stars become black holes while some become another interesting type of star called a Neutron Star.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_neutron-star.gif" alt="neutron-star"

via Giphy </PostImage>

Kilonova

A neutron star is a type of star that is compressed so tightly that the protons & electrons in the atom join and become neutrons. These stars are very dense and have the strongest gravitational force in the Universe after the black holes. Their gravity is so strong that light bends around them making all of their sides visible. The core of such a star can destroy the commonly known atomic structure leaving us no clue but only wonder what might be present in them ﹣ a quark-gluon plasma or strange matter?! Nobody really knows.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_nobody-knows.gif" alt="nobody-knows"

via Giphy </PostImage>

The neutron star that we are concerned with here is the one in a binary star system ﹣ two neutron stars spinning around each other attracted by gravity. Such a binary neutron star system eventually collapse with a massive explosion called Kilonova (which we recently observed in 2017). This explosion provides the necessary conditions for creation of super heavy elements in the periodic table such as Gold, Platinum, Uranium, Plutonium etc. This is why elements with higher atomic numbers get rarer to find as we move through the periodic table, not only do they need a star to die but they need the star to die twice.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_kilonova.gif" alt="kilonova"

via Giphy </PostImage>

As for the two neutron stars that collided, they will inevitably become a black hole, consuming more matter as it grows. But now that we know the natural processes that have been creating the elements in the periodic table, we can actually start creating our own heavy elements!

Filling up the Period 7

All the heavy elements in the Period 7 of the table are radioactive. They are very unstable hence they actively decay as soon as they have been created. The elements after Uranium are not naturally available but using a particle accelerator we were able to create heavier atoms.

A cyclotron is a particle accelerator that can accelerate particles on a spiral path and have them collide to produce the required heavy nuclei. But these elements decay in a matter of micro seconds after they are formed. Hence precise measurement is needed to confirm that these elements existed at that particular time. We finished up the whole Period 7 of the Table (up to element 118) by 2016.

Time for a new period

Starting 2020, a new research will begin for the search of elements 119 & 120. This will be taking place at the newly inaugurated SUPERHEAVY ELEMENT FACTORY. The scientists are hoping to find the "island of stability" in the newly created elements ﹣ An element which has longer half life and doesn't decay as fast as the other elements. This holds exciting possibilities for the future as more elements means more materials for us to build our tech on. Also no one knows if the newly synthesized elements stick to the established conventional properties of the periodic table or they are going to unlock something we missed so far! ﹣ This is exciting either way.

<PostImage src="/the-periodic-table-and-the-stars/PERIODIC_lets-find-out.gif" alt="lets-find-out"

via Giphy </PostImage>

Stars ﹣ Again!

Thinking back, all the elements that we are using now, the ones in your mobile phones, laptops, food and even our own body have been through billions of years of manufacturing process. Thanks to the universe, we get to be spectators of the extraordinary stuff happening before us and experience something as awesome as life for free.

The goal of this blog post isn't to prove a scientific or a technical point, but to give a simple appreciation to the things we have now; to remind us how grateful we are to the stars and the universe. This sense of gratefulness will be the driving force, taking Humanity on the better path.

What are we?

Sun, 27 Oct 2019 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

Before we start

Have added a little intro about myself, you can click here to directly skip to the blog post

Not sure how exactly to put it but this morning I have decided to start writing my blog.

For people who don't know me, I came up with the idea 💡 of Science & Stardust 🛰 blog almost three months ago! Since then, along with the idea, came, my writer's block 😩. I'm a programmer 👨‍💻 and I'm pretty good at it ✨. I have already written a book before, which is based on Javascript programming language, so I thought writing a science blog would be, you know, a "similar" experience of sorts... I even bragged on twitter how I'm gonna overcome my writer's block and just gonna start writing real soon!

<blockquote class="twitter-tweet" data-lang="en-gb"> <p lang="en" dir="ltr"> Will be fighting my writer's block and sharing the stuff I learn in my new publication "Science & Stardust". <br /> <br /> Wish me luck also it will be empty for the first few months, so feel free to ignore... <a target="blank" href="https://t.co/dJ7Ux7RbAq"> https://t.co/dJ7Ux7RbAq </a> </p> — Dani Akash (@dani_akash){" "} <a target="blank" href="https://twitter.com/dani_akash/status/1175809064074264576?ref_src=twsrc%5Etfw"

22 September 2019

</a> </blockquote> <script async src="https://platform.twitter.com/widgets.js" charset="utf-8"

</script>

And that was a month ago... But, only since I started writing, did I learnt, I knew nothing about science 😶. Yeah, quite literally! I'm a computer science student, I majored in computer science and engineering and I make a living by building user-facing applications. I got into programming because of my curiosity. When I was introduced to computers back in 2004, it was exciting. It could do all sorts of stuff! (yeah I was scribbling in MS Paint ✌️) and It triggered one of the most important parts of my brain - "dentate gyrus" which basically makes you curious. I wanted to know, to understand, how it was working...

Fast forward to 15 years and here I am writing a science blog. How? well, my curiosity led me here. I started programming almost 7 years ago. I started building applications and solving complex problems. I decided to do a major in computer science and as I was moving forward in my journey, I found out the computers weren't exactly the most complex things I expected them to be. In fact, they weren't that complex at all. They were simply tools being used to solve the real, actual, complex problems that were happening around us every day! and it's called Science 🧬

Some of you might already be thinking, "I'm not much of a science person, I'll never understand this blog post", but if you think science is boring, it's not science's fault, it is your teacher's fault. They probably taught you to help you score good marks and definitely not for the joy of learning or satisfying your curiosity. This blog, of course, is not for everyone. It is created for science enthusiasts by another science enthusiast, me, sharing my learnings. However, this post is for everyone. You might be an artist, a programmer, a writer or even a "veterinary acupuncturist", I don't know, I didn't even knew such a job existed until a few months ago. I wanted this to be something for everyone. Let's get into this...

What are we?

<PostImage src="/night-sky-stars.jpg" alt="what-are-we"> Photo by Greg Rakozy on Unsplash </PostImage>

For many, they simply answer this question, by their profession.

What are you?
"I'm a doctor"
"I'm an engineer"
"I write the terms and conditions page in every software"

Well, every profession is important. Yeah, it is! But did that really define who we are? cuz a doctor is also a father, a brother, a son and an uncle. An engineer is also a mother, a sister, a daughter and an aunt. So our profession doesn't exactly define us cuz we are much more than that. It simply tells what we do with most of our time. We do multiple roles in our lifetime. So how do we define us?

<PostImage src="/what-am-i.gif" alt="what-am-i"> _via via Giphy </PostImage>

Do our interests define us?

We can try defining us with what we wish to do with our lives. It comes close, the Japanese had a term called Ikigai (生き甲斐) which means "a reason for being". It emphasizes us to find a reason to be alive and make our life worthwhile. This is because our life is temporary. We aren't gonna be living forever and of course, it is important to make good use of whatever little time we were given. Now this tells us to become something in our lifetime but it still doesn't explain what exactly are we in the first place! Yeah, think about it, the actions you take, the job you do, the food you eat, your experiences all are just things you do in your lifetime! They don't accurately answer the question “What is you?”. Turns out, this is exactly the question we have been searching for so long throughout our history, in Science.

We are special and also not so special

Just think about it - "We are a group of self-aware beings who are walking on a floating spherical rock, which is hurling through space moving around a giant ball of burning gas". Now tell me, what are we? Feels weird Nah? I know that feel bro.

Given how a single cell microscopic organism which miraculously appeared on a space rock which is moving around a star which is one among the billions of stars in a galaxy which is also one among the trillions of galaxies in the Universe decided to evolve and then become a better version of itself and over the course of several million years of evolution resulted in us - the people who we are now. We are special. Really special. We had everything. From the right amount of sunlight and to the right amount of moonlight. We started off from a single cell organism. We are now a collection of millions of cells working hard every single day trying their best to help keep the whole entity alive. We also carry one of the most complex individual structures found in this galaxy called our "Human Brain". We are nothing short of a miracle. We were so special or so we thought until we started looking up at the night sky.

Initially, we thought the sky was for us. The sun was shining for us, the stars were twinkling for us and the whole world was working for us. But soon, after centuries of exploring the sky, we found out that those things were just there. They aren't made for us but they just happened to be there. Despite being such a miraculous creation, we are watching a story that is not about us. Every event in the Universe just happens. With or without us. This soon caused many people to fall into an existential crisis. Many turned over to nihilism. We found out whatever we do, we are just a group of simple species who will probably never even leave their own local group. Not so special aren't we now? Hmm, Not exactly. This is where science comes into play.

<PostImage src="/what-am-i-doing-here.gif" alt="what-am-i-doing-here"> via GIPHY </PostImage>

How science changes the perspective

We are given a role to play in a very short lifetime. By looking back at our creation, we can understand how important we are to this universe. Shortly after the beginning (The Big Bang Theory we came up with), there were simple subatomic particles like protons, neutrons and electrons. One of each combined to create the simplest element called the Hydrogen. However, gravity kept pulling these particles together tightly which put so much pressure on Hydrogen atoms and they fused to produce Helium. Then Helium atoms fused to produce even heavier elements and the process continued with a release of a huge amount of heat and light which created the first-ever stars aka primordial stars of our Universe. Stars give life to the Universe. Because it is the stars that created all the elements we know now. The star's core will continue to fuse atoms together tightly using the gravitational force and once it runs out of elements to fuse, it will die in a huge explosion called the supernova. This supernova will scatter the stardust through millions of kilometres (light-years perhaps) in space.

<PostImage src="/super-nova.gif" alt="super-nova"> via Giphy </PostImage>

Many stars have spent so much energy and matter and have ended up as stardust throughout the Universe. Everything we look around us today was initially part of a star at some point. Biology says 99% of our body is made up of just 6 elements oxygen, carbon, hydrogen, nitrogen, calcium, and phosphorus which were also created by the same stardust. We are as important to the Universe as the stars that make up our universe. We are the Universe. We are a way for the Universe to know itself. We are the Universe's consciousness.

We

The Universe is constantly changing and evolving, Black Holes eating away millions of stars, dark energy pulling apart distant galaxies away from each other every second and then there is us, a group of people who are living in one of the small floating space rocks. However, we have been given the power of Science. The power to learn about us and the power to explore and enjoy the time we have for us. We can help each other, save lives, create art, master a craft, write a novel, travel to distant places, build cities and towns, explore the space and of course, try and learn more about ourselves through science. We don't know anything clearly yet and our knowledge of Science is very limited. However, we have been given all of this for free and I'd say it's a nice bargain.

Our time might be limited but we matter, we energy and most importantly, we stardust.

The first image of the black hole is cool but what else haven’t we seen yet?

Sat, 11 May 2019 18:30:00 GMT

import PostImage from "../../components/PostImage.astro";

<PostImage src="/black-hole/night-sky.webp" alt="night-sky"> Photo by Paul Volkmer on Unsplash </PostImage>

1) Dark Matter

You literally can't see this one! (despite the fact 27% of the universe is made out of it) Dark matter is all around us. But scientists are still trying to detect them because they exhibit no electromagnetic force (emf) and they emit no light.

The only way we can feel the normal matter is because of the electrons in the matter repel the electrons in our own skin. Since the dark matter exhibits no electric charge, they simply pass through our bodies.

But we do know they exist because their effects can be detected by gravity! Scientists can detect how much matter is present in a galaxy by the motion of the stars and it turns out something has been deeply influencing the motion of the stars but they remain undetectable by anything other than their gravitational effect. This led to the discovery of dark matter's existence and in recent years we even discovered a galaxy called Dragonfly 44 which is made up of 99.99% Dark Matter

<PostImage src="/black-hole/dragonfly.webp" alt="dragonfly-44"> Dragonfly 44 galaxy looks like a dirty smudge on space. Photo from space.com </PostImage>

2) Dark Energy

If you are familiar with the big bang theory, the universe is formed by a huge explosion which pushed particles away at a really high speed. Even now, the universe keeps expanding but it's actually accelerating instead of slowing down. Theoretically, the gravitational force of attraction should bring the universe close together and eventually the expansion should stop leading to the big crunch. However, there is some form of energy which is actually accelerating the expansion which we haven't been able to understand yet.

This unknown form of energy which is called Dark Energy actually makes up 67% of our whole universe. Other than its existence which is accelerating the cosmic expansion, we know nothing about it and several interesting theories have been proposed to justify the existence of this mysterious energy.

The normal matter which we know of, only makes up about 5% of the whole universe!

3) The Great Attractor

The universe has been expanding since the big bang and has been growing at a rate of 2.2 million kilometers per hour. Thanks to dark energy, the expansion is supposed to be even across the whole universe. However, it turns out our milky way galaxy isn't moving at that speed but it is actually moving towards something else. Not just us, everything within a few hundred and millions of light years from us are also moving towards the same direction.

Enough gravity can actually combat the cosmic expansion and something in the Laniakea Supercluster (which is home to many galaxies including our home) has been attracting us along with the other galaxies in the supercluster. Scientists call this gravitational anomaly as "The Great Attractor" and it is expected to have a mass of about a quadrillion suns.

<PostImage src="/black-hole/super-cluster.webp" alt="super-cluster"> The Laniakea Supercluster (location of Milkyway highlighted with a red dot). Photo from space.com </PostImage>

As interesting as it may be, we are, unfortunately, unable to see this gravitational anomaly because it lies in the Zone of Avoidance - the region in the sky hidden from us due to the interstellar dust and stars from our own Milkyway galaxy.

4) Binary Black Holes

What is cooler than one black hole? Two black holes orbiting each other! The black holes may be formed due to various reasons such as high mass binary star systems or galactic mergers. We are yet to confirm an active binary black hole system in the universe, however, we do know their existence since binary black holes eventually merge producing an immense amount of gravitational waves which can be detected by our technology.

<PostImage src="/black-hole/binary-black-hole.webp" alt="binary-black-hole"> A binary black hole system. Photo from Wikipedia </PostImage>

So far, we have detected 10 binary black hole mergers and two possible active binary black hole systems. We might soon take a picture of this one!

There's so much more!

We have only scratched the surface of the secrets of our night sky. There's still so much out there we are yet to explore. We are still looking at ways to study the exotic matter, gravitons and we are still yet to confirm the existence of hypothetical objects such as the white holes.

Never a dull moment to look at the night sky after all!

What is prototype pollution and why is it such a big deal?

Thu, 09 May 2019 18:30:00 GMT

import { Image } from "astro:assets"; import { inferRemoteSize } from "astro:assets"; import PostImage from "../../components/PostImage.astro"; import YoutubeEmbed from "../../components/YoutubeEmbed.astro";

<PostImage src="/pollution.webp" alt="prototype-pollution"> Photo by Thomas Millot on Unsplash </PostImage>

If you were following the news last month, you probably would have come across how jQuery received a new security patch which addresses the prototype pollution flaw. It is a huge deal, given how 74 percent of all internet sites use the vulnerable version of the library!

<PostImage src="/js-book.jpg" alt="js-book"> Photo by Greg Rakozy on Unsplash </PostImage>

Now before we all panic, prototype pollution isn't exactly an easy vulnerability to be exploited. It needs a fair amount of knowledge on the application architecture to be exploited. This also means all those open source Javascript frameworks and projects in Github are at a huge risk of being exploited.

Before we dig deeper into how much the risk is spread, let's understand what exactly causes the prototype pollution. In Javascript, prototypes define an object's structure and properties so that the application knows how to deal with the data. But it turns out if you modify the prototype in one place, it will affect how the objects work throughout the entire application.

Overwriting the prototype of a default javascript object is considered a bad practice for a long time. You might wanna try reading this article by Nicholas C. Zakas back in 2010.

So, you might not do it in your code. But what if the prototypes can be modified by someone else? That is my friend, prototype pollution and it happens due to some unsafe merge, clone, extend and path assignment operations on JSON objects obtained through user inputs.

It is pretty common in Javascript that you wanna merge two objects together. Generally, this is how such a merge operation looks like the following code snippet.

<figure> <div className="not-prose"> <script src="https://gist.github.com/DaniAkash/b3d7159fddcff0a9ee035bd10e34b277.js" data-astro-rerun ></script> </div> <figcaption> A typical object merge operation that might cause prototype pollution </figcaption> </figure>

The merge operation iterates through the source object and will add whatever property that is present in it to the target object. It's simple. But also makes things complicated if the source is supplied by a 3rd party.

All the attacker has to do to pollute your prototype is to provide you JSON data that has the __proto__ property. A common payload will look something like this:

{
  "foo": "bar",
  "__proto__": {
    "polluted": "true"
  }
}

If you pass this payload to your merge operation without sanitizing the fields, it will completely pollute your object prototypes.

<PostImage src="/prototype-pollution-example.webp" alt="vulnerability-example"> Prototype Pollution in action </PostImage>

This kind of vulnerability is identified in the hoek package used by millions of projects

The severity of pollution depends on the type of payload and how you use your objects. If you use them to authorize admins

if (user.isAdmin) {
  // do something
}

Then it will let the attacker get access to sensitive information by polluting the scope with the isAdmin property. If the attacker changes some existing attribute to an unexpected return type (say toString attribute to return type integer) it will cause your application to crash (Denial of Service) or if you are using your server for code execution like node.js exec or eval then it might even lead to Remote code execution(RCE).

<figure className="flex flex-col items-center justify-center"> <YoutubeEmbed src="https://www.youtube.com/watch?v=LUsiFV3dsK8" /> <figcaption> Olivier Arteau explaining RCE with prototype pollution on GHOST CMS </figcaption> </figure>

So, How many libraries are affected?

As per Snyk reports, there are more than 20+ known vulnerabilities across different packages that run on Node.js and the browser. There might be many that haven't yet been discovered.

When was it discovered?

The term Prototype pollution was coined many years ago. It probably exists ever since people started using vulnerable operations in Javascript.

What is the fix?

If you are using a vulnerable operation like the merge operation we saw above, you can fix it by simply preventing the merge if the key name is __proto__ like the following code.

<figure> <div className="not-prose"> <script src="https://gist.github.com/DaniAkash/02f2e9e01232370172a98eca532900de.js" data-astro-rerun ></script> </div> <figcaption> A safe object merge operation that will not allow prototype pollution </figcaption> </figure>

What if the vulnerability is introduced by an NPM package?

In this case, first, you should check if you are affected by a vulnerable package by running the npm-audit command and you can mostly fix it automatically. Many popular vulnerable libraries such as jquery, lodash, hoek, etc have been updated to address prototype pollution.

If you happen to find a vulnerability in the package you use and an update hasn't been released for it, immediately notify the maintainer of the package.

There also happens to be some rare cases where updating the package might break the whole project like this scenario or the update will take a long time to be released like this case. If you happen to fall into one of these rare categories, you might wanna read how to fix prototype pollution with no-pollution.

What are the other vulnerable methods like merge?

Clone operation which is basically, merge operation on an empty object

var clone = function (objectToBeCloned) {
  return merge({}, objectToBeCloned);
};

Path-value assignment operation where you can define the property of an object by directly accessing its path. A vulnerable path assignment operation will look something like the following code snippet.

<figure> <div className="not-prose"> <script src="https://gist.github.com/DaniAkash/46a6a2e8858795d0a9a78299e06807d5.js" data-astro-rerun ></script> </div> <figcaption> A vulnerable path-value assignment operation on a javascript object </figcaption> </figure>

The following code snippet explains how the above method causes prototype pollution

var obj = pathAssignment({}, "foo", "bar");
// This will create and object { foo: "bar" }

var obj = pathAssignment({}, "__proto__.polluted", true);
// This will totally pollute your object prototypes!

Path assignment based prototype pollution vulnerability is rare but it cannot be fixed by no-pollution. So, make sure the path of the operation can never be controlled by any 3rd party other than your own code. One known case of this vulnerability is affecting the mpath package which already received a fix.

Better safe than sorry

Good programming practices will automatically mitigate prototype pollution attacks. Since this attack relies heavily on the data sent from the client side, make sure you sanitize them all and also run the npm-audit periodically to keep track of vulnerabilities in the packages you use. After all, It is better safe than to be sorry.