DEV Community: zerodays

From Idea to Reality in 2 Days: Bringing the Hackathon Approach into our Office

Špela Buh — Wed, 19 Mar 2025 10:46:49 +0000

If you read our DragonHack blog, you already know what an important role the hackathon approach has played in shaping our team dynamic and making us the team we are today. It threw us in headfirst, challenging us to solve real-life problems for the first time outside the classroom. And most importantly, it gave us the opportunity to discover the best way to work while tackling really hard problems head-on and still creating something incredible within the time constraints.

So, with a larger team than ever before and growing ambitions to explore some product ideas, we decided to see if this approach is still the right path for us, by holding a two-day internal company hackathon.

Ground Rules

Before we started, we had to set some ground rules for how the event and the work would take place.

Sleep at home: While true one-piece hackathons can be a lot of fun (staying up all night together, trying to get things done, and pushing through the slumps) we recognize that people have lives outside of work. So, we decided to spread the hackathon across two days.
Think about the users and make sure you’re solving a problem: It’s not just about the product; it’s about ensuring there is a product-user fit. Don’t just build something cool - make sure it actually solves a real-life problem.
Make a demo and pitch the idea: Think broader than just building it - show that you understand the problem and your product, and sell it to us.

Let’s Start at the Beginning - What To Do?

Of course, we couldn’t start without knowing what we wanted to work on. So, we kicked things off with a brainstorming session a week before to define the problem we wanted to solve. Each team member had to pitch two problems they were interested in tackling. The ideas were varied and diverse - ranging from development-focused issues that had bothered us for months to personal annoyances we encountered in everyday life and niche market problems we stumbled upon by chance.

With over 20 different ideas, we needed a way to narrow them down. So, we did a bit of research and combined different resources to get the 13 questions we asked for each problem to evaluate them:

Is this a solution or a problem?
Are we the right team to solve this problem?
Market size (large with little competition, or growing fast)?
How big is the problem?
Can we imagine a good business model?
Can we reach the target audience?
Is there competition? (Not necessarily bad - but do we need a new approach?)
Would we use this product ourselves?
Has the solution only recently become possible or necessary?
Are there successful similar companies in other markets?
Can we see ourselves working on this idea for years?
Is it scalable?
What is the success rate in this space?

At the end of this process, we were left with four ideas that checked all the boxes. Three days later, after everyone had a bit of time to sleep on it, we voted and selected the final two. With that, we were ready to start our hackathon.

Let’s Get Crackin’

Time for the main event - let’s get to building. We started by setting clear expectations and splitting into two balanced teams. From there, we defined key features, divided the work, and got to building.

Each team was also tasked with completing a value proposition canvas and creating a landing page to better understand the product, the problem, and how to communicate the value proposition. Then, the building began - of course, with a well-deserved pizza break along the way.

The first day was all about tackling the toughest challenges first and ensuring there was something to show - because the next morning kicked off with a short demo of what had been accomplished so far. The other team could ask questions and suggest ideas, giving us fresh momentum to push forward. But the hacking stopped at 15:30 sharp.

Then, it was pens down and time to pitch. Both teams did an incredible job - both in building and presenting, resulting in two amazing demos. But we’re not showing them to you just yet!

So Was This the Right Way?

Ending our two-day journey with a celebratory beer, we would say, absolutely! Beyond just building something awesome, we:

Created a great environment for innovation, maintained full focus, and really pushed through it.
Switched teams around a bit and explored different dynamics.
Coordinated, explored new roles, and tried out different approaches.
Thought more strategically, beyond just the technical aspects.
Had an amazing team-building experience.

🧩 Beyond the Popup: Crafting Next-Level Chrome Extensions with CRXJS

Tim Vučina — Wed, 19 Feb 2025 10:21:50 +0000

1. The Magic of Chrome Extensions ✨

Chrome extensions are more than just handy little tools - they’re like superpowers for your browser. From automating workflows to enhancing user experience, they can transform the way people interact with the web. But the real beauty? Extensions can seamlessly integrate into websites, modify content on the fly, and even leverage AI for mind-blowing results (like Classmate does).

Instead of a dull definition, let’s highlight what makes extensions exciting:

They live inside your browser – meaning instant access and control over webpages.
They hook into powerful APIs – like the Chrome Storage API, Context Menus, Side Panels, and even WebRTC.
They enable automation, AI, and interaction enhancements – basically, they let you mold the web to your will.

2. Choosing Your Stack: The Right Tools for the Job 🛠️

Unlike traditional web apps, building a Chrome extension usually requires a carefull balancing of performance, compatibility, and maintainability. There are multiple ways to approach extension development, from vanilla JavaScript to full-blown frameworks.

Popular Choices for Extension Development:

Plain JavaScript – Lightweight but messy for scaling.
React (or Preact) – Great for UI-heavy extensions but requires careful bundling.
TypeScript – A must-have for maintainability.
Vite + ESBuild – Super fast and developer-friendly for modern extensions.
TailwindCSS – Ideal for crafting polished UIs quickly.
Supabase/Firebase – Cloud storage, authentication, and real-time syncing made easy.

For Classmate, we went with React, TypeScript, Vite, Tailwind, and Supabase, ensuring a modern, scalable architecture with minimal bloat.

3. The Unique Challenges & Superpowers of Extension Development 🔥

Chrome extensions offer incredible browser APIs but also introduce quirks and gotchas that developers need to navigate.

The Good: Browser APIs That Supercharge Your Extension 🚀

chrome.tabs – Interact with and modify webpages dynamically.
chrome.scripting – Inject JavaScript and CSS into any page.
chrome.contextMenus – Create custom right-click options for quick actions.
chrome.storage – Persist user settings without a backend.
chrome.identity – Handle authentication seamlessly.

The Bad: Common Pitfalls & Limitations 😬

Manifest V2 → V3 transition – Service workers replace background scripts, breaking some old workflows.
Restricted access – Some APIs are off-limits (e.g., network requests need special permissions).
No direct database storage – Requires external storage like Firebase or Supabase.
Performance concerns – Extensions should be lightweight to avoid slowing down the browser.

The Ugly: Bad Practices That Can Doom Your Extension ❌

Over-permissioning – Requesting too many permissions leads to rejection by the Chrome Web Store.
Not optimizing storage – Extensions with large local storage can slow down performance.
Blocking the main thread – Keep content scripts efficient to avoid laggy pages.

4. Bridging the Gap: Messaging Between Popup & Content Scripts 🔄

One of the biggest challenges in Chrome extension development is getting different parts of the extension – popup, background scripts, and content scripts – to talk to each other efficiently. Unlike a traditional web app, where everything runs in a single execution context, Chrome extensions are split into isolated environments.

This means:

✅ The popup doesn’t directly control the webpage – it must send messages.

✅ The content script can interact with the page but lacks access to extension APIs – it needs to communicate with the background.

✅ The background service worker acts as a central hub, receiving messages and dispatching commands.

How We Handle Messaging in Classmate ⚡

To keep our messaging system structured and scalable, we use typed messages with TypeScript, ensuring every communication has a clear format.

Message Structure & Commands

We define a set of commands, like:

export type Command =
  | 'START_SCREENSHOT'
  | 'ASK_AI'
  | 'TRIGGER_AUTOSOLVE'
  | 'OPEN_SIDEBAR';

Each message follows a strict format, using interfaces like:

export interface AskAI extends BaseMessage {
  command: 'ASK_AI';
  text: string;
  autoSolveData?: AutoSolveQuestion | null;
}

This ensures every part of our extension knows exactly what kind of messages to expect, reducing errors.

Sending Messages to the Active Tab

We use a helper function to find and message the active tab:

export const sendMessageToActiveTab = async (message: Message) => {
  const tab = await getActiveTab();
  if (!tab?.id) throw new Error('No active tab found');
  return await sendMessageToTab(tab.id, message);
};

This makes sure we’re always targeting the currently open webpage, whether it’s to trigger AI processing or capture screenshots.

Listening for Messages

We use React hooks to set up message listeners inside components. This makes handling commands like "START_SCREENSHOT" declarative and efficient:

useMessageListener('START_SCREENSHOT', () => {
  setState('area-picker');
});

This way, the UI updates reactively whenever the popup or background script sends a command.

The Result? A Seamless Experience 🎯

With typed messages, structured commands, and well-defined listeners, our extension avoids race conditions, unexpected behavior, and debugging nightmares. Instead, every part of the extension stays in sync, making interactions smooth and instantaneous. 🚀

5. CRXJS: The Modern Way to Build Chrome Extensions ⚡

If you’re building Chrome extensions with modern web frameworks, CRXJS is a game-changer. It simplifies the development process by integrating seamlessly with Vite, allowing you to use React (or other frameworks) with minimal hassle.

Why CRXJS?

Traditional Chrome extension development often involves complex configurations, dealing with manifest quirks, and managing different extension environments (background, content scripts, popup). CRXJS abstracts much of this complexity while staying lightweight and performant.

✅ Zero-config setup – Works out of the box with Vite.
✅ Automatic bundling – No need to manually manage content scripts and background scripts.
✅ HMR (Hot Module Replacement) for popups & options pages – Develop faster without needing to reload the extension manually.
✅ TypeScript & React support – Makes modern development workflows much easier.

Setting Up CRXJS in Your Project 🚀

To get started, install CRXJS Vite plugin:

npm install @crxjs/vite-plugin -D

Then, configure it in vite.config.ts:

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import { crx } from '@crxjs/vite-plugin';
import manifest from './manifest.json';

export default defineConfig({
  plugins: [react(), crx({ manifest })],
});

This setup ensures that your extension files are properly processed, including background scripts, content scripts, and popup UI.

Efficiency and Simplicity 🏆

With CRXJS, we eliminated the boilerplate, improved the development speed with HMR, and kept our extension lean and maintainable. It’s the perfect tool for modern Chrome extension development, allowing us to focus on building features instead of wrestling with configuration files.

If you're working with React, Vite, or TypeScript, CRXJS is a no-brainer! 🚀

6. Our Journey: How We Built Classmate 🏆

When developing Classmate - AI-powered quiz assistant, we faced all the classic extension challenges:

✅ Ensuring a seamless user experience with React + Vite.

✅ Handling authentication with Supabase.

✅ Managing API calls efficiently with Zodios.

✅ Avoiding Chrome Web Store rejection by keeping permissions minimal.

Through smart architecture choices and the right stack, we turned a simple idea into a powerful AI assistant for online learners. 🚀

Final Thoughts 💡

Chrome extension development is an exciting playground where you can experiment with browser APIs, automation, and AI. Whether you’re building productivity tools, AI-driven helpers, or something entirely unique, there’s no limit to what you can create.

Got an idea? Time to ship it! 🚢💻

From Competitors to Partners – Our 7-Year Journey with DragonHack

Miha Majetič — Thu, 13 Feb 2025 11:51:15 +0000

DragonHack is the longest-running and largest student hackathon, and it challenges over 150 students each year to compete in a 24-hour problem-solving marathon. Last year, the event celebrated its 10th anniversary, and we are proud to have been part of this incredible journey for the past seven years. Looking ahead, we hope our involvement continues for at least twice as long.

24 Hours to Build a Team

Our journey with DragonHack didn’t begin as company partners - we started on the other side, as competitors. For several years, our founding team participated in the hackathon, experiencing firsthand the adrenaline, creativity, and teamwork that define the event.

Each year, we participated in the 24-hour challenge, fueled by energy drinks, coffee and sugar, learning how to tackle projects, solve key problems, and create something presentable for the judging panel. What made it truly unique was how different it was from working on regular college assignments. In a classroom setting, you collaborate within structured guidelines, but at DragonHack, you're thrown into a real challenge with no predefined solutions. It’s an intense, fast-paced environment where you have to test yourself as a team, experience both highs and lows together, and adapt quickly. The atmosphere was electric - a non-stop cycle of brainstorming, problem-solving, and pushing through moments of stress and fatigue. It wasn’t just about completing tasks; it was about taking an idea, developing it under real-world constraints, and presenting it with confidence.

Through these intense hours, we connected as a team, strengthened our problem-solving skills, and built resilience - experiences that proved invaluable when we launched our own company. But above all, it was an absolute blast.

Continuing the Journey as Partners and Mentors

When we founded zerodays, it was a no-brainer to continue our involvement with DragonHack - this time as partners. However, partnership for us wasn’t just about brand visibility or the potential for finding new developers; it was, first and foremost, about mentorship. Having benefitted greatly from the guidance of industry professionals during our time as competitors, we wanted to pass that on to the next generation of hackers.

Every year, at least two members of our team stay with the participants throughout the night, offering advice, technical insights, and support. We see this as an investment not only in young, promising talent but in the broader tech community as well.

Beyond mentorship, DragonHack also brings value to our team and business. It offers long-term brand-building opportunities, the chance to meet potential business partners, and a platform to exchange ideas with other industry experts. In fact, one of the ideas we originally pitched as competitors even evolved into a business venture.

More Than Just an Event

At its core, our continued involvement with DragonHack isn’t just about giving back — it’s about staying connected, sharing knowledge, and, most importantly, having fun.

We are incredibly grateful for the opportunities, experiences, and lessons this event has given us. It has shaped us as individuals and as a company, and we firmly believe it’s an invaluable experience for any young team looking to test their skills, discover how they collaborate under pressure, and explore new possibilities.

Here’s to many more years of DragonHack and to the next generation of innovators, creators, and problem-solvers who will take on the challenge.

🚀 Building an Interactive 3D Rocket Easter Egg with React Three Fiber

Tim Vučina — Tue, 17 Sep 2024 09:16:23 +0000

When we hit 1000 followers on LinkedIn, we knew we had to celebrate in style! Inspired by Vercel's awesome post on Building an Interactive 3D Event Badge with React Three Fiber, we wanted to take that vibe and launch something fun of our own. So, what better way to celebrate than with a 3D rocket Easter egg on our shiny new website, zerodays.dev?

It’s one of those things that’s just fun to build, like the digital equivalent of a fidget spinner, but way cooler. We had a blast working on it, and today we’re going to take you behind the scenes.

Let's get straight into it.

🚀 Table of Contents:

🏁 The Setup
- 🛠️ Tools to Build Our 3D Rocket
- 🎬 Setting Up the 3D Scene
- 🎥 Camera Choice: Why We Went with Orthographic
- 💡 Quick Tip: Handling Events with eventSource
🚀 The Main Actor: Our Interactive Rocket
- Key Features
- Rocket Following Movement: Keeping Track of the Mouse
- 💡 Quick Tip: Handling Events on <group>
- 🚀 Summary - Rocket
💥 Particle System: Fueling the Rocket’s Exhaust
- Key Concepts
- 💥 Summary - Particles
🪨 SpaceRocks: Asteroids with Physics and Splitting
- Key Features
- 🪨 Summary - SpaceRocks
🌌 SpaceEnvironment: Immersive Space Backdrop
- Key Features
- 💡 Quick Tip: Using window.devicePixelRatio for Consistent Shader Rendering
- 🌌 Summary - SpaceEnvironment
🏎️ Performance Boosts: Optimizing for Smooth Rocket Experience
- 🚀 1. Frame Loop Control: "Always" vs. "Demand"
- 🚀 2. Custom useViewportSize Hook
- 🚀 3. Mesh Instancing for Planets
- 🚀 4. Using Refs for Non-Rerender Values
- 🚀 5. General React-Three-Fiber Performance Tips
- 💡 Quick Tip: Canvas Size Limits on Some Devices
🚀 Wrapping it Up: The Final Countdown

🏁 The Setup:

🛠️ Tools to Build Our 3D Rocket

We kept our tech stack lean but powerful to make this Easter egg fly.

React: The core of our interactive UI.
TypeScript: Strong typing to keep our code bug-free.
react-three-fiber: The magic behind our 3D scene, integrating three.js with React.
react-three-drei: Handy helpers for cameras, lighting, and effects.
react-three-rapier: Physics engine for realistic collisions and rocket interactions.

🎬 Setting Up the 3D Scene

The first step was setting up the basic 3D scene for our rocket. We used react-three-fiber to handle rendering the scene inside a React component, along with react-three-drei for some helpers like the camera and lighting. We also integrated react-three-rapier for physics and collision detection.

Here’s a simplified version of the initial setup:

'use client';

import { Canvas } from '@react-three/fiber';
import { OrthographicCamera } from '@react-three/drei';
import { Physics } from '@react-three/rapier';
import Rocket from '@/components/three/rocket';
import SpaceEnvironment from '@/components/three/space-environment';
import SpaceRocks from '@/components/three/space-rocks';

const RocketScene = () => {
  return (
    <Canvas>
      <OrthographicCamera makeDefault position={[0, 0, 0]} zoom={1} />
      <ambientLight intensity={0.4} />
      <directionalLight position={[-30, 100, 0]} intensity={0.8} />

      <Physics gravity={[0, 0, 0]}>
        <Rocket />
        <SpaceRocks />
      </Physics>

      <SpaceEnvironment />
    </Canvas>
  );
};

export default RocketScene;

This sets up our 3D world with:

Rocket: The star of the show.
SpaceEnvironment: A cool space backdrop.
SpaceRocks: Floating space debris that adds extra flair—and danger! The rocket can collide with these rocks, causing them to split apart for a more dynamic and interactive experience.
Lighting: Ambient and directional lights for a cosmic glow.
Physics: Handles collisions and interactions between objects.

🎥 Camera Choice: Why We Went with Orthographic

We chose an Orthographic Camera for our scene because it keeps everything proportional, no matter where the rocket is flying. Since our rocket scene spans the entire page (with height dictated by the scrollable content), an orthographic camera lets us fly the rocket up and down smoothly without any weird perspective distortions. It ensures a consistent, user-friendly experience as you scroll through the page and interact with the rocket.

💡 Quick Tip: Handling Events with `eventSource`

To ensure the 3D rocket scene can still respond to pointer events (e.g., mouse or touch interactions) even when other page content overlays it, we used the eventSource prop in our Canvas component. This tells react-three-fiber where to listen for events. By setting eventSource to the root element (#root), the rocket can receive events while other content layers above it.

Here's how we set it up:

<Canvas
  eventSource={document.getElementById('root')}  // Specifies the DOM element to listen for pointer events
  eventPrefix="page"         // The event prefix that is cast into canvas pointer x/y events
/>

🚀 The Main Actor: Our Interactive Rocket

The rocket is the star of the show—interacting with the environment, responding to mouse movements, and launching across the page. To make it truly dynamic, we used react-three-fiber for rendering and react-three-rapier for physics. Let’s break down the core functionality.

Key Features:

State Machine: Handles the rocket’s different states—idle, launching, following (tracking the mouse), and resetting.
Collision and Physics: Using CapsuleCollider and RoundConeCollider, the rocket can collide with space rocks. Physics also helps simulate rocket movement and impulse on launch.
Hover and Click Interaction: The rocket responds to mouse hover with a scale-up effect, and clicking either launches it or resets its position.
Smooth Movement: The rocket tracks the mouse, using vectors to calculate distance and apply force, while also smoothly rotating to follow its flight direction in useFrame().
Particles: Adds dynamic exhaust particles during the rocket’s movement.

Here’s a key snippet:

const Rocket = memo(() => {
    // Refs and Hooks
    const rocketHovered = useRef(false);
    ...

    // State machine
    const { value: rocketState, transitionTo } = useStateMachine({
      initial: 'idle',
      states: {
        idle: {},
        launching: { onEnter: () => { setTimeout(() => transitionTo('following'), 500); } },
        following: {},
        resetting: { onEnter: async () => { await resetRocket(); transitionTo('idle'); } },
      },
    });

    // Rocket reset logic
    const resetRocket = useCallback(() => {
      ... // Reset rocket position, velocity, rotation
    }, [viewportSize]);

    // Frame logic (executed every frame)
    useFrame((state, delta) => {
      ...
      // Scale the rocket when hovered
      rocketHovered.current
        ? meshRef.current?.scale.lerp(new Vector3(1.1, 1.1, 1.1), delta * 5)
        : meshRef.current?.scale.lerp(new Vector3(1, 1, 1), delta * 5);

      // Execute state-specific logic
      switch (rocketState) {
        case 'idle': resetRocket(); break;
        case 'launching': rocket.applyImpulse(..., true); break;
        case 'following': { ... } // Move rocket towards pointer, apply rotation
      }
    });

    return (
      <group>
        <RigidBody ref={rigidBodyRef}>
          <CapsuleCollider />
          <RoundConeCollider />
          <group
            ref={meshRef}
            onPointerEnter={() => { rocketHovered.current = true; }}
            onPointerLeave={() => { rocketHovered.current = false; }}
            onClick={() => rocketState === 'following' ? transitionTo('resetting') : transitionTo('launching')}
          >
            <RocketModel />
          </group>
        </RigidBody>

        {/* Our own particle effects component of the rocket exhaust clouds */}
        <Particles
          visible={rocketState === 'launching' || rocketState === 'following'}
          objectRef={exhaustMeshRef}
          config={{ ... }}
        />
      </group>
    );
});

Rocket Following Movement: Keeping Track of the Mouse

One of the coolest parts of our rocket is its ability to follow the mouse as it flies through space. This is powered by the useFrame hook in react-three-fiber, which lets us update the rocket's position and rotation every frame. Here's how we handle the rocket's smooth movement and rotation while tracking the user's pointer.

Key Points:

Mouse Tracking: We convert the normalized device coordinates (NDC) from the pointer into viewport coordinates and move the rocket towards that point.
Distance Calculation: We compute the distance between the rocket's current position and the target, using that to apply a force in the correct direction.
Rotation: The rocket smoothly rotates to face the direction it’s moving, giving a realistic flight experience.

Here’s a simplified version of how we achieve this:

useFrame((state, delta) => {
  const rocket = rigidBodyRef.current;
  if (!rocket || !viewportSize) return;

  // Convert pointer coordinates to viewport space
  const x = (state.pointer.x * viewportSize.width) / 2;
  const y = (state.pointer.y * viewportSize.height) / 2;

  // Calculate distance between current rocket position and target
  const currentPos = rocket.translation() as Vector3;
  const targetPos = new Vector3(x, y, currentPos.z);
  const distance = targetPos.distanceTo(currentPos);

  // Apply impulse to move rocket toward target
  direction.current.copy(targetPos).sub(currentPos).normalize().multiplyScalar(delta * 1000 * distance);
  rocket.applyImpulse(direction.current, true);

  // Calculate the rotation angle and smoothly rotate the rocket
  const rotationAngle = Math.atan2(y - currentPos.y, x - currentPos.x);
  targetQuaternion.current.setFromAxisAngle(rotationAxis.current, rotationAngle - Math.PI / 2);
  slerpedQuaternion.current.slerpQuaternions(rocket.rotation(), targetQuaternion.current, 0.08);
  rocket.setRotation(slerpedQuaternion.current, true);
});

💡 Quick Tip: Handling Events on `<group>`

When dealing with three.js and raycasting, it's common to have multiple meshes or submeshes within a <group>. This can result in multiple onClick or onPointerEnter events being fired as each submesh gets hit by the raycaster. To avoid this, we can use e.stopPropagation() to prevent multiple event triggers.

Here’s a quick example:

<group
  name="rocket"
  onClick={(e) => {
    e.stopPropagation(); // Prevent multiple onClick calls

  }}
>
  <RocketModel />
  <pointLight />
  <mesh ... />
</group>

🚀 Summary - Rocket:

State Machine: Controls the rocket's different modes—idle, launching, following (tracking the mouse), and resetting. This ensures smooth transitions between states and interactions.
Physics and Collisions: Using CapsuleCollider and RoundConeCollider, the rocket can collide with objects like space rocks. Physics-based movement and impulse handling ensure realistic responses to collisions.
Mouse Interaction: The rocket grows when hovered over, thanks to scaling effects. Clicking it launches the rocket or resets it to its initial state, adding fun interaction for users.
Smooth Mouse Tracking: The rocket tracks the mouse position smoothly, with calculated forces applied based on the distance to the pointer. It rotates toward the direction it’s moving, giving the feeling of true flight.
Particles: The dynamic exhaust particles follow the rocket, adding visual flair as it launches and moves.

💥 Particle System: Fueling the Rocket’s Exhaust

Our rocket wouldn't feel complete without some epic exhaust particles! We built a custom particle system using three.js for rendering and shader-based control to give it that dynamic look. The system is fairly customizable, allowing us to control everything from particle lifetime to velocity and turbulence.

Key Concepts:

Custom Shader Material: We use a ShaderMaterial to control particle appearance, such as size and color. The fragment shader includes logic to fade particles based on their age.

const ParticleShaderMaterial = new ShaderMaterial({
  uniforms: {
    color: { value: new Color('cyan') },
    pointSize: { value: 1.0 },
    dpr: { value: window.devicePixelRatio },
  },
  vertexShader: `
    attribute float age;
    varying float vAge;
    void main() {
      vAge = age;
      gl_PointSize = ...;
      gl_Position = ...;
    }
  `,
  fragmentShader: `
    varying float vAge;
    void main() {
      float alpha = 1.0 - vAge; // Fade based on age
      gl_FragColor = vec4(color, alpha);
    }
  `,
});

Particle Initialization: Particles are initialized with random positions and velocities, creating a realistic spread for the exhaust. Each particle has attributes like position, age, and size.

function initializeParticles(...) {
  const positions = [], velocities = [], ages = [], sizes = [];
  for (let i = 0; i < count; i++) {
    positions.push(...); // Set initial position
    velocities.push(new Vector3(...)); // Random velocity
    ages.push(-i / emissionRate); // Stagger particle emission
    sizes.push(size + sizeVariance * (Math.random() - 0.5) * 2);
  }
  return { positions, velocities, ages, sizes };
}

Frame Updates: Each frame, we update particle positions based on their velocity and apply gravity and turbulence. As particles age, they fade out and are reset when they reach their lifetime limit.

useFrame((state, delta) => {
  // Update particle position and age every frame
  for (let i = 0; i < config.maxParticles; i++) {
    if (ages[i] >= 1.0) resetParticle(i); // Reset expired particles
    else updateParticle(i, delta);
  }
});

Dynamic Particle Reset: When a particle’s age reaches its limit, it’s reset to a new position, velocity, and age, making it ready for the next emission cycle.

function resetParticle(index) {
  // Reset particle to new random position and velocity
  positions[index * 3] = ...;
  velocities[index] = new Vector3(...);
  ages[index] = 0;
}

Component Structure:

The particle system is rendered as a <points> mesh with buffer attributes for position, age, and size. A custom ShaderMaterial controls particle appearance and behavior.

<points visible={visible} ref={meshRef}>
    <bufferGeometry attach="geometry">
      <bufferAttribute attach="attributes-position" {...positions} />
      <bufferAttribute attach="attributes-age" array={ages} itemSize={1} />
      <bufferAttribute attach="attributes-particleSize" {...sizes} itemSize={1} />
    </bufferGeometry>
    <primitive attach="material" object={ParticleShaderMaterial} transparent />
</points>

💥 Summary - Particles:

Custom Shader Material: We use a ShaderMaterial to manage particle appearance, handling size, color, and fade effects. The particles fade based on their age, providing a realistic exhaust effect.
Particle Initialization: Each particle is randomly initialized with a position, velocity, age, and size. This randomness gives the exhaust a natural spread as the rocket moves.
Frame Updates: Every frame, the system updates particle positions based on their velocity and applies effects like gravity and turbulence. As particles age, they fade out and are reset when their lifetime ends.
Dynamic Particle Reset: When a particle expires, it’s reset with new random properties (position, velocity, etc.), ensuring continuous emission without needing to generate new particles from scratch.
Efficient Structure: The system leverages a <points> mesh with buffer attributes for efficient handling of particle data. The ShaderMaterial manages the rendering and visual effects, keeping everything performant.

🪨 SpaceRocks: Asteroids with Physics and Splitting

The SpaceRocks component brings extra life to our scene by generating asteroid-like rocks that float around and can be split upon collisions. Using Rapier for physics, these rocks bounce around, interact with the rocket, and split dynamically when hit hard enough.

Key Features:

Rock Geometry: Each rock is created using a ConvexGeometry made from random vertices. This results in irregular, rock-like shapes.

const generateRockGeometry = () => {
  const vertices: Vector3[] = [];
  for (let i = 0; i < 50; i++) {
    vertices.push(new Vector3((Math.random() - 0.5) * 3, ...));
  }
  const geometry = new ConvexGeometry(vertices);
  geometry.scale(5, 5, 5);
  return geometry;
};

Rock Splitting: When a rock collides with enough force, it's split into two smaller rocks. The splitting is handled by calculating the intersection points along a defined plane, then generating two new rocks from the original.

const splitRock = (rockGeometry: ConvexGeometry) => {
  const verticesA: Vector3[] = [], verticesB: Vector3[] = [];
  // Split the geometry along a plane
  const plane = new Plane(new Vector3(1, 0, 0), 0);
  const geometryA = new ConvexGeometry(verticesA), geometryB = new ConvexGeometry(verticesB);
  return [geometryA, geometryB];
};

Collision Handling: When a rock collides with the rocket or another object, we compute the force of the collision. If the force is above a threshold, the rock splits.

onContactForce={(payload) => {
  const forceMag = payload.totalForceMagnitude / 100000;
  if (forceMag > 80) handleCollision(key, forceVec); // Only split if the force is strong enough
}}

Rock Generation:

Rocks are randomly positioned and given velocity in a grid. They are assigned attributes like velocity, angular velocity, and the ability to split on collisions.

for (let i = 0; i < 10; i++) {
  const rockId = `${idPrefix}_rock_${i + 1}`;
  rockMap.set(rockId, {
    ref: createRef<RapierRigidBody>(),
    position: gridCells[i],
    velocity: new Vector3((Math.random() - 0.5) * 10, ...),
    geometry: generateRockGeometry(),
    canSplit: true,
    scale: 3 + Math.random() * 4,
  });
}

Component Structure:

Each rock is a RigidBody with properties such as restitution (bounciness) and friction. These rocks interact dynamically, bouncing off the environment and splitting upon impact.

<RigidBody
    ref={rock.ref}
    position={rock.position}
    linearVelocity={rock.velocity.toArray()}
    restitution={0.9} // Bouncy collisions
    friction={0.1}
    onContactForce={(payload) => handleCollision(key, forceVec)} // Handle rock splitting
>
    {/* Hull - Auto-generates mesh collider for convex geometries */}
    <MeshCollider type="hull">
    <mesh geometry={rock.geometry} scale={rock.scale}>
        <primitive attach="material" object={rockMaterial} />
    </mesh>
    </MeshCollider>
</RigidBody>

🪨 Summary - SpaceRocks:

Dynamic Geometries: Rocks are randomly generated with irregular shapes using ConvexGeometry.
Collisions and Splitting: Rocks split into smaller rocks upon high-force collisions, creating dynamic interactions.
Physics Integration: Using Rapier for realistic movement, friction, and bouncy collisions makes the rocks behave convincingly in the scene.

This system adds an extra layer of interactivity and fun as the rocket navigates through space!

🌌 SpaceEnvironment: Immersive Space Backdrop

The SpaceEnvironment component brings a dynamic backdrop to our rocket scene. It includes a starfield and a collection of planets scattered throughout space. Here’s how we built it using three.js, react-three-fiber, and shaders for custom effects.

Key Features:

Dynamic Starfield: Stars are randomly generated in a cylindrical volume (height = pageHeight) and made to twinkle with a custom shader that controls size and opacity. The stars appear to blink and fade, simulating a living, dynamic space scene.

const StarShaderMaterial = new ShaderMaterial({
  uniforms: { color: { value: new Color('white') }, opacity: { value: 0 }, time: { value: 0 }, dpr: { value: 1.0 }},
  vertexShader: `
    varying float vTwinkle; 
    uniform float time;
    void main() {
      vTwinkle = 0.5 + 0.5 * sin(time + position.x * 10.0);
      gl_PointSize = ...;
      gl_Position = projectionMatrix * modelViewMatrix * vec4(position, 1.0);
    }
  `,
  fragmentShader: `
    varying float vTwinkle;
    void main() {
      gl_FragColor = vec4(color, opacity * vTwinkle);
    }
  `,
  transparent: true,
});

Instanced Planets: We use instancing to efficiently render planets at random positions within the space. Each planet has a random color, size, and location, filling the scene with variety.

const planets = useMemo(() => {
  return Array.from({ length: 20 }).map((_, index) => (
    <Instance
      key={index}
      position={getRandomInCylinder(radius, height, innerPadding)}
      scale={Math.random() * 100}
      color={planetColors[index % planetColors.length]}
    />
  ));
}, [radius, height, innerPadding]);

Rotating Space Environment: The entire space environment rotates slowly, making the stars and planets appear to move in the background.

useFrame((state, delta) => {
  environmentRef.current.rotation.y += delta * 0.015;
  StarShaderMaterial.uniforms.time.value = state.clock.getElapsedTime();
});

💡 Quick Tip: Using `window.devicePixelRatio` for Consistent Shader Rendering

When working with shaders that involve point size (like stars in a starfield), it’s crucial to account for varying screen resolutions and pixel densities. By incorporating window.devicePixelRatio, you ensure that your shader adjusts to different screens, maintaining consistent rendering across devices.

Here's how we applied this:

const StarShaderMaterial = new ShaderMaterial({
  uniforms: {
    dpr: { value: window.devicePixelRatio }, // Ensures consistent point size across devices
  },
  vertexShader: `
    uniform float dpr;
    void main() {
      gl_PointSize = gl_PointSize * dpr; // Adjust point size by device pixel ratio
    }
  `,
});

Reminder: Always update the dpr value in your useFrame or relevant hook when screens change, like dragging your window across monitors with different resolutions!

useFrame(() => {
  StarShaderMaterial.uniforms.dpr.value = window.devicePixelRatio;
});

Component Structure:

The stars and planets are rendered inside a <group> element. Stars are rendered using <points>, while planets are created using Instances for efficient rendering.

<group>
  {/* Instanced stars */}
  <points position={[0, 0, 0]}>
    <bufferGeometry>
      <bufferAttribute attach="attributes-position" {...stars} />
    </bufferGeometry>
    <primitive attach="material" object={StarShaderMaterial} />
  </points>

  {/* Instanced planets */}
  <Instances limit={100} material={PlanetMaterial}>
    <sphereGeometry args={[1, 32, 32]} />
    {planets}
  </Instances>
</group>

🌌 Summary - SpaceEnvironment:

Dynamic Starfield: Twinkling stars scattered randomly in a cylindrical space add life to the environment.
Instanced Planets: Randomly positioned and scaled planets provide variety and depth to the scene.
Rotating Environment: Slow rotation of the entire backdrop makes space feel vast and alive.
Smooth Transitions: Stars and planets fade in and out seamlessly when the environment becomes visible or hidden.

This space environment creates an immersive, dynamic backdrop for the rocket's adventure, contributing to the overall feeling of motion and depth in the scene.

🏎️ Performance Boosts: Optimizing for Smooth Rocket Experience

For an interactive experience like our rocket scene, keeping performance top-notch is critical—especially when dealing with 3D rendering and physics calculations. Let’s explore how we squeezed out those extra frames and kept things smooth:

🚀 1. Frame Loop Control: "Always" vs. "Demand"

To prevent unnecessary GPU usage when the rocket isn’t in view, we created a trigger element just below the content on the webpage. This switch toggles the frame loop between "always" and "demand", ensuring the browser only re-renders when needed.

"Always": Used when the rocket is visible (scrolled into view) or animating, ensuring buttery-smooth performance.
"Demand": Used when the rocket is idle and not in view, meaning the scene only re-renders when a specific event occurs.

This technique helps reduce GPU strain and optimizes battery usage for mobile and laptop users.

<Canvas frameloop={isRocketVisibleOrFlying ? 'always' : 'demand'} />

🚀 2. Custom `useViewportSize` Hook

We opted for a custom useViewportSize() hook to track viewport changes without triggering excessive re-renders. While useThree()'s { viewport/size } would cause rerenders on every scroll, we throttle viewport size checks to avoid performance hits.

const useViewportSize = () => {
  const [size, setSize] = useState(null);

  useFrame((state) => {
    if (state.clock.elapsedTime % throttleTime > 0.01) return;

    const { width, height } = state.size;
    if (!size || size.width !== width || size.height !== height) {
      setSize({ width, height });
    }
  });

  return size;
};

🚀 3. Mesh Instancing for Planets

For efficiency, we used mesh instancing to handle the rendering of planets. Instancing allows you to render multiple copies of a geometry while reusing the same material, which drastically reduces the overhead of drawing each individual planet in the scene.

<Instances limit={100} material={PlanetMaterial}>
  <sphereGeometry args={[1, 32, 32]} />
  {planets}
</Instances>

🚀 4. Using Refs for Non-Rerender Values

When dealing with dynamic updates inside the useFrame() loop, we stored frequently changing values (like positions or velocities) in Refs. This way, we can manipulate them directly without triggering component rerenders, which saves CPU cycles.

🚀 5. General React-Three-Fiber Performance Tips

Lastly, we adhered to best practices from the React Three Fiber docs to avoid performance pitfalls. Some of these include:

Avoid excessive use of useFrame() unless absolutely necessary.
Batch updates by using setState() sparingly inside animation loops.
Minimize new object creation inside loops to prevent garbage collection.

For more advanced performance tips, be sure to check out the official React Three Fiber pitfalls guide and performance optimization tips.

💡 Quick Tip: Canvas Size Limits on Some Devices

When working with large canvases, remember that some devices (like Android Chrome and Firefox on Desktop) have size limitations that may not render properly if the canvas height exceeds 4096px. Always account for these limitations and consider dynamic scaling or feature disabling for large viewports!

if (height > 4096 && browserName === 'Firefox' && isDesktop) {
  setSize(null);
  return;
}

By implementing these performance tweaks, we ensured a smooth, immersive experience without bogging down users' devices—whether they’re on mobile or desktop. 🖥️📱

🚀 Wrapping it Up: The Final Countdown

Celebrating our 1,000 followers on LinkedIn with this interactive 3D rocket has been an absolute blast! From building a dynamic, mouse-controlled rocket to adding splitting space rocks, twinkling stars, and performance optimizations—this project has truly been a fun journey.

It’s projects like these that remind us why we love what we do: blending creativity, tech, and a little bit of rocket science (okay, a lot of rocket science). We hope you enjoyed reading about how we put it all together and maybe even picked up a few tips for your own interactive web projects.

Feel free to check out the live rocket Easter egg on zerodays.dev and, of course, keep an eye out for more interactive fun as we continue to build cool things and push the boundaries of what’s possible in web development.

Here’s to the next milestone—and maybe, the next rocket! 🚀

Thanks for reading and following along!

Should Startups Outsource Software Development?

Miha Majetič — Fri, 30 Aug 2024 11:36:15 +0000

"Why would we hire an agency instead of simply employing developers that will work full-time for us?" … is a question we often hear when we pitch ourselves to startups. And it’s a completely valid question! Why would somebody want to pay an outsourced team, when it could be cheaper or easier to have somebody on the inside? But is this really the case?

Who are we?
Firstly, let’s introduce ourselves - we are zerodays, a custom software development team based in Slovenia, with extensive experience in working with startups. They have been a part of our story right from the beginning of our company.

Some of the more notable startups we worked on since the early startup days were for example Astra AI (AI powered math tutor), Proky.io (online platform that connected clients and horeca suppliers) and LlamaJET (pharmaceutical marker for laboratory labware).

Should you outsource?
So do we believe that outsourcing is the right choice for all startups? Well, the answer differs a bit based on the founders - are they themselves a technical founder and do they already have a team or not, and of course based on the industry they operate in, but shortly - yes. Outsourcing the development team is beneficial in each case. We can only speak from experience, but in our work with startups, we've gained valuable insights that make us believe outsourcing to a partner is the best move for startups for multiple reasons:

1. Worked Across Different Niches: An outsourced agency has probably worked in various industries, which means they’ve seen a lot and can quickly adapt to different challenges.

2. Learning from Mistakes and Gaining Knowledge: Outsourced development partners witness the ups and downs of startup life while working with startups, so they know what works and what doesn’t. Additionally, by partnering with an established team, you gain access to extensive knowledge, including valuable resources like code templates that we have crafted for the best performance, which you would otherwise have to develop on your own.

3. Efficient Resource Use: Instead of hiring full-time staff for everything, an agency can cover all your needs with fewer people. For example, providing a third of the time for frontend, backend, and DevOps each month rather than having to hire three separate in-house full-time developers.

4. Flexible Work Model: The startup world is unpredictable, and when work slows down, you don’t have to worry about layoffs with an outsourced development partner. You can just scale back the work, pause it, or ramp it up as needed—whatever works best for you.

5. Agencies Stick Around: Unlike in-house developers who might leave and take their knowledge with them, agencies should ensure that all the expertise stays with your project. Even if someone from the team moves on, the knowledge stays, so you don’t lose any momentum.

6. Faster Turnaround: Agencies usually already have an established team that can get to work quickly, saving you time and costs associated with building your own team from scratch. The shorter learning curve also allows to start projects swiftly, without the delays of assembling and onboarding a new team.

7. Comprehensive Service and Quality: Outsourced partners should focus on finding and training top developers, taking care of all employment aspects, so you can concentrate solely on your product. Finding and onboarding new developers is challenging, but with the right partner, you won’t have to build your dream team - they handle it all for you.

So should startups without tech founders or already established team outsource their software development?
That’s obviously a pretty clear-cut case—it’s easy to see why someone with limited tech knowledge would choose to trust their software development to an outsourced team. These teams bring in experts from different areas of software development, make smart tech decisions, and can even lead the project on their own. So, for all the reasons we’ve talked about, outsourcing is definitely the way to go.

How about startups which have a tech founder/team?
If the startup already has a technical team or founders who take on the main development roles, an agency might not always be the perfect fit. However, there are still some advantages to outsourcing, mainly when it comes to the increase in the amount of work—instead of temporarily employing someone, an outsourced agency can easily cover the spikes for them.

All in all, we can say that outsourcing is the right path for many startups. From extensive experience, to faster turnaround the benefits of having a great development partner who is committed to delivering outstanding results is the key advantage in the volatile startup world. And let’s not forget the most important thing - the passion for work and creating amazing digital products.

If you are looking for a top notch development partner with experience and passion, reach out to us, and let’s make something great together!

This blog was made by the awesome team at zerodays.dev.

How to Translate Your Next.js App in 5 Minutes With Crowdin

Žan Horvat — Wed, 14 Aug 2024 11:00:48 +0000

For the majority of websites using content management systems such as Webflow or WordPress, localization is not an issue, as it can be relatively easily done through the system.

But for custom solutions, such as custom web applications using Next.js or just plain React, this can be quite a pain.

When the client wants to have the product in another language, one of the developers has to open the code and manually translate the strings, as the process is often too technical to be outsourced and fully done by the translators.

Now, imagine having to translate the entire web app into more than one language - simply a buttload of manual work developers don’t have time for.

We decided to see if there are any solutions to this issue on the market, did a bit of research, and decided to try out Crowdin - and we think it’s awesome! It offers:

Support for almost all languages
Integration with 600+ apps (including GitHub integration)
Easy to use UI for translating strings

So for our needs we developed a localization pipeline around Crowdin and wanted to share it with you.

Localization pipeline

In our applications, translatable strings are stored in specific translation files (usually in JSON format). In addition to storing translatable strings in translation files, we usually use some sort of internationalization framework (for example next-i18next for our Next.js applications).

Example of our folder structure:

/project-root 
  /public 
    /locales 
      /en-INTL 
        common.json
      /sl-SI 
        common.json

Example translation file common.json:

{
  "welcome_message": "Welcome to our app!", 
  "login_button": "Login", 
  "logout_button": "Logout"
}

To keep the translation files updated, we use Crowdin CLI to upload the source files and download translations.

Once the strings are available in Crowdin, our clients or dedicated translators work on translating the strings into the target languages within the Crowdin web platform.

After translations are completed, Crowdin's integration with GitHub automates the next step. Crowdin automatically generates a pull request in the project's GitHub repository.

Code example

In this section, we’ll take a look at a step-by-step guide on how to implement the pipeline from the previous section.

Create account and project on Crowdin website
Download Crowdin CLI. If you use macOS, you can easily use Homebrew:

brew install crowdin@4

Configuration file

After installation, you need to configure the CLI to work with your Crowdin project.

You can do this by creating a configuration file (crowdin.yml) in your project's root directory. Configuration file can be created with following command:

crowdin init

After creating the configuration file, set Crowdin credentials. You can find them in the Crowdin Web UI.

'project_id_env': 'CROWDIN_PROJECT_ID'
'api_token_env': 'CROWDIN_PERSONAL_TOKEN'
'base_path_env': 'CROWDIN_BASE_PATH'
'base_url_env': 'CROWDIN_BASE_URL'

The preserve_hierarchy property should be set to true. This ensures that the directory structure of the source files is maintained in Crowdin.

The files section in the configuration file specifies which files should be synchronized with Crowdin. It includes the paths to the source files and their corresponding locations for translated files. If your source language is en-US and translation files are located in /public/locales/<locale>/, the files section should look like this:

- source: '/public/locales/en-US/*.json'
  translation: '/public/locales/%locale%/%original_file_name%'
  dest: '/%original_file_name%'

Let's explain this:

source specifies the pattern for files to be uploaded for translation.
translation specifies where the translated files should be placed locally. %locale% is a placeholder for the target language code.
dest indicates file name of translations.

Uploading/downloading translations from Crowdin

To streamline the process of managing translation files with Crowdin, two custom commands are used: push-i18n and pull-i18n.

We’ll define these commands in the project's package.json file and automate the process of uploading and downloading translation files.

"push-i18n": "crowdin upload sources && crowdin upload translations"

The push-i18n command is responsible for pushing both source files and any existing translations to Crowdin. This command is typically run when you want to update Crowdin with the latest version of your project’s localization files.

"pull-i18n": "crowdin download sources && crowdin download"

The pull-i18n command handles the process of downloading files from Crowdin to your local project. This ensures that you have the most recent translations available in your project.

To use these commands conveniently add them to the scripts section of your package.json file.

To upload your newly updated strings just use push-i18n. To update your local strings with changes from other translators just run pull-i18n.

Conclusion

Crowdin offers a great solution for a painful problem of web app localization. Instead of keeping the work on the developer side, the entire translation process can be done by non-technical team members, through an intuitive dashboard. Numerous integrations and language support are also a plus!

Do you recommend any other localization tools? Let us know in the comments!

This blog and its underlying research were made by the awesome team at zerodays.dev.

Lighthouse vs. PageSpeed Insights: The Lack of Correlation

Žiga Patačko Koderman — Mon, 05 Aug 2024 12:23:00 +0000

What's the problem?

Have you ever run PageSpeed Insights (PSI) on your website only to receive a wildly different performance score than when running Lighthouse via Chrome Developer Tools? Let me show you what I mean:

The overall scores are relatively similar, but there is almost no correlation between the metrics that make them up. This is a problem because you cannot run PageSpeed Insights on your local build of the website, forcing you to publish any changes and test them online, which is slow, inconvenient, and a bad practice. Let's take a look at where the difference between Lighthouse and PageSpeed comes from.

The reason for the discrepancy

PageSpeed uses Lighthouse under the hood, so what is the deal here? Googling this tells you that PageSpeed also includes some real-world data and so on, but this does not address the problem at stake. After some lengthy deep dives into the issue, we found the reason for it here:

PageSpeed Insights run Lighthouse using a relative 4x CPU slowdown.

The fact that it is relative results in a different score based on the device running the benchmark.

You might be tempted to say "just multiply the times here by X to compensate for having a faster computer." However, this won't work. We won't go into the depths of why this is the case beyond saying that those metrics are complex and don't scale in that way. You can find out more here (TBT is perhaps the simplest example of that).

Solution

Let us start by installing the tools we'll need further down the line.

1. Install the Lighthouse CLI

You cannot tweak the CPU slowdown of a Lighthouse simulation through the Chrome Dev Tools. Hence the need for Lighthouse CLI. You can install it using



npm install -g lighthouse

2. Estimate the slowdown factor (optional)

Here we will show how to extract the benchmarkIndex for your device and then calculate an approximate slowdown factor that you need to use. This is the procedure found in the Chrome documentation. However, you will probably need to readjust the slowdown even after that. Therefore, we prefer to skip this step and find a suitable constant using trial and error.

2.1 Extract `benchmarkIndex` from the report

Here is a command that extracts the benchmarkIndex from the report. It presumes that you have jq installed on your system.



lighthouse YOUR_WEBSITE_URL --output=json --chrome-flags="--headless" --form-factor=mobile | jq '.environment.benchmarkIndex'

On a baseline 2021 M1 MacBook Pro, this number is around 2900.

2.2 Convert `benchmarkIndex` into a slowdown estimate

You can use the CPU Throttling Calculator to estimate the slowdown factor you need. For benchmarkIndex 2900, this yields 9.9. However, it later turns out that this is not enough by almost a factor of two.

Let's take a look at why this might be the case. By reverse engineering the website code, we found that this calculator uses a linear estimation based on a few calibrated points. Let's take a look at a chart of their estimation function:

The last calibrated point is around benchmark index 1300, more than two times lower than what a modern laptop is capable of. This explains why the estimated CPU slowdown of around 10 does not produce satisfactory results. In other words, it is not (yet) calibrated in the range that matters to us.

For a baseline 2021 M1 MacBook Pro, the slowdown factor that produces reasonable results sits around 19.

3. Run Lighthouse

You can run Lighthouse with a desired CPU slowdown like this:



lighthouse YOUR_WEBSITE_URL --throttling.cpuSlowdownMultiplier YOUT_CPU_SLOWDOWN --output=html --chrome-flags="--headless" --form-factor=mobile --output-path report.html

and then open up the generated HTML report.

This produces somewhat more relevant results:

The values are not the same, but we should not expect them to be — this is a complex benchmark running on a simulated device, after all. Go ahead and tweak your slowdown factor until it resembles what online PageSpeed Index test is telling you.

Here is a one-liner using a JSON report that also extracts the metrics in question:



lighthouse YOUR_WEBSITE_URL --throttling.cpuSlowdownMultiplier YOUT_CPU_SLOWDOWN --output=json --chrome-flags="--headless" --form-factor=mobile | jq -r '{LCP: .audits["largest-contentful-paint"].numericValue, "LCP Score": .audits["largest-contentful-paint"].score, FCP: .audits["first-contentful-paint"].numericValue, "FCP Score": .audits["first-contentful-paint"].score, SI: .audits["speed-index"].numericValue, "SI Score": .audits["speed-index"].score, TBT: .audits["total-blocking-time"].numericValue, "TBT Score": .audits["total-blocking-time"].score, CLS: .audits["cumulative-layout-shift"].numericValue, "CLS Score": .audits["cumulative-layout-shift"].score, "TOTAL": .categories.performance.score} | to_entries[] | "\(.key): \(.value)"'

It is not the prettiest, but it can be useful.

4. Repeat multiple times

The last thing we wanted to touch on is repeatability. Lighthouse will produce vastly different performance results each run. Therefore, we usually like to run it at least 5 times and compute the averages. This allows us to have a better sense of whether we are moving in the right direction.

The gist here contains a script that does just that for you.

5. Dive deeper

The Lighthouse JSON report contains much more information that the HTML one, so it is worth examining a bit. It contains all the reasons why the webpage might not be performing well. One of the more useful things we found is the largest-contentful-paint-element, which tells you which element you should optimize in order to achieve a better LCP score.

Let's get back to work

Well, now the hard part begins - improving the webpage performance. However, do not forget that Lighthouse is a (very relevant) made-up metric - in reality, you need to optimize your webpage for real-world users. And web crawlers, but we will get into the SEO debate some other time.

This blog post was written by the awesome team at zerodays.dev.

Goodbye Webflow, Hello Our Shiny New Website

Špela Buh — Tue, 23 Jul 2024 06:38:25 +0000

“That's it! I'm done with Webflow! It's been nothing but a nightmare. We're moving to a headless CMS, and we're doing it now. No more wasting time!”... is what could have easily been heard about two months ago in our office, after (yet again) discussing whether to make a move to a headless CMS for our company website or not.

In reality, the discussion was much longer and much more boring to sum up here. But what is true, is that for the past few months we have been working hard to revamp our website after growing frustrated with Webflow, and we finally launched it! So, after completing this strenuous path, we decided to share the journey insights with you.

A short history of what we tried and why it was time to move on.

So, as evident from the title, we of course used Webflow, but we also tried out WordPress, as well as hard coding our website using React and considered a few other alternatives. However, each of these options was in some way too limiting for our needs.

Hard coded website

Took too long to set up.
Difficult to edit content.
Can’t outsource the editing work to a non-technical team.

Webflow

Limited by the selected theme.
It requires more technical understanding than expected - when editing the content, you can easily change something on one page that changes the layout, or some other design aspects on other pages as well. This was at least in part a problem with the theme we were using, but Webflow did not help either.
There are some live preview issues.
Localization was not built-in until very recently.
The customization is very hard and a lot of things were taken out of our hands (performance, fine-grained SEO, lazy loading, etc.).

WordPress

Performance is subpar.
Localization issues in the headless version.
Bottom line: If you are using WordPress as a template it works fine but as a headless CMS it mostly sucks because of subpar API support.

We also considered Squarespace, Wix and Framer, and although it is possible to use them as headless CMS, they are also quite limiting. So we decided to find a suitable headless CMS, meaning we could use Next.js (our beloved framework) for frontend development and develop a completely custom website, but still have a content management system, which allows a relatively simple input and editing of content.

What we were looking for:

Based on our experience we decided to go for a suitable headless CMS for managing the content of a Next.js-based landing page, allowing full customization and seamless integration. Other requirements we had were also support of custom sections or components that emulate a purposely primitive website builder, rich text editor support, user-friendly admin interface, SEO support, multi-user support, media hosting and easy backups and restoring.

We conducted quite an extensive research when it came to choosing the right solution for us. As this was long enough for a whole separate blog post, we decided to post it here:

The Hunt for a Perfect Headless CMS

Žiga Patačko Koderman for zerodays ・ Jul 3

#nextjs #cms #payload #webdev

The solution

In the end, we (web)landed on Payload because of its superb integration with Next.js - our technology of choice for web development.

This approach allows us to:

Have absolute control over performance.
Play around with SEO and analytics on a lower level than with other solutions.
Have a great experience for the content editors.
Build a tailored website including great animations and easter eggs.
Use our favorite libraries and tools along the way (Framer Motion, Tailwind CSS, shadcn/ui among others - take a look at our Next.js template on GitHub).

The results speak for themselves.

Desktop performance

Mobile performance

So far, we are loving it, but what we love even more is the new website, built by our team of talented developers. Check it out!

Here are also some before and after shots, so you can compare the improvement for yourself:

Landing page before:

Landing page after:

About Us page before:

About Us page after:

Visualization of our development process before:

Visualization of our development process after:

Services page before:

Services page after:

Contact form before:

Contact form after:

How Our Infrastructure Supports Last-Minute Studying

Žiga Patačko Koderman — Thu, 04 Jul 2024 08:15:21 +0000

The past few weeks, one of our clients, Astra AI - an AI powered math tutor, has been recording a steep increase in traffic. This makes sense, as in June, students were frantically studying to improve their final grades right before the school year ended and preparing for the Slovenian national high school final exam - Matura.

Although it’s been years since our teachers warned us not to study in the last days and avoid cramming, the data shows that this is still the case. Well, little has changed since our study days (not that we listened to teachers back then either, of course).

But this time we are experiencing this phenomenon from a completely new perspective - intensely studying in the last few days before the exam means a sudden increase in traffic. The chart below represents the number of OpenAI tokens used by Astra per day:

We won’t be sharing the absolute numbers of course, but suffice to say that we believe this to be one of the biggest usages in our region.

This was Astra’s first time through such (admittedly expected) load increase. However, we were fairly confident in our infrastructure and did nothing special in advance to handle this. And in fact no technical issues arose.

Since the peak, we’ve analyzed the logs, reviewed the data, and attributed this to a few key factors:

Some clever load balancing between multiple API keys in order to climb OpenAI's tier ladder.
Great choice of hosting providers allowing for easy elastic scaling, namely:
- Vercel for the Next.js frontend and part of the backend. The killer features for us include autoscaling, CDN and instant rollbacks out of the box 📦.
- Railway.app for the background machinery handling the more complicated requests.
Great choice of monitoring and analytics tools (Sentry, Axiom, Posthog and Uptime Kuma) coupled with amazing Slack integrations that allowed us to iron out any issues way before the traffic spike while the troubling features were still fresh from the oven.

As we could talk about our infrastructure choices for days, we decided to keep this post short and simple but are planning on doing more of a deep dive in one of the future posts, so keep an eye out for that.

This blog post was written by the zerodays.dev team.

The Hunt for a Perfect Headless CMS

Žiga Patačko Koderman — Wed, 03 Jul 2024 06:57:50 +0000

We recently decided to leave Webflow (the reasons why will be further explained in our next blog) and migrate our company website to a headless content management system. For that reason we decided to thoroughly research the options available and select the best solution for us.

🗒️ Requirements (and wishes ✨)

Our main goal was to select a suitable headless CMS for managing the content of a NextJS-based landing page, allowing for full customization and seamless integration. Based on that we developed a list of requirements for the system we wanted, not just for our website, but also for the majority of other landing pages we develop for our clients.

Must have:

Localization support (RTL support in editor is a bonus)
Good integration with NextJS:
Good React integration.
Possible server-side (pre)rendering.
Supports custom sections or components to emulate a purposely primitive website builder.
Rich text editor support.
User-friendly admin interface.
SEO support.
Multi-user support.
Media hosting.
Easy backup and restore.
Good reputation.

Nice to have:

Open source.
Ability to self-host.
Support for drafts and versioning
Live preview inside the content editor.
Admin panel customization options.
A/B testing support.

Other considerations:

Migration challenges from the existing website.
Multi-region hosting and caching (can be done on NextJS side).

Based on those requirements we tested and considered lots of CMS options. Let’s jump straight into why the Payload ended up our first choice.

🥇 The winner - Payload CMS

Reasons for Selection:

Excellent integration with NextJS. Latest version (3.0) is now a part of a NextJS application.
Native localization support where localization can be done per field, instead of only per-block.
Open source and widely used.
Ability to be self-hosted.
Admin dashboard is easy to extend with custom React components.
Easy to extend with custom functionalities since CMS code is co-located with the frontend.
Native TypeScript support.
Live editing preview option.

Cons:

The version 3 that includes all the sweet features we desire is still in beta - this is why we are using it only for our website at the moment and not experimenting on our clients.

🥈 Other CMS systems considered

Below is the list of all the other options we’ve tested. This is not to say that none of those could work for us - Strapi was extremely close too, and others might be best suited for your specific use case.

Strapi

Pros:

Open source.
(Probably) the most popular headless CMS option.
Self-hosted easily.
Official plugin to generate Swagger documentation so NextJS integration is trivial (although generated schema doesn’t include localization parameters).
Native localization support
Customizable admin dashboard.

Cons:

Locales are still separate, when translating content all fields need to be set in all locales instead of preserving some fields (images, slugs, etc.). This might cause some friction for editors.
Poor TypeScript support.

WordPress

Pros: Very popular option, familiarity.

Cons: Requires additional plugins and configuration to achieve full headless functionality. Worse NextJS integration and development experience. Forces you to use different technologies on frontend and backend.

Sanity

Pros: NextJS support, UI editor integration, flexible localization methods.

Cons: No self hosting, high price (per user, per request and bandwidth).

Prismic

Pros: NextJS support, live preview editor.

Cons: No self-hosting, clunky localization (all locales are totally separate), restrictive pricing plans (max 8 locales in platinum plan).

Tina.io

Pros: Simple, developer friendly, has live editing capabilities.

Cons: Poor i18n support, needs to be handled by developers.

Directus

Cons: More a dataset editor than a CMS.

Contentful

Cons: Limited language support without enterprise tier.

KeystoneJS

Pros: Seems inactive, development progress on the official website was not updated since 2022.

Contentstack

Cons: CMS is a minor part of the product. Company’s focus is elsewhere.

Storyblok

Cons: Expensive. Subpar developer experience.

🏁 Conclusion

In the end, Payload took the crown for us. What ultimately sold us on it, was its superb integration with Next.js - our technology of choice for web development.

This blog and its underlying research was made by the awesome team at zerodays.dev.

All Paths Lead To Jira

Žiga Patačko Koderman — Wed, 22 May 2024 07:03:24 +0000

zerodays’ journey through the world of project management tools

Right after we started our company in late 2021, we knew a good project management tool will be absolutely essential for our work, but we had some specific requirements. We do a lot of agency work, developing for multiple different clients at the same time so the tool had to be amazing for cross project planning, as well as enable some type of transparent sharing of the project progress with the client.

Now, almost two and a half years later and with four tools tested in detail, few others considered and most of them tossed, we feel like we finally landed on a good option for us - Jira. But, as this was definitely not a smooth path, we wanted to do an overlook of everything we have tried, why it worked and why not, in hopes it eases the process for anyone else trying to navigate the world of project management tools.

What methodology do we follow?

The methodology we follow of course defines the tools needed for our project management, so let’s start with that. We follow agile principles, but no specific methodology strictly, however, we use Kanban boards. So, we were looking for a tool that would offer us flexible and user-friendly Kanban boards and would allow us to plan as well as track the time spent on various tasks/tickets.

Trying out the Tools

GitHub Issues and Projects

Our first project management tool we took on was GitHub Projects. We knew and loved GitHub Issues from the open source projects and believed that Projects would be the tool that would fit us. However, unfortunately, it left quite a lot to be desired.

What we disliked:

All the project management is connected only to the repository. So if your project exists in two separate repositories (frontend and backend for example), you have to make two separate tickets instead of one and cross linking through the repositories is not a practical solution.
It isn’t really a fit for our office team, as the non-development tasks don’t fit in, and it’s expensive as a project management tool.
Every ticket you create is a draft by default (this isn’t really a deal-breaker on its own, but it definitely makes the user experience a lot less enjoyable).
There is no hierarchy when it comes to tickets, which makes having an overview of the issue timeline, the main issue, the sub issues etc. difficult.
Poor time tracking.

So after a while, we made the decision to move on and try out Clickup 2.0.

ClickUp

ClickUp is advertised as an “all in one productivity platform” which drew us to it. It definitely solved most of the issues we mentioned with GitHub, such as cross project tracking and ticket hierarchy, but unfortunately we still weren’t completely satisfied.

What we disliked:

Firstly, the app had a lot of bugs and issues, which made it difficult to use. For example, often when creating a ticket, it didn’t show up until a couple of minutes later, when two same tickets popped up. Slow loading times were also a common issue.
The layout and organization of the platform was in our opinion a bit cluttered, so the project tracking and overlook of the projects is messy.

We have to mention that the bugs mentioned above are supposedly resolved in the 3.0 version, however as the app didn’t convince us, we decided not to stay aboard, and jumped ship to Notion.

Notion

Notion is an everyday organization tool, combining project management tools with wikis, docs, planning tools, etc. Its customizability and the lure of having one place for the documentation and project management are what convinced us to try it. We used it for most of our development and non-development documentation and tried out two Kanban boards - a free Kanban template offered by the platform, and our own customizable Kanban board. What we liked about the platform was the easy addition of external guests and sharing the projects with people outside of the company, and good tools for non-development related team collaboration.

What we disliked:

Although Notion is quite known to be very customizable for everyday use, it was too limited for our development team. We specifically had issues with the Kanban boards - they were too rigid. Both the template and our own version lacked the ability to move, rename columns, add filters, automatically hide done tickets, etc.
Poor GitHub integration.
Sometimes it doesn't work - some tickets are not saved on the first try and other bugs.
Similar to GitHub - there was no ticket hierarchy, which made the project overlook difficult.
Columns don’t have an option to hide tickets, so it gets cluttered.
Project planning and filter options were quite limited. There was also no option to integrate it with our time-tracking tool.

With enough experience to finally know what we like and what not, we started considering our final move to either Linear or Jira.

Jira

In the end we settled on Jira, because of the configurability of the tool and integrations it offers, specifically with Slack, Figma and GitHub, the last one being absolutely amazing. So far, it solves the majority of the issues we had with other tools, most notably, it is automated where it can be, which makes a more hassle-free user experience for the development team.

What do we still dislike:

Although we love the configurability it offers, it is quite difficult to set up everything - it is confusing, cluttered in different places, and the learning curve is very steep. On the good side, it is only a pain for the admins, not the developers.
It doesn’t really offer good template options. The way around we found is that we have a project that we named template and we then initiate new projects based on it.. The downside is we still have to manually set up filters and settings, so it takes a while. Again, thankfully it is the issue only for the admins.
We had to make our own integration for the time tracking software we use - Clockify. There are some apps that offer some integration, but we wanted time tracking to be synced with Jira’s own time tracking. However, with Jira, we at least had an option to do this ourselves.

Wrapping it up

We also considered Linear and although it seemed to cover most of our requirements, we decided to go for Jira because of the integrations it offers. In all honesty, we have to admit that we might have not considered it enough and will maybe return back to it at some point, but a decision had to be made.

So, here we are at last - Jira. Is this the best solution for eternity? Probably not. But, we are happy at the moment, as we configured it to our specific needs and it doesn’t restrict our developers, while being fairly automated, so the hassle of moving tickets etc. is minimized.

zerodays is a custom software development team based in Ljubljana, Slovenia. We focus on AI development and consulting, web and mobile app development, business digitalization, and process automation solutions. If you’re interested in what we do and want to keep up with us, visit our website or follow us on LinkedIn.

Generative UI in React Native

Žiga Patačko Koderman — Thu, 11 Apr 2024 11:09:47 +0000

Let's build a generative UI Weather Chatbot!

This article is inspired by Vercel's Generative UI. It expands on OpenAI's functions/tools by allowing the model to visualize data to the user.

Let's get straight into it.

Create an Expo Typescript app 📱

npx create-expo-app -t expo-template-blank-typescript demo
cd demo

Install 📦

yarn add react-native-gen-ui zod

This adds the react-native-gen-ui package that offers:

Exposes useChat hook for easy access to OpenAI's completions api.
Supports streaming.
Enables Generative UI via tools.
Is fully type-safe.

The package was initially developed by us at zerodays.dev and was open-sourced for everyone to use.

We also install zod here for validation of tool parameters.

Import dependencies

At the top of the App.tsx add

import { z } from "zod";
import { OpenAI, isReactElement, useChat } from 'react-native-gen-ui';

Initialize OpenAI

Below imports, write:

const openAi = new OpenAI({
  apiKey: process.env.EXPO_PUBLIC_OPENAI_API_KEY!,
  model: 'gpt-4',
});

Then make sure to add EXPO_PUBLIC_OPENAI_API_KEY to your environment or in .env file. You can obtain an API key in the OpenAI Platform.

Utilize `useChat` hook.

At the top of the App function, let's use the useChat hook.

export default function App() {
  const { input, onInputChange, messages, isLoading, handleSubmit } = useChat({
    openAi,
    initialMessages: [
      { content: "You are a nice little weather chatbot.", role: "system" },
    ],
  });

  return <View/>;
}

Here we are passing initial messages into the useChat hook, then allow it to manage the state of messages, stream the content from OpenAI and update the UI.

But we are still missing a way to render this - make the function return the snippet below:

return (
  <View
    style={{
      flex: 1,
      backgroundColor: "#fff",
      alignItems: "center",
      justifyContent: "center",
    }}
  >
    {/* Iterate over all messages and render them */}
    {messages.map((msg, index) => {
      // Message can be either a React component or a string
      if (isReactElement(msg)) {
        return msg;
      }
      switch (msg.role) {
        // Render user messages in blue
        case "user":
          return (
            <Text style={{ color: "blue" }} key={index}>
              {msg.content?.toString()}
            </Text>
          );
        case "assistant":
          // Render assistant messages
          return <Text key={index}>{msg.content?.toString()}</Text>;
        default:
          // This includes tool calls, tool results and system messages
          // Those are visible to the model, but here we hide them to the user
          return null;
      }
    })}
    {/* Text input for chatting with the model */}
    <TextInput
      style={{
        borderColor: "gray",
        borderWidth: 1,
        textAlign: "center",
        width: "100%",
      }}
      autoFocus={true}
      value={input}
      onChangeText={onInputChange}
    />
    <Button
      onPress={() => handleSubmit(input)}
      title="Send"
      disabled={isLoading}
    />
  </View>
);

Then run the app using npx expo start. More details about running an Expo app can be found here.

Voilà - we can have a basic chat with 🤖 now!

Add a tool

Now the real magic begins 🪄. A tool is defined by:

its name,
description (a simple string for model to understand what this tool does),
parameters (a type-safe zod schema of what this tool accepts as arguments) and
a render function for handling what both the user and model see when this tool is called.

Let's add a “get weather tool“ to tell us what the weather is like at a certain location:

const { ... } = useChat({
  ...
  tools: {
    getWeather: {
      description: "Get weather for a location",
      // Parameters for the tool
      parameters: z.object({
        location: z.string(),
      }),
      // Render component for weather - can yield loading state
      render: async function* (args) {
        // Fetch the weather data
        const data = await getWeatherData(args.location);

        // Return the final result
        return {
          // The data will be seen by the model
          data,
          // The component will be rendered to the user
          component: (
            <View
              key={args.location}
              style={{
                padding: 20,
                borderRadius: 40,
                backgroundColor: "rgba(20, 20, 20, 0.05)",
              }}
            >
              <Text style={{ fontSize: 20 }}>
                {data.weather === "sunny" ? "☀️" : "🌧️"}
              </Text>
            </View>
          ),
        };
      },
    },
  },
});

This allows the model to call the getWeather function. The model receives the data and can comment upon it, while the user is presented with an emoji representation of the weather (either ☀️ or 🌧️).

The getWeatherData function is still missing, let's add it:

async function getWeatherData(location: string) {
  // Wait 3 seconds to simulate fetching the data from an API
  await new Promise((resolve) => setTimeout(resolve, 3000));

  // Randomly return either `sunny` or `rainy`
  return {
    weather: Math.random() > 0.5 ? "sunny" : "rainy",
  };
}

The result is a chat interface that goes beyond just words and can display custom components (even though, this is just emojis in our example).

Show loading states

The react-native-gen-ui allows us to yield zero or more components before returning the actual data and the final component. This can be used to display progress to the user until the data is fetched.

Add the following code at the beginning of render:

render: async function* (args) {
  // Yield a loading indicator
  yield <ActivityIndicator key="activity-indicator" />;

  // Fetch the weather data
  ...

The render function is in fact a generator - this is denoted by the * after the function keyword. The interface will always display the last component that was either yielded or returned, allowing us to swap what the user sees over time.

This can be especially useful if the the render function takes a lot of time and has multiple steps. The user can stay informed of whatever is happening in the background. For example, one could pre-render partial information before the entire data pipeline completes.

References

📦 react-native-gen-ui
A minimal example like the one in this post.
A complete weather bot example from the GIF at the top.

This blog post and the react-native-gen-ui package were made by the awesome team at zerodays.dev.

DEV Community: zerodays

From Idea to Reality in 2 Days: Bringing the Hackathon Approach into our Office

Ground Rules

Let’s Start at the Beginning - What To Do?

Let’s Get Crackin’

So Was This the Right Way?

🧩 Beyond the Popup: Crafting Next-Level Chrome Extensions with CRXJS

1. The Magic of Chrome Extensions ✨

2. Choosing Your Stack: The Right Tools for the Job 🛠️

Popular Choices for Extension Development:

3. The Unique Challenges & Superpowers of Extension Development 🔥

The Good: Browser APIs That Supercharge Your Extension 🚀

The Bad: Common Pitfalls & Limitations 😬

The Ugly: Bad Practices That Can Doom Your Extension ❌

4. Bridging the Gap: Messaging Between Popup & Content Scripts 🔄

How We Handle Messaging in Classmate ⚡

Message Structure & Commands

Sending Messages to the Active Tab

Listening for Messages

The Result? A Seamless Experience 🎯

5. CRXJS: The Modern Way to Build Chrome Extensions ⚡

Why CRXJS?

Setting Up CRXJS in Your Project 🚀

Efficiency and Simplicity 🏆

6. Our Journey: How We Built Classmate 🏆

From Competitors to Partners – Our 7-Year Journey with DragonHack

24 Hours to Build a Team

Continuing the Journey as Partners and Mentors

More Than Just an Event

🚀 Building an Interactive 3D Rocket Easter Egg with React Three Fiber

🚀 Table of Contents:

🏁 The Setup:

🛠️ Tools to Build Our 3D Rocket

🎬 Setting Up the 3D Scene

🎥 Camera Choice: Why We Went with Orthographic

💡 Quick Tip: Handling Events with eventSource

🚀 The Main Actor: Our Interactive Rocket

Key Features:

Here’s a key snippet:

Rocket Following Movement: Keeping Track of the Mouse

Key Points:

Here’s a simplified version of how we achieve this:

💡 Quick Tip: Handling Events on <group>

🚀 Summary - Rocket:

💥 Particle System: Fueling the Rocket’s Exhaust

Key Concepts:

Component Structure:

💥 Summary - Particles:

🪨 SpaceRocks: Asteroids with Physics and Splitting

Key Features:

Rock Generation:

Component Structure:

🪨 Summary - SpaceRocks:

🌌 SpaceEnvironment: Immersive Space Backdrop

Key Features:

💡 Quick Tip: Using window.devicePixelRatio for Consistent Shader Rendering

Component Structure:

🌌 Summary - SpaceEnvironment:

🏎️ Performance Boosts: Optimizing for Smooth Rocket Experience

🚀 1. Frame Loop Control: "Always" vs. "Demand"

🚀 2. Custom useViewportSize Hook

🚀 3. Mesh Instancing for Planets

🚀 4. Using Refs for Non-Rerender Values

🚀 5. General React-Three-Fiber Performance Tips

💡 Quick Tip: Canvas Size Limits on Some Devices

🚀 Wrapping it Up: The Final Countdown

Should Startups Outsource Software Development?

How to Translate Your Next.js App in 5 Minutes With Crowdin

Localization pipeline

Code example

Configuration file

Uploading/downloading translations from Crowdin

Conclusion

Lighthouse vs. PageSpeed Insights: The Lack of Correlation

What's the problem?

The reason for the discrepancy

Solution

1. Install the Lighthouse CLI

2. Estimate the slowdown factor (optional)

2.1 Extract benchmarkIndex from the report

💡 Quick Tip: Handling Events with `eventSource`

💡 Quick Tip: Handling Events on `<group>`

💡 Quick Tip: Using `window.devicePixelRatio` for Consistent Shader Rendering

🚀 2. Custom `useViewportSize` Hook

2.1 Extract `benchmarkIndex` from the report

2.2 Convert `benchmarkIndex` into a slowdown estimate

Utilize `useChat` hook.