That was the only goal.

The AI multiplier effect

To speed up development, I started using AI coding agents: Claude Code, Gemini, and Codex. Not just for productivity. I wanted to understand firsthand how these agents behave in a real development workflow. What they're good at, where they break, and how they change the way you think about building software.

What I didn't expect was the effect on scope. When you can implement an idea in minutes instead of hours, you stop triaging ideas. You just build them. I went from "let me maintain these two libraries" to "let me build 300+ tools" in just 3 weeks.

Currently I'm on Claude Code 20x. The combination of an agent that understands your codebase deeply and can execute multi-step tasks autonomously has been the biggest development velocity multiplier I've experienced.

The architecture: everything on the user's device

Kitmul's fundamental technical decision is that everything runs on the client. No exceptions whenever possible.

The stack is straightforward: if native JavaScript is enough, use JavaScript. If the operation is intensive (audio processing, heavy image manipulation, track separation) compile to WebAssembly. For performance-critical parts, Rust compiled to WASM.

For example, here's how we merge PDFs entirely in the browser:

import { PDFDocument } from "pdf-lib";

export async function mergePDFs(files) {
  const merged = await PDFDocument.create();

  for (const file of files) {
    const bytes = await file.arrayBuffer();
    const pdf = await PDFDocument.load(bytes);
    const pages = await merged.copyPages(pdf, pdf.getPageIndices());
    pages.forEach((page) => merged.addPage(page));
  }

  return merged.save(); // Returns Uint8Array, never leaves the browser
}

Zero network calls. The file goes from File API → pdf-lib → download.

Why Rust + WASM: the prime number checker

For heavier computation, JavaScript hits a wall. A real example from Kitmul: our Prime Number Checker. JavaScript can check primality for small numbers, but try testing a number with more than 1,200 digits and the browser tab freezes.

function isPrime(n) {
  if (n <= 1) return false;
  if (n <= 3) return true;
  if (n % 2 === 0 || n % 3 === 0) return false;
  for (let i = 5; i * i <= n; i += 6) {
    if (n % i === 0 || n % (i + 2) === 0) return false;
  }
  return true;
}

// Works for small numbers, but for a 1200+ digit number?
// BigInt arithmetic becomes so slow the tab freezes.

The solution: we compiled a Rust crate that uses num-bigint with a Miller-Rabin primality test to WASM. The Rust side receives the number as a string (because it can be thousands of digits long) and returns whether it's prime:

use num_bigint::BigUint;
use num_traits::{One, Zero};

#[no_mangle]
pub extern "C" fn is_number_prime(ptr: *const u8, len: usize) -> i32 {
    let bytes = unsafe { std::slice::from_raw_parts(ptr, len) };
    let num_str = std::str::from_utf8(bytes).unwrap_or("0");
    let n = num_str.parse::<BigUint>().unwrap_or_else(|_| BigUint::zero());

    if n <= BigUint::one() { return 0; }

    if miller_rabin(&n) { 1 } else { 0 }
}

The thesis: AI agents shouldn't control your apps. They should BE the app.

This is where I think the current industry is getting it wrong.

OpenAI with Operator, Anthropic with Computer Use, Google with Project Mariner: the big players are all building AI agents that control existing applications. They take screenshots of your screen, move your mouse, click buttons, fill forms. Essentially they're building really sophisticated RPA bots.

I think this approach is fundamentally flawed. Here's why:

1. You're building on top of interfaces designed for humans, not machines. When an AI agent navigates a website, it's fighting against dropdowns, modals, cookie banners, CAPTCHAs, and layout changes. Every website redesign can break the agent. This is fragile by design.

2. You still depend on third-party services. The AI agent might be smart, but it's still uploading your PDF to iLovePDF, still sending your images to Canva's servers, still giving your data to someone else. The privacy problem doesn't go away just because a robot is clicking the buttons.

3. It's slow. Screenshot → analyze → click → wait for page load → screenshot again. This loop takes seconds per action. Meanwhile, a direct function call takes milliseconds.

The alternative: what I'm building with Kitmul is radically different.

The AI agent doesn't control apps. The AI agent IS the app.

Instead of navigating to some website to remove an image background, the agent calls a local function that runs a WASM-compiled AI model directly in the browser. No screenshots. No navigation. No external servers. Just a function call that returns a result.

From dev tools to tools for everyone

As an open source developer, I've always built for other developers. Libraries, CLI tools, build utilities. Limited audience, limited impact.

With Kitmul I flipped the question. Instead of "what tool does a dev need," I asked: "what tool do people search for on Google and end up on a website that charges them or uploads their files to a server."

The answer: hundreds of tools. Remove image backgrounds, separate audio tracks, convert formats, compress PDFs, generate QR codes. Tools people use daily, and for which many sites charge €10-20/month.

Today Kitmul has over 300. And they're not trivial wrappers.

The part that gets really interesting: self-building tools

Here's where Kitmul diverges from everything else.

With 300+ tools, we cover a lot of use cases. But when a user asks for something we don't have, instead of saying "sorry, we can't do that," the system should be able to create the tool on the fly with AI; and then, critically, have a human-in-the-loop verify that the generated tool actually works correctly before it becomes part of the permanent catalog.

Think about it:

1. User asks: "I need a tool that converts MIDI files to sheet music."
2. The AI generates the tool: a client-side implementation using WebAssembly.
3. A human reviewer (me, or eventually a community of contributors) verifies the tool works, handles edge cases, and meets Kitmul's quality standards.
4. Once approved, the tool is permanently added to the catalog.
5. The next user who asks for the same thing gets the verified, production-quality tool instantly.

The system literally builds itself based on what users need. Every unanswered request becomes a signal. Every verified tool makes the platform more capable. It's a flywheel where AI generates, humans verify, and the catalog grows organically.

This is fundamentally different from the "generate code at runtime" approach that some AI companies are pursuing. Generated code running without verification is a liability: it might have bugs, security holes, or simply not work for edge cases. The human-in-the-loop step is not a limitation; it's a feature. It ensures every tool in the catalog is production-quality.

See it in action

Here's a quick demo of how Kitmul works:

What's next

The orchestration works for simple flows, but complex workflows with branching, conditionals, and feedback loops still need work. The self-building pipeline is being designed right now.

The long-term vision: a system where any task you do today with fragmented software (uploading files here, paying a subscription there, installing an app for something else) can be resolved within a single interface, executed locally, orchestrated by AI, and constantly expanding based on what users actually need.

The question I want to leave you with: Do we really need AI agents that puppet our existing apps? Or do we need to rethink what the app itself should be?

I think the answer is the latter. And I think the browser is the right runtime to prove it.

Getting the hello world

We are going to start our App with just two files: index.html and App.js:

.
├── index.html
└── App.js

We are going to load our App.js file inside the index.js adding the type="module":

index.html:

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta charset="utf-8" />
    <script type="module" src="App.js"></script>
    <title>My App without Webpack</title>
  </head>
  <body id="app" />
</html>

Then, in our App.js file, we are going to use Preact loaded directly using unpkg.com. Unpkg is a fast, global content delivery network for everything on npm. The reasons to choose Preact instead of React are:

• Instead of JSX (That requires Babel) we can use a similar syntax.
• Is just 3kb and it has the same React API.
• It has better performance than React.

App.js:

import { html, render } from 'https://unpkg.com/htm/preact/standalone.module.js'

function App() {
  return html`
    <div>
      Hello world
    </div>
  `
}

render(html`<${App} />`, document.getElementById('app'))

Now we can start the project in local with:

npx serve .

And open http://localhost:5000.

We did only 2 steps and already have our Preact App working! Without Webpack, babel, package.json...

Importing other components

To import a new component into our project, once we've created the file:

.
├── index.html
+├── Header.js
└── App.js

We can use a normal import but be careful, it should finish with the extension .js, because this is JavaScript, not Webpack.

In our App.js

import { html, render } from 'https://unpkg.com/htm/preact/standalone.module.js'

// New import:
import { Header } from './Header.js'

function App() {
  // Fragments doesn't exist anymore :)
  return html`
    <${Header} title="This is my app">
      An example without Webpack and Babel
    </${Header}>

    <div>
      Content of the page
    </div>
  `
}

render(html`<${App} />`, document.getElementById('app'))

In our Header.js

import { html } from 'https://unpkg.com/htm/preact/standalone.module.js'

export function Header({ title, children }) {
  return html`
    <header>
      <h1>${title}</h1>
      ${children}
    </header>
  `
}

Using hooks

Sure. We can use hooks in Preact.

// The same React hooks are available on the same package
import {
  html,
  useEffect,
} from 'https://unpkg.com/htm/preact/standalone.module.js'

export function Header({ title, children }) {
  useEffect(() => {
    document.title = title
  }, [title])

  return html`
    <header>
      <h1>${title}</h1>
      ${children}
    </header>
  `
}

Codesandbox

Support

Support of JavaScript modules is available in all modern browsers:

• https://caniuse.com/#search=modules

If you want to use a fallback for legacy browser, you can use the nomodule attribute:

<script type="module" src="modern-browsers.js" />
<script nomodule src="legacy-browsers.js" />

Using more packages

On https://www.pika.dev/ you can search all the npm packages that have support to modules, and their https://www.unpkg.com link to import to your project.

This isn't a technical article. It's personal. But I genuinely believe it can help a lot of people, especially developers and founders who spend long hours in front of a screen and feel like their brain gives up before their schedule does.

I want to talk about the things that changed my daily performance more than any tool, framework, or productivity app ever did. Not hypothetical stuff I read on a blog. Things I've been doing for months (some for years) that produced measurable, repeatable differences in how I work.

Here are the numbers first:

• Resting heart rate: 68 → 56 bpm
• Breathing rate: 14-16 → 8-10 breaths/min
• Deep work blocks: ~90 min max → 3-4 hours consistently
• Post-meeting recovery: 20-30 min → basically instant

None of this came from a supplement, an app, or a course. It came from applying things I learned through competitive athletics to how I work as a developer.

• Some context about me
• The parkour connection
• Hack #1: Intermittent hypoxia
  • What it actually is
  • What changed for me
  • The science (briefly)
• Hack #2: The Pomodoro technique, done right
  • Why most people do it wrong
  • The parkour parallel
  • How I actually use it
• Hack #3: Walking meetings
• Hack #4: Strategic caffeine
• Hack #5: Cold exposure
• Hack #6: Power naps
• What didn't work
• The thing nobody talks about: Silicon Valley already does this
• The physiological argument for founders
• How to start
• References

Some context about me

I've been in software development for over ten years. Most of that time I've been deep in open source. I created NextTranslate, Teaful, and more recently Brisa, a web framework built on web components. I also recently built Kitmul, which went from a testing ground for my libraries to 300+ browser-based tools in three weeks (I wrote about that here).

That's the professional side. But there's another side that's been part of my life for just as long: parkour.

The parkour connection

I started doing parkour in the mid-2000s. By 2011 I was competing in Red Bull events. Not casually. This was serious training, serious risk, serious discipline. I trained alongside people who are now elite athletes preparing for the Olympics. Parkour will officially be part of the Games, and some of the people I used to train with are on that path.

In 2021 I had the worst accident of my life. I misjudged a jump from a rooftop to a fence, fell badly, and ended up in a coma for three days. When I woke up, my vestibular system was damaged. The apparatus that controls balance. For weeks I couldn't walk straight without the world spinning.

Most people would have quit parkour after that. I did the opposite. I used parkour as rehabilitation. I went back to basics. Simple movements, low risk, building balance from scratch. The mindset was the same one I apply to debugging: the jump wasn't the problem. My execution was. I analyzed what I did wrong, and I trained specifically to fix it.

It took years of patient work. But this year, I went back and completed that exact same jump. Rooftop to fence. Clean.

I'm telling this story because it's directly relevant to everything that follows. The accident taught me something I already knew intellectually but had never felt in my bones: your body is the foundation of everything you do. When it breaks, nothing else matters. Not your code, not your startup, not your deadlines. And when you rebuild it deliberately, with discipline, everything else gets better too.

These days I do parkour as a hobby to stay in shape. But the years of competitive training, the accident, the recovery, gave me something that no programming book or productivity course ever could: an intuitive understanding of how the body and brain actually perform under pressure. And how fragile that performance is if you don't take care of the hardware.

Athletes know things about performance that knowledge workers generally ignore. How rest periods affect output quality. How breathing patterns change your nervous system state. How adrenaline management is a trainable skill, not a personality trait. How the difference between a good day and a bad day often comes down to physiology, not motivation. And how you recover from failure matters more than the failure itself.

Once I started applying these principles to my work as a developer, everything changed.

And exercise itself, just moving your body regularly, is the most underrated performance hack that exists. It increases BDNF (the protein that helps your brain form new connections), regulates cortisol, improves sleep, and directly enhances executive function. Everything else I'm about to describe works better on top of a foundation of consistent physical activity. Parkour is my thing, but any movement practice works.

Hack #1: Intermittent hypoxia

This is the one that surprised me the most.

What it actually is

Intermittent hypoxia training (IHT) is simple: you alternate short periods of reduced oxygen breathing with normal recovery. It's the same principle behind altitude training, the thing that endurance athletes have been doing for decades to improve oxygen efficiency, except you can do it at sea level, sitting at your desk, in 15-30 minutes.

The protocol: controlled breathing cycles that temporarily reduce your blood oxygen saturation, followed by recovery breathing. Repeat for several rounds. That's it.

I started doing this to improve my breath-hold times and cardiovascular performance for parkour. The results in training were immediate. Longer runs, faster recovery between sequences, and much better composure during high-risk movements. When you're mid-air in a precision jump, the ability to manage your adrenaline response is not optional. IHT gave me noticeably more control over that.

What changed for me

But the real surprise came outside of training sessions. And this is the part that I think matters for anyone who works with their brain.

After about two weeks of consistent IHT practice, I noticed something: I was breathing more slowly throughout the entire day. Not because I was trying to. My body had simply recalibrated. Where I used to take 14-16 breaths per minute sitting at my desk, I dropped to 8-10.

This sounds minor. It's not.

Patrick McKeown, author of The Oxygen Advantage, has documented extensively how slower, lighter nasal breathing improves CO2 tolerance. Higher CO2 tolerance means better oxygen delivery to tissues, including your brain. It's counterintuitive (more CO2 = better oxygenation?), but the physiology is well-established: CO2 is what triggers hemoglobin to release oxygen to cells (the Bohr effect). If you breathe fast and shallow, you actually reduce oxygen delivery despite taking in more air.

Here's what I noticed in my daily work after my breathing shifted:

Sustained focus got dramatically easier. I used to hit a wall at about 90 minutes of deep work. That wall moved to 3-4 hours. Not through willpower or discipline. I just didn't get tired as quickly. Better brain oxygenation, fewer stress hormones circulating, more stable energy.

Adrenaline management at work. This was the one I didn't expect. Running a startup (or even just being a senior developer) means constant high-stakes moments. A production incident at 2am. A hard conversation with a coworker. An investor call where you have 20 minutes to make your case. Before IHT, these situations would leave me wired for hours afterward. Now the recovery is almost instant. The same nervous system control that helps me stay calm mid-air during parkour helps me stay clear-headed during a crisis at work.

Faster cognitive recovery. After an intense 3-hour coding session or a difficult meeting, I used to need a significant break before I could do anything useful again. Now I bounce back in minutes. It's like my brain's recovery time dropped from "restart the computer" to "close the tab and open a new one."

The science (briefly)

I'll keep this short because I'm a developer, not a scientist, but I did go down the rabbit hole on the research:

A 2022 study in Frontiers in Neuroscience found that IHT causes "proadaptive modifications" in the brain, stimulating BDNF (brain-derived neurotrophic factor) and increasing what they called "the adaptive potential, endurance, and working capacity of the brain" [1]. Another study showed significant gains in memory recall and attention in participants following IHT protocols [2].

The mechanism is called hormesis. Controlled, small doses of stress that make the body more resilient. Same principle as cold exposure, sauna, or fasting. The difference is that hypoxia specifically targets oxygen efficiency and neural adaptation.

A study published in Physiology documented that intermittent hypoxia upregulates three growth factors (EPO, BDNF, and VEGF) all directly linked to enhanced neural function and cellular resilience [10]. This isn't about feeling zen. It's about building a more capable brain at the physiological level.

Andrew Huberman, a Stanford neuroscientist, has documented how breathing protocols shift autonomic nervous system state, reducing cortisol, increasing parasympathetic tone, and enhancing executive function [4]. IHT is essentially a more intense version of breathwork: it doesn't just teach you to breathe better in the moment. It permanently upgrades your baseline respiratory efficiency.

My resting heart rate went from 68 to 56 bpm. That's not a small change.

Hack #2: The Pomodoro technique, done right

I know, I know. Everyone's heard of Pomodoro. "25 minutes of work, 5 minutes of break, revolutionary." Most people try it for a week and drop it because it feels artificial.

I did the same thing years ago. Then parkour taught me something that made me come back to it with a completely different understanding.

Why most people do it wrong

The issue isn't the timer. It's what people do during the "break."

Most developers hit the 5-minute break and immediately check Slack, scroll Twitter, read email, or look at their phone. That's not rest. That's a different kind of cognitive load. Your prefrontal cortex doesn't get to discharge. It just switches to a different task. When the timer starts again, you're not fresh. You're fragmented.

The parkour parallel

Here's what parkour taught me about rest, and it took me years to really internalize this:

You need rest to improve. The gains happen during recovery, not during effort.

In a parkour training session, you give 100% on a sequence. A run, a series of jumps, a technical combination. Then you walk back. You breathe. You shake out your arms. You stand there for a minute doing literally nothing. And then you go again at 100%.

If you skip that recovery and try to chain explosive movements back-to-back, two things happen: your performance degrades fast, and you get injured. Every serious practitioner learns this the hard way.

Your brain works exactly the same.

When you try to code for four straight hours without structured breaks, the last two hours are objectively worse. Your attention drifts. Your error rate climbs. You make architectural decisions you'll regret tomorrow. But you don't notice it in the moment because cognitive degradation is invisible from the inside.

How I actually use it

Once I understood that the 5-minute break is not a concession to weakness but the actual mechanism that makes high performance sustainable, Pomodoro clicked for me.

25 minutes of full-intensity focus. One task. No Slack. No email. No "quick check" on anything. If something pops into my head, I write it on a sticky note and go back to what I'm doing. The goal is to create a state of total immersion, the same mental state I'm in during a parkour sequence where I literally can't afford to think about anything else.

5 minutes of real rest. Stand up. Look out the window. Walk to the kitchen. Breathe. The key word is "real." Your eyes need to leave the screen. Your working memory needs to flush. If you don't do this, you're just doing 4 hours of gradually degrading work with arbitrary timer interruptions.

The parallel to parkour is direct: train hard in bursts, rest completely between sets. The rest is what lets you sustain 100% intensity. Without it, by the third round you're operating at 60% and making mistakes. Except at your desk, the "injury" is a bug you'll spend two days debugging.

Here's a trick I use that combines both hacks: during some Pomodoro breaks, I do a quick round of breath-hold exercises. Five minutes of controlled breathing resets my autonomic nervous system and primes me for the next focus block. It's like a mini-reboot. When the timer starts again, I'm genuinely fresh, not just "took a break" fresh.

After four Pomodoro cycles, I take a longer break of 15-20 minutes. Go outside if possible. Move. The compounding effect across a full day is dramatic. Hour six feels like hour one.

Hack #3: Walking meetings

This one is simple but I almost never see people talk about it.

Many meetings don't require you to be sitting at a desk staring at slides. Status updates, brainstorming sessions, 1-on-1s, planning discussions. For all of these, you can be walking.

I use a walking treadmill at my desk during meetings. Slow pace, 3-4 km/h, just enough to keep blood flowing. The effects are immediate: better attention, less fidgeting, fewer distractions. There's something about low-intensity movement that keeps the brain engaged without consuming cognitive resources. Research backs this up: walking improves creative thinking and sustained attention.

But here's the part nobody mentions: what happens after the meeting. When you've been sitting for an hour-long call, you finish drained. You need a transition period before you can do real work again. When you've been walking during that same call, you finish energized. You sit down at your desk and you're immediately ready to work. The meeting didn't drain your battery. It charged it.

This has been particularly useful for me during weeks with heavy meeting loads. The meetings themselves become light exercise, and the transitions between meetings and deep work become seamless.

Obviously this doesn't work for every meeting. If you're pair programming, sharing your screen, or doing a code review where you need to type, sit down. But for the 60-70% of meetings that are primarily conversation, walking is strictly better than sitting.

Hack #4: Strategic caffeine

I've never been a big coffee drinker. But I noticed that the few times I did have coffee, the effect was massive. That got me thinking about why.

The answer is simple: most people drink coffee every day, and daily caffeine consumption builds tolerance fast. After a couple of weeks, your morning coffee doesn't enhance your performance. It gets you back to your baseline. You're not getting a boost. You're paying a tax (dependency, sleep disruption, afternoon crashes) to feel normal. That's a bad trade.

Because I don't have that daily habit, I can treat caffeine purely as a tool.

Most days I drink water. Just water. This means my caffeine tolerance stays low. Then, when I actually need it (I slept poorly and have a big day ahead, there's a product launch, I'm doing a full day of complex pair programming) a single coffee delivers a genuine cognitive boost. Alertness, processing speed, working memory, all measurably better because my body isn't habituated.

Think of it like a power-up in a game. If you use it on every level, it stops being special. If you save it for the boss fight, it actually matters.

The transition period when you stop daily coffee is about a week of mild headaches and low energy. After that, you reach a new normal where you feel fine without it, and caffeine becomes something you choose to deploy strategically rather than something you depend on to function.

I know this one is controversial. Coffee culture is deeply embedded in developer identity. All I can say is: try it for two weeks and see what happens. The worst that can happen is you go back to your regular habit.

Hack #5: Cold exposure

This is a quick one. A cold shower at the end of my normal shower, 60-90 seconds of cold water, produces a norepinephrine spike that improves alertness and mood for hours. This is well-documented by Huberman and others [4].

I'm not doing ice baths or any extreme Wim Hof protocol. Just cold water at the end. The cost is minimal (it's uncomfortable for about 30 seconds, then you adapt). The effect on morning focus is noticeable and consistent.

Wim Hof's method (breathing + cold + meditation) was actually validated in a Radboud University study that showed trained participants could voluntarily influence their sympathetic nervous system and innate immune response [8]. That's remarkable. But you don't need the full method to get the basic alertness benefit. Just turn the handle to cold for a minute at the end of your shower.

Hack #6: Power naps

When I hit a wall after lunch or after a heavy morning, a 20-30 minute nap resets me completely. Not a "nice to have." A genuine cognitive reboot.

The key is keeping it under 30 minutes. Go longer and you enter deep sleep, which means you wake up groggy and worse than before. But a short nap, 20 minutes is the sweet spot, clears the mental fog and gives you what feels like a second morning. I've had some of my most productive afternoons right after a power nap.

I don't schedule them. I just listen to my body. If I'm not tired, napping is pointless. But when the signal is there, fighting it with coffee or willpower is a losing strategy. The nap is faster, free, and has no side effects.

What didn't work

I think it's important to mention what I tried that either didn't stick or didn't produce noticeable results. Not everything works for everyone, and I don't want to give the impression that I just tried five things and all five were magic.

Meditation apps. I tried Headspace and Calm for a few months each. They're well-made products, but guided meditation didn't produce the same physiological changes as breathwork and IHT. My suspicion is that meditation works better as a long-term practice (years, not months) while breathing protocols produce measurable changes in weeks. Your mileage may vary.

Strict time-blocking the entire day. I tried scheduling every 30-minute slot for a few weeks. It created more anxiety than productivity. Pomodoro works for me because it structures intensity and rest, not content. I decide what to work on, then I decide how intensely to focus on it. Scheduling every minute took away the flexibility that makes creative work possible.

The thing nobody talks about: Silicon Valley already does this

Here's what I find interesting. These aren't fringe biohacking experiments. Breathwork and oxygen manipulation have been quietly adopted across the tech industry for years. Not as a trend, but as a serious performance tool.

Bryan Johnson, the founder of Braintree (sold to PayPal for $800M), spends roughly $2M per year on biohacking protocols. The man literally moved his office into a hyperbaric chamber [5]. Now, $2M/year is absurd and not what I'm suggesting. But the underlying logic, that physiological optimization directly translates to cognitive performance, is sound.

Jack Dorsey, co-founder of Twitter and Block, has practiced meditation and controlled breathing for over 20 years [6]. Tim Ferriss has dedicated entire podcast episodes to breathing protocols for performance, hosting James Nestor (author of the NYT bestseller Breath: The New Science of a Lost Art) to discuss how subtle breathing adjustments transform cognitive output [7].

Dave Asprey, founder of Bulletproof, has worked extensively with Wim Hof. Patrick McKeown's Oxygen Advantage method, which is essentially breath-hold training that simulates altitude, has been adopted by athletes, military operators, and increasingly, tech executives [3].

Longevity Technology reported that biohacking has become "a major trend among Silicon Valley executives seeking to optimize health and performance," with breathwork, cryotherapy, and oxygen manipulation among the most commonly adopted protocols [9].

What's telling is why these people gravitate toward physiological hacks rather than (or in addition to) productivity software. When you're building something that demands 12-16 hours of sustained cognitive output per day, across months and years, the bottleneck is not your task manager. It's not your team structure. It's not your tech stack. The bottleneck is your brain's ability to maintain quality output under sustained pressure. That's a physiology problem, not a tooling problem.

And marginal gains in oxygen efficiency and stress resilience compound dramatically over time.

The physiological argument for founders

The startup world glorifies hustle but ignores the hardware it runs on. You can optimize your deployment pipeline, your sprint process, your hiring funnel. But if your brain is running on shallow breathing and chronic cortisol, none of it matters. You're making your worst decisions at the end of the day, exactly when they matter most.

Consider what changes when your baseline physiology is different:

Your resting heart rate drops. Mine went from 68 to 56 bpm. A lower resting heart rate correlates with better cardiovascular efficiency, better stress recovery, and better autonomic regulation. You're literally running calmer all day.

Your breathing rate drops. 8 breaths per minute instead of 15. Fewer breaths means less sympathetic nervous system activation throughout the day. Less fight-or-flight. Less background anxiety. Less cortisol.

Your work is structured around recovery. Pomodoro ensures that hour six of your day is as sharp as hour one. You don't gradually degrade. You stay at peak performance in short bursts and actively recover between them.

Your oxygen utilization improves. The same blood volume delivers more oxygen to your prefrontal cortex, the part of your brain that handles planning, decision-making, and impulse control. The exact functions you need most as a founder.

Your stress recovery accelerates. The interval between "something went wrong" and "here's what we're going to do about it" shrinks from minutes to seconds. This is probably the most practically valuable change. In a startup, the speed at which you can move from panic to plan is everything.

None of this is woo. James Nestor's research, documented across multiple peer-reviewed collaborations, shows that breathing efficiency is one of the single highest-leverage interventions for cognitive performance [7]. And a study published in Physiology documented that intermittent hypoxia upregulates EPO, BDNF, and VEGF, three growth factors directly linked to neural function and cellular resilience [10].

How to start

None of this requires expensive equipment or complicated protocols.

Intermittent hypoxia, the 5-minute version:

1. Breathe normally through your nose for 2 minutes. Just calm, quiet nasal breathing.
2. Take a normal breath in, exhale gently, and hold your breath.
3. Walk slowly while holding. When you feel a moderate urge to breathe, stop.
4. Resume nasal breathing and recover for 1-2 minutes.
5. Repeat for 6-8 rounds.

This is a simplified version of Patrick McKeown's Oxygen Advantage method [3]. It works by increasing your CO2 tolerance and training your body to do more with less oxygen, exactly what altitude training does, but at sea level.

For more structured sessions with timed rounds and progressive difficulty, I built an intermittent hypoxia breathing timer as one of the tools on Kitmul.

Pomodoro, the non-negotiable version:

1. Pick one task. Not "a few things." One.
2. Set a timer for 25 minutes.
3. Work at full focus. No Slack, no email, no phone.
4. When the timer rings, stop. Stand up. Walk away from your screen for 5 minutes.
5. Repeat. After 4 cycles, take a 15-20 minute break.

The discipline is in the rest, not the work. Anyone can focus for 25 minutes. The hard part is actually stopping and actually resting. If you want a good timer, there's a Pomodoro timer on Kitmul too.

Caffeine reset:

Stop drinking coffee for one week. Push through the headaches (they peak at day 2-3 and disappear by day 5). Then only use caffeine on days when you genuinely need a boost. You'll be amazed at how much more effective a single cup becomes.

Cold exposure:

At the end of your normal shower, turn the water to cold for 60-90 seconds. That's it. The first week is uncomfortable. After that, it becomes almost pleasant, and the alertness benefit is consistent.

Walking meetings:

Buy a cheap walking treadmill. Use it during any meeting where you don't need to type. You'll finish meetings energized instead of drained.

I started all of this because of parkour. The breathing work, the structured rest, the body awareness. It all came from athletic training, not from reading productivity blogs. But the transfer to knowledge work was immediate and dramatic.

The best productivity hack I've found in over ten years of professional software development isn't a tool, a framework, or an AI agent. It's optimizing the machine that runs all the other machines: your body.

Oxygen and well-timed rest. That's it.

References

1. Rybnikova, E. & Nalivaeva, N. (2022). "Intermittent Hypoxic Training as an Effective Tool for Increasing the Adaptive Potential, Endurance and Working Capacity of the Brain." Frontiers in Neuroscience. Read study

2. Schega, L. et al. (2013). "Effects of Intermittent Hypoxia on Cognitive Performance and Quality of Life in Elderly Adults." Gerontology. Read on PubMed

3. McKeown, P. The Oxygen Advantage. Breath-hold exercises that simulate altitude training at sea level. Official site

4. Huberman, A. "Breathwork Protocols for Health, Focus & Stress." Huberman Lab. Read article

5. Johnson, B. Braintree founder, $2M/year biohacking protocol including hyperbaric oxygen. Source

6. Dorsey, J. 20+ years of meditation and breathwork practice. Source

7. Nestor, J. Breath: The New Science of a Lost Art. NYT bestseller on breathing science. Official site

8. Wim Hof Method. Radboud University study on voluntary influence over sympathetic nervous system. Read more

9. "Silicon Valley's biohacking obsession: Why tech executives are hooked." Longevity Technology. Read article

10. Dale, E. et al. (2014). "Unexpected Benefits of Intermittent Hypoxia: Enhanced Respiratory and Nonrespiratory Motor Function." Physiology. Read study

11. Intermittent Hypoxia Breathing Timer. Free guided tool for structured IHT sessions.

12. Pomodoro Timer. Free focus timer with structured work/rest cycles.

Why HTML Streaming is Important

HTML Streaming is a powerful technique that allows you to send HTML incrementally from the server to the client, improving performance and reducing latency. With Brisa, you can stream HTML content directly to the client, not only for the initial render but also for subsequent updates and server actions.

If your app needs just 1 request to fetch server data, you’re stuck in the CDN trap. Add more requests, and you’re in a cascading nightmare. CDNs are fine for assets—nothing more. Your website is an asset only if it doesn’t rely on server data.

Rendering the Components on the server with streaming is the best way to avoid the CDN trap. Brisa not only uses HTML Streaming for the first render but also as a response to Server Actions after rendering a component on the server.

You may wonder, but many components are static and I don't want to render them always on the server. Well, Brisa allows you to pre-render them at build-time with just one attribute, so that only dynamic components are rendered on the server.

<StaticComponent renderOn="build" />

Do dynamic imports solve the CDN trap?

No. Using HTML Streaming on Server Actions have exactly the same benefits as using it on the first render.

Imagine managing the opening and rendering of a dialog with a dynamic import:

Only if the dialog needs server data, we are in the same problem.

Code example: Quiz with HTML Streaming

As an example, we are going to make a quiz of questions in Brisa using HTML Streaming through Server Actions, and you will see how easy it is to do it, apart from its benefits.

In order to make the quiz, we are going to create a component that will be rendered on the server and will be responsible for managing the questions and answers. The questions will be sent to the client through HTML Streaming, and the answers will be processed on the server.

import { renderComponent } from 'brisa/server';

// Define the type for questions to ensure type safety.
type Question = {
  answer: string; // The correct answer for the question ('yes' or 'no').
  question: string; // The text of the question to be displayed.
  id: number; // Unique identifier for each question.
};

// All this code is server-code. It ensures that the user cannot infer the correct
// answers by inspecting the page source or the network.
const questions: Question[] = [
  { id: 1, answer: 'no', question: 'Is the Earth flat? ' },
  { id: 2, answer: 'yes', question: 'Is the Earth round? ' },
  { id: 3, answer: 'no', question: 'Can giraffes lay eggs?' },
  { id: 4, answer: 'yes', question: 'Can penguins fly?' },
  { id: 5, answer: 'no', question: 'Can a cow jump over the moon?' },
  { id: 6, answer: 'yes', question: 'Is water wet by definition?' },
  { id: 7, answer: 'yes', question: 'Is the sky blue?' },
  { id: 8, answer: 'yes', question: 'Do fish sleep with their eyes open?' },
  { id: 9, answer: 'no', question: 'Can a cow fly?' },
];

// Function to open the modal with a random question.
function openModal() {
  const randomIndex = Math.floor(Math.random() * questions.length);
  
  renderComponent({
    element: <Modal {...questions[randomIndex]} />,
    target: '#content', // Specify the DOM element where the modal should render.
  });
}

// Function to process the user’s answer and display the result.
function processAnswer(e: ClickEvent, value = 'yes') {
  // We have the event on the server, so we can access the target and the dataset!
  const id = (e.target as HTMLButtonElement).dataset.id;

  // Check if the user's answer matches the correct answer.
  const isCorrect = questions.find((q) => q.id === Number(id)).answer === value;

  // Render feedback based on the correctness of the answer.
  renderComponent({
    element: isCorrect ? (
      <p id="content" class="correct">
        Correct!
      </p>
    ) : (
      <p id="content" class="incorrect">
        Incorrect!
      </p>
    ),
    target: 'dialog',
  });
}

// Main homepage component.
export default function Homepage() {
  return (
    <>
      <div class="hero">
        <h1>
          <span class="h1_addition">Welcome to </span>Brisa
        </h1>
        <p class="edit-note">✏️ SSR Modal example</p>
        <code>src/pages/index.tsx</code>
      </div>

      <form onSubmit={openModal}>
        <button>Open modal</button>
        <div id="content" /> {/* Container for rendering dynamic content */}
      </form>
    </>
  );
}

// Modal component to display a question and answer options.
function Modal({ question, answer, id }: Question) {
  return (
    <dialog open>
      <form method="dialog">
        <h2>{question}</h2>
        {/* Button for "Yes" answer */}
        <button data-id={id} onClick={(e) => processAnswer(e, 'yes')}>
          Yes
        </button>
        {/* Button for "No" answer */}
        <button data-id={id} onClick={(e) => processAnswer(e, 'no')}>
          No
        </button>
      </form>
    </dialog>
  );
}

• 🔗 Code example here

One of the advantages of using server-side logic for rendering and controlling a dialog is the enhanced security and simplicity it offers. With Brisa, you can offload both the rendering and logic processing to the server, ensuring that critical data remains inaccessible to the client and maintaining a clean separation of concerns.

In this example, a modal dialog is used to present random quiz questions to the user. The logic for selecting the question, validating the answer, and rendering the UI is entirely managed on the server. This approach eliminates the risk of exposing sensitive data, such as the correct answer, to the client.

Normally we load modals on the client with a dynamic import to avoid loading them at the start, requesting the CDN, and then if the modal needs server data, once rendered it has to make a cascade of calls to the server. With Brisa, we can load the modal directly from the server, avoiding the need to make additional calls and keeping the modal logic on the server.

With this approach, we get the following benefits:

1. Enhanced Security: Sensitive data, such as correct answers, remain on the server, preventing unauthorized access or manipulation.
2. Improve UX: By rendering the modal directly on the server with streaming, we can avoid additional network requests and improve the user experience thanks to streaming.
3. Simplified State Management: By centralizing logic on the server, the client remains lightweight and focuses only on rendering and user interaction.
4. Reduced Client-Side Complexity and Size: No need for complex state management libraries or additional client-side logic to handle the modal. The server manages everything and you can do an SPA without increasing the client bundle size.

SPA without Client-Side JavaScript?

Yes, you can! Although we support writing Web Components with JSX and Signals with very little code (3kb), we want you to use them only for pure client interactions. Our goal is to make it possible to create SPAs without the need for client-side JavaScript.

Imagine that your e-commerce site, instead of having a cascade of requests and a lot of client-side JavaScript code that harms performance and user experience, becomes a SPA without client-side JavaScript, since most interactions that require server data can be managed directly on the server.

Rendering on the server is very cheap and fast (~10ms)!

Control stream chunks with Async Generators

Brisa allows you to control the stream chunks with Async Generators. This way, you can stream the HTML in chunks and control the flow of the stream.

import { Database } from "bun:sqlite";
import { renderComponent } from "brisa/server";

export default function LoadMovies() {
  function streamMovies() {
    renderComponent({
      element: <MovieItems />,
      target: "ul",
      placement: "append",
    });
  }

  return (
    <>
      <button id="movies" onClick={streamMovies}>
        Click here to stream movies from a Server Action
      </button>
      <ul />
    </>
  )
}

const db = new Database("db.sqlite");

async function* MovieItems() {
  for (const movie of db.query("SELECT title, year FROM movies")) {
    yield (
      <li>
        {movie.title} ({movie.year})
      </li>
    );
  }
}

In this example, we are using an Async Generator to stream the movies from a SQLite database. Any yield is a chunk of the stream that will be sent to the client.

• 🔗 Code example Streaming HTML from SQLite

What is renderComponent?

Brisa’s renderComponent allows developers to:

1. Re-render components dynamically on server actions.
2. Render specific components to specific locations in the DOM.
3. Choose how and where to place them (e.g., replace, append, prepend, after & before).
4. Enhance transitions with the View Transition API.
5. Stream JSX components incrementally from the server.

Here’s a quick look:

export default function MyComponent({ text = "foo" }: { text: string }) {
  function handleClick() {
    // Re-render the same component
    renderComponent();

    // Re-render with new props
    renderComponent({ element: <MyComponent text="bar" /> });

    // Render another Component to a specific location
    renderComponent({
      element: <AnotherComponent />,
      target: "#target-id",
      placement: "append",
      withTransition: true, // Enhance transitions with the View Transition API
    });
  }

  return (
    <div>
      <button onClick={handleClick}>{text}</button>
    </div>
  );
}

All this code is server-side code. In Brisa, all the events from server components are Server Actions.

Why is This a Game-Changer?

Brisa’s approach to server actions is inspired by React’s model and HTMX concepts but is designed to be simpler and inherently safer.

Brisa vs. HTMX

HTMX allows developers to dynamically update portions of the DOM via server responses. But it lacks:

• Component-level granularity: HTMX relies on server-generated HTML partials without the concept of components.
• Streaming support: HTMX does not natively support streaming updates to the client.
• Bundle size: HTMX is a 14KB library, while Brisa is only 2KB.

With renderComponent, you get:

• Component reuse: Brisa components are re-rendered seamlessly, leveraging JSX and React-like composition.
• Dynamic placement: Update or append components where in the DOM.
• Streaming support: Send and render data incrementally using server-side streams.

Brisa vs. React

In React, implementing server actions often involves using "use server" and "use client" directives. This dual model introduces the potential for human error and can unintentionally expose components to the client.

Key differentiators include:

• Streaming HTML support: React communicates between the server and client by sending JavaScript, which can add significant overhead. Conversely, Brisa streams HTML directly to the client, reducing complexity and improving performance.
• Signals - fine-grained reactivity: Brisa’s client-side signals automatically react to server-side changes by updating Web Components, avoiding the need for a complete re-render.
• Bundle size: React-DOM v.19 weighs around 200KB, while Brisa maintains an ultra-lightweight footprint of just 2KB.
• Selective updates: Brisa allows you to update specific components on the server, reducing the need for full-page reloads.

Conclusion

Brisa’s HTML Streaming avoids the CDN trap and improves your app’s performance. You can stream HTML content directly to the client for the initial render, subsequent updates, and Server Actions. This approach improves security, and user experience, and simplifies state management, making it an ideal choice for server-side rendering.

If you’re looking to build fast, secure, and scalable web applications, give Brisa a try today!

Support Us: Visit our shop for Brisa swag! 🛍️

I recommend reading this other article where I introduce Tensorflow.js.

However, after this, you'll be able to classify any kind of image in an easy way even without any knowledge of ML. Also, it can be replicated for any image classification problem.

We will cover the following:

• The dataset
• Training the model
• Testing our model
• Using the model in our (P)React app
  • Installing dependencies
  • Loading the model
  • Using the model
• Why in the browser?
• Code of this article
• Conclusion
• References and acknowledgments

The dataset

Before we start training a model, we need to have many images of cats and dogs, as varied as possible, to not have any bias. We have two options:

• Recopilate our custom dataset
• Use an existing dataset

For this, I'm going to use this dataset from Kaggle, with 10.000 images of cats/dogs:

• https://www.kaggle.com/tongpython/cat-and-dog

Thus, you only need to download it.

Note: On Kaggle you'll find a lot of available datasets, it's a good place to search for data. For our purposes, we'll choose a small dataset of 218MB. I recommend using one not too big at least for now, so you won't end up with your device's resources.

Training the model

Once our dataset of images is ready, we can train the model.

The first thing we have to know is what kind of model we want. We'll train an Image Classification Model, which after a given input image will say if it's a cat or dog.

There is a model called Mobilenet, already trained to classify 1000 different images. The problem? It does not classify the images we want. To fix this we'll use a technique called transfer learning, to use its "intelligence" to recognize our images.

Currently, we can transfer this knowledge without coding thanks to some open source tools. That's what we're going to do, we'll leave the code for the usage part of this model.

Let's use this tool:

• https://thekevinscott.github.io/ml-classifier-ui/

This tool uses a layer of the MobileNet neural network located at the end (conv_pw_13_relu). This means that it works well for images similar to the ones MobileNet has trained with (animals, instruments, everyday objects...). If you want to use more different images (for example skin freckles to detect a melanoma), it may not work unless you use an earlier layer. The closer the layer is to the end, the faster it'll be and the less resources will be used when training the model.

Now you need to drag and drop the training_set folder from the downloaded dataset and wait. That's all.

Note: Depending on your device GPU performance it can take a long time. If you have chosen a bigger dataset or another layer and your browser doesn't have enough resources, you can use the ml-classifier in a Node.js environment.

Testing our model

Testing a model lets us know if it works with new images, not only the ones you have already trained. That's how we know that a model is working.

To test it, we'll use the test_set folder of the dataset. We can drag and drop it again. It contains different images from the ones we've used in the training.

It will be much faster now than before.

After checking that the trained model predicts quite well, we'll download it to use it in our app.

Using the model in our (P)React app

We are going to create a Preact app with Snowpack by doing:

npx create-snowpack-app cat-dog-detection-tfjs --template @snowpack/app-template-preact --use-yarn

Then, we'll add our model downloaded files (JSON + weights) inside cat-dog-detection-tfjs/public.

public
├── favicon.ico
├── index.html
+├── model
+│   ├── ml-classifier-dogs-cats.json
+│   └── ml-classifier-dogs-cats.weights.bin
└── robots.txt

Note: If you want to rename the model, don't forget to modify the weightsManifest inside the .json file to point correctly to the renamed .weights.bin file.

Installing dependencies

To load the model we'll use Tensorflow.js. Also, add preact/hooks to use hooks.

yarn add @tensorflow/tfjs@1.0.0 preact/hooks

Loading the model

To load our model, first we must load the Mobilenet model, as this is the model from which we have applied transfer learning. It's necessary for prediction. We will also load our model.

We're going to create two files:

• Hook to load the model
• Our component to load the hook

Hook to load the model (src/hooks/useLoadCatsDogsModel.js):

import * as tf from '@tensorflow/tfjs'
import { useEffect, useState } from 'preact/hooks'

const pretrainedModel = {
  url:
    'https://storage.googleapis.com/tfjs-models/tfjs/mobilenet_v1_0.25_224/model.json',
  layer: 'conv_pw_13_relu',
}

export default function useLoadCatsDogsModel() {
  const [state, setState] = useState([])

  useEffect(() => {
    async function loadModel() {
      const mobilenet = await tf.loadLayersModel(pretrainedModel.url)
      const layer = mobilenet.getLayer(pretrainedModel.layer)
      const pretrained = await tf.model({
        inputs: mobilenet.inputs,
        outputs: layer.output,
      })

      const model = await tf.loadLayersModel(
        './model/ml-classifier-dogs-cats.json'
      )

      setState([model, pretrained])
    }
    loadModel()
  }, [])

  return state
}

Our component to load the hook (src/CatsDogsDetection.jsx):

import { h } from 'preact'
import useLoadCatsDogsModel from './hooks/useLoadCatsDogsModel'

export default function CatsDogsDetection() {
  const model = useLoadCatsDogsModel()

  if (!model) return 'Loading the model...'

  return 'Model loaded!'
}

In order to test if it loads correctly:

• Add the <CatsDogsDetection /> component inside your src/App.jsx.
• Run yarn start

We already have the loaded model. Now we are going to replace the displayed text "Model loaded!" by using this model.

Using the model

In this tutorial, we are going to implement something not too complex by simply loading an image from the filesystem. It will display the prediction (cat or dog). We could complicate it by adding a camera, but this is not the purpose of the article.

What we're going to do to get the prediction is this:

In order to implement this, we're going to replace our CatsDogsDetection component to this:

import { h } from 'preact'
import { useState } from 'preact/hooks'
import * as tf from '@tensorflow/tfjs'
import useLoadCatsDogsModel from './hooks/useLoadCatsDogsModel'

export default function CatsDogsDetection() {
  const [model, pretrainedModel] = useLoadCatsDogsModel()
  const [previewUrl, setPreviewUrl] = useState()
  const [predictionStatus, setPredictionStatus] = useState()

  function onLoadPreview(e) {
    const image = e.target.files[0]
    if (!image) return
    if (previewUrl) URL.revokeObjectURL(previewUrl)
    setPreviewUrl(URL.createObjectURL(image))
    setPredictionStatus('predicting')
  }

  async function predict() {
    const pixels = tf.browser.fromPixels(document.querySelector('img'))
    const image = tf
      .reshape(pixels, [1, 224, 224, 3])
      .toFloat()
      .div(tf.scalar(127))
      .sub(tf.scalar(1))
    const modelPrediction = model.predict(pretrainedModel.predict(image))
    const [dog, cat] = Array.from(modelPrediction.dataSync())
    setPredictionStatus(dog >= cat ? '🐶' : '😸')
  }

  if (!model) return 'Loading the model...'

  return (
    <div>
      <h1>Choose a dog or cat image</h1>
      <input type="file" onChange={onLoadPreview} accept="image/*" />
      {previewUrl && (
        <div style={{ marginTop: 10 }}>
          <img
            src={previewUrl}
            onLoad={predict}
            width={224}
            height={224}
            alt="preview"
          />
        </div>
      )}
      {predictionStatus === 'predicting' ? (
        'Predicting...'
      ) : (
        <div style={{ fontSize: 50 }}>{predictionStatus}</div>
      )}
    </div>
  )
}

What it does:

1. Using the input file, we show in the <img> element the image preview with 224x224px resolution (important to keep it).
2. Once the image is loaded (onLoad event) we can start predicting.

And the result:

Why in the browser?

You've probably wondered at some point why are we doing it with JavaScript, rather than Python or something else.

Here are several reasons:

• Faster predictions: It's not necessary to make a request to any server from our application, so we save the time it takes for the request.
• Working offline: As in the previous point, we can make predictions with our device (mobile, tablet, desktop...) even without the Internet.
• Cost zero in money: We just need to put our app on a CDN. If 2000 people are using the application at the same time to make predictions, we won't saturate any server as there is no need even to have a server. Each user will make the predictions directly from their device.
• Open-source models: Instead of hiding the models behind a server by using them with JavaScript, we are publishing them in such a way that any developer who likes the application can use the same models for their project.
• Privacy: The data is not stored in any external database nor travels on the net, it stays on the device.

Code of this article

The code of this article can be found in my GitHub:

• https://github.com/aralroca/cat-dog-detection-tfjs

And the demo link:

• https://cat-dog-detection-tfjs.vercel.app/

Conclusion

We've seen how to solve any kind of image classification problem with a few steps. As an example, we have implemented a cat/dog classifier. The same example can be replicated for any type of image classification:

• Skin cancer detection
• Rock-paper-scissors game
• etc

References and acknowledgments

I want to thank Kevin Scott (author of ml-classifier tool) for this article. He helped me understand and solve some problems.

• https://github.com/thekevinscott/ml-classifier-ui
• https://thekevinscott.com/image-classification-with-javascript/
• https://www.tensorflow.org/js/tutorials

In this article, I will discuss a common issue that I have encountered in React applications: the creation of single-use components that lack the versatility and elegance of a truly reusable component. Rather than designing components for specific use cases, it is more beneficial to create generic components that can be adapted to various contexts.

Problem: Simple-use and overly contextualized components

Some developers argue that it is acceptable to initially create a single-use component and refactor it later if a similar component is needed elsewhere. While this approach may avoid violating the YAGNI principle, it is not ideal.

The YAGNI (You Aren't Gonna Need It) principle is a software development practice that focuses on avoiding the implementation of unnecessary features. Instead of anticipating all possible future requirements and writing code for them, developers should write code only to meet the current project's needs.

...Are we doing the right thing here?

Consider an example where we are creating a ProductCardCarousel component because we will only use it momentarily for the product page.

We have created first the product page and placed a significant amount of logic there, and subsequently, we have transferred some of this logic into a component named ProductCardCarousel because it is responsible for displaying the products in a carousel.

First we implemented the product page:

export default function ProductPage({ products }) {
  return (
    <div>
      {/* ...more code here... */}
      <div className="product-carousel">
        {products.map((product) => (
          <div className="card" key={product.id}>
            <img src={product.image} alt="Product" />
            <h4>{product.name}</h4>
            <p>{product.description}</p>
          </div>
        ))}
      </div>
    </div>
  )
}

Then transferred some logic into ProductCardCarousel:

export default function ProductPage({ products }) {
  return (
    <div>
      {/* ...more code here... */}
      <ProductCardCarousel products={products} />
    </div>
  )
}

// product-card-carousel.js
export function ProductCardCarousel({ products }) {
  return (
    <div className="product-carousel">
      {products.map((product) => (
        <div className="card" key={product.id}>
          <img src={product.image} alt="Product" />
          <h4>{product.name}</h4>
          <p>{product.description}</p>
        </div>
      ))}
    </div>
  )
}

Does that make sense? 🤔 Well, we are approaching this task inaccurately.

Creating single-use components is a bad practice because it can lead to inefficient and duplicative code. These components lack versatility and elegance and are designed for specific use cases, making it challenging to adapt them to different contexts. Placing a significant amount of logic in a specific part of the codebase can result in code duplication, as developers may need to create similar components for other use cases. Refactoring single-use components into reusable ones can also be challenging.

Shift in focus

The best practice is to design versatile and elegant components from the outset to avoid these issues.

What I propose is a shift in focus when implementing React components from the start. This change not only adheres to the YAGNI principle but also makes your project more scalable, allowing for more reusable components and reducing the need for future refactoring.

The key is to ensure that components are as "dumb" as possible concerning business logic. Their sole responsibility should be to serve as UI components that can receive any context required to fulfill their UI functionality.

When component names start to include business logic or other UI behaviors rather than just one UI element, it is a sign that the component may be overly contextualized. In the last ProductCardCarousel example, should not contain product-specific logic neither card-specific logic.

Developing a web page using React without first defining its components is akin to attempting to construct a Lego house without the requisite Lego pieces.

Solution: Components as Lego Blocks

To address this issue, it is helpful to approach the implementation of new React features by starting with the lower-level components and working your way up to the parent component, which will handle the business logic. The parent component can then use the created UI components (or existing ones) and feed them the necessary context without burdening them with the responsibility of managing business logic.

A common mistake is to begin at the top level. This approach often leads to the creation of a component containing all the logic, which is later broken down into smaller components. This only serves to pass the responsibility of managing business logic down through the component hierarchy. For example:

• 1: ProductSection
  • 2: ProductSubsection
    • 3: ProductCardCarousel
    • 4: ProductCardList

This method does not make sense. It is reminiscent of working with a single HTML file 20 years ago—the only difference is that the code is now distributed across multiple components.

The true power of components lies in their reusability and separation from business logic.

In order to fix the example above, development should begin with the Card component, which should be entirely agnostic to the business logic. Although the Card is required for displaying products, it should be adaptable to any context (e.g., product, user, etc.). Once the Card component is complete, developers can create both a List and a Carousel component to display cards. These components (List and Carousel) should also be context-agnostic, accepting any content such as Card, images, paragraphs, etc.

Finally, at the highest level, all these "Lego pieces" can be assembled to construct the ProductSection. By keeping the business logic at the top level, the ProductSection can combine these context-agnostic UI components to satisfy the requirements of the specific business model.

• 4: ProductSection
  • 2: Carousel
    • 1: Card
  • 3: List
    • 1: Card

Simple example in code:

// card.js
export function Card({ image, alt, name, description }) {
  return (
    <div className="card">
      <img src={image} alt={alt} />
      <h4>{name}</h4>
      <p>{description}</p>
    </div>
  )
}

// carousel.js
export function Carousel({ children }) {
  return <div className="carousel">{children}</div>
}

// list.js
export function List({ children }) {
  return <div className="list">{children}</div>
}

// product-section.js
export default function ProductSection({ products }) {
  const productCards = products.map((product) => (
    <Card
      key={product.id}
      alt="Product"
      image={product.image}
      name={product.name}
      description={product.description}
    />
  ))

  return (
    <div className="product-section">
      {/* ...more code here... */}
      <h2>Products carousel</h2>
      <Carousel>{productCards}</Carousel>
      <h2>Products list</h2>
      <List>{productCards}</List>
    </div>
  )
}

Once you have established your components, you can create not only the required web page but also other pages with entirely different business logic, leveraging the same building blocks.

The advantage of using reusable components is that they can be adapted to various contexts, providing a more efficient and effective development process. By designing generic components that can be utilized in different scenarios, developers can avoid duplicative and inefficient code, resulting in a more robust and scalable application.

Conclusion

In conclusion, when developing in React, it is crucial to avoid creating components that lack real utility or usefulness and are designed for single-use. Instead, developers should focus on creating generic components that can be used in many different contexts.

When implementing a new React feature, it is best to start with the lowest-level components and work up to the parent, which will have the business logic and can use the UI components that have been created to display the UI. This approach ensures that components are much more reusable and scalable and avoids violating the YAGNI principle.

Finally, developers should shift their focus from creating the simplest possible components to the business model. The only responsibility of a UI component should be to display the UI and be fed with any context necessary to fulfill its UI functionality. By following these guidelines, developers can create more efficient and maintainable React applications.

What is "default-composer"?

"default-composer" is a lightweight (~300B) JavaScript library that allows you to set default values for nested objects. The library replaces empty strings/arrays/objects, null, or undefined values in an existing object with the defined default values, which helps simplify programming logic and reduce the amount of code needed to set default values.

Benefits over Spread Operator and Object.assign

While ...spread operator and Object.assign() can also be used to set default values for objects, "default-composer" provides several benefits over these methods.

• Works with nested objects, whereas the spread operator and Object.assign() only work with shallow objects.
• More concise and easier to read than spread operator or Object.assign(). The code required to set default values with these methods can become very verbose and difficult to read, especially when dealing with nested objects.
• More granular control over which properties should be set to default values. With spread operator and Object.assign().

Imagine we have this original object:

const original = {
  name: '',
  score: null,
  address: {
    street: '',
    city: '',
    state: '',
    zip: '',
  },
  emails: [],
  hobbies: [],
  another: 'anotherValue',
}

And these are the defaults:

const defaults = {
  name: 'John Doe',
  score: 5,
  address: {
    street: '123 Main St',
    city: 'Anytown',
    state: 'CA',
    zip: '12345',
  },
  emails: ['john.doe@example.com'],
  hobbies: ['reading', 'traveling'],
}

We want to merge these objects replacing the original values that are "", null, [], undefined and {} to the default value. So the idea is to get:

console.log(results)
/**
 * {
 * "name": "John Doe",
 * "score": 5,
 * "address": {
 *   "street": "123 Main St",
 *   "city": "Anytown",
 *   "state": "CA",
 *   "zip": "12345"
 * },
 * "emails": [
 *   "john.doe@example.com"
 * ],
 * "hobbies": [
 *   "reading",
 *   "traveling"
 * ],
 * "another": "anotherValue"
 **/

Probably with spread operator we will have to do something like that:

const results = {
  ...defaults,
  ...original,
  name: original.name || defaults.name,
  score: original.score ?? defaults.score, // "??" beacause 0 is valid
  address: {
    ...defaults.address,
    ...original.address,
    street: original.address.street || defaults.address.street,
    city: original.address.city || defaults.address.city,
    state: original.address.state || defaults.address.state,
    zip: original.address.zip || defaults.address.zip,
  },
  emails: original.emails.length ? original.emails : defaults.emails,
  hobbies: original.hobbies.length ? original.hobbies : defaults.hobbies,
}

and with Object.assign something like this:

const results = Object.assign({}, defaults, original, {
  name: original.name || defaults.name,
  score: original.score ?? defaults.score, // "??" beacause 0 is valid
  address: Object.assign({}, defaults.address, original.address, {
    street: original.address.street || defaults.address.street,
    city: original.address.city || defaults.address.city,
    state: original.address.state || defaults.address.state,
    zip: original.address.zip || defaults.address.zip,
  }),
  emails: original.emails.length ? original.emails : defaults.emails,
  hobbies: original.hobbies.length ? original.hobbies : defaults.hobbies,
})

Maintaining this can be very tidious, especially with huge, heavily nested objects.

With defaultComposer we could only use this:

import defaultComposer from 'default-composer' // 300B
// ...
const results = defaultComposer(defaults, original)

Easier to maintain, right? 😉

What happens if in our project there is a special property that works differently from the others and we want another replacement logic? Well, although defaultComposer has by default a configuration to detect the defautable values, you can configure it as you like.

import { defaultComposer, setConfig } from 'default-composer'

setConfig({
  // This function is executed for each value of each key that exists in
  // both the original object and the defaults object.
  isDefaultableValue: (
    // - key: key of original or default object
    // - value: value in the original object
    // - defaultableValue: pre-calculed boolean, you can use or not,
    //   depending if all the rules of the default-composer library are correct
    //   for your project or you need a totally different ones.
    { key, value, defaultableValue }
  ) => {
    if (key === 'rare-key') {
      return defaultableValue || value === 'EMPTY'
    }

    return defaultableValue
  },
})

Conclusions

I've introduced the "default-composer" library as a solution for setting default values for nested objects in JavaScript.

The library is lightweight and provides more concise and easier-to-read code than the spread operator and Object.assign methods. It also offers more granular control over which properties should be set to default values.

In this article I provide examples of how to use the library and how it simplifies the code for maintaining nested objects.

Finally, I explain how the library can be configured to handle special cases where a different replacement logic is required. Overall, "default-composer" is a useful library for simplifying the task of setting default values for nested objects in JavaScript.

In today's article I want to show you how easy it's to use the text toxicity detection model without any previous knowledge of machine learning.

What is text toxicity detection?

Toxicity detection detects text containing toxic content such as threatening language, insults, obscenities, identity-based hate, or sexually explicit language.

With this in your browser, it'll be esier to prevent unwanted comments/opinions and speed up the review process of these content.

However, this looks so complicated... Nah, good news for you! You don't need to be a machine-learning expert to use this model. Let's see how.

The hook

I wrote a React hook to simplify the way to use it, so you can get the predictions of text just by using a hook in one line of code:

import useTextToxicity from 'react-text-toxicity'

// Usage inside your component or custom hook
const predictions = useTextToxicity('This is an example')
/*
  {
    "label": "identity_attack",
    "match": false,
    "probability": "3.40%",
    "probabilities": [0.9659664034843445, 0.03403361141681671],
  },
  {
    "label": "insult",
    "match": true,
    "probability": "91.8%",
    "probabilities": [0.08124706149101257, 0.9187529683113098],
  },
  ...
*/

I uploaded the npm package so you can use it by doing:

yarn add react-text-toxicity

And the GitHub repo 👉 https://github.com/aralroca/react-text-toxicity

We can connect the useTextToxicity hook to a state by using:

const [value, setValue] = useState('')
const predictions = useTextToxicity(value)

//...
;<textarea value={value} onChange={(e) => setValue(e.target.value)} />

This way, everytime that the value changes, the predictions will be updated (we can predict "on the fly").

Here's the full example code of Fig 1:

import React, { Fragment, useState } from 'react'
import useTextToxicity from 'react-text-toxicity'

function Toxicity({ predictions }) {
  const style = { margin: 10 }

  if (!predictions) return <div style={style}>Loading predictions...</div>

  return (
    <div style={style}>
      {predictions.map(({ label, match, probability }) => (
        <div style={{ margin: 5 }} key={label}>
          {`${label} - ${probability} - ${match ? '🤢' : '🥰'}`}
        </div>
      ))}
    </div>
  )
}

export default function Index() {
  const [value, setValue] = useState('')

  // predictions are updated every time the value is updated
  const predictions = useTextToxicity(value)

  return (
    <div style={{ display: 'flex' }}>
      <div>
        <div>Write something</div>
        <textarea
          style={{ width: 300, height: 200 }}
          value={value}
          onChange={(e) => setValue(e.target.value)}
        />
      </div>
      {value && <Toxicity predictions={predictions} />}
    </div>
  )
}

Under the "hook"

Under the hood, the hook is using Tensorflow.js toxicity model:

• https://github.com/tensorflow/tfjs-models/tree/master/toxicity

If you need to implement the same outside React, you can use this repo.

Conclusion

Sometimes when we listen about machine learning and/or Tensorflow our mind disconnects, we think that's too complicated for us. However, there are pretrained models we can use without headaches.

The usage of React hooks facilitates data prediction from pretrained models in one simple line of code.

Now, I encourage you to experiment with these Tensorflow models or start using them in your projects!

In the last few months, I've heard a lot of talk about Snowpack and I hadn't given it a chance. The time has come.

Working with ESM

To understand what Snowpack does, let's see first how to work with ESM directly, without any tools.

Currently, if we want for example to setup a Preact app without any tooling, we can do something like this:

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta charset="utf-8" />
    <script type="module" src="index.js"></script>
    <link rel="stylesheet" type="text/css" href="style.css" />
    <title>Example app</title>
  </head>
  <body id="app" />
</html>

Adding the type="module" to the script tag is enough to tell the browser that we are using ESM.

Then, the index.js will be the entrypoint of our Preact app, the top of the Component tree.

index.js

import { html, render } from 'https://unpkg.com/htm/preact/standalone.module.js'
import { Example } from './example.js'

function App() {
  return html`
    <h1>Some example</h1>
    <${Example} />
  `
}

render(html`<${App} />`, document.getElementById('app'))

This works well. However, it has certain drawbacks that current tools such as Webpack or Parcel already solved. Among the most important:

• Hot reloading in development
• Importing other files as .json, .css...
• Tooling as Typescript, JSX, PostCSS, Sass, Babel...
• Compatibility with legacy browsers
• Managment of thirty party libraries

So... Why not use Webpack or Parcel to cover this? It may still make sense to use bundlers such as Webpack or Parcel. Let's keep asking... What does a bundler do? Why do we really need a bundler?

Module bundlers

In 2012 there were no ESM and with the arrival of Webpack the use of bunlders began to be relevant. Thanks to them it's possible to use .js files as if they were modules, being able to use import and export everywhere.

Bundlers still make a lot of sense today, since many browsers do not yet support ESM. We can use the same process to minimize and optimize our production code.

The main question here should be "Does it make sense to keep using a bundler in development?" Running your entire application through a bundler introduces additional work and complexity to your dev workflow that is unnecessary now that ESM is widely supported.

Unbundled Development

Snowpack was intended to use an unbundled development, using directly ESM. Among other advantages:

• Much faster (no-wait build time, reflecting changes immediately)
• Easier to debug
• Project size doesn't affect dev speed
• Simpler tooling
• Minimal configuration

It also provides a solution to the ESM problems we have mentioned. Although you can do the production build directly with Snowpack, it gives you the flexibility to still optimizing your production builds with Webpack or Parcel.

Preact with Snowpack

Let's create a Preact project with create-snowpack-app CLI:

npx create-snowpack-app preact-snowpack-example --template @snowpack/app-template-preact --use-yarn

Then:

cd preact-snowpack-example
yarn start

After yarn start, in ~50ms we have our Preact dev environment up under http://localhost:8080, with Babel, JSX and familiar Webpack things.

You can test it to see how fast and easy it is.

If you inspect the source code you'll see that ESM is used behind the scenes, with some differences:

import { h, render } from '/web_modules/preact.js' // Uses /web_modules/* for dependencies
import '/web_modules/preact/devtools.js'
import App from './App.js'
import './index.css.proxy.js' // Uses .js files for css imports

Conclusion

We have seen a bit of Snowpack's surface, enough to start understanding how it fits into the JavaScript ecosystem.

I hope this article will make you curious and eager to try Snowpack. It's not a guide, to know more details about Snowpack and ESM I recommend to visit the reference links.

References

• https://www.snowpack.dev
• https://hacks.mozilla.org/2018/03/es-modules-a-cartoon-deep-dive/

What is Rome?

Rome is a full toolchain (can be used via CLI, VSCode extension, and in the future via API for testing purposes) that unifies the JavaScript and Typescript development: bundling, compiling, documentation generation, formatting, linting, minification, testing, type checking, etc. It tries to be a "one-in-all" solution, being able to do all these tasks under one CLI.

Perhaps you wonder if we can handle Webpack, Babel, Prettier, Jest, etc with this Rome CLI? The answer is NO... Rome implemented all these toolchain from scratch, without any dependency, using the same configuration file for everything.

The person behind this project is Sebastian McKenzie, the same author of Babel and Yarn, who has also worked on projects such as Prepack and React Native.

Rome is still in beta, and right now the current areas fully implemented are linting and formatting. The other areas are still in development.

Better performance

Current tools as webpack, TS, Babel, or ESlint, among others, run their own parser to generate an Abstract Syntax Tree (AST). After this, they manipulate and process their own AST.

When all these tasks become the only tool (Rome), we'll be able to reuse the AST for each task, parsing the files only once. Also, some processes will be simplified, for example: watching files, dependency verification, or integration with your editor.

Who benefits?

• Maintainers/contributors: simplifies all unnecessary duplications.
• Developers: a faster development experience with less consumption of resources.

Only one configuration file

Right now we need to configure too many tools for a simple feature, for example, to work with absolute imports you need to configure ESLint, TS, and also webpack!

Instead, using the same tool (Rome) removes the duplicated configurations, so we'll only have one config file.

In addition, some tools configurations are currently depending on others, for example, Prettier has to be integrated with ESLint to avoid conflicting formatting. Often these tools integrations require adding a whole bunch of plugins to make them work together but, with Rome, we don't have the need to use any plugin since all the tools are perfectly integrated.

Who benefits?

• Maintainers/contributors: Tools like Babel had exposed all their internals to allow the creation of plugins, making it much more difficult to maintain and evolve.
• Developers: For a feature, you only need to touch one configuration, simplifying the development without the need of plugins. It also makes it much easier to reuse settings between projects.

Less dependencies

In the JavaScript ecosystem, we're used to work with many devDependencies for all the tools and their plugins: Jest, Babel, Prettier, webpack. Besides, each of them have their own dependencies.

With Rome, many of these devDependencies disappear, moreover Rome has zero dependencies.

So we have:

• Stronger security: The chance to have a vulnerability decreases because we drastically reduce all dependencies.
• Better maintenance and evolution of your project: Before, updating a new release of some tool could have broken the integration with another one. Now all is under one well-integrated big tool.
• Better maintenance and evolution of Rome: Rome has no dependencies, this means it has a lot of flexibility and a great innovator potential. For example, if they wanted to migrate to another language using wasm, they could do it.
• Faster installation: You won't have to wait so long after doing npm install. Less things to install.

Friendly for beginners

As we've seen in the previous sections, Rome makes it much easier to start a project.

We feel more encouraged to start learning something new if we see that it has an easy start. In the last years starting JavaScript projects without frameworks was really complicated. Simplifying all this tooling will encourage many to learn and enter the world of JavaScript in a much more enjoyable way.

In order to take the first steps in Rome, you can install it via yarn or npm, and then run npx rome init / yarn rome init to create the default .config/rome.rjson.

Finally, you can use every command of the CLI using rome [command], as rome check for linting and formatting a set of files, rome format to format a single file, rome start to start a daemon, etc. You can see all the available commands by running rome --help.

Do all roads lead to Rome? My thoughts about it

We started the article questioning about if Rome is going to replace all current toolchain. It's a question that will be answered over time, depending on the adoption of Rome within the community and the evolution of Rome and the current tools.

From my point of view, I think that in the short term the answer is "no". Although it replaces the functionality of those tools, that doesn't obsolete them. There are still a lot of projects that depend on them. However, in the long term I think the answer would be "yes". It may not be Rome, maybe another similar approach like Deno adopting a similar philosophy of having everything integrated.

In my opinion, the JavaScript ecosystem is too fragmented right now, you usually need to have a bunch of dependencies installed for most things. New projects like Rome or Deno, even though many people think that they're fragmenting even more the ecosystem, I think it's just the opposite. They're tools that aim to fix that fragmentation, and that's positive.

You may be wondering if one of the pieces doesn't fit 100% your needs and you still want to use your old tool. For example, you could prefer to continue using webpack as a compiler. The good thing about Rome is that if you only want to use one piece, you can. Thus, you can also use all of Rome's pieces except the compiler, to continue using webpack or another one.

Now it's your turn, what do you think about the future of JavaScript / TypeScript tooling?

References

• https://romefrontend.dev/blog/2020/08/08/introducing-rome.html
• https://news.ycombinator.com/item?id=24094377
• https://jasonformat.com/rome-javascript-toolchain/

Difference between controlled and uncontrolled

To understand what “uncontrolled” means, first, we’ll see the meaning of “controlled”.

A common mistake in React is to try to control every single field of a form using a state and an onChange method. This way is usually chosen to allow the use of this state inside the onSubmit method, although it’s not the only and best way to get the fields.

Controlled fields

<form onSubmit={onSignIn}>

  <div>
    <input
      required
      value={this.state.username}
      onChange={e => this.setState({ username: e.target.value )}
      name="username"
      type="text"
      placeholder={userNamePlaceholder}
    />
  </div>

  <div>
    <input
      value={this.state.password}
      onChange={e => this.setState({ password: e.target.value )}
      name="password"
      type="password"
      placeholder={passwordPlaceholder}
    />
  </div>

  <button type="submit">
      Sign In
  </button>
</form>

Then we can use the state directly in the onSignIn method.

onSignIn = () => {
  const { username, password } = this.state
  // ...
}

These fields are controlled because every time that the state changes, the text rendered changes inside the input. Moreover, every time that the user types, the onChange event is fired to save the new state. If we type a username of 15 characters and a password of 8; 24 react renders will happen under the hood (one for each character + one extra for the first render).

This controlled behavior is useful if the state is used before submitting the form. For example, to validate dynamically the fields. Otherwise, if we want to use all the fields after submitting the form, it will be more useful to do it uncontrolled.

Uncontrolled fields are the natural way to write without a React state:

Uncontrolled input

<form onSubmit={onSignIn}>
  <div>
    <input
      required
      name="username"
      type="text"
      placeholder={userNamePlaceholder}
    />
  </div>

  <div>
    <input name="password" type="password" placeholder={passwordPlaceholder} />
  </div>

  <button type="submit">Sign In</button>
</form>

In this case, the state is not necessary. We need these fields on the event onSubmit but it’s not necessary to store it at every change in the React state because we already have it in the event. This means that we only do 1 simple render for this component: The first render.

On the onSignIn function, we can find the username and password fields inside event.target.

onSignIn = (event) => {
  const [username, password] = Array.prototype.slice
    .call(event.target)
    .map((field) => field.value)

  // ...
}

However, although we simplified it a little, it’s still quite ugly to repeat this Array.prototype.slice.call in every single form submit. Let’s see how to improve it.

Improving the uncontrolled way

Our goal here is to simplify the logic of every “submit” event in order to avoid the need of finding continuously the fields inside the event.target. We want something more enjoyable like:

onSignIn = ({ username, password }) => {
  // ...
}

In this case, we will provide the fields directly as an argument. This argument is an object with all the fields of the form when the key is the name attribute.

To achieve our goal, we can replace the form tag to our personal Component:

Our reusable personal Form Component could be:

function Form({ children, onSubmit, ...restOfProps }) {
  const onSubmitAllFields = useCallback(
    (event) => {
      event.preventDefault()
      event.stopPropagation()

      const fields = Array.prototype.slice
        .call(event.target)
        .filter((field) => field.name)
        .reduce(
          (form, { name, value }) => ({
            ...form,
            [name]: typeof value === 'string' ? value.trim() : value,
          }),
          {}
        )

      onSubmit(fields)
    },
    [onSubmit]
  )

  return (
    <form {...restOfProps} onSubmit={onSubmitAllFields}>
      {children}
    </form>
  )
}

export default memo(Form)

Thus, we are moving the repeating code that we always do in our forms: preventDefault , stopPropagation , extract fields + trim string fields.

Now, we can use this new approach by only changing one character, from “form” to “Form”.

Note : I’m using the new hooks API (proposal), even though it can also be written as a class component.

Conclusions

Both approaches; controlled and uncontrolled forms are great for different reasons. We have to know the difference to choose the best for any occasion. My advice would be: use normally uncontrolled unless you really need the state to do dynamic checks or to change dynamically the text of each input.

{% twitter 1015954912075644930 %}

If you want to try the Form component, I added in npm:

npm install react-form-uncontrolled --save

Repo: https://github.com/aralroca/react-form-uncontrolled

A little bit of context

When we want to directly use existing image recognition models such as ImageNet, COCO-ssd or YOLO, we are limited to predict only everyday objects such as cars, people, etc. This is because these models have only learned to recognize these objects within an image. However, there are techniques such as transfer-learning that allow us to retrain these models to predict what we want.

In order to retrain these models, we have to manually label each object that we want to recognize by writing the coordinates of the object in a text file for each image to train. This way the model will be able to learn how to recognize them. This labeling process can be very boring and tedious.

Currently, there are not many alternative tools for this labeling process. The best known current tool is labelImg. The tool is good and does its job, although it has some root problems:

• Not available in all devices. It can only be downloaded as a desktop application.
• Requires installation. It requires installation and it isn't very beginner-friendly. Depending on your OS and Python version the dependencies will be different. For example on Mac with Python 3+, you need to install first some dependencies like qt and libxml2 with Homebrew, and pyqt5 and lxml with pip.
• Security. The application manipulates the files on your system. In theory, it only manipulates files related to annotations. I say "in theory", because we hope there won't be a bug in the future touching what it shouldn't...
• Updates are not automatic. Related to the previous point, many updates are made for security reasons, especially if it has dependencies. The fact that updates are not done automatically makes it your responsibility to keep your application up to date.

Launching Etiketai

Using labelImg during the last months, I realized that a web application inspired by it would solve several of these problems:

• Available in all devices. Being a web application makes it accessible from any device, even tablets, and mobiles.
• No installation required. It speeds up the start, as it does not require installation and has no dependencies on your operating system. Only the browser.
• Automatic updates. You will always have the latest version available.
• Security. No file on your system is directly manipulated. Files are imported/saved using the security layer of your browser.
• Beginner-friendly. We want it to be an easy-to-use process without losing flexibility. To start, you only need to open a browser with any device.

So during my August holiday, I took the opportunity to implement the first POC of my idea. And today, I announce that its first version is out.

This version 1.0.0 is focused on being useful as a web tool to label your images and supports both ImageNet and YOLO, and its variants.

In addition, I tried to improve the user experience when labeling by making it less necessary to press so many buttons.

Currently, I have some future ideas to expand the features so that it does not remain only as an annotation tool, but to train models after labeling the images.

Future features

As a free open-source tool we want to evolve according to the contributions of the community. However, in the first version, there are some things that have not yet been implemented and the idea is to implement them for the next version:

• Improve tablet / mobile experience. Now the support is minimal, it works, but not as well as some users would like. For example, it is not very responsive. This should be improved in a next version.
• Possibility to train directly your labeled images with the same app and also to save the generated model.
• Offline support. Now it only works online, but one of the improvements would be to support it offline as PWA.

Any further improvements you would like to make? Please let me know in the comments.

Try it

I encourage you to try the app and contribute to GitHub to evolve this tool according to the community.

• App: https://etiketai.vercel.app/
• GitHub: https://github.com/aralroca/etiketai

To help me boost this project, please, let me know that you like it by starring on GitHub.

To know more about it, I recommend to read these references:

• https://wicg.github.io/portals/#the-portalactivateevent-interface
• https://web.dev/hands-on-portals
• https://github.com/WICG/portals/blob/master/explainer.md

In this article, I will explain how to use this future feature to do a "Hello world" demo with React.

Getting started

First of all, to use this draft feature you'll need Chrome Canary. Once you have it, activate the flag of Portals:

Next, we'll test portals. Remember that portals need to be on the top level of our app (unlike it happens with iframes).

Hello world with HTMLPortalElement and React:

import React, { useState, useEffect, useRef } from 'react'
import { render } from 'react-dom'

function PortalExample() {
  if (!window.HTMLPortalElement) {
    return 'HTMLPortalElement is not supported in your browser.'
  }

  return <portal src="https://aralroca.com" />
}

render(<PortalExample />, document.getElementById('root'))

We get a similar result than using an iframe:

Nevertheless, we want a beautiful transition to navigate to the content of this page. How could we get this?

Navigating to a portal

<portal
  src="https://aralroca.com"
  // navigate to content
  onClick={({ target }) => target.activate()}
/>

Now we can navigate to the content. Although without any transition... yet:

Adding a page transition

Therefore, our css transition is going to scale the portal until the portal fits all the content of the page (width and height 100%).

React code:

import React, { useState } from 'react'
import { render } from 'react-dom'

import './style.css'

function PortalExample() {
  const [transition, setTransition] = useState(false)

  if (!window.HTMLPortalElement) {
    return 'HTMLPortalElement is not supported in your browser.'
  }

  return (
    <portal
      src="https://aralroca.com"
      className={`portal ${transition ? 'portal-reveal' : ''}`}
      onClick={() => setTransition(true)}
      onTransitionEnd={(e) =>
        e.propertyName === 'transform' && e.target.activate()
      }
    />
  )
}

render(<PortalExample />, document.getElementById('root'))

Styles:

body {
  background-color: #212121;
}

.portal {
  position: fixed;
  width: 100%;
  cursor: pointer;
  height: 100%;
  transition: transform 0.4s;
  box-shadow: 0 0 20px 10px #999;
  transform: scale(0.4);
}

.portal.portal-reveal {
  transform: scale(1);
}

Finally, we get the page transition in our portal:

Code: https://github.com/aralroca/HTMLPortalElement-react-example

Benefits of portals

They can be useful for previews of videos / audio, so you can navigate to the content page without stop watching / listening the media at any moment.

Of course, here we are using a different origin (YouTube). Nevertheless, if we use the same origin, we can communicate with the portal at any moment and do things like displaying a beauty preview or loading the rest of the content after the portal is activated.

Conclusion

References:

• https://wicg.github.io/portals/#the-portalactivateevent-interface
• https://web.dev/hands-on-portals
• https://github.com/WICG/portals/blob/master/explainer.md

We will cover the following:

• What is WebGL?
• Creating a WebGL Canvas
• Vertex coordinates
• GLSL and shaders
  • Vertex shader
  • Fragment shader
• Create program from shaders
• Create buffers
• Link data from CPU to GPU
• Drawing the triangle
• All the code together
• Conclusion
• References

What is WebGL?

The literal definition of WebGL is "Web Graphics Library". However, it is not a 3D library that offers us an easy-to-use API to say: «put a light here, a camera there, draw a character here, etc».

It's in a low-level that converts vertices into pixels. We can understand WebGL as a rasterization engine. It's based on OpenGL ES 3.0 graphical API (WebGL 2.0, unlike the old version that is based on ES 2.0).

The existing 3d libraries on the web (like THREE.js or Babylon.js) use WebGL below. They need a way to communicate to the GPU to tell what to draw.

This example could also be directly solved with THREE.js, using the THREE.Triangle. You can see an example here. However, the purpose of this tutorial is to understand how it works underneath, i.e. how these 3d libraries communicate with the GPU via WebGL. We are going to render a triangle without the help of any 3d library.

Creating a WebGL canvas

In order to draw a triangle, we need to define the area where it is going to be rendered via WebGL.

We are going to use the element canvas of HTML5, retrieving the context as webgl2.

import { useRef, useEffect } from 'preact/hooks'

export default function Triangle() {
  const canvas = useRef()

  useEffect(() => {
    const bgColor = [0.47, 0.7, 0.78, 1] // r,g,b,a as 0-1
    const gl = canvas.current.getContext('webgl2') // WebGL 2.0

    gl.clearColor(bgColor) // set canvas background color
    gl.clear(gl.DEPTH_BUFFER_BIT | gl.COLOR_BUFFER_BIT) // clear buffers
    // @todo: Render the triangle...
  }, [])

  return <canvas style={{ width: '100vw', height: '100vh' }} ref={canvas} />
}

The clearColor method sets the background color of the canvas using RGBA (with values from 0 to 1).

Furthermore, the clear method clears buffers to preset values. Used constants values are going to depend on your GPU capacity.

Once we have the canvas created, we are ready to render the inside triangle using WebGL... Let's see how.

Vertex coordinates

First of all, we need to know that all these vectors range from -1 to 1.

Corners of the canvas:

• (0, 0) - Center
• (1, 1) - Top right
• (1, -1) - Bottom right
• (-1, 1) - Top left
• (-1, -1) - Bottom left

The triangle we want to draw has these three points:

(-1, -1), (0, 1) and (1, -1). Thus, we are going to store the triangle coordinates into an array:

const coordinates = [-1, -1, 0, 1, 1, -1]

GLSL and shaders

A shader is a type of computer program used in computer graphics to calculate rendering effects with high degree of flexibility. These shaders are coded and run on the GPU, written in OpenGL ES Shading Language (GLSL ES), a language similar to C or C++.

Each WebGL program that we are going to run is composed by two shader functions; the vertex shader and the fragment shader.

Almost all the WebGL API is made to run these two functions (vertex and fragment shaders) in different ways.

Vertex shader

The job of the vertex shader is to compute the positions of the vertices. With this result (gl_Position) the GPU locates points, lines and triangles on the viewport.

To write the triangle, we are going to create this vertex shader:

const vertexShader = `#version 300 es
  precision mediump float;
  in vec2 position;

  void main () {
      gl_Position = vec4(position.x, position.y, 0.0, 1.0); // x,y,z,w
  }
`

We can save it for now in our JavaScript code as a template string.

The first line (#version 300 es) tells the version of GLSL we are using.

The second line (precision mediump float;) determines how much precision the GPU uses to calculate floats. The available options are highp, mediump and lowp), however, some systems don't support highp.

In the third line (in vec2 position;) we define an input variable for the GPU of 2 dimensions (X, Y). Each vector of the triangle is in two dimensions.

The main function is called at program startup after initialization (like in C / C++). The GPU is going to run its content (gl_Position = vec4(position.x, position.y, 0.0, 1.0);) by saving to the gl_Position the position of the current vertex. The first and second argument are x and y from our vec2 position. The third argument is the z axis, in this case is 0.0 because we are creating a geometry in 2D, not 3D. The last argument is w, by default this should be set to 1.0.

The GLSL identifies and uses internally the value of gl_Position.

Once we create the shader, we should compile it:

const vs = gl.createShader(gl.VERTEX_SHADER)

gl.shaderSource(vs, vertexShader)
gl.compileShader(vs)

// Catch some possible errors on vertex shader
if (!gl.getShaderParameter(vs, gl.COMPILE_STATUS)) {
  console.error(gl.getShaderInfoLog(vs))
}

Fragment shader

After the "vertex shader", the "fragment shader" is executed. The job of this shader is to compute the color of each pixel corresponding to each location.

For the triangle, let's fill with the same color:

const fragmentShader = `#version 300 es
  precision mediump float;
  out vec4 color;

  void main () {
      color = vec4(0.7, 0.89, 0.98, 1.0); // r,g,b,a
  }
`
const fs = gl.createShader(gl.FRAGMENT_SHADER)

gl.shaderSource(fs, fragmentShader)
gl.compileShader(fs)

// Catch some possible errors on fragment shader
if (!gl.getShaderParameter(fs, gl.COMPILE_STATUS)) {
  console.error(gl.getShaderInfoLog(fs))
}

The syntax is very similar to the previous one, although the vect4 we return here refers to the color of each pixel. Since we want to fill the triangle with rgba(179, 229, 252, 1), we'll translate it by dividing each RGB number by 255.

Create program from shaders

Once we have the shaders compiled, we need to create the program that will run the GPU, adding both shaders.

const program = gl.createProgram()
gl.attachShader(program, vs) // Attatch vertex shader
gl.attachShader(program, fs) // Attatch fragment shader
gl.linkProgram(program) // Link both shaders together
gl.useProgram(program) // Use the created program

// Catch some possible errors on program
if (!gl.getProgramParameter(program, gl.LINK_STATUS)) {
  console.error(gl.getProgramInfoLog(program))
}

Create buffers

We are going to use a buffer to allocate memory to GPU, and bind this memory to a channel for CPU-GPU communications. We are going to use this channel to send our triangle coordinates to the GPU.

// allowcate memory to gpu
const buffer = gl.createBuffer()

// bind this memory to a channel
gl.bindBuffer(gl.ARRAY_BUFFER, buffer)

// use this channel to send data to the GPU (our triangle coordinates)
gl.bufferData(
  gl.ARRAY_BUFFER,
  new Float32Array(coordinates),
  // In our case is a static triangle, so it's better to tell
  // how are we going to use the data so the WebGL can optimize
  // certain things.
  gl.STATIC_DRAW
)

// desallocate memory after send data to avoid memory leak issues
gl.bindBuffer(gl.ARRAY_BUFFER, null)

Link data from CPU to GPU

In our vertex shader, we defined an input variable named position. However, we haven't yet specified that this variable should take the value that we are passing through the buffer. We must indicate it in the following way:

const position = gl.getAttribLocation(program, 'position')
gl.enableVertexAttribArray(position)
gl.bindBuffer(gl.ARRAY_BUFFER, buffer)
gl.vertexAttribPointer(
  position, // Location of the vertex attribute
  2, // Dimension - 2D
  gl.FLOAT, // Type of data we are going to send to GPU
  gl.FALSE, // If data should be normalized
  0, // Stride
  0 // Offset
)

Drawing the triangle

Once we have created the program with the shaders for our triangle and created the linked buffer to send data from the CPU to the GPU, we can finally tell the GPU to render the triangle!

gl.drawArrays(
  gl.TRIANGLES, // Type of primitive
  0, // Start index in the array of vector points
  3 // Number of vertices to be rendered
)

This method renders primitives from array data. The primitives are points, lines or triangles. Let's specify gl.TRIANGLES.

All the code together

I've uploaded the article code to CodeSandbox in case you want to explore it.

Conclusion

With WebGL it is only possible to draw triangles, lines or points because it only rasterizes, so you can only do what the vectors can do. This means that WebGL is conceptually simple, while the process is quite complex... And gets more and more complex depending on what you want to develop. It's not the same to rasterize a 2D triangle than a 3D videogame with textures, varyings, transformations...

I hope this article has been useful to understand a little bit of how WebGL works. I recommend a reading of the references below.

References

• https://webglfundamentals.org
• https://webgl2fundamentals.org/
• https://developer.mozilla.org/es/docs/Web/API/WebGL_API/Tutorial/
• https://developer.mozilla.org/en-US/docs/Web/API/WebGL_API/WebGL_best_practices
• http://vispy.org/modern-gl.html
• https://github.com/subhasishdash/webglinternals

We'll cover the following:

• What is WebAssembly?
• Why in Rust?
• Execute Rust code from JavaScript
  • Rust code
  • Compilation
  • Use the compiled code on our JS project
• Execute JavaScript code from Rust
• Performance - JavaScript vs Rust
• Debugging
• Publishing to NPM
• Code from the article
• Conclusions
• References

What is WebAssembly?

In all current browsers, there is a JavaScript engine that interprets and executes the code. This has allowed us to implement very rich web applications because JavaScript is getting better and more complete every day. However, it's a high-level language but still not ideal for some tasks because it has not been developed to be a fast language with a lot of performance.

WebAssembly (WASM) is a new portable binary-code format that can be executed in modern browsers. It is complemented with a text format (WAT) to make it more readable/debuggable for us, in addition, to allow us to code directly in a kind of "assembly" code. It's an open W3C standard still in progress that allows us to write fast and efficient code for the web in other languages than JavaScript and it runs with a similar performance to the native language. It's not here to replace JavaScript, but to complement it.

Another purpose of WebAssembly is to keep the web secure, light and fast, keeping a small .wasm file size and always maintaining backwards-compatibility in new WASM features, so the web doesn't break.

There are more than 40 supported languages for WebAssembly, the most common are C, C++, and Rust for their performance and maturity, although you also can write code for WASM with high-level languages like Python, PHP or even JavaScript!

Some practical uses of WebAssembly:

• Encryption
• Games that require a lot of assets
• Image and video editing
• P2P
• High-performance algorithms
• VR, AR
• Visualizations and simulations
• A big etc...

Why in Rust?

Perhaps you wonder why choose Rust, when we have so many languages available with WebAssembly. There are several reasons for that:

• Performance: Rust is free from the non-deterministic garbage collection and it gives to programmers the control over indirection, monomorphization, and memory layout.
• Small .wasm sizes: Rust lacks a runtime, enabling small .wasm size because there is no extra bloat included like a garbage collector. Hence you only pay in code size, for these functions that you're using.
• Integration: Rust and Webassembly integrates with existing JavaScript tooling (npm, Webpack...).

Execute Rust code from JavaScript

Assuming you have both NPM (for JS) and Cargo (for Rust), another prerequisite we need to install it is wasm-pack:

> cargo install wasm-pack

Rust code

Let's create a new Rust project for the "Hello world":

> cargo new helloworld --lib

On Cargo.toml we are going to add the next:

[package]
name = "helloworld"
version = "0.1.0"
authors = ["Aral Roca Gomez <contact@aralroca.com>"]
edition = "2018"

## new things...
[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2.67"

[package.metadata.wasm-pack.profile.release]
wasm-opt = ["-Oz", "--enable-mutable-globals"]

• cdylib lib for wasm final artifacts.
• wasm-bindgen dependency to facilitate high-level interactions between Wasm modules and JavaScript.

Note: The latest part about --enable-mutable-globals in principle, in upcoming wasm-bindgen releases, should not be needed but for this tutorial it's necessary. Otherwise we can not work with Strings.

WebAssembly only supports the i32, u32, i64, and u64 types. If you want to work with other types, such as String or Objects, you normally must first encode them. However, wasm-bindgen does these bindings for us. There's no need to worry about it anymore. That said, let's create our helloworld function to return a String in src/lib.rs:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn helloworld() -> String {
    String::from("Hello world from Rust!")
}

Compilation

Let's compile Rust's code with:

> wasm-pack build --target web

We are using the web target, however, there are different targets we can use depending on how we want to use that wasm file:

• --target bundler - for bundlers like Webpack, Parcel, or Rollup.
• --target web - for the web as ECMAScript module.
• --target no-modules - for the web without ECMAScript module.
• --target nodejs - for Node.js

After executing the above command, a pkg directory will have been created with our JavaScript library containing the code we have made in Rust! It even generates the "types" files of TypeScript.

> ls -l pkg
total 72
-rw-r--r--  1 aralroca  staff    929 Aug 15 13:38 helloworld.d.ts
-rw-r--r--  1 aralroca  staff   3210 Aug 15 13:38 helloworld.js
-rw-r--r--  1 aralroca  staff    313 Aug 15 13:38 helloworld.wasm
-rw-r--r--  1 aralroca  staff    268 Aug 15 13:38 helloworld_bg.d.ts
-rw-r--r--  1 aralroca  staff  15160 Aug 15 13:38 helloworld_bg.wasm
-rw-r--r--  1 aralroca  staff    289 Aug 15 13:38 package.json

Now it's ready as a JavaScript package so we can use it in our project or even upload the package to NPM as we can see later.

The .js file contains the necessary "glue" code to not have to worry about working outside the pkg with buffers, text decoders, etc.

Use the compiled code on our JS project

In order to use the wasm file in our JavaScript, we can import the generated pkg module to our project. To test it, we can create an index.html on the root of the Rust project with this:

<!DOCTYPE html>
<html>
  <head>
    <meta charset="UTF-8" />
    <title>"Hello world" in Rust + Webassembly</title>
    <script type="module">
      import init, { helloworld } from './pkg/helloworld.js'

      async function run() {
        await init()
        document.body.textContent = helloworld()
      }

      run()
    </script>
  </head>

  <body></body>
</html>

As you can see, before using the helloworld function it's important to call the asynchronous init function in order to load the wasm file. Then, we can use the public Rust functions more easily!

To test it, you can do npx serve . and open http://localhost:5000.

Execute JavaScript code from Rust

It is possible to use JavaScript code within Rust, for example, to use window variables, write in the DOM or call internal functions such as console.log. All we have to do is to declare the JavaScript bindings we want to use inside extern "C".

As an example we are going to use the function console.log inside Rust:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
extern "C" {
    #[wasm_bindgen(js_namespace = console)]
    fn log(s: &str);
}

#[wasm_bindgen]
pub fn example() {
    log("Log from rust");
}

As we can see, inside the extern "C" we have to indicate the js_namespace (console) declaring the function that we'll use inside the namespace (log). In this case, we've put only one string as a parameter but if we wanted to execute a console.log with multiple parameters they would have to be declared.

And in our JS:

import init, { example } from './pkg/helloworld.js'

async function run() {
  await init()
  example() // This will log "Log from rust" to the console
}

run()

Performance - JavaScript vs Rust

Let's do a comparison of a slightly more expensive function, such as the fibonacci function, to see how it performs in both Rust and JavaScript:

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn fibonacci(n: u32) -> u32 {
    match n {
        0 | 1 => n,
        _ => fibonacci(n - 1) + fibonacci(n - 2),
    }
}

Using the console.time function we can measure the performance of each one:

import init, { fibonacci } from './pkg/helloworld.js'

function fibonacciInJs(n) {
  if (n <= 1) return n
  return fibonacciInJs(n - 1) + fibonacciInJs(n - 2)
}

async function run() {
  await init()
  const num = 20

  console.time('Fibonnaci in rust')
  const fibRust = fibonacci(num)
  console.timeEnd('Fibonnaci in rust')

  console.time('Fibonnaci in JS')
  const fibJS = fibonacciInJs(num)
  console.timeEnd('Fibonnaci in JS')

  document.body.textContent = `Fib ${num}:  Rust ${fibRust} - JS ${fibJS}`
}

run()

And the result:

• In Rust: 0.13ms
• In JS: 1.28ms

Around x10 times faster in Rust than in JS!

However, it's important to note that not all functions we implement in Rust will be faster than in JavaScript. But there will be a considerable improvement in many of them that require recursion or loops.

Debugging

If in devtools -> source we look inside our files for our .wasm file, we'll see that instead of binary it shows us the WAT file being more readable and debuggable.

For a better debugging experience, you can use the --debug flag to display the names of the functions you have used in Rust.

> wasm-pack build --target web --debug

For now, with wasm-bindgen it's not possible to use source-maps to display the code in Rust on devtools. But I suppose in the future it will be available.

Publishing to NPM

Once we have our pkg directory generated, we can package it with:

>  wasm-pack pack myproject/pkg

And publish it at npm with:

> wasm-pack publish

They work the same way as with npm pack and npm publish, so we could use the same flags as wasm-pack publish --tag next.

Code from the article

I've uploaded the code used in this article to my GitHub:

• https://github.com/aralroca/helloworld-wasm-rust

Conclusions

In this article, we've seen a bit of what WebAssembly is and what is necessary to start creating web applications with Rust.

We have used Rust because is one of the best integrated but it's possible to use many other languages. This way, we can bring back to life old applications made with languages like C or C++, and implement more futuristic and portable applications for VR or AR. All this thanks to the browser!

References

• https://www.rust-lang.org/
• https://rustwasm.github.io/docs/wasm-pack/
• https://rustwasm.github.io/book/why-rust-and-webassembly.html
• https://blog.logrocket.com/webassembly-how-and-why-559b7f96cd71/#:~:text=What%20WebAssembly%20enables%20you%20to,JavaScript%2C%20it%20works%20alongside%20JavaScript.

What is a Model?

Or maybe a better question would be: 'What is the reality?'. Yes, that's quite complex to answer... We need to simplify it in order to understand it! A way to represent a part of this simplified "reality"  is using a model. So; there are infinity kind of models: world maps, diagrams, etc.

It's easier to understand the models that we can use without machine help. For example, if we want to do a model to represent the price of Barcelona houses regarding the size of the house: First, we can collect some data:

Then, we display this data on a 2D graph, 1 dimension for each param (price, rooms):

And... voilà! We can now draw a line and start predicting some prices of houses with 6, 7 or more rooms. This model is named linear regression and it's one of the most simple models to start in the machine learning world. Of course this model is not good enough:

1. There are only 5 examples so it's not reliable enough.
2. There are only 2 params (price, rooms), yet there are more factors that could have an effect on the price: district, the age of the house, etc.

For the first problem, we can deal with it by adding more examples, e. g. 1.000.000 examples instead of 5. For the second problem, we can add more dimensions... right? With 2D chart we can understand the data and draw a line while in 3D dimensions we could also use a plane:

But, how to deal with more than 3D? 4D or 1000000D? Our mind can't visualize this on a chart but... good news! We can use maths and calculate hyperplanes in more than 3D and neural networks are a great tool for this! By the way, I have good news for you; using TensorFlow.js you don't need to be a math expert.

What is a neural network?

Before understanding what is a neural network, we need to know what is a neuron. A neuron, in the real world looks similar to this:

The most important parts of a neuron are:

• Dendrites: It's the input of the data.
• Axon: It's the output.
• Synapse (not in the image): It's the structure that permits a neuron to communicate with another neuron. It is responsible to pass electric signals between the nerve ending of the axon and a dendrite of a near neuron. These synapses are the key to learn because they increase or decrease the electrical activity depending on the usage.

A neuron in machine learning (simplified):

• Inputs: The parameters of the input.
• Weights: Like synapses, their activity increase or decrease to adjust the neuron in order to establish a better linear regression.
• Linear function: Each neuron is like a linear regression function so for a linear regression model we only need one neuron!
• Activation function: We can apply some activation function to change the output from a scalar to another non-linear function. The more common; sigmoid, RELU and tanh.
• Output: The computed output after applying the activation function.

The usage of an activation function is very useful, it's the power of a neural network. Without any activation function it's not possible to have a smart neuron network. The reason is that although you have multiple neurons in your network, the output of the neural network is always going to be a linear regression. We need some mechanism to deform this individual linear regressions to be non-linear to solve the non-linear problems. Thanks to activation functions we can transform these linear functions to non-linear functions:

Training a model

Drawing a line in our chart, as in the 2D linear regression example, is enough for us to start predicting new data. Nevertheless, the idea of "deep learning" is that our neural network learn to write this line. For a simple line we can use a very simple neural network with only one neuron, but for another models maybe we want to do more complex things like classify two groups of data. In this case, the "training" is going to learn how to draw something like this:

Remember that this is not complex because it's in 2D. Every model is a world, but the concept of "training" is very similar in all of them. The first step is drawing a random line, and improving it in a iteration algorithm, fixing the error in each iteration. This optimization algorithm has the name of Gradient Descent (there are more sophisticated algorithms as SGD or ADAM, with the same concept). In order to understand the Gradient Descent, we need to know that every algorithm (linear regressor, logistic regressor, etc.) has a different cost function to measure this error. The cost functions always converge in some point and can be convex and non-convex functions. The lowest converge point is found on the 0% error. Our aim is to achieve this point.

When we work with the Gradient Descent algorithm, we start in some random point of this cost function but, we don't know where is it! Imagine that your are on the mountains, completely blind, and you need to walk down, step by step, to the lowest point. If the land is irregular (like non-convex functions), the descent is going to be more complex.

I'm not going to explain Gradient Descent algorithm deeply. Just remember that it's the optimization algorithm to train the AI models to minimize the error of predictions. This algorithm requires time and GPU for matrix multiplications. This converge point is usually hard to achieve in the first execution so we need to fix some hyperparameters like the learning rate (size of the step down the hill) or add some regularization. After the iterations of Gradient Descent we get a closer point to the converge point when the error is close to 0%. At this moment, we already have the model created and we are ready to start predicting!

Training a model with TensorFlow.js

TensorFlow.js provides us with an easy way to create neural networks. At first, we are going to create a LinearModel class with a method trainModel. For this kind of model we are going to use a sequential model. A sequential model is any model where the outputs of one layer are the inputs to the next layer, i.e. when the model topology is a simple 'stack' of layers, with no branching or skipping. Inside the method trainModel we are going to define the layers (we are going to use only one because it's enough for a Linear Regression problem):

import * as tf from '@tensorflow/tfjs';

/**
* Linear model class
*/
export default class LinearModel {
  /**
 * Train model
 */
  async trainModel(xs, ys){
    const layers = tf.layers.dense({
      units: 1, // Dimensionality of the output space
      inputShape: [1], // Only one param
    });
    const lossAndOptimizer = {
      loss: 'meanSquaredError',
      optimizer: 'sgd', // Stochastic gradient descent
    };

    this.linearModel = tf.sequential();
    this.linearModel.add(layers); // Add the layer
    this.linearModel.compile(lossAndOptimizer);

    // Start the model training!
    await this.linearModel.fit(
      tf.tensor1d(xs),
      tf.tensor1d(ys),
    );
  }

  ...more
}

To use this class:

const model = new LinearModel()

// xs and ys -> array of numbers (x-axis and y-axis)
await model.trainModel(xs, ys)

After this training, we are ready to start predicting!

Predicting with TensorFlow.js

Predicting normally is the easier part! Training a model requires to define some hyperparameters... but still, predicting is so simple. We are going to write the next method into the LinearRegressor class:

import * as tf from '@tensorflow/tfjs';

export default class LinearModel {
  ...trainingCode

  predict(value){
    return Array.from(
      this.linearModel
      .predict(tf.tensor2d([value], [1, 1]))
      .dataSync()
    )
  }
}

Now, we can use the prediction method in our code:

const prediction = model.predict(500) // Predict for the number 500
console.log(prediction) // => 420.423

You can play with the code here:

• https://stackblitz.com/edit/linearmodel-tensorflowjs-react

Use pre-trained models with TensorFlow.js

Learning to create models is the most difficult part; normalizing the data for training, deciding all the hyperparams correctly,  etc.  If you are a beginner in this area (like me) and you want to play with some models, you can use pre-trained models. There are a lot of pre-trained models that you can use with TensorFlow.js. Moreover, you can import external models, created with TensorFlow or Keras. For example, you can use the posenet model (Real-time human pose estimations) for funny projects:

📕 Code: https://github.com/aralroca/posenet-d3 It's very easy to use:

import * as posenet from '@tensorflow-models/posenet'

// Constants
const imageScaleFactor = 0.5
const outputStride = 16
const flipHorizontal = true
const weight = 0.5

// Load the model
const net = await posenet.load(weight)

// Do predictions
const poses = await net.estimateSinglePose(
  imageElement,
  imageScaleFactor,
  flipHorizontal,
  outputStride
)

poses variable is this JSON:

{
  "score": 0.32371445304906,
  "keypoints": [
    {
      "position": {
        "y": 76.291801452637,
        "x": 253.36747741699
      },
      "part": "nose",
      "score": 0.99539834260941
    },
    {
      "position": {
        "y": 71.10383605957,
        "x": 253.54365539551
      },
      "part": "leftEye",
      "score": 0.98781454563141
    }
    // ...And for: rightEye, leftEar, rightEar, leftShoulder, rightShoulder
    // leftElbow, rightElbow, leftWrist, rightWrist, leftHip, rightHip,
    // leftKnee, rightKnee, leftAnkle, rightAnkle
  ]
}

Imagine how many funny projects you can develop only with this model!

📕 Code: https://github.com/aralroca/fishFollow-posenet-tfjs

Importing models from Keras

We can import external models into TensorFlow.js. In this example, we are going to use a Keras model for number recognition (h5 file format). For this, we need the tfjs_converter.

pip install tensorflowjs

Then, use the converter:

tensorflowjs_converter --input_format keras keras/cnn.h5 src/assets

Finally, you are ready to import the model into your JS code!

// Load model
const model = await tf.loadModel('./assets/model.json')

// Prepare image
let img = tf.fromPixels(imageData, 1)
img = img.reshape([1, 28, 28, 1])
img = tf.cast(img, 'float32')

// Predict
const output = model.predict(img)

Few lines of code is enough to enjoy with the number recognition model from Keras into our JS code. Of course, now we can add more logic into this code to do something more useful, like a canvas to draw a number and then capture this image to predict the number.

📕 Code: https://github.com/aralroca/MNIST_React_TensorFlowJS

Why in the browser?

Training models in the browser can be very inefficient depending on the device. Even thought TensorFlow.js takes advantage of WebGL to train the model behind the scenes, it is 1.5-2x slower than TensorFlow Python. However, before TensorFlow.js, it was impossible to use machine learning models directly in the browser without an API interaction. Now we can train and use models offline in our applications. Also, predictions are much faster because they don't require the request to the server. Another benefit is the low cost in server because now all these calculations are on client-side.

Conclusion

• A model is a way to represent a simplified part of the reality and we can use it to predict things.
• A good way to create models is using neural networks.
• A good and easy tool to create neural networks is TensorFlow.js.

References:

• https://js.tensorflow.org
• https://en.wikipedia.org/wiki/Scientific_modelling
• https://www.quantstart.com/articles/Supervised-Learning-for-Document-Classification-with-Scikit-Learn
• https://en.wikipedia.org/wiki/Synapse
• https://medium.com/tensorflow/real-time-human-pose-estimation-in-the-browser-with-tensorflow-js-7dd0bc881cd5
• https://github.com/tensorflow/tfjs-models/tree/master/posenet
• https://www.youtube.com/watch?v=Y_XM3Bu-4yc
• https://ml4a.github.io/demos/confusion_mnist/

At Vinissimus, we have recently launched a virtual sommelier that suggests wines given a text of a food dish.

In this article we'll explore the development of this suggester, trained with machine learning and consumed directly from the browser.

Prerequisites

• Have a database with many wines (there are +15000 wines in our database), with food labels (in total we have +1000 food labels).

Requirements

• Given a text, for example "Wine for paella" (or just "paella"), returns all the labels among the +1000 we have that are related: paella, seafood, rice, shrimp...
• Fast to train and use.

Type of problem to solve

Before starting with the project, it's necessary to know what kind of problem we are facing; regression, binary-class classification, multi-class classification, multi-class multi-label classification... To know this, we must know what each term is.

Regression

The regression makes sense when the value we want to predict is a numerical value that can give a new value outside the training values.

It's not the type of problem we want to solve ❌...

Classification

We use a classification, when the value we want to predict is a value within a set of predefined values (classes).

Okay, this is what we want ✅.

Within the classification, there are:

• Binary single-label: predicts a class between two classes (not our case, since we have 1000 classes ❌ ).
• Multi-class single-label: predicts a class between more than two classes (not our case either, since we don't have to choose 1. For example for paella we can recommend: paella, rice and seafood labels ❌ ).
• Multi-class multi-label: predicts a range of classes between more than two classes (This is what we want ✅ ).

It is important to know that our problem is a multi-class multi-label classification as this will determine some hyperparameters to use such as the loss function.

Exploring techniques/tools

Now that we know that the problem we want to solve is a multi-class multi-label classification, let's explore a few ways in order to solve the problem, considering that we want to load the model directly from the browser.

Tensorflow.js

Spoiler: we'll discard it.

Tensorflow is one of the most used frameworks for deeplearning, it allows you to create neural network models in a simple and declarative way. It also has a JavaScript version that allows us to load an already trained model from the browser to make predictions. So initially this tool could be considerated adequate to solve the problem.

Tensorflow works with tensors (n-dimensional vectors) as a lingua franca, so to work with text we must transform the text into tensors. To do this there are several embedding models, however we'll use the Universal Sentence Encoder that is already optimized to work from the browser, because to make the prediction we must also pass the text to tensor from the browser.

We can transform our entire dataset into encodings with:

import '@tensorflow/tfjs-node-gpu'
import * as use from '@tensorflow-models/universal-sentence-encoder'
import data from './data.json'
import _ from 'lodash'
import fs from 'node:fs'

console.log('Encoding...')
use
  .load()
  .then((model) =>
    model.embed(data.map(({ text }) => text.trim().toLowerCase()))
  )
  .then((r) => {
    fs.writeFileSync(
      'embeddings.json',
      JSON.stringify(_.chunk(Array.from(r.dataSync()), 512))
    )
    console.log('Saved...')
  })

And use a network architecture like this:

import * as tf from '@tensorflow/tfjs'
import '@tensorflow/tfjs-node-gpu'

const model = tf.sequential()

model.add(
  tf.layers.dense({
    inputShape: [512],
    activation: 'relu',
    units: 512,
  })
)

for (let i = 0; i < 10; i += 1) {
  model.add(
    tf.layers.dense({
      inputShape: [512],
      activation: 'relu',
      units: 512,
    })
  )
}

model.add(
  tf.layers.dense({
    activation: 'sigmoid',
    units: classes.length,
  })
)

model.compile({
  loss: 'binaryCrossentropy',
  optimizer: 'adam',
  metrics: ['accuracy'],
})

To train the model, pass it the encodings that we have generated:

import embeddings from './embeddings.json'
import outputs from './outputs.json'

const dataset = tf.data
  .generator(async function* gen() {
    for (let i = 0; i < embeddings.length; i += 1) {
      yield {
        xs: embeddings[i],
        ys: outputs[i],
      }
    }
  })
  .batch(128)

model.fitDataset(dataset, { epochs: 600 }).then((history) => {
  console.log(history)
  model.save('file://./model')
})

Of course there are many hyperparameters to play with: number of epochs, batch size, dense layer activation functions, optimizer, etc. However, after spending a lot of time we haven't found yet the best way to solve two problems that had arisen when we tried to solve the problem with Tensorflow:

• The time needed to train with +1000 classes and +400000 examples in the dataset made it unfeasible. Around 10 days of training.
• Testing with fewer classes and examples works well... But calculating the embeddings with the Universal Sentense encoder is a bit expensive (although the prediction is cheaper). To make the prediction we have to pass the embeddings so it's a price to pay.

One of the requirements (Fast to train and use) was not feasible with Tensorflow.js. We have to look for other alternatives!

FastText

Spoiler: This is what we finally use.

FastText is a Facebook tool that, among other things, is used to train text classification models. Unlike Tensorflow.js, it is more intended to work with text so we don't need to pass a tensor and we can use the text directly. Training a model with it is much faster and there are fewer hyperparameters. Besides, to use the model from the browser is possible through WebAssembly. So it's a good alternative to try. Moreover, we can directly use the fastText CLI, which makes it easier to test combinations.

After some tests, we found that fastText met the requirements. The following sections of the article will focus on the use of FastText.

Preparing the data & data augmentation

FastText expects a text file with different labels and texts with a similar format to this one:

__label__1606 __label__433 rabbit with mushrooms

The text rabbit with mushrooms is related to the labels with the id 1606 (id of the "rabbit with mushrooms" label) and 433 (id of the "rabbit" label).

The initial problem is that we don't start from ready-made sentences because the search engine didn't exist before, so we have to generate them from each label we have.

Surely we could put more labels on it, for example, white meat, but how do we make all those relationships?

What we did is to save an array with each label in a JSON, and make several scripts for each label to have extra information such as: synonyms, plurals, closest words, relations, etc. For each language we have (en, es, it, fr and de).

• For synonyms, plurals and missing translations we used the API of DeepL.
• For closest words, FastText has available Wikipedia vectors to search the closest words with k-nearest.
• For relations, we simply made several iterations in the array applying logics like: all words that have "beef, goat, etc" are marked as children of "red meat". And so on with all the detected labels that were more generic, such as: fish, rice, pasta, etc.

Apart from normalizing each text with this simple JS function:

function normalize(text = '') {
  return text
    .trim()
    .toLowerCase()
    .normalize('NFD')
    .replace(/[\u0300-\u036f]/g, '')
}

Example of 2 items of this array:

[
  {
    "id": "1109",
    "txt": {
      "es": "revueltos",
      "fr": "oeufs brouilles",
      "de": "ruhreier",
      "it": "uova strapazzate",
      "en": "scrambled eggs"
    },
    "similar": ["fritos", "revuelto", "egg", "huevo", "estrellados"],
    "parent": ["779"]
  },
  {
    "id": "779",
    "txt": {
      "es": "huevos",
      "fr": "oeuf",
      "de": "eier",
      "it": "uova",
      "en": "eggs"
    },
    "similar": [
      "uovo",
      "œuf",
      "ei",
      "kartoffel omelette",
      "omelette",
      "huevo",
      "spiegelei",
      "tortilla de patatas",
      "tortilla",
      "gebraten",
      "tortillas",
      "fritos",
      "frito",
      "fichi",
      "ous"
    ],
    "parent": []
  }
]

Preparing this array has been the most laborious part of the whole process. Once this array is ready, then we can generate with the format that FastText is expecting as many food sentences as possible by adding plurals, synonyms, knowing which generic labels to put for each sentence, etc. Besides we can add extra words to the sentences such as "Wine for ...", "Pairing for ...", etc.

So we went from 1000 labels, and therefore 1000 possible sentences with 1 label per sentence, to increase to 74,000 sentences and each sentence with several labels.

Training

Once the file with all the sentences and labels has been generated, we can train the model. With FastText we can do this directly with the CLI. After playing a little with the hyperparameters, this was the command that best converged our loss function:

./fasttext supervised -input data/dataset.txt -output model -epoch 50 -lr 0.1 -lrUpdateRate 1000 -minCount 1 -minn 3 -maxn 6 -wordNgrams 2 -dim 100 -neg 20 -loss ova

As a loss function we use the ova (one vs all) which is the one that best suits us for a multi-class multi-label classification problem. Other parameters such as epoch, learning rate, etc, are the result of playing with the hyperparameters so that the loss function is as close to 0 as possible (where there is less error).

minn and maxn are important to avoid misspelings when typing. So if people search for "pizzza", for example, they will get the same results as "pizza". On the other hand, it significantly increases the final size of the model. I'll explain later how to fix this.

If you run the command, you'll see that the training time is much faster than using Tensorflow, with 20min maximum.

Evaluation

To know how well your model is doing, one of the things to look at during the training, as I said, is how the loss is closer to zero. We can also look how the accuracy is closer to 100. However, once it's already trained we can evaluate how well the model is doing by looking at two other factors: Recall and precision. To do this, FastText has a test command that can be applied to a set of sentences that have not been used during training.

Reducing the model size: Quantization

One problem we encountered was that the size of the model occupied 400mb, so it was totally unfeasible to be used in the browser... This is the cost we include for avoiding misspelings with minn and maxn parameters.

To solve this, we use a well-known technique in machine learning called quantization, which consists of reducing the memory size reserved for each weight.

Fortunately, FastText has its own implementation to apply quantization in its models. For more details they published a paper.

It's important to be aware that applying quantization is not a panacea, and that we are likely to lose some model accuracy.

We apply the quantization with this command:

./fasttext quantize -output model -input data/dataset.txt -qnorm -retrain -epoch 1 -cutoff 100000

With this, we drop from 400mb to 4mb! 100 times less. 4mb is still big for the browser, but more feasible...

Using the model on the browser

To use the model trained with FastText from the browser, it is necessary to load it via WebAssembly. However, you don't require a WebAssembly knowledge as you can use the fasttext.js file which has all the glue code.

We can load the model dynamically with the following function:

const [model, setModel] = useState()

async function onLoadModel() {
  const { FastText, addOnPostRun } = await import('./fasttext.js')
  addOnPostRun(async () => {
    const ft = new FastText()
    setModel(await ft.loadModel('./model.ftz'))
  })
}

In the first part of the above example we've loaded the fasttext library. Then we've loaded the model and saved it, in this case, in the React state, so that we can use it later.

For label prediction through a text, we can use this function:

function predictLabelsFromText(text) {
  const threshold = 0.5
  const predictions = []
  const numLabels = 5
  const res = model.predict(normalize(text), numLabels, 0)

  for (let i = 0; i < res.size(); i += 1) {
    predictions.push(res.get(i))
  }

  return predictions
    .filter(([score]) => score > threshold)
    .sort(([scoreA], [scoreB]) => scoreB - scoreA)
    .map(([score, label]) => label.replace('__label__', ''))
}

Given a text, this function returns the 5 related labels (if the probability is higher than 50%, controled by the threshold).

Compared to Tensorflow, the prediction here is very fast.

Conclusions

In this article we have seen how to train a text prediction model easily using FastText and how to use it directly from the browser.

The example used in the article is a real example of a project we developed at Vinissimus, in which, given a text about food, relates to the referenced food labels in order to be able to recommend a wine.

You can test the result in:

• https://www.vinissimus.co.uk/en/virtual-sommelier/ (English)
• https://www.vinissimus.com/es/virtual-sommelier/ (Spanish)
• https://www.italvinus.it/it/virtual-sommelier/ (Italian)
• https://www.vinissimus.fr/fr/virtual-sommelier/ (French)
• https://www.hispavinus.de/de/virtual-sommelier/ (German)

That moment stuck with me. Not because AI saved me time (it does that daily), but because of what it revealed about the nature of the answer. The model didn't know where the bug was. It inferred it. It observed the rendered HTML, estimated which parts of the code could produce that output, and surfaced the most probable origin. That probabilistic inference across two different representations of the same system; browser and codebase; was more effective than my deterministic debugging would have been.

We're living through something bigger than most people realize. The shift from deterministic to probabilistic computing isn't just a technical upgrade. It's a change in how knowledge gets created.

The first paradigm shift: analog to digital

The move from analog to digital was the defining technology transition of the late 20th century. It converted continuous signals into discrete data. Suddenly you could copy information without degradation. Transmit it globally. Store it efficiently. The internet, distributed systems, modern software; all of it descends from that single insight: continuous signals can be represented as sequences of ones and zeros.

But there was something that transition left untouched: the process of creation itself.

Digital software is deterministic. Given the same input, it produces the same output. Every line of code, every system, every product had to be explicitly designed, written, and maintained by a human. The computer executed instructions. It didn't generate anything it hadn't been told to generate. A SQL formatter formats SQL because someone wrote exact rules for how SQL should be formatted. A password generator produces random strings because someone implemented CSPRNG algorithms that define precisely how randomness gets produced.

Deterministic systems are predictable, testable, and reliable. They're also fundamentally limited: they can only do what someone has already imagined and coded.

The second paradigm shift: deterministic to probabilistic

With large language models and deep learning, we entered a new phase. Systems that don't execute rigid instructions but generate results based on probability distributions.

The difference is structural:

• We no longer describe exactly what to do. We train models to learn how to do it.
• We don't generate information manually. We infer it.
• We produce answers, content, and decisions that were never explicitly programmed.

Think about what an AI content detector does. It doesn't have a list of "AI-written sentences" to match against. It computes statistical properties of text; Zipf's law conformity, punctuation entropy, sentence length distributions; and estimates a probability that the text was machine-generated. The detector itself is a probabilistic system analyzing the output of another probabilistic system. That's a sentence that would have been meaningless ten years ago.

Or consider automatic subtitle generation. OpenAI's Whisper model doesn't follow if-then rules to transcribe speech. It processes audio spectrograms and predicts the most probable sequence of tokens that corresponds to what was said. It gets it right most of the time. Not all of the time. That "most of the time" is the defining characteristic of probabilistic systems.

This shift has a direct impact on the most valuable resource that exists: time. AI reduces the effort required to create, analyze, and predict by orders of magnitude.

Knowledge generation without precedent

The key difference is that probabilistic systems can work with the unknown. From learned patterns, they can:

• Generate text, images, or code that has never existed before.
• Predict future outcomes from incomplete data.
• Find relationships that were never explicitly defined.

This breaks a historical constraint: we no longer need to write every possible case. The system can generalize.

Consider the Monte Carlo forecaster. Classical project management asked teams to estimate how long tasks would take and then added the numbers up. Monte Carlo simulation does something smarter: it runs thousands of scenarios using historical data and gives you a probability distribution of delivery dates. "There's an 85% chance you'll finish by March 15" is more useful than "the estimate is March 10." But here's a nuance that matters: Monte Carlo is deterministic code. Statistical formulas executed with perfect precision. There's no inference; there's simulation. It's probabilistic thinking implemented on deterministic infrastructure. Today an LLM could make the same prediction without any of that code; you pass it the team's historical data and it gives you a reasonable estimate. But "reasonable" isn't "reliable." Until models reach 99.99% accuracy, hand-coded statistical simulations remain the safe bet. Monte Carlo is exactly the kind of tool that marks the transition: probabilistic thinking that still needs deterministic crutches.

The same principle applies everywhere. A background remover running a neural network in the browser doesn't have rules about what counts as "background." It has learned probability distributions over millions of segmented images and applies those distributions to your photo. A prompt generator doesn't store pre-written prompts; it structures natural language patterns that probabilistically produce better model outputs.

Even tools that seem purely deterministic are being reshaped. HTML to Markdown conversion is deterministic; the same HTML always produces the same Markdown. But the reason that tool exists is probabilistic: people need clean Markdown because feeding raw HTML to an LLM wastes 60-80% of tokens on structural noise. A deterministic tool serving a probabilistic ecosystem.

The current limitations: why it's not perfect yet

Despite the potential, current AI has real constraints:

Inference time. Generating responses means processing enormous quantities of tokens. A complex reasoning chain in a frontier model can take 30-60 seconds. That's fast compared to human analysis, but slow compared to a database query. The latency gap between "compute a hash" (nanoseconds) and "reason about a bug" (seconds) is six orders of magnitude.

Probabilistic errors. Models don't "know" in the classical sense. They estimate. As of April 2026, GPT-5.5, Claude Opus 4.7, and Gemini 3.1 Pro score between 89% and 92% on MMLU-Pro; the harder benchmark replacing the original MMLU. Each generation climbs a few points, but the numbers are still statistical. A graph traversal animator will always find the shortest path because BFS is deterministic. An LLM asked to find the shortest path will probably find it, but it might hallucinate an edge that doesn't exist.

Classical infrastructure. These models run on hardware designed for deterministic computation: CPUs, GPUs, TPUs. NVIDIA's H100 is optimized for parallel matrix multiplication, which is what transformers need, but the underlying architecture is still classical. We're solving probabilistic problems with deterministic machines.

The trajectory: approaching 100% accuracy

The trend line is clear. Each new model generation improves on benchmarks, reduces error rates, and expands generalization capacity. Google's Gemini, Anthropic's Claude, and OpenAI's GPT families are converging toward accuracy levels that make the distinction between "correct" and "highly probable" practically meaningless for many tasks.

When models reach 99.99% accuracy on routine cognitive tasks:

• Trust in AI systems will match or exceed trust in human judgment.
• Most intellectual tasks that follow learnable patterns will be delegated entirely.
• The marginal cost of generating knowledge will approach zero.

We're not there yet. But the distance is shrinking with every model release.

The bottleneck: classical compute vs. quantum compute

Here's an idea worth sitting with: we're solving a fundamentally probabilistic problem using deterministic tools.

GPUs and TPUs parallelize massive calculations, but they operate under classical principles. This creates real constraints:

• High energy consumption. Training GPT-5 class models required tens of thousands of NVIDIA H100 GPUs for months, at costs exceeding $100 million.
• Expensive scaling. More parameters means more hardware, more cooling, more electricity.
• Significant latency on large models.

The theoretical alternative is quantum computing.

Companies like IBM, Google, and D-Wave Systems are exploring QPUs (Quantum Processing Units) that work directly with probabilistic states through superposition and entanglement.

In theory, this would allow:

• Solving certain calculations exponentially faster.
• Modeling probabilistic systems natively instead of simulating them on deterministic hardware.
• Drastically reducing the computational cost of AI inference.

If you want to see what quantum circuits actually look like, the Quantum Circuit Simulator lets you build and run circuits in the browser. Two lines of code create a Bell State; a maximally entangled pair of qubits where measurement of one instantly determines the other. That kind of native probabilistic behavior is exactly what current AI infrastructure lacks.

The hard problem: quantum error correction

Quantum computing isn't ready for this role yet. The main obstacle is Quantum Error Correction.

Quantum systems are extremely sensitive to noise and interference. Every interaction with the environment can collapse a qubit's superposition, corrupting the computation. Current quantum processors have error rates that make them impractical for the sustained, reliable computation that AI inference requires.

For a QPU to be viable at scale, three things need to happen:

1. Error rates must drop dramatically. Current physical qubits have error rates around 0.1-1%. Useful quantum computation needs rates below 0.0001%.
2. Stable qubit counts must scale. IBM's current roadmap targets 100,000 qubits by 2033. That's ambitious, but the engineering challenges at each step are enormous.
3. Fault-tolerant architectures must mature. Surface codes and other error correction schemes work in principle but require thousands of physical qubits per logical qubit. The overhead is still prohibitive.

What's at stake isn't just speed. It's energy.

Data centers consumed around 415 TWh in 2024; 1.5% of global electricity. The IEA estimates they'll exceed 1,000 TWh by 2026, with AI as the main growth driver. Training a frontier model consumes the electricity equivalent of thousands of households for a year. Every inference query burns over 33 Wh on long prompts; ten times what a Google search uses. And this scales. More models, more agents, more robotics with embedded AI; every layer adds energy demand.

The day quantum error correction gets solved, that equation changes radically. Current QPUs consume around 25 kW, most of it on cryogenic cooling; not computation. But quantum computing works with the probabilistic problem natively instead of simulating it with trillions of matrix multiplications. Quantum compression algorithms already demonstrate 84% energy efficiency gains on specific AI tasks. And partial error correction is enabling quantum models to maintain high accuracy with thousands of qubits instead of millions.

When quantum error correction matures, we won't just have faster AI. We'll have AI that consumes orders of magnitude less energy per inference. That's what turns quantum computing from a lab curiosity into viable infrastructure for the billions of agents the future requires.

Until that happens, we'll continue running probabilistic AI on deterministic hardware. Which, honestly, works remarkably well for how fundamentally mismatched the paradigms are.

What this means practically

This isn't abstract philosophy. The shift from determinism to probabilism changes how you build, how you work, and how you think about tools.

A binary search tree lab teaches deterministic algorithms. Insert a node, traverse the tree, get the same result every time. That kind of certainty is still valuable. Databases still need B-trees. Routing still needs Dijkstra. Blue noise generators still need deterministic sampling algorithms to produce well-distributed random points.

But the layer above those deterministic primitives is increasingly probabilistic. The database query is deterministic; the AI agent that decides which query to run is probabilistic. The algorithm is deterministic; the model that selects which algorithm fits the problem is probabilistic. The text is deterministic once written; the system that extracts text from images using OCR neural networks is probabilistic.

We're building a stack where deterministic systems execute and probabilistic systems decide. That's new. And it's only going to accelerate.

The next step isn't better AI; it's a composable compute stack

What comes next doesn't replace one paradigm with another. It composes them.

Think about how modern infrastructure already works. CPUs execute deterministic logic; database transactions, cryptographic verification, your operating system's kernel. GPUs and TPUs solve probabilistic problems; they train models, run inference, process distributions across millions of parameters. Each layer does what the other can't. Nobody suggests replacing CPUs with GPUs. You combine them.

QPUs complete the third layer. They solve a class of problems that classical hardware simulates poorly: combinatorial optimization, high-dimensional distribution sampling, search across exponential spaces. AI inference doesn't just get faster; it becomes viable at scales that are currently intractable.

The stack looks like this: deterministic systems execute and verify. Probabilistic systems propose and generate. Quantum systems optimize what neither of the other two can touch.

But there's a piece almost nobody is talking about yet.

Models talking to machines talking to models

So far we think of AI as something that receives a prompt and returns text. That's like thinking the internet is email. The next layer is communication between probabilistic models; and between those models and the deterministic hardware they control.

A language model analyzes sensor data and decides it needs more information from a specific area. It communicates that decision to a vision model controlling a drone. The drone moves, collects data, processes it through another specialized model, and returns the results to the first one. No human intervened in the cycle. No human decided that area was interesting. The system inferred it.

That's not automation. Automation executes what a human designed. This is different: probabilistic systems deciding what data to collect, how to collect it, and what to do with what they find. Robots with AI models that choose to explore information sources that wouldn't have occurred to us.

Think about a marine drone with chemical sensors and a model trained on oceanic biodiversity. It doesn't follow a preprogrammed route. It detects an anomaly in water composition, infers it could indicate an unknown microbial community, adjusts its trajectory, and takes samples. It finds something no marine biologist would have looked for because none would have predicted it would be there. Another model analyzes the samples, identifies compounds with pharmaceutical potential, and asks the drone to return to the same zone with different sensors.

That's genuinely new knowledge. Not extracted from existing data or inferred from human text. Generated by a system that decided to go look for it.

When prediction takes nanoseconds

The current limitations are real. Inference takes seconds. Accuracy hovers around 86-95% depending on the benchmark. But those are the limitations of the first generation of a paradigm that's barely getting started. The trajectory points toward models with 99.99% accuracy and nanosecond response times.

When that happens, the world reorganizes in ways that are hard to imagine from where we stand now.

A self-driving car that takes 30 milliseconds to decide is a car that brakes late. One that decides in nanoseconds reacts before the obstacle finishes appearing. A network of medical models with 99.99% accuracy doesn't assist the doctor; it diagnoses with a reliability no human can match. A supply chain where every node has a predictive model communicating with all the others doesn't need quarterly planning; it reoptimizes in real time, every millisecond.

But the really important thing is what happens when probabilistic inference becomes so fast and accurate that it's functionally indistinguishable from deterministic certainty. The distinction between "computing" and "inferring" disappears. Your operating system doesn't need to distinguish between an arithmetic operation and a prediction. The compiler doesn't need to know if the result comes from formal logic or a 400B parameter model. It's all computation; part rule-based, part distribution-based, part quantum-optimized. Seamlessly integrated.

AI stops being a tool you open and becomes an infrastructure layer you don't even notice. Like electricity. Like TCP/IP. It's everywhere and you don't think about it.

Knowledge beyond the human

Robots with AI models don't just automate what we used to do. They perceive what we can't.

An ultrasonic sensor coupled with a materials model detects microfractures in a wind turbine that no visual inspection would find. A portable spectrometer with a chemical model identifies contaminants at concentrations human protocols don't measure. A hydrophone array with an acoustic model classifies marine species by sound patterns no biologist has cataloged yet.

These aren't incremental efficiency improvements. They're new sources of knowledge. Data that existed in the physical world but was invisible to us because we didn't have the right sensors coupled with the right intelligence to interpret them.

And here's where the loop closes. Those robots don't just collect data; the models inside them decide what data is worth collecting. But the cycle goes further than that. An AI analyzing ocean temperature anomalies determines that the existing sensor grid is too coarse; it needs readings at depths and frequencies no current instrument covers. So it designs a new sensor specification. A manufacturing robot builds it. A deployment robot installs it on a fleet of underwater drones. Those drones collect data that no previous system could capture, and that data trains a better model, which identifies the next gap in sensing capability, and the cycle begins again.

No human decided what to measure. No human designed the sensor. No human chose where to deploy it. The entire chain; from identifying a knowledge gap to filling it with new physical hardware; was driven by probabilistic inference.

When millions of such systems operate simultaneously, each one designing sensors for the others, deploying instruments that didn't exist a cycle ago, and feeding the results back into shared models, humanity gains access to a layer of reality it literally couldn't perceive before. It's not an improvement on what we already knew. It's access to what we didn't know we didn't know.

The full stack

Thirty years ago the question was "can you code?". Ten years ago it was "can you use APIs?". Today it's "can you direct models?". Tomorrow it'll be irrelevant; models will direct each other.

Deterministic systems execute and verify. Probabilistic systems propose, generate, and decide. Quantum systems optimize the intractable. Sensors and robots extend all of this into the physical world. And communication between models closes the loop: systems that discover what they don't know, decide how to find out, and act to get it. Without human intervention. Without anyone telling them where to look.

If the analog-to-digital shift redefined how we store information, and the deterministic-to-probabilistic shift is redefining how we generate knowledge, the full integration; models, hardware, sensors, robots, quantum computing; redefines the limits of what's possible to perceive and understand.

We won't be using better tools. We'll be surrounded by an intelligence that sees what we don't see, seeks what we don't seek, and finds what we didn't know existed.

I've tried to collect some of the most used topics in Node, and looked for their alternative with Deno. First of all, I would like to make it clear that we can use many of the current Node.js modules. There is no need to look for an alternative for everything, as many modules are reusable. You can visit pika.dev to look for modules to use in Deno. That said, let's start with the list:

We will cover the following:

• Electron
• Forever / PM2
• Express / Koa
• MongoDB
• PostgresSQL
• MySQL / MariaDB
• Redis
• Nodemon
• Jest, Jasmine, Ava...
• Webpack, Parcel, Rollup...
• Prettier
• NPM Scripts
• Nvm
• Npx
• Run on a Docker
• Run as a lambda
• Conclusion

Electron

With Node.js we can create desktop applications using Electron. Electron uses Chromium as interface to run a web environment. But, can we use Electron with Deno? Are there alternatives?

Well, right now Electron is far from being able to be executed under Deno. We must look for alternatives. Since Deno is made with Rust, we can use web-view rust bindings to run Destkop application in Deno.

This way, we can use the native OS webview to run as many webviews as we want.

Repo: https://github.com/eliassjogreen/deno_webview

import { WebView } from 'https://deno.land/x/webview/mod.ts'

const sharedOptions = {
  width: 400,
  height: 200,
  resizable: true,
  debug: true,
  frameless: false,
}

const webview1 = new WebView({
  title: 'Multiple deno_webview example',
  url: `data:text/html,
    <html>
    <body>
      <h1>1</h1>
    </body>
    </html>
    `,
  ...sharedOptions,
})

const webview2 = new WebView({
  title: 'Multiple deno_webview example',
  url: `data:text/html,
    <html>
    <body>
      <h1>2</h1>
    </body>
    </html>
    `,
  ...sharedOptions,
})

await Promise.all([webview1.run(), webview2.run()])

Forever / PM2

Forever and PM2 are CLI tools for ensuring that a given script runs continuously as a daemon. Unlike Forever, PM2 is more complete and also serves as load balancer. Both are very useful in Node, but can we use them in Deno?

Forever is intended for Node only, so using it is not feasible. On the other hand, with PM2 we can use an interpreter.

➜ pm2 start app.ts --interpreter="deno" --interpreter-args="run --allow-net" 

Express / Koa

Express and Koa are the best known Node frameworks. They're known for their robust routing system and their HTTP helpers (redirection, caching, etc). Can we use them in Deno? The answer is not... But there are some alternatives.

Http (std lib)

Deno's own STD library already covers many of the needs provided by Express or Koa. https://deno.land/std/http/.

import { ServerRequest } from 'https://deno.land/std/http/server.ts'
import { getCookies } from 'https://deno.land/std/http/cookie.ts'

let request = new ServerRequest()
request.headers = new Headers()
request.headers.set('Cookie', 'full=of; tasty=chocolate')

const cookies = getCookies(request)
console.log('cookies:', cookies)

However, the way to declare routes is not very attractive. So let's look at some more alternatives.

Oak (Third party lib)

One of the most elegant solutions right now, very inspired by Koa. https://github.com/oakserver/oak

import { Application } from 'https://deno.land/x/oak/mod.ts'

const app = new Application()

app.use((ctx) => {
  ctx.response.body = 'Hello World!'
})

await app.listen({ port: 8000 })

Abc (Third party lib)

Similar to Oak. https://deno.land/x/abc.

import { Application } from 'https://deno.land/x/abc/mod.ts'

const app = new Application()

app.static('/static', 'assets')

app.get('/hello', (c) => 'Hello!').start({ port: 8080 })

Deno-express (Third party lib)

Maybe the most similar alternative to Express Framework. https://github.com/NMathar/deno-express.

import * as exp from 'https://raw.githubusercontent.com/NMathar/deno-express/master/mod.ts'

const port = 3000
const app = new exp.App()

app.use(exp.static_('./public'))
app.use(exp.bodyParser.json())

app.get('/api/todos', async (req, res) => {
  await res.json([{ name: 'Buy some milk' }])
})

const server = await app.listen(port)
console.log(`app listening on port ${server.port}`)

MongoDB

MongoDB is a document database with a huge scability and flexibility. In the JavaScript ecosystem has been widely used, with many stacks like MEAN or MERN that use it. It's very popular.

So yes, we can use MongoDB with Deno. To do this, we can use this driver: https://github.com/manyuanrong/deno_mongo.

import { init, MongoClient } from 'https://deno.land/x/mongo@v0.6.0/mod.ts'

// Initialize the plugin
await init()

const client = new MongoClient()
client.connectWithUri('mongodb://localhost:27017')

const db = client.database('test')
const users = db.collection('users')

// insert
const insertId = await users.insertOne({
  username: 'user1',
  password: 'pass1',
})

// findOne
const user1 = await users.findOne({ _id: insertId })

// find
const users = await users.find({ username: { $ne: null } })

// aggregation
const docs = await users.aggregation([
  { $match: { username: 'many' } },
  { $group: { _id: '$username', total: { $sum: 1 } } },
])

// updateOne
const { matchedCount, modifiedCount, upsertedId } = await users.updateOne(
  (username: { $ne: null }),
  {
    $set: { username: 'USERNAME' },
  }
)

// deleteOne
const deleteCount = await users.deleteOne({ _id: insertId })

PostgresSQL

Like MongoDB, there is also a driver for PostgresSQL.

• https://github.com/buildondata/deno-postgres.

import { Client } from 'https://deno.land/x/postgres/mod.ts'

const client = new Client({
  user: 'user',
  database: 'test',
  hostname: 'localhost',
  port: 5432,
})
await client.connect()
const result = await client.query('SELECT * FROM people;')
console.log(result.rows)
await client.end()

MySQL / MariaDB

As with MongoDB and PostgresSQL, there is also a driver for MySQL / MariaDB.

• https://github.com/manyuanrong/deno_mysql

import { Client } from 'https://deno.land/x/mysql/mod.ts'

const client = await new Client().connect({
  hostname: '127.0.0.1',
  username: 'root',
  db: 'dbname',
  poolSize: 3, // connection limit
  password: 'password',
})

let result = await client.execute(`INSERT INTO users(name) values(?)`, [
  'aralroca',
])
console.log(result)
// { affectedRows: 1, lastInsertId: 1 }

Redis

Redis, the best known database for caching, has also a driver for Deno.

• https://github.com/keroxp/deno-redis

import { connect } from 'https://denopkg.com/keroxp/deno-redis/mod.ts'

const redis = await connect({
  hostname: '127.0.0.1',
  port: 6379,
})
const ok = await redis.set('example', 'this is an example')
const example = await redis.get('example')

Nodemon

Nodemon is used in development environment to monitor any changes in your files, automatically restarting the server. This makes node development much more enjoyable, without having to manually stop and restart the server to see the applied changes. Can it be used in Deno?

Sorry, but you can't... but still, there is an alternative: Denon.

• https://github.com/eliassjogreen/denon

We can use Denon as we use deno run to execute scripts.

➜ denon server.ts

Jest, Jasmine, Ava...

In the Node.js ecosystem there are a lot of alternatives for test runners. However, there isn't one official way to test the Node.js code.

In Deno, there is an official way, you can use the testing std library.

• https://deno.land/std/testing

import { assertStrictEq } from 'https://deno.land/std/testing/asserts.ts'

Deno.test('My first test', async () => {
  assertStrictEq(true, false)
})

To run the tests:

➜  deno test

Webpack, Parcel, Rollup...

One of the strengths of Deno is that we can use ESmodules with TypeScript without the need for a bundler such as Webpack, Parcel or Rollup.

However, probably you wonder if given a tree of files, we can make a bundle to put everything in one file to run it on the web.

Well, it's possible, yes. We can do it with Deno's CLI. Thus, there's no need for a third-party bundler.

➜ deno bundle myLib.ts myLib.bundle.js

Now it's ready to be loaded in the browser:

<script type="module">
  import * as myLib from 'myLib.bundle.js'
</script>

Prettier

In the last few years Prettier has become quite well known within the JavaScript ecosystem because with it you don't have to worry about formatting the files.

And the truth is, it can still be used on Deno but it loses its meaning, because Deno has its own formatter.

You can format your files using this command:

➜  deno fmt

NPM Scripts

With Deno, the package.json no longer exists. One of the things I really miss are the scripts that were declared in the package.json.

A simple solution would be to use a makefile and execute it with make. However, if you miss the npm syntax, there is an npm-style script runner for Deno:

• https://github.com/umbopepato/velociraptor

You can define a file with your scripts:

# scripts.yaml
scripts:
  start: deno run --allow-net server.ts
  test: deno test --allow-net server_test.ts

Execute with:

➜  vr run <SCRIPT>

Another alternative is denox, very similar to Velociraptor.

Nvm

Nvm is a CLI to manage multiple active Node versions, to easy upgrade or downgrade versions depending on your projects.

A nvm equivalent in Deno is dvm.

• https://github.com/axetroy/dvm

➜  dvm use 1.0.0

Npx

Npx in recent years has become very popular to execute npm packages without having to install them. Now many projects won't exist within npm because Deno is a separate ecosystem. So, how can we execute Deno modules without having to install them with deno install https://url-of-module.ts?

In the same way that we run our project, instead of a file we put the URL of the module:

➜  deno run https://deno.land/std/examples/welcome.ts

As you can see, not only we have to remember the name of the module, but the whole URL, which makes it a little more difficult to use. On the other hand it gives a lot more flexibility as we can run any file, not just what's specified as a binary in the package.json like npx.

Run on a Docker

To run Deno inside a Docker, we can create this Dockerfile:

FROM hayd/alpine-deno:1.0.0

EXPOSE 1993  # Port.

WORKDIR /app

USER deno

COPY deps.ts .
RUN deno cache deps.ts # Cache the deps

ADD . .
RUN deno cache main.ts # main entrypoint.

CMD ["--allow-net", "main.ts"]

To build + run it:

➜  docker build -t app . && docker run -it --init -p 1993:1993 app

Repo: https://github.com/hayd/deno-docker

Run as a lambda

To use Deno as a lambda, there is a module in Deno STD library. https://deno.land/x/lambda.

import {
  APIGatewayProxyEvent,
  APIGatewayProxyResult,
  Context,
} from 'https://deno.land/x/lambda/mod.ts'

export async function handler(
  event: APIGatewayProxyEvent,
  context: Context
): Promise<APIGatewayProxyResult> {
  return {
    body: `Welcome to deno ${Deno.version.deno} 🦕`,
    headers: { 'content-type': 'text/html;charset=utf8' },
    statusCode: 200,
  }
}

Interesting references:

• Deno in Vercel: https://github.com/lucacasonato/now-deno
• Deno in AWS: https://blog.begin.com/deno-runtime-support-for-architect-805fcbaa82c3

Conclusion

I'm sure I forgot some Node topics and their Deno alternative, let me know if there's anything I missed that you'd like me to explain. I hope this article helps you break the ice with Deno.

To explore all libraries you can use with Deno:

• https://deno.land/std
• https://deno.land/x
• https://www.pika.dev/

After a few articles I decided to create my own personal blog. However, I've always wanted to continue contributing to dev.to. That's why I post articles on my personal blog and then share them on dev.to with the canonical. I suppose it's a standard practice and more than one of you are doing it.

In order to make my life a little easier, I've recently made a GitHub action that posts directly to dev.to when it detects a new article on my blog.

How I detect a new post

To know if the article is new and needs to be published, you can use the markdown metadata to find out. In my case, I keep the date of publication as metadata (in case I want to publish it another day even if it's merged to master).

Then, once it's posted to dev.to with the GitHub action I create another metadata so it gets tagged as published.

Why? Because the GitHub action will run:

• Whenever something is pushed to master.
• Every day at 17:00 UTC.

This way, marking the post as already published, we avoid publishing it twice if we push an article to master at 16:00.

GitHub action in action

name: Publishing post

on:
  push:
    branches: [master]
  schedule:
    - cron: '0 17 */1 * *'

jobs:
  build:
    runs-on: ubuntu-latest

    strategy:
      matrix:
        node-version: [14.x]

    steps:
      - uses: actions/checkout@v2

      - name: Publishing post
        uses: actions/setup-node@v1
        with:
          node-version: ${{ matrix.node-version }}
      - run: yarn install --pure-lockfile
      - run: yarn run publish:post
        env:
          DEV_TO: ${{ secrets.DEV_TO }} 
      - run: |
          git config user.name aralroca
          git config user.email aral-rg@hotmail.com
          git add -A
          git diff --quiet && git diff --staged --quiet || git commit -m "[bot] Published to dev.to"
          git push origin master

What does it do?

1. Programs the action on push to master and every day at 17:00 UTC using a cron.
2. Installs dependencies with yarn install --pure-lockfile
3. Sets environment variable DEV_TO using GitHub secrets. This is required for our script.
4. Runs our script to publish to dev.to
5. Commits and pushes to master only when there are changes.

Script to publish to dev.to

In our package.json file we have to indicate that the script runs our node file:

{
  "scripts": {
    "publish:post": "node ./publish/index.js"
  }
}

This is the content of our script that publishes articles to dev.to:

async function deploy() {
  const post = getNewPost()

  if (!post) {
    console.log('No new post detected to publish.')
    process.exit()
  }

  await deployToDevTo(post)
}

console.log('Start publishing')
deploy()
  .then(() => {
    console.log('Published!')
    process.exit()
  })
  .catch((e) => {
    console.log('ERROR publishing:', e)
    process.exit(1)
  })

The getNewPost function returns the post already formatted in the way dev.to needs, null in case that there aren't new posts:

const fs = require('fs')
const path = require('path')
const matter = require('gray-matter')

const deployToDevTo = require('./dev-to')

function getNewPost() {
  const today = new Date()

  return (
    fs
      .readdirSync('posts')
      .map((slug) => {
        const post = matter(fs.readFileSync(path.join('posts', slug)))
        return { ...post, slug }
      })
      .filter((p) => {
        const created = new Date(p.data.created)

        return (
          !p.data.published_devto &&
          created.getDate() === today.getDate() &&
          created.getMonth() === today.getMonth() &&
          created.getFullYear() === today.getFullYear()
        )
      })
      .map(({ slug, data, content }) => {
        const id = slug.replace('.md', '')
        const canonical = `https://aralroca.com/blog/${id}`
        const body = `***Original article: ${canonical}***\n${content}`

        return {
          body_markdown: body,
          canonical_url: canonical,
          created: data.created,
          description: data.description,
          main_image: data.cover_image,
          published: true,
          series: data.series,
          slug,
          tags: data.tags,
          title: data.title,
        }
      })[0] || null
  )
}

I use the gray-matter library to retrieve the markdown metadata and its content.

Here's the deployToDevTo function used in our script:

const fetch = require('isomorphic-unfetch')
const path = require('path')
const fs = require('fs')

function createPost(article) {
  return fetch('https://dev.to/api/articles', {
    method: 'POST',
    headers: {
      'api-key': process.env.DEV_TO,
      'content-type': 'application/json',
    },
    body: JSON.stringify({ article }),
  })
    .then((r) => r.json())
    .then((res) => {
      console.log('dev.to -> OK', `https://dev.to/aralroca/${res.slug}`)
      return res.slug
    })
    .catch((e) => {
      console.log('dev.to -> KO', e)
    })
}

async function deployToDevTo(article) {
  const devToId = await createPost(article)

  if (!devToId) return

  const postPath = path.join('posts', article.slug)
  const post = fs.readFileSync(postPath).toString()
  let occurrences = 0

  // Write 'published_devto' metadata before the second occurrence of ---
  fs.writeFileSync(
    postPath,
    post.replace(/---/g, (m) => {
      occurrences += 1
      if (occurrences === 2) return `published_devto: true\n${m}`
      return m
    })
  )
}

We request to the dev.to API to upload the article and then modify our markdown file to add the published_devto: true metadata. This way, our GitHub action will detect that there are changes to upload to master.

Conclusions

In this short article we've seen how to create a GitHub action to post automatically our personal blog new articles to dev.to. I hope you find it useful.

Here, instead of rendering a triangle, we'll see how to render more complex structures and how to give it movement. To do that we'll implement three dynamic gears:

We will cover the following:

• Identifying shapes
  • Circle with border
  • Circle with filled color
  • Circle with teeth
• Identifying data to draw
• How we will implement the rotation
• Let's implement it!
  • Initialize program with shaders
  • Draw each frame + calculate rotation angles
  • Draw gears
• Show me all the code
• Conclusion
• References

Identifying shapes

The gears we want to draw are composed of circles. Among these circles there are certain varieties: a circle with teeth, a circle with colored border and circle filled with a color.

Therefore, this confirms that we can draw these gears by drawing circles but, as we saw in the previous article, in WebGL you can only rasterize triangles, points, and lines... So, what's the difference between these circles and how can we make each of them?

Circle with border

To draw a circle with a border, we'll use multiple points:

Circle with filled color

To draw a circle with a filled color, we'll use multiple triangles:

The drawing mode needed for this is Triangle strip:

A triangle strip is a series of connected triangles from the triangle mesh, sharing vertices, allowing for more efficient memory usage for computer graphics. They are more efficient than triangle lists without indexing, but usually equally fast or slower than indexed triangle lists. The primary reason to use triangle strips is to reduce the amount of data needed to create a series of triangles. The number of vertices stored in memory is reduced from 3N to N+2, where N is the number of triangles to be drawn. This allows for less use of disk space, as well as making them faster to load into RAM. Source: Wikipedia

Circle with teeth

For the gear teeth, we'll also use triangles. This time, without the "strip" mode. This way we'll draw triangles that go from the center of the circumference to the outside.

While we build the teeth, it's important that we create another circle inside filled with color to make the effect that the teeth are coming out of the circle itself.

Identifying data to draw

One thing these 3 types of figures have in common is that we can calculate their coordinates from 2 variables:

• Center of the circle (x and y)
• Radius

As seen in the previous article, the coordinates within webGL go from -1 to 1. So let's locate the center of each piece of gear and its radius:

In addition, we have optional variables for specific figures such as:

• Number of teeth
• Stroke color (color of the border)
• Fill color
• Children (more pieces of the same gear with the same data structure)
• Direction of the rotation (only valid for the parent)

At the end, in JavaScript, we'll have this array with the data of the three gears and all their pieces:

const x1 = 0.1
const y1 = -0.2

const x2 = -0.42
const y2 = 0.41

const x3 = 0.56
const y3 = 0.28

export const gears = [
  {
    center: [x1, y1],
    direction: 'counterclockwise',
    numberOfTeeth: 20,
    radius: 0.45,
    fillColor: [0.878, 0.878, 0.878],
    children: [
      {
        center: [x1, y1],
        radius: 0.4,
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x1, y1],
        radius: 0.07,
        fillColor: [0.741, 0.741, 0.741],
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x1 - 0.23, y1],
        radius: 0.12,
        fillColor: [1, 1, 1],
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x1, y1 - 0.23],
        radius: 0.12,
        fillColor: [1, 1, 1],
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x1 + 0.23, y1],
        radius: 0.12,
        fillColor: [1, 1, 1],
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x1, y1 + 0.23],
        radius: 0.12,
        fillColor: [1, 1, 1],
        strokeColor: [0.682, 0.682, 0.682],
      },
    ],
  },
  {
    center: [x2, y2],
    direction: 'clockwise',
    numberOfTeeth: 12,
    radius: 0.3,
    fillColor: [0.741, 0.741, 0.741],
    children: [
      {
        center: [x2, y2],
        radius: 0.25,
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x2, y2],
        radius: 0.1,
        fillColor: [0.682, 0.682, 0.682],
        strokeColor: [0.6, 0.6, 0.6],
      },
    ],
  },
  {
    center: [x3, y3],
    direction: 'clockwise',
    numberOfTeeth: 6,
    radius: 0.15,
    fillColor: [0.741, 0.741, 0.741],
    children: [
      {
        center: [x3, y3],
        radius: 0.1,
        strokeColor: [0.682, 0.682, 0.682],
      },
      {
        center: [x3, y3],
        radius: 0.02,
        fillColor: [0.682, 0.682, 0.682],
        strokeColor: [0.6, 0.6, 0.6],
      },
    ],
  },
]

For the colors, a little reminder: they go from 0 to 1, instead of 0 to 255, or 0 to F, as we are accustomed in CSS. For example [0.682, 0.682, 0.682] would be equivalent to rgb(174, 174, 174) and #AEAEAE.

How we will implement the rotation

Before we begin the implementation, we need to know how to implement the rotation of each gear.

In order to understand the rotation and other linear transformations, I highly recommend the serie about linear algebra from 3blue1brown YouTube channel. In special, this video explains it very well:

To sum up, if we multiply our positions by any matrix, it receives a transformation. We have to multiply each gear position by the rotation matrix. We need to add every "transformation" in front of it. If we want to rotate, we will do rotation * positions instead of positions * rotation.

We can create the rotation matrix by knowing the angle in radians:

function rotation(angleInRadians = 0) {
  const c = Math.cos(angleInRadians)
  const s = Math.sin(angleInRadians)

  return [
    c, -s, 0, 
    s, c, 0, 
    0, 0, 1
  ]
}

This way we can make each gear turn differently by multiplying the positions of each gear with its respective rotation matrix. To have a real rotation effect, in each frame we must increase the angle a little bit until it gives the complete turn and the angle returns to 0.

However, it's not enough to simply multiply our positions with this matrix. If you do it, you'll get this:

rotationMatrix * positionMatrix // This is not what we want.

We've got every gear doing its rotation but the axis of rotation is always the center of the canvas, and that's incorrect. We want them to rotate on their own center.

In order to fix this, first, we'll use a transformation named translate to move our gear to the center of the canvas. Then we'll apply the right rotation (the axis will be the center of the canvas again, but in this case, it's also the center of the gear), and finally, we'll move the gear back to its original position (by using translate again).

The translation matrix can be defined as follows:

function translation(tx, ty) {
  return [
    1, 0, 0, 
    0, 1, 0, 
    tx, ty, 1
  ]
}

We'll create two translation matrices: translation(centerX, centerY) and translation(-centerX, -centerY). Their center must be the center of each gear.

To get that, we'll do this matrix multiplication:

// Now they will turn on their axis
translationMatrix * rotationMatrix * translationToOriginMatrix * positionMatrix

You are probably wondering how to do that each gear spins at its own speed.

There's a simple formula to calculate the speed according to the number of teeth:

(Speed A * Number of teeth A) = (Speed B * Number of teeth B)

This way, in each frame we can add a different angle step to each gear and everyone spins at the speed that they're physically supposed to.

Let's implement it!

Having reached this section, we now know:

• What figures we should draw and how.
• We have the coordinates of each gear and its parts.
• We know how to rotate each gear.

Let's see how to do it with JavaScript and GLSL.

Initialize program with shaders

Let's write the vertex shader to compute the positions of the vertices:

const vertexShader = `#version 300 es
precision mediump float;
in vec2 position;
uniform mat3 u_rotation;
uniform mat3 u_translation;
uniform mat3 u_moveOrigin;

void main () {
  vec2 movedPosition = (u_translation * u_rotation * u_moveOrigin * vec3(position, 1)).xy;
  gl_Position = vec4(movedPosition, 0.0, 1.0);
  gl_PointSize = 1.0;
}
`

Unlike the vertex shader we used in the previous article, we'll pass the u_translation, u_rotation, and u_moveOrigin matrices, so the gl_Position will be the product of the four matrices (along with the position matrix). This way we apply the rotation as we have seen in the previous section. In addition, we'll define the size of each point we draw (which will be useful for the circle with the border) using gl_PointSize.

Note: Matrix multiplication is something we could do directly on the CPU with JavaScript and already pass the final matrix here, but the truth is that the GPU is made precisely for matrix operations so it's much better for performance to do it on the shader. Besides, from JavaScript, we would need a helper to do this multiplication, since we can't multiply arrays directly.

Let's write the fragment shader to compute the color of each pixel corresponding to each location:

const fragmentShader = `#version 300 es
precision mediump float;
out vec4 color;
uniform vec3 inputColor;

void main () {
   color = vec4(inputColor, 1.0);
}
`

As we can see there is no magic added to this fragment, it's the same as in the previous article. Given a defined color in the CPU with JavaScript, we'll pass it to the GPU to color our figures.

Now we can create our program with the shaders, adding the lines to get the uniform locations that we defined in the vertex shader. This way, later while running our script we can send each matrix to each uniform location per each frame.

const gl = getGLContext(canvas)
const vs = getShader(gl, vertexShader, gl.VERTEX_SHADER)
const fs = getShader(gl, fragmentShader, gl.FRAGMENT_SHADER)
const program = getProgram(gl, vs, fs)
const rotationLocation = gl.getUniformLocation(program, 'u_rotation')
const translationLocation = gl.getUniformLocation(program, 'u_translation')
const moveOriginLocation = gl.getUniformLocation(program, 'u_moveOrigin')

run() // Let's see this in the next section

The getGLContext, getShader and getProgram helpers do what we saw in the previous article. I put them down here:

function getGLContext(canvas, bgColor) {
  const gl = canvas.getContext('webgl2')
  const defaultBgColor = [1, 1, 1, 1]

  gl.clearColor(...(bgColor || defaultBgColor))
  gl.clear(gl.DEPTH_BUFFER_BIT | gl.COLOR_BUFFER_BIT)

  return gl
}

function getShader(gl, shaderSource, shaderType) {
  const shader = gl.createShader(shaderType)

  gl.shaderSource(shader, shaderSource)
  gl.compileShader(shader)

  if (!gl.getShaderParameter(shader, gl.COMPILE_STATUS)) {
    console.error(gl.getShaderInfoLog(shader))
  }

  return shader
}

function getProgram(gl, vs, fs) {
  const program = gl.createProgram()

  gl.attachShader(program, vs)
  gl.attachShader(program, fs)
  gl.linkProgram(program)
  gl.useProgram(program)

  if (!gl.getProgramParameter(program, gl.LINK_STATUS)) {
    console.error(gl.getProgramInfoLog(program))
  }

  return program
}

Draw each frame + calculate rotation angles

The run function we have seen called in the previous section will be responsible for the gears being drawn at a different angle in each frame.

// step for a gear of 1 tooth
// gears with more teeth will be calculated with this formula:
// realRotationStep = rotationStep / numberOfTeeth
const rotationStep = 0.2

// Angles are all initialized to 0
const angles = Array.from({ length: gears.length }).map((v) => 0)

function run() {
  // Calculate the angles of this frame, for each gear
  gears.forEach((gear, index) => {
    const direction = gear.direction === 'clockwise' ? 1 : -1
    const step = direction * (rotationStep / gear.numberOfTeeth)

    angles[index] = (angles[index] + step) % 360
  })

  drawGears() // Let's see this in the next section

  // Render next frame
  window.requestAnimationFrame(run)
}

Given the data we have in the gears array, we know the number of teeth and in which direction each gear rotates. With this we can calculate the angle of each gear on each frame. Once we save the new calculated angles, we call the function drawGears to draw each gear with the correct angle. Then we'll recursively call the run function again (wrapped with window.requestAnimationFrame to make sure that it's called again only in the next animation cycle).

You will probably be wondering why we don't implicitly tell to clean the canvas before each frame. It's because WebGL does it automatically when drawing. If it detects that we change the input variables, by default it will clean the previous buffer. If for some reason (not this case) we want the canvas not to be cleaned, then we should have obtained the context with an additional parameter const gl = canvas.getContext('webgl', { preserveDrawingBuffer: true });.

Draw gears

For each gear in each frame, we'll pass to the GPU the necessary matrices for the rotation: u_translation, u_rotation and u_moveOrigin. Then, we'll start drawing each of the pieces of the gear:

function drawGears() {
  gears.forEach((gear, index) => {
    const [centerX, centerY] = gear.center

    // u_translation
    gl.uniformMatrix3fv(
      translationLocation,
      false,
      translation(centerX, centerY)
    )

    // u_rotation
    gl.uniformMatrix3fv(rotationLocation, false, rotation(angles[index]))

    // u_moveOrigin
    gl.uniformMatrix3fv(
      moveOriginLocation,
      false,
      translation(-centerX, -centerY)
    )

    // Render the gear + each gear piece
    renderGearPiece(gear)
    if (gear.children) gear.children.forEach(renderGearPiece)
  })
}

We will draw each piece of the gear with the same function:

function renderGearPiece({
  center,
  radius,
  fillColor,
  strokeColor,
  numberOfTeeth,
}) {
  const { TRIANGLE_STRIP, POINTS, TRIANGLES } = gl
  const coords = getCoords(gl, center, radius)

  if (fillColor) drawShape(coords, fillColor, TRIANGLE_STRIP)
  if (strokeColor) drawShape(coords, strokeColor, POINTS)
  if (numberOfTeeth) {
    drawShape(
      getCoords(gl, center, radius, numberOfTeeth),
      fillColor,
      TRIANGLES
    )
  }
}

• If it's a circle with a border (Fig 3.) --> we'll use POINTS.
• If it's a color-filled circle (Fig 4.) --> we'll use TRIANGLE_STRIP.
• If it's a circle with teeth (Fig 5.) --> we'll use TRIANGLES.

Implemented with various "ifs", it allows us to create a circle filled with one color but with the border in another color, or a circle filled with color and with teeth. That means more flexibility.

The coordinates of the filled circle and the circle with border, even if one is made with triangles and the other with points, are exactly the same. The one that does have different coordinates is the circle with teeth, but we'll use the same helper to get the coordinates:

export default function getCoords(gl, center, radiusX, teeth = 0) {
  const toothSize = teeth ? 0.05 : 0
  const step = teeth ? 360 / (teeth * 3) : 1
  const [centerX, centerY] = center
  const positions = []
  const radiusY = (radiusX / gl.canvas.height) * gl.canvas.width

  for (let i = 0; i <= 360; i += step) {
    positions.push(
      centerX,
      centerY,
      centerX + (radiusX + toothSize) * Math.cos(2 * Math.PI * (i / 360)),
      centerY + (radiusY + toothSize) * Math.sin(2 * Math.PI * (i / 360))
    )
  }

  return positions
}

What we still need to know would be the helper drawShape, although it's the same code we saw in the previous article: It passes the coordinates and color to paint to the GPU, and calls the function drawArrays indicating the mode (if triangles, points...).

function drawShape(coords, color, drawingMode) {
  const data = new Float32Array(coords)
  const buffer = createAndBindBuffer(gl, gl.ARRAY_BUFFER, gl.STATIC_DRAW, data)

  gl.useProgram(program)
  linkGPUAndCPU(gl, { program, buffer, gpuVariable: 'position' })

  const inputColor = gl.getUniformLocation(program, 'inputColor')
  gl.uniform3fv(inputColor, color)
  gl.drawArrays(drawingMode, 0, coords.length / 2)
}

And voila! We got it.

Show me all the code

I've uploaded all the code for this article to my GitHub. I have implemented it with Preact. All the code can be found inside the hook useGears:

• https://github.com/aralroca/webgl-gears

You can also see the demo here:

• https://webgl-gears.vercel.app/

Conclusion

We have seen how to generate more complex figures using triangles and points. We have even given them movement with matrix multiplications.

There is a drawing mode we haven't seen yet, lines. That's because the lines that can be made with it are very thin, and they wouldn't fit the teeth of the gear. You can't change the thickness of the line easily, to do it you have to make a rectangle (2 triangles). These lines have very little flexibility and most figures are drawn with triangles. Anyway, at this point, you should be able to use the gl.LINES given 2 coordinates.

This article was the second part of "First steps with WebGL". Stay tuned because in next articles of this series we'll see: textures, image processing, framebuffers, 3d objects, and more.

References

• http://www.corehtml5.com/trianglestripfundamentals.php
• https://mattdesl.svbtle.com/drawing-lines-is-hard
• https://stackoverflow.com/a/54585370/4467741
• https://webgl2fundamentals.org/webgl/lessons/webgl-2d-matrices.html
• https://webgl2fundamentals.org/webgl/lessons/webgl-2d-rotation.html
• https://www.youtube.com/watch?v=nlNOSNlTXEQ

Streaming HTML

During the initial load, we don't have to worry much because the browsers do it automatically. When they receive the HTML chunks during the streaming they print the content.

To activate the streaming from the server you have to adapt the headers, for example:

{
  "transfer-encoding": "chunked",
  "vary": "Accept-Encoding",
  "content-type": "text/html; charset=utf-8"
}

And in the response use a ReadableStream. This would be the example with Bun:

const encoder = new TextEncoder()

// ...

return new Response(
  new ReadableStream({
    start(controller) {
      controller.enqueue(encoder.encode('<html lang="en">'))
      controller.enqueue(encoder.encode('<head />'))
      controller.enqueue(encoder.encode('<body>'))
      controller.enqueue(encoder.encode('<div class="foo">Bar</div>'))
      controller.enqueue(encoder.encode('</body>'))
      controller.enqueue(encoder.encode('</html>'))
      controller.close()
    },
  })
)

Each string inside enqueue is a chunk that the browser will receive.

Changing the HTML content during streaming

One of the practices that is being done a lot because it has many performance benefits is to change the HTML content during streaming. A clear example is React Suspense. The idea is to show empty content (placeholder, skeleton, or spinner) while loading the rest of the HTML and in the meantime, it is loading the missing content. Once the server has the missing content then in streaming-time it changes it!

Perhaps the first question that comes to your mind is how can you modify a part of the HTML that has already been sent and processed by the browser 🤔?

Well, browsers are smart enough to execute small JS scripts during streaming. However, they have to be scripts without being module type, because they always wait for all the HTML to be loaded before executing. In this case, we are not interested.

This would be an example to make it visually understandable (it's normally more complex than this):

return new Response(
  new ReadableStream({
    async start(controller) {
      const suspensePromises = []

      controller.enqueue(encoder.encode('<html lang="en">'))
      controller.enqueue(encoder.encode('<head>'))
      // Load the code to allow "unsuspense"
      controller.enqueue(
        enconder.encode('<script src="unsuspense.js"></script>')
      )
      controller.enqueue(encoder.encode('</head>'))
      controller.enqueue(encoder.encode('<body>'))

      // Add a placeholder (suspense)
      controller.enqueue(
        encoder.encode('<div id="suspensed:1">Loading...</div>')
      )

      // Load the content - without "await" (IMPORTANT)
      suspensePromises.push(
        computeExpensiveChunk().then((content) => {
          // enqueue the real content
          controller.enqueue(
            encoder.encode(
              `<template id="suspensed-content:1">${content}</template>`
            )
          )
          // enqueue the script to replace the suspensed content to the real one
          controller.enqueue(encoder.encode(`<script>unsuspense('1')</script>`))
        })
      )

      controller.enqueue(encoder.encode('<div class="foo">Bar</div>'))
      controller.enqueue(encoder.encode('</body>'))
      controller.enqueue(encoder.encode('</html>'))

      // Wait for all suspended content before closing the stream
      await Promise.all(suspensePromises)

      controller.close()
    },
  })
)

Where the unsuspense.js file is the one that exposes the window.unsuspense in this case so that it can be executed during the streaming and it replaces the content of the suspensed:1 by the content of the suspensed-content:1 template. In this case, the user will see the Loading... text and also the div with the Bar text. Once the content has been processed, the Loading... content will be changed to the real content.

Thinking of benefits, everything is done with a single request and the user instantly sees the HTML and the changes to it without having to make extra requests. In the past years, these requests were made from the client, for example in React using a useEffect, making this not executed until all the HTML was loaded, making another extra request to the server and complicating the life of the developers.

By being able to modify the HTML content during streaming, it now allows you to use async components and you can directly use fetch or make database requests in conjunction with Suspense.

HTML Streaming in runtime

We have talked about the practicality of HTML streaming for the initial loading of HTML, but apart from the initial loading, are there other scenarios where we want to stream HTML?

Yes, there are two cases:

• Navigation (View Transitions API)
• RPCs (ex: server actions)

Navigation (View Transitions API)

Since 2023 Chrome announced the View Transition API, and it looks like Safari is also going to support it soon.

The View Transitions API provides a mechanism for easily creating animated transitions between different DOM states simulating single-page apps (SPAs) while also updating the DOM contents in a single step.

During navigation, we usually want to replace all HTML content with other content. However, we must take advantage of streaming so that we don't have to wait.

window.navigation.addEventListener('navigate', navigate)

function navigate(event) {
  const url = new URL(event.destination.url)
  const decoder = new TextDecoder()

  // Only intercept navigations within the same origin for security
  if (location.origin !== url.origin) return

  event.intercept({
    async handler() {
      const res = await fetch(url.pathname)
      // Creates a new "sandbox" HTML Document
      const doc = document.implementation.createHTMLDocument()
      const stream = res.body.getReader()

      // Transition to the new document with smooth scrolling
      await document.startViewTransition(() => {
        // Connect the current document's DOM with the sandbox's DOM
        document.documentElement.replaceWith(doc.documentElement)
        document.documentElement.scrollTop = 0
      }).ready

      // Process the response body in chunks
      while (true) {
        const { done, value } = await stream.read()

        if (done) break // Exit the loop when the stream is finished

        // Inject decoded content into the sandbox document
        // within a transition. The sandbox treats the string and
        // parses it, then during the transition it is put into the
        // real DOM.
        await document.startViewTransition(() =>
          doc.write(decoder.decode(value))
        ).ready
      }
    },
  })
}

In this example, document.implementation.createHTMLDocument is used in conjunction with doc.write to process the stream, making each chunk a different transition. The use of doc.write should not raise an alert, in this context, it is well used. For more details of this trick this Chrome's video explains it.

The above example serves only to replace all HTML content with other content, but what if we wanted to have more control over the HTML nodes during streaming? Perhaps to filter out specific nodes during this streaming.

To make this possible, we can use the parse-html-stream library to make it easy to transform a stream reader to an HTML node generator. In this case, we could use it like this:

import parseHTMLStream from 'parse-html-stream' // Import it

window.navigation.addEventListener('navigate', navigate)

function navigate(event) {
  const url = new URL(event.destination.url)
  const decoder = new TextDecoder()

  if (location.origin !== url.origin) return

  event.intercept({
    async handler() {
      const res = await fetch(url.pathname)
      const doc = document.implementation.createHTMLDocument()
      const stream = res.body.getReader()

      await document.startViewTransition(() => {
        document.documentElement.replaceWith(doc.documentElement)
        document.documentElement.scrollTop = 0
      }).ready

      // Use it:
      for await (const node of parseHTMLStream(reader)) {
        // You have full control of each HTML Node during the streaming
        console.log(node.nodeName)
      }
    },
  })
}

However, it is much more complex now to implement adding the node in the right place in the main document, isn't it? So does all this make sense?

To understand the benefit of this, read on.

RPCs (ex: server actions)

A remote procedure call (RPC) is used so that developers do not have to implement an endpoint and all the communication logic between browser-sever and server-browser is handled by the RPC. An example of RPC would be React server actions, which can trigger updates to the DOM during streaming. However, React here is using a virtual DOM instead of transferring hypermedia (HTML) and using the diff algorithm with the real DOM.

In this article, I will not explain the technical details of how to implement an RPC, but to understand how server actions would work in a different context than React, I invite you to watch this video with an example of making events like onClick work on server components, i.e. when the user clicks a button in the browser, then the onClick function is executed on the server.

{% twitter 1753061161866572213 %}

The video of this tweet is about an experimental framework I'm doing, I hope in a few months to make it public and give more details.

The grace is that from the server you can modify the DB or whatever you want and see the HTML changes reflected in the browser.

{% twitter 1760028908647559375 %}

To make this possible, from the RPC client code (200B) a request is made to the action and if it is the first time, another request is made to download the lazy client code (1 kb) to process the response. This last code will be responsible for processing the HTML and updating the DOM only for the parts that have changed using the DOM Diffing algorithm.

To show you the benefit of this, think that you could build a SPA with almost no JS on the client, just the RPC. However, server actions make sense for interactions that involve server. For purely client interactions or that you need the Web API then you can use web components.

Another benefit of updating only the modified parts of the DOM, instead of the entire DOM, is its excellent integration with Web components. Web components, particularly those utilizing signals to react to changes, can maintain their internal state without losing synchronization.

DOM Diffing algorithm

React to update the Document Object Model (DOM) uses the diffing algorithm but with a virtual DOM, so it transfers the virtual DOM instead of hypermedia (HTML) directly. It does this to have more control over the client components since they are not reactive to the DOM. On the other hand, if our client components are web components with signals their properties are reactive and if the element is updated by adding a new attribute, then the web component without losing its internal state will react to the changes. This allows us to transfer directly HTML and work directly with the DOM.

Currently there are several open-source DOM diff algorithms, some examples:

• morphdom
• set-dom
• diffhtml
• diffDOM
• nanomorph
• incremental-dom

Most implementations use breadth-first search to traverse the DOM tree and update it.

However during HTML Streaming the nodes arrives as depth-first search (DFS):

If the server can start sending HTML as soon as possible and the browser does not wait for the entire response to arrive, it can process the HTML code in fragments as it arrives.

The last image is how browsers process streaming HTML, but the same must be done to support the DOM Diffing algorithm for streaming.

The rendering work is incremental to present the page changes to the user as quickly as possible. This approach generates a better Interaction to Next Paint (INP) score for the page.

Even the chunks arrive in DFS order, the browser cannot render an element until it has received all the information that defines it.

If you remember, when we talked about navigation, we gave an example that did the following:

for await (const node of parseHTMLStream(reader)) {
  // You have full control of each HTML Node during the streaming
  console.log(node.nodeName)
}

At this point, the nodes always arrive in DFS order. But it is not enough, because we need to walk through the tree inside the DOM diffing algorithm. That is, visit the firstChild, nextSibling, the parentNode, etc, and compare it with the real DOM nodes.

To do this, the parse-html-stream library that I have recently put in open-source, supports also walking through the tree of nodes during streaming, allowing you to do incremental rendering, while you walk through the tree the library is parsing the HTML chunks in the order they arrive, and while you have the parsed nodes you are making the rendering changes.

import htmlStreamWalker from 'parse-html-stream/walker'

// ...

const reader = res.body.getReader()
const walker = await htmlStreamWalker(reader)

// Root node
const rootNode = walker.rootNode

// Gives the firstChild taking into account the stream chunks
const child = await walker.firstChild(rootNode)

// Gives the nextSibling taking into account the stream chunks
const brother = await walker.nextSibling(rootNode)

// You can do it with every HTML node:
const childOfBrother = await walker.firstChild(brother)

In this case rootNode, child, brother, and childOfBrother are Nodes and you have access to all Node properties. Note, however, that there are two properties that may not be true because streaming chunks have yet to be received:

• node.firstChild ❌ - Stop being correct, in some cases, it would work, in others it would not because maybe the next chunk is the child of the Node.
• node.nextSibling ❌ - Stop being correct, in some cases, it would work, in others it would not because maybe the next chunk is the sibling of the Node.

For these cases, the parse-html-stream walker offers two methods to replace them so that they always work:

• walker.firstChild(node) ✅ - Try first to get the firstChild, if not yet wait for the next chunk to verify if it has it or not. When the next chunk arrives it processes the next nodes.
• walker.nextSibling(node) ✅ - Try first to get the nextSibling, if not yet wait for the next chunk to verify if it has it or not. When the next chunk arrives it processes the next nodes.

The initial nodes do not lose context and can be used after the execution of these functions.

Conclusions

In the article, we talked about the benefits and practical applications of HTML Streaming beyond just the initial rendering.

We talked about more technical concepts such as RPC, View Transitions API, DOM Diffing algorithm, but without going into detail on each of these topics, but rather how to use HTML Streaming in each of them. If you are interested in knowing more about topics that I have not gone into depth in this article, comment it in the comments and I will take it into account to make another article focusing on other topics that interest you.

We have also talked about parse-html-stream, a small library that I have recently put in open-source so that anyone can use it.

On a final note, the web was invented to transfer hypermedia (HTML) and after using JSON and a lot of client code over the last years, I hope to see more Hypermedia-Driven applications available to make life easier for developers and make websites lighter with almost no JavaScript code, so I see great promise for the future of HTML streaming beyond the initial load.

References

• https://bun.sh/docs/api/streams
• https://react.dev/reference/react/Suspense
• https://developer.mozilla.org/en-US/docs/Web/API/Document_Object_Model
• https://github.com/aralroca/parse-html-stream
• https://web.dev/articles/client-side-rendering-of-html-and-interactivity
• https://htmx.org/essays/hypermedia-driven-applications/
• https://en.wikipedia.org/wiki/Depth-first_search
• https://en.wikipedia.org/wiki/Breadth-first_search
• https://github.com/patrick-steele-idem/morphdom
• https://github.com/DylanPiercey/set-dom
• https://diffhtml.org/
• https://github.com/fiduswriter/diffDOM
• https://github.com/choojs/nanomorph
• https://google.github.io/incremental-dom/
• https://demystifying-rsc.vercel.app/static-content/2/

• Why HTML Streaming Over the Wire?
  • Interaction with JSON
  • Interaction with HTML Streaming
• Diff DOM Algorithm with Streaming
• Show me the code
  • Community Support and Adoption
• Show me some example
• Conclusion

Why HTML Streaming Over the Wire?

Given that modern browsers have supported HTML streaming for years, why limit ourselves to initial page loads? Why not extend HTML streaming to server interactions as well? Ultimately, reverting to HTML (HyperText Markup Language) restores the web's fundamental principles (HyperText Transfer Protocol).

For some time now, I've been immersed in developing Brisa, an experimental framework slated for public release this summer (If you are interested in knowing more, subscribe to my blog newsletter for now). One of our primary objectives has been to minimize client-side JavaScript code for server interactions. Drawing inspiration from server actions and HTMX concepts, we've achieved the capability to build single-page applications (SPAs) with just 800 bytes—equivalent to the RPC (Remote Procedure Call) for server communication. In cases requiring client components, they seamlessly transform into web components with signals, expanding the code to a mere 3KB.

Additionally, we have aimed to leverage the web platform to its fullest extent. For server actions, we opted to transmit Hypertext. As for client components, they transform into web components and, coupled with signals, respond dynamically to document changes without data transmission.

To understand the difference between the server interactions that we are familiar with in recent years, let's review how we are doing these server interactions through JSON:

Interaction with JSON

Traditionally, server interactions entail:

• Capturing a client event and writing code to serialize data, sending JSON to an endpoint (expanding client-side code).
• Writing an endpoint, deserializing/serializing both input and output data to return JSON.
• Processing the response on the client side, deserializing JSON, and maintaining it in memory for UI library rerendering, thereby further increasing client-side bundle size.

This is a very silly example about debouncing an input text and validating a code, but to show you that you can be familiar with doing all this logic on the client to do a server interaction:

Client code:

function debounce(func, delay) {
  let timeoutId;
  return (...args) => {
    const fn = func.bind(this, ...args)
    clearTimeout(timeoutId);
    timeoutId = setTimeout(fn, delay);
  };
}

export function ClientComponent() {
  const [showContent, setShowContent] = useState(false)

  async function handleInputOnClient(e) {
    const code = e.target.value;
    const res = await fetch(/* some endpoint */, {
      method: 'POST',
      body: JSON.stringify({ code })
    })
    if(res.ok) setShowContent(true)
  }

  if (showContent) return 'some content'

  return <input type="text"  onChange={debounce(handleInputOnClient, 300)} />
}

Server code:

export function POST(request: Request) {
  const data = await req.json()
  return new Response(null, { status: data.code === 'foo' ? 200 : 401 })
}

Isn't this cumbersome? Having to repeat this process for each server interaction only bloats client-side code.

Interaction with HTML Streaming

With HTML Streaming Over the Wire, the workflow in Brisa transforms:

• Upon capturing a client event within a server component, the process resembles that of an endpoint, where access to the browser event serialized from the server is available thanks to Brisa's RPC.
• Upon completing event processing within the server component, the RPC runtime on the client side updates only the modified portions of the web, streaming HTML generated from the rerender executed on the server.

Server component:

export function ServerComponent({}, request: RequestContext) {
  async function handleInputOnServer(e) {
    if (e.target.value === 'foo') {
      request.store.set('display-content', true)
      rerenderInAction()
    }
  }

  if (request.store.get('display-content')) return 'some content'

  return <input type="text" onInput={handleInputOnServer} debounceInput={300} />
}

In this workflow, there is debounce[Event] attribute inspired by HTMX to make the RPC client do the debounce, the rest is code that runs only on the server, and the store lives on request time.

This new workflow adds zero bytes of client-side code for each server interaction. Why add client-side JavaScript to perform the same DOM update task? This is the essence of the RPC code, which remains constant over time. The server actions are in charge of streaming HTML for the client RPC to update the UI.

By eliminating JSON transmission, we can leverage streaming for significantly faster and more progressive UI updates, even enabling "suspense" without additional client-side code.

Diff DOM Algorithm with Streaming

The Diff DOM (Document Object Model) algorithm has been utilized for years to simulate React's "Virtual DOM" without virtualization. Instead, it operates directly on the "Browser DOM," comparing two HTML nodes efficiently and updating the first DOM tree based on the modifications present in the second.

In essence, HTML Over the Wire (without streaming) has been achievable for years thanks to the Diff DOM Algorithm, widely adopted by many modern libraries and frameworks.

React, for instance, avoids using HTML for transmission between server components (RSCs) to facilitate streaming in single-page applications and communication with server actions. It relies on progressively loaded JSON with "holes", which must be processed before employing the Virtual DOM. Dan Abramov elucidated this in a tweet a few months ago. I inquired further in another tweet regarding the feasibility of HTML Streaming, to which he cited two obstacles:

1. doesn’t help with passing new data to stateful stuff (like a list of todos to an already mounted todo list component)

2. you’d have to either parse HTML yourself (non-trivial to do correctly) or create throwaway DOM nodes

Upon analysis, I found these obstacles to be surmountable.

Regarding the first point, Brisa obviates the need to pass data for stateful components, as client components utilize real DOM elements, namely web components. When attributes are modified, they react to changes using signals, updating their content while preserving the state. Hence, use native constructs—web components, signals (currently as a proposal in TC39 with stage 0), and HyperText Markup Language—made more sense.

Regarding the second point, browsers offer a native "hack" for parsing nodes from a stream. This technique is elucidated in a video on the "Chrome for Developers" YouTube channel here.

Therefore, to support the Diff DOM Algorithm with HTML Streaming, three aspects must be considered:

1. DFS (Depth-First Search): Instead of implementing breadth-first search (BFS) for analyzing the DOM tree, DFS must be employed to synchronize with streaming, as HTML chunks during streaming always arrive in DFS order.
2. Parsing HTML String Chunks to HTML Nodes: Efficient parsing of each incoming node during streaming is essential, along with traversal among the arriving nodes.
3. Stop and Wait for Missing Chunks: Identifying instances where comparison involves data yet to be received, waiting only as necessary without blocking.

Show me the code

I've open-sourced diff-dom-streaming, a library weighing only 1KB. Most of the time, you'll load it lazily since user interaction triggers its need, eliminating the necessity of loading it upfront.

import diff from 'https://unpkg.com/diff-dom-streaming@latest'

// ...

const res = await fetch(/* some url */)

// Apply diff DOM between the current document
// and the stream reader:
await diff(document, res.body.getReader())

This library heralds the reality of HTML Streaming Over the Wire, accessible not just to Brisa but to numerous other libraries and frameworks. You can even employ it in vanilla JavaScript without any additional libraries.

Community Support and Adoption

If you see potential in HTML Streaming Over the Wire and wish to contribute to its growth, consider giving the diff-dom-streaming library a star on GitHub. Your support helps to promote its visibility and encourages further development in this innovative approach to web development.

Show me some example

Here's the demo of the boxes you can try out without any framework.

{% twitter 1776956020574585206 %}

Conclusion

HTML Streaming Over the Wire, empowered by the Diff DOM algorithm, promises a return to the web's core principles, paving the way for a faster, more responsive, and scalable web experience for all. The future of this technology holds immense potential, and I'm eager to see how it unfolds in more frameworks and libraries.

Before we begin... A little context

First, let me tell you about Next-translate. It is one of the most widely used libraries for loading and using translations in Next.js pages (~70k weekly downloads) and has existed since Next.js 9.

By default, translations are stored in locales/{lang}/{namespace}.json:

.
├── en
│   ├── common.json
│   └── home.json
└── es
    ├── common.json
    └── home.json

*However, they can also be loaded from a CDN or integrated with an online internationalization platform like localize.

🦄 One of the library's goals is to be easy to use. With a little configuration in the i18n.js file, you can already consume these translations in your pages and components:

import useTranslation from 'next-translate/useTranslation'

export default function Example() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('example')}</h1>
}

🌍 Another goal of the library is to have all the i18n essentials: interpolation, plurals, formatters, translations with HTML tags, etc.

📦 And another goal is to be as lightweight as possible. In version 1.0, we made it occupy ~1kb, but with version 2.0, there have been even more improvements that we will see in this post.

I won't go into further detail on how the library works. I invite you to read the documentation if you want more details.

Now that I have introduced the library, let's see if it is still easy to use, lightweight, and has all the i18n essentials in the new paradigm that Next.js 13 introduced in late 2022: the app directory...

What is the app dir?

The app directory in Next.js 13 (beta) introduces a new routing and data fetching system that supports layouts, nested routes, and utilizes React 18 Server Components by default.

Server components are a new type of React component that executes on the server and on the server only. This means that they are never shipped to the client, resulting in a significant reduction in the amount of code that needs to be shipped to the browser. This reduction in the amount of code can improve the performance of React applications, especially those dealing with large amounts of data.

They were originally thought of as a way to solve the "waterfall problem" in React applications. This occurs when a React component requires data from a server, but that data is not available yet. This can result in a "waterfall" of network requests, as each component waits for the data it needs before it can render, causing significant delays in rendering and impacting the user experience.

With Server components allows the server to fetch all the required data in one go, instead of going back and forth with the client. This results in a significant improvement in the performance of React applications.

They also reduce the amount of code that needs to be shipped to the client, which can improve the load time of React applications. They can also improve the maintainability of applications, as they can make it easier to manage data fetching in large applications.

However, if there are parts of your code that require interactivity with the user, you can create client component islands, where the page only uses the kilobytes of JavaScript used in these islands. As less JavaScript is always better, this approach is ideal.

One of the challenges with this paradigm shift of working with server components and client islands is that they function differently and are like two separate worlds. Therefore, the goal is to find a way to make the usage of both as simple and consistent as possible.

Server components headaches

If a programmer works with both Server Components and Client Components at the same time, they may face some challenges in terms of integration and coordination between the two types of components.

One of the main challenges could be the need to maintain coherence between the data handled on the server and on the client. For example, if a server page loads a translation namespace and all page components need to use these translations, island client components must also have access to the same translations without fetching them from the client, which requires coordinating data requests to avoid unnecessary redundancies and ensure that the data is obtained efficiently to avoid delays in site loading and reduce unnecessary bandwidth usage.

Finally, there may be challenges in integrating libraries used to work with Server Components and Client Components. Ensuring that these tools work well together can be a challenge. So let's see how we have dealt with these problems at Next-translate.

Load and consume translations in Next.js 13 app dir

In Next-translate 2.0, we have struggled with this issue to make the solution as user-friendly as possible. In the end, we achieved this goal, and no additional configuration is necessary in your i18n.js setup. 🎉

Simply keep in mind 🧠 that the pages defined in the configuration are now used for the pages within the app directory:

// i18n.js
module.exports = {
  locales: ['en', 'ca', 'es'],
  defaultLocale: 'en',
  pages: {
    '*': ['common'],
    '/': ['home'], // app/page.tsx
    '/checkout': ['checkout'], // app/checkout/page.tsx
  },
}

That's all you need to do! 😜

Our plugin, which was already present Next-translate 1.0, now in Next-translate 2.0 takes care of loading translations in both server and client pages, as well as client component islands within a server page. Furthermore, we have reduced the size of our library from 1.8kb to 498B (minified + gzipped).

Prior to the app directory, the pages always had 1.8kb of translations in the bundle, but now:

• If you have all translations in server components: 0kb 🥳
• If you need client component islands that change the text according to user interaction: 498B 🎉

To consume these translations, use the useTranslation hook or the Trans component:

🌊 Server page (+0kb): app/page.js:

import useTranslation from 'next-translate/useTranslation'

export default function HomePage() {
  const { t, lang } = useTranslation('home')

  return <h1>{t('title')}</h1>
}

In this case, we are dealing with a server page, as pages are by default server components. Under the hood, the next-translate-plugin dynamically loads translations directly, without the need for the useEffect hook or context. It also sets the language and namespace in the HTML, enabling other components, such as client-side islands, to hydrate and consume the same translations loaded for the page.

🏝️ Client page (+498B): app/checkout/page.js

'use client'
import useTranslation from 'next-translate/useTranslation'

export default function CheckoutPage() {
  const { t, lang } = useTranslation('checkout')

  return <h1>{t('title')}</h1>
}

For client pages, which are not the default in Next.js, it is necessary to indicate that they are client-side using the "use client" line, which is a new feature in the app directory of Next.js 13. By default, if this line is not present, the page is server-side. Under the hood, the next-translate-plugin loads translations for these pages using the useEffect hook. In this case, there is no need to add anything to the HTML because all components will already have access to the translations without the need for hydration.

🏝️ Client component (+498B): components/ClientIsland

'use client'
import useTranslation from 'next-translate/useTranslation'

export default function ClientIsland() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('island')}</h1>
}

The same logic applies to components: if they do not have the "use client" line, they are server-side by default, but if they include it, they become client component islands that can be used on a server page.

In this case, the next-translate-plugin will check whether hydration is necessary, since it is possible that the translations are already accessible if the parent page or component was also a client.

🌊 Server component (+0kb): components/ServerSea

import useTranslation from 'next-translate/useTranslation'

export default function ServerSea() {
  const { t, lang } = useTranslation('common')
  return <h1>{t('sea')}</h1>
}

For server components, the plugin does not perform any transformation, as translations have already been loaded at the page level, and direct access to the translations is available within the useTranslation hook.

🌊🏝️🏝️ Server page with client islands (+498B): app/page.js

import ServerSea from '@components/ServerSea' // this part 0kb
import ClientIsland from '@components/ClientIsland'
import AnotherClientIsland from '@components/AnotherClientIsland'

export default function HomePage() {
  return (
    <>
      <ServerSea />
      <ClientIsland />
      <AnotherClientIsland />
    </>
}

However, if there is a server page with client components, the client components must hydrate what has been provided from the server page and rerender.

i18n routing with app dir

Next.js 10 introduced i18n routing support, allowing pages to be rendered by navigating to /es/page-name, where the page pages/page-name.js was accessed using the useRouter hook to obtain the locale.

However, since the pages have been moved from the pages dir to the app dir, this i18n routing no longer works correctly.

At Next-translate, we have chosen not to re-implement this functionality, as we aim to be a library for translating pages, rather than routing them. We hope that in the future, this feature will be implemented in the app directory, as it is still in beta and many features still need to be supported.

However, all the support currently available is with the lang parameter. That is, /es/page-name?lang=es renders the page app/page-name/page.js, where we have internal access to the lang parameter, and you do not need to do anything extra other than using the useTranslation hook to consume your translations.

All the same, if you wish to use the language as a subpath /es/page-name without the param, you can utilize middleware to append the lang parameter and perform a rewrite:

// middleware.ts
import { NextResponse } from 'next/server'
import type { NextRequest } from 'next/server'
import i18n from './i18n'

// /es/page-name -> rewrites to -> /es/page-name?lang=es
export function middleware(request: NextRequest) {
  const locale = request.nextUrl.locale || i18n.defaultLocale
  request.nextUrl.searchParams.set('lang', locale)
  request.nextUrl.href = request.nextUrl.href.replace(`/${locale}`, "")
  return NextResponse.rewrite(request.nextUrl)
}

Here in the middleware, we are not adding the locale as a subpath, but rather eliminating the need to manually add the lang parameter. By default, the subpath still exists, but you cannot use useRouter from next/router to access the locale within the components of the app directory. Therefore, we still need the parameter, even if we hide it from view.

And to navigate:

<Link href={`/?lang=${locale}`} as={`/${locale}`}>
  {locale}
</Link>

If you need more i18n routing features like automatic locale detection you can follow these steps from the Next.js documentation:

• https://beta.nextjs.org/docs/guides/internationalization.

Demo

To conclude, if you are eager to try an example application using Next.js with the app directory and Next-translate, you can take a look at this example:

• Codesandbox

Conclusion

This article discusses the Next.js 13 paradigm shift in managing pages, which introduces a new routing and data-fetching system that supports layouts, nested routes, and server components. Server components are a new type of React component that executes only on the server, reducing the amount of code that needs to be shipped to the browser and improving the performance of React applications.

The article also discusses the Next-translate library, which is one of the most widely used libraries for loading and using translations in Next.js pages. It aims to be easy to use, have all the i18n essentials, and be as lightweight as possible. The article evaluates whether Next-translate is still easy to use, lightweight, and has all the i18n essentials in the new paradigm of Next.js 13, and explains how to use it.

References

• Next-translate repo: https://github.com/aralroca/next-translate
• Next-translate 2.0 release: https://github.com/aralroca/next-translate/releases/tag/2.0.0
• Next-translate-plugin repo: https://github.com/aralroca/next-translate-plugin
• Next.js app dir docu: https://beta.nextjs.org/docs/guides/internationalization
• Next.js i18n routing docu (before app dir):https://nextjs.org/docs/advanced-features/i18n-routing
• Deno article about client islands: https://deno.com/blog/the-future-and-past-is-server-side-rendering
• React server components: https://reactjs.org/blog/2020/12/21/data-fetching-with-react-server-components.html
• React 18 features: https://reactjs.org/blog/2022/03/29/react-v18.html

His goals are now different. After realizing that there were some design errors impossible to fix in Node.js, he decided to create another JavaScript (also TypeScript) runtime built with V8: Deno (in Rust). Deno 1.0.0 will be finally released on 13th May 2020.

We'll see how Deno works and its differences with Node, implementing a simple chat application.

We will cover the following:

• Installing Deno
• Simple "Hello World"
• Serve an index.html
• Using WebSockets
• Third-party and deps.ts convention
• Testing
• Debugging
• Conclusion
• Code of this article
• References

Installing Deno

There are different ways to install Deno: Using curl, iwr, Homebrew, Chocolatey... See how to install it here. Deno is a single binary executable, it has no external dependencies.

In my case I'm going to use Homebrew:

➜  ~ brew install deno
➜  ~ deno --version
deno 1.0.0-rc1
v8 8.2.308
typescript 3.8.3

As we can see, there's no npm here. Npm started to be essential in the Node ecosystem... And it's a centralized (privately controlled even) repository for modules. This is now changing with Deno. We will see later how to install packages without a package.json and node_modules either.

To upgrade to the latest version we need to do deno upgrade.

I recommend to execute deno help to see all the possible usages:

USAGE:
    deno [OPTIONS] [SUBCOMMAND]

OPTIONS:
    -h, --help                     Prints help information
    -L, --log-level <log-level>    Set log level [possible values: debug, info]
    -q, --quiet                    Suppress diagnostic output
    -V, --version                  Prints version information

SUBCOMMANDS:
    bundle         Bundle module and dependencies into single file
    cache          Cache the dependencies
    completions    Generate shell completions
    doc            Show documentation for a module
    eval           Eval script
    fmt            Format source files
    help           Prints this message or the help of the given subcommand(s)
    info           Show info about cache or info related to source file
    install        Install script as an executable
    repl           Read Eval Print Loop
    run            Run a program given a filename or url to the module
    test           Run tests
    types          Print runtime TypeScript declarations
    upgrade        Upgrade deno executable to newest version

ENVIRONMENT VARIABLES:
    DENO_DIR             Set deno's base directory (defaults to $HOME/.deno)
    DENO_INSTALL_ROOT    Set deno install's output directory
                         (defaults to $HOME/.deno/bin)
    NO_COLOR             Set to disable color
    HTTP_PROXY           Proxy address for HTTP requests
                         (module downloads, fetch)
    HTTPS_PROXY          Same but for HTTPS

In case that you are using Visual Studio Code, I recommend to install this plugin to ease working with Deno:

• https://marketplace.visualstudio.com/items?itemName=axetroy.vscode-deno

Simple "Hello World"

For a simple "Hello world" in Deno, we just need to create a file .js or .ts, and execute it with deno run [file].

In case of .ts, it will compile + execute, meanwhile for .js, the file will be executed directly:

// example.ts file
console.log('Hello from Deno 🖐')

And in the shell:

➜  deno run example.ts
Compile file:///Users/aralroca/example.ts
Hello from Deno 🖐

The tsconfig.json file is optional because in Deno there are some TypeScript defaults. To apply the tsconfig.json we should use deno run -c tsconfig.json [file].

By the way, Deno uses web standards where possible. It's possible to use window, fetch, Worker... Our code should be compatible with both Deno and the browser.

Serve an index.html

Deno has his own standard library https://deno.land/std/ so to use their modules we can import it directly from the URL. One of its goals is shipping only a single executable with minimal linkage. This way it's only necessary to import the URL to their projects, or execute directly with deno run https://... in case of CLIs.

In order to create a http server and serve an index.html we are going to use this module: https://deno.land/std/http/.

We are going to create two files: server.ts and index.html.

index.html

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta name="viewport" content="width=device-width, initial-scale=1" />
    <meta charset="utf-8" />
    <title>Example using Deno</title>
  </head>
  <body>
    index.html served correctly
  </body>
</html>

server.ts

import { listenAndServe } from 'https://deno.land/std/http/server.ts'

listenAndServe({ port: 3000 }, async (req) => {
  if (req.method === 'GET' && req.url === '/') {
    req.respond({
      status: 200,
      headers: new Headers({
        'content-type': 'text/html',
      }),
      body: await Deno.open('./index.html'),
    })
  }
})

console.log('Server running on localhost:3000')

We can use ESmodules by default instead of Common.js, indicating the file extension always at the end. Moreover, it supports the latest features as async-await.

Also, we don't need to worry about formatting anymore. Instead of using tools as Prettier, we can format the files with deno fmt command.

The first time deno run server.ts runs, we'll see two differences with respect to the "Hello World" example:

1. It downloads all the dependencies from http module. Instead of using yarn or npm install, it should install all the needed dependencies before running the project. This happens only the first time, since it's cached. To clean the cache you can use the --reload command.

2. It throws an error Uncaught PermissionDenied: network access to "127.0.0.1:3000", run again with the --allow-net flag. Deno is secure by default. This means that we can't access to the net or read a file (index.html). This is one of the big improvements over Node. In Node any CLI library could do many things without our consent. With Deno it's possible, for example, to allow reading access only in one folder: deno --allow-read=/etc. To see all permission flags, run deno run -h.

Now we are ready to serve index.html:

➜ deno run --allow-net --allow-read server.ts
Compile file:///Users/aralroca/server.ts
Server running on localhost:3000

Using WebSockets

WebSockets, UUID, and other essentials in Node are not part of the core. This means that we need to use third-party libraries to use it. Yet, you can use WebSockets and UUID among many others by using Deno standard library. In other words, you don't need to worry about maintenance, because now it will be always maintained.

To continue implementing our simple chat app, let's create a new file chat.ts with:

import {
  WebSocket,
  isWebSocketCloseEvent,
} from 'https://deno.land/std/ws/mod.ts'
import { v4 } from 'https://deno.land/std/uuid/mod.ts'

const users = new Map<string, WebSocket>()

function broadcast(message: string, senderId?: string): void {
  if (!message) return
  for (const user of users.values()) {
    user.send(senderId ? `[${senderId}]: ${message}` : message)
  }
}

export async function chat(ws: WebSocket): Promise<void> {
  const userId = v4.generate()

  // Register user connection
  users.set(userId, ws)
  broadcast(`> User with the id ${userId} is connected`)

  // Wait for new messages
  for await (const event of ws) {
    const message = typeof event === 'string' ? event : ''

    broadcast(message, userId)

    // Unregister user conection
    if (!message && isWebSocketCloseEvent(event)) {
      users.delete(userId)
      broadcast(`> User with the id ${userId} is disconnected`)
      break
    }
  }
}

Now, register an endpoint /ws to expose the chat on server.ts:

import { listenAndServe } from 'https://deno.land/std/http/server.ts'
import { acceptWebSocket, acceptable } from 'https://deno.land/std/ws/mod.ts'
import { chat } from './chat.ts'

listenAndServe({ port: 3000 }, async (req) => {
  if (req.method === 'GET' && req.url === '/') {
    req.respond({
      status: 200,
      headers: new Headers({
        'content-type': 'text/html',
      }),
      body: await Deno.open('./index.html'),
    })
  }

  // WebSockets Chat
  if (req.method === 'GET' && req.url === '/ws') {
    if (acceptable(req)) {
      acceptWebSocket({
        conn: req.conn,
        bufReader: req.r,
        bufWriter: req.w,
        headers: req.headers,
      }).then(chat)
    }
  }
})

console.log('Server running on localhost:3000')

To implement our client-side part, we are going to choose Preact to be able to use modules directly without the need of npm, babel and webpack, as we saw on the previous article.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <title>Chat using Deno</title>
  </head>
  <body>
    <div id="app" />
    <script type="module">
      import {
        html,
        render,
        useEffect,
        useState,
      } from 'https://unpkg.com/htm/preact/standalone.module.js'

      let ws

      function Chat() {
        // Messages
        const [messages, setMessages] = useState([])
        const onReceiveMessage = ({ data }) => setMessages((m) => [...m, data])
        const onSendMessage = (e) => {
          const msg = e.target[0].value

          e.preventDefault()
          ws.send(msg)
          e.target[0].value = ''
        }

        // Websocket connection + events
        useEffect(() => {
          if (ws) ws.close()
          ws = new WebSocket(`ws://${window.location.host}/ws`)
          ws.addEventListener('message', onReceiveMessage)

          return () => {
            ws.removeEventListener('message', onReceiveMessage)
          }
        }, [])

        return html`
          ${messages.map((message) => html` <div>${message}</div> `)}

          <form onSubmit=${onSendMessage}>
            <input type="text" />
            <button>Send</button>
          </form>
        `
      }

      render(html`<${Chat} />`, document.getElementById('app'))
    </script>
  </body>
</html>

Result:

It's a very ugly chat without styles, but functional, because our aim here is to understand how Deno works.

Third-party and deps.ts convention

We can use third-party libraries in the same way we use the Deno Standard Library, by importing directly the URL of the module.

• STD, Deno core libraries: https://deno.land/std/
• X, Deno Third-party libraries: https://deno.land/x/

However, the ecosystem in https://deno.land/x/ is quite small yet. But hey, I have good news for you, we can use packages from https://www.pika.dev. Thanks to tools like Parcel or Minibundle we can compile Node libraries into modules to re-use them in Deno projects.

We are going to use the camel-case package to transform every chat message to camelCase!

Let's add this import in our chat.ts file:

import { camelCase } from 'https://cdn.pika.dev/camel-case@^4.1.1'
// ...before code
const message = camelCase(typeof event === 'string' ? event : '')
// ... before code

That's it. Running again the server.ts is going to download the camel-case package. Now you can see that it works:

However, if I want to use this camelCase helper in more than one file, it's cumbersome to add the full import everywhere. The URL indicates which version of the package we have to use. This means that if we want to upgrade a dependency we will need to search and replace all the imports. This could cause us problems, but don't worry, there is a Deno convention for the dependencies that solves this. Creating a deps.ts file to export all project dependencies.

// deps.ts file
export { camelCase } from 'https://cdn.pika.dev/camel-case@^4.1.1'

and

// chat.ts file
import { camelCase } from './deps.ts'
// ...
const message = camelCase(typeof event === 'string' ? event : '')
// ...

Testing

We are going to build a useless camelize.ts utility to return the text in camelCase with a nice extra, it includes one 🐪 per uppercase letter. Why? To see how to test it with Deno.

/**
 * Return the text in camelCase + how many 🐪
 *
 * @example "this is an example" -> "thisIsAnExample 🐪🐪🐪"
 * @param text
 * @returns {string}
 */
export function camelize(text: string) {
  // @todo
}

By the way, we can visualize the JSdocs of a file using deno doc [file]:

➜  deno doc camelize.ts
function camelize(text: string)
  Return the text in camelCase + how many 🐪

Let's create a file test.ts. The test runner is built into the core of Deno using the Deno.test() and we can use assertions using the STD https://deno.land/std/testing/asserts.ts.

import { assertStrictEq } from 'https://deno.land/std/testing/asserts.ts'
import { camelize } from './camelize.ts'

Deno.test('camelize works', async () => {
  assertStrictEq(camelize('this is an example'), 'thisIsAnExample 🐪🐪🐪')
})

To run all tests, we just need to execute deno test.

➜  deno test
Compile file:///Users/aralroca/test.ts
running 1 tests
test camelize works ... FAILED (0ms)

failures:

camelize works
AssertionError: actual: undefined expected: thisIsAnExample 🐪🐪🐪
    at assertStrictEq (asserts.ts:224:11)
    at test.ts:5:3
    at asyncOpSanitizer ($deno$/testing.ts:36:11)
    at Object.resourceSanitizer [as fn] ($deno$/testing.ts:70:11)
    at TestApi.[Symbol.asyncIterator] ($deno$/testing.ts:264:22)
    at TestApi.next (<anonymous>)
    at Object.runTests ($deno$/testing.ts:346:20)

failures:

        camelize works

test result: FAILED. 0 passed; 1 failed; 0 ignored; 0 measured; 0 filtered out (0ms)

Of course it fails because we didn't implemented our utility yet, but still, we can see how the errors are displayed in the shell.

After implementing the camelize utility:

import { camelCase } from './deps.ts'

/**
 * Return the text in camelCase + how many 🐪
 *
 * @example "this is an example" -> "thisIsAnExample 🐪🐪🐪"
 * @param text
 * @returns {string}
 */
export function camelize(text: string) {
  const camelCaseText = camelCase(text)
  const matches = camelCaseText.match(/[A-Z]/g) || []
  const camels = Array.from({ length: matches.length })
    .map(() => '🐪')
    .join('')

  return `${camelCaseText} ${camels}`
}