DEV Community: Meursyphus

My AI Tests Passed While Half the Mutants Went Undetected

Meursyphus — Tue, 10 Nov 2026 00:34:17 +0000

If someone asked me how I verified code written by AI, I used to have a simple answer: I ran the tests.

My project had 451 tests across 84 files. Claude Code had written them, and I had reviewed and merged them. A green test run felt reassuring.

Then a friend mentioned mutation testing. I tried it on ten files in src/lib that already had tests. The tool generated 550 small changes to the production code and checked whether the tests noticed.

Scope	Mutants	Killed	Survived	No coverage
Ten tested files in `src/lib`	550	273	161	116

The tests caught 49.6% of those mutants. Another 161 survived despite running tests, and 116 had no test coverage.

That does not mean half of my 451 tests were worthless. It means roughly half of the generated mutations in this sample went undetected. That was enough to make me inspect what the tests actually asserted.

Some tests only checked the source text

Here is an excerpt from my project, with the test description translated:

function source(relativePath: string): string {
  return readFileSync(
    fileURLToPath(new URL(`../${relativePath}`, import.meta.url)),
    'utf8',
  )
}

it('separates new time credits from the legacy user baseline', () => {
  const codingTimeRepository = source(
    'src/server/repository/coding-time-credit/index.ts',
  )

  expect(codingTimeRepository).toContain('userCodingTimeCreditLedger')
  expect(codingTimeRepository).not.toContain('projectId')
})

This reads a file as a string and checks for words. It does not execute the credit calculation or verify its result.

I found 62 tests like this across seven files. They can enforce a convention, but they cannot establish that the program behaves correctly. The implementation could return the wrong value while those checks stay green.

Other patterns deserved a closer look too:

Copying the implementation's current output directly into the expected value, without checking whether that output matches the requirement.
Reimplementing the production algorithm inside the test to calculate the expected result.
Checking only that a mock was called. My project had 139 toHaveBeenCalled() assertions; the useful question was what each one established about behavior.
Treating test-file count or coverage as proof that important decisions have assertions.

None of this is unique to AI. But when the same agent writes the implementation and its tests in one session, both can inherit the same misunderstanding.

A 2026 study, All Smoke, No Alarm, examined 86,156 test-file patches from 33,596 agent-authored pull requests. Its syntactic classification found weak or absent explicit oracle signals in 80.2% of patches. That is a result about observable assertion patterns in that dataset, not proof that 80.2% of all AI tests are useless. It does reinforce why counting tests is a poor substitute for inspecting their checks. Study

Mutation testing checks whether a change makes a test fail

A mutation tool changes the production code in small ways: replacing < with <=, changing + to -, forcing a condition to false, or replacing a return value.

Each modified version is a mutant. The tool runs the relevant tests against it.

Result	Meaning
Killed	At least one test failed with the mutation active
Survived	The tests still passed
No coverage	No test covered the mutated code

These are the three results I focused on. Tools also report timeouts, invalid mutations, and other states. Stryker's overall score counts detected mutants against valid mutants; its covered-code score uses a different denominator. Stryker states and metrics

Consider this function:

function isUserOldEnough(user: { age: number }) {
  return user.age >= 18
}

If a mutant changes >= 18 to > 18, tests using ages 17 and 19 still pass. A test for exactly 18 can distinguish the two implementations.

Coverage can tell me that a test executed the comparison. Mutation testing helps me find whether the assertion notices a meaningful change to it.

Eleven tests missed six boundary changes

My first run used StrykerJS with Vitest in a Next.js project. The configuration was small:

{
  "testRunner": "vitest",
  "plugins": ["@stryker-mutator/vitest-runner"],
  "mutate": ["src/lib/**/*.ts"],
  "disableTypeChecks": false,
  "incremental": true,
  "reporters": ["clear-text", "html"]
}

With Stryker and its Vitest runner installed and the test configuration available, I ran:

npx stryker run

That initial run took 1 minute and 5 seconds in my project.

The disableTypeChecks: false setting kept Stryker from inserting its usual @ts-nocheck directives. It did not make Vitest perform TypeScript checking; type validation still needs its own checker or command. Stryker configuration

The most memorable result came from kstRelativeTime, a utility that produces labels such as “just now,” “three hours ago,” and “yesterday.” Eleven tests exercised it. All six mutants that changed < to <= survived.

I had tests around the date boundaries, but not at the boundaries. None asked what should happen at exactly 48 hours. A branch that produced a number of weeks had no coverage at all.

Other results were harder to ignore:

Changing + 1 to - 1 in a sequence number used for concurrent editing still passed.
Replacing if (local === remote) with if (false) in text-merging logic still passed.
The Markdown image parser killed only six out of 109 mutants.

Every one of those files already had tests. The CI result was green.

The source-text tests caused a different problem. Instrumentation changes the source file, so tests that inspect its literal text can fail because the tool inserted scaffolding. I excluded those tests from the mutation run. I wanted failures caused by changed behavior, not by the instrumentation's spelling.

Why this matters when agents write tests

Tests give a coding agent feedback. Weak assertions can tell the agent that it has finished even when an important behavior remains unchecked.

Mutation testing provides a more specific follow-up than “write more tests.” I can point to a surviving change and ask what input would distinguish the original behavior from the mutated behavior. Then I can review whether that expected result actually follows from the requirement.

Meta's Automated Compliance Hardener uses a related approach at a different scale. It generates concern-specific mutants with an LLM, then generates tests to catch faults that the existing suite misses. The reported deployment produced 9,095 mutants and 571 tests; engineers accepted 73% of tests in its Messenger and WhatsApp test-a-thons. The useful idea is that a new test can improve fault detection even when it exercises lines that existing tests already cover. Meta paper

The agent can help improve the tests, but I still need to decide what the program should do. Otherwise it can simply encode the same wrong assumption more thoroughly.

Keep the feedback close to the change

The obvious concern is runtime. A naive process that runs a five-minute suite for each of 1,000 mutants would take about 83 hours.

Modern tools avoid much of that repetition. Stryker can select tests using per-test coverage, and incremental mode reuses previous results where appropriate. That makes a small run on relevant logic a different proposition from mutating an entire repository every time. Stryker configuration, incremental mode

For Comwit and its project template, I adopted a few practical rules:

Start with application logic: utilities, server logic, APIs, and state. I excluded pages, routing, UI components, and database schemas from this particular setup.
Run mutation tests on changed files during normal work. Use a broader run occasionally to establish a baseline.
When an agent changes tests, have it run the changed-file mutation command and inspect survivors.
Review survivors by cause. A boundary change suggests an exact-value test; a skipped branch suggests a missing input path. Equivalent behavior or irrelevant logging changes need a different decision.

The command in my repository is pnpm test:mutation:changed. It is a project-specific script, not a built-in Stryker command.

I also ran a larger baseline: 902 logic files, 41,343 mutants, and about 49 minutes in my environment.

Area	Total mutants	Covered mutants	Survived	Score on covered mutants
All targeted logic	41,343	10,230	3,799	62.9%
`src/server/repository`	12,516	5,121	2,021	60.5%
`src/server/domain-jobs`	2,490	1,084	459	57.7%

The denominator matters. The 62.9% figure describes the covered mutants, not all 41,343 generated mutants. Only about a quarter of the generated mutants had coverage, and more than a third of those covered mutants survived.

Those numbers gave me places to investigate. They did not give me a reliable estimate of how many production bugs the application had.

The score is a prompt to investigate

A surviving mutant is not automatically a missing requirement. Some mutations leave observable behavior unchanged. Those equivalent mutants cannot be killed by a test that correctly checks the same behavior.

Mutation testing also cannot prove that the implementation matches the intended specification. It checks sensitivity to the generated changes. A test suite and implementation can agree with each other and still agree on the wrong behavior.

That is why I do not want the mutation score to become a team KPI. It would be easy to optimize the number and miss the reason for running the tool.

I still ask AI to write tests. What changed is the next question I ask: if this code were slightly wrong, which test would notice?

In my first run, one minute of mutation testing gave me a much more useful review queue than another reassuring green check.

I build Comwit, where this workflow is part of the project template. Adapted from my original Korean article on Velog, published October 7, 2026.

Contact: X @meursyphus.

Why Next.js Navigation Feels Slow Even When the Server Is Fast

Meursyphus — Tue, 10 Nov 2026 00:30:32 +0000

I used Next.js for a while before I could explain why clicking a link sometimes did nothing for a moment.

The server was not doing anything especially expensive. The browser already had plenty of JavaScript. Yet the next screen still waited for a network round trip.

The missing piece was the React Server Component payload for the destination route. Understanding when Next.js fetches that payload, and which parts it can reuse, made the delay much easier to explain and fix.

This is the first article in my Next.js performance series. The examples cover the App Router, the older route-level caching model, and the cacheComponents and partialPrefetching options available in Next.js 16.3 and later.

The browser needs more than JavaScript

In a client-rendered application, the browser can render a destination screen as soon as it has the relevant JavaScript. Data may still be loading, but the application can show its own loading UI immediately.

Server Components change what the browser has available. Their implementation stays on the server. The browser receives their rendered output through the RSC payload, alongside references to Client Components and the props those components need.

That payload is a serialized representation of the component tree. It is not simply an HTML document, and it is not the source code of the Server Components.

Here is a small example:

// app/posts/page.tsx
import { LikeButton } from './like-button'

export default function PostsPage() {
  return (
    <main>
      <h1>Posts</h1>
      <LikeButton />
    </main>
  )
}

// app/posts/like-button.tsx
'use client'

import { useState } from 'react'

export function LikeButton() {
  const [liked, setLiked] = useState(false)
  return (
    <button onClick={() => setLiked(!liked)}>
      {liked ? 'Liked' : 'Like'}
    </button>
  )
}

PostsPage is a Server Component even though it has no async, await, or database query. App Router pages and layouts are Server Components by default. The 'use client' directive establishes a client boundary; components imported through that boundary belong to the client module graph.

For navigation, I find it useful to imagine that the browser has part of the destination tree, with spaces that need the server's output. The important question is whether that output arrives before or after the click.

If the required payload is missing, navigation may wait for the server. A prefetched loading boundary or static shell can still provide immediate feedback, so the presence of a Server Component alone does not make every transition slow.

What Link prefetching actually does

Next.js can fetch route data before navigation. In production, a <Link> entering the viewport normally triggers prefetching. The browser can then reuse the payload when the user clicks. Automatic prefetching is disabled in development, so next dev is not a useful way to judge its production behavior.

Before enabling Partial Prefetching, the default behavior differs by route:

Destination	Default prefetch behavior
Statically rendered route	Prefetch the full route
Dynamically rendered route	Prefetch down to the nearest `loading.js` boundary, when available

prefetch={true} requests a fuller prefetch, including for dynamic routes under the older model. It can reduce the wait after a click, but it also does more server work before the user decides to visit. With Partial Prefetching enabled, the rules change again: default prefetching focuses on the shared App Shell. Next.js Link reference

The basic sequence is:

Link becomes visible
  → fetch reusable route content
  → keep it in the browser's Client Cache

User clicks
  → render the cached content
  → request anything still missing

Moving work before the click can matter more to perceived speed than shaving a few milliseconds off the server render.

Dynamic segments and dynamic rendering are different

The word “dynamic” causes a lot of confusion here.

A folder such as posts/[slug] defines a dynamic URL segment. It does not, by itself, mean that every visit requires request-time rendering. generateStaticParams can provide values that Next.js prerenders.

Dynamic rendering means rendering at request time. In the previous caching model, reading request-specific values such as cookies() or headers() opts a route into dynamic rendering. That can happen deep inside a component tree.

Imagine a mostly static article page with a small personalized control:

Article page
├─ Article title
├─ Article body
└─ Personal controls
   └─ reads cookies()

Without Cache Components or another partial-prerendering setup, that request-specific read affects the route's rendering mode. The title and body may be easy to render, but the route no longer has one completely static response that can serve every request. Cached data and shared layouts can still be reused; “dynamic” does not mean every cache disappears. Next.js previous caching model

Suspense helps only when its fallback is available

Wrapping the personalized control in <Suspense> lets the server stream the surrounding content and fallback before the slow part finishes.

But in the previous model, an ordinary Suspense boundary inside a dynamic page does not automatically turn everything around it into a build-time shell. The browser may still need the first server response before it knows what to render.

Click
  → request the destination payload
  → first response arrives
  → show surrounding content and fallback
  → stream the remaining content

A prefetched loading.tsx boundary can make the initial transition feel immediate. A fallback that exists only in an unfetched destination payload cannot do that yet. This is the distinction I was missing when I thought, “I already use Suspense, so why does navigation still pause?” Next.js instant navigation guide

Network distance makes the difference obvious. While hosting one of my services on Cloudflare, I sometimes saw traffic from Korea reach Los Angeles or Hong Kong. Even a quick server render could not eliminate that round trip.

Read staleTimes as page reuse rules

The experimental staleTimes configuration controls reuse of page segments in the Client Cache:

// Defaults in the previous caching model
const nextConfig = {
  experimental: {
    staleTimes: {
      dynamic: 0,
      static: 300,
    },
  },
}

export default nextConfig

The names are easy to read too literally. The dynamic interval applies to pages that are neither statically generated nor fully prefetched. The static interval also applies to fully prefetched pages. Loading boundaries use the static interval, shared layouts can remain reusable, and browser back/forward navigation has its own caching behavior.

So dynamic: 0 does not mean “Next.js never keeps anything from a dynamic route.” It explains one particular reason an ordinary revisit may request the page segment again. The default changed from 30 seconds to zero in Next.js 15. Next.js staleTimes reference

Cache Components gives the page a reusable shell

With Cache Components, Next.js can prerender a shell while leaving request-specific content behind Suspense boundaries:

// next.config.ts
const nextConfig = {
  cacheComponents: true,
}

export default nextConfig

That gives us a different navigation sequence:

Before the click
  → prefetch the static shell and its fallbacks

After the click
  → show that shell immediately
  → stream request-specific content into it

I now place a boundary around the part that actually needs request-time information, rather than assuming the whole page must wait.

Enabling the flag also changes how the application expresses caching. Reusable work can use 'use cache'; uncached work that should stream needs an appropriate Suspense boundary. Existing applications may need more than a configuration change to adopt this model. Next.js caching guide

I learned that through an awkward migration. With Next.js 16.2 on Cloudflare/OpenNext, I turned the option on and off while working through middleware compatibility, authentication reads in layouts, and transition behavior. I eventually enabled it after changing hosting. That experience made me treat this as an application migration, not a free performance switch.

There is also a lifecycle detail to check. Next.js can preserve recently visited screens with React Activity. Activity hides DOM and preserves state while cleaning up Effects. Code that assumes leaving a route always destroys its DOM may need attention, particularly media elements and other work tied to the DOM itself. React Activity reference

Partial Prefetching shares the shell across URLs

Next.js 16.3 introduced another opt-in flag:

const nextConfig = {
  cacheComponents: true,
  partialPrefetching: true,
}

export default nextConfig

An article list might link to /posts/1, /posts/2, and /posts/3. Those URLs can share the same structural shell even though the article content differs. Partial Prefetching lets Next.js reuse that App Shell across links to the same route pattern, instead of treating each URL as a completely separate prefetch target. Next.js 16.3 announcement

Where we read URL-specific information matters. Awaiting params at the top of a page ties more of the render to that particular URL. Passing the promise down and reading it inside a Suspense boundary leaves more URL-independent UI in the shared shell.

The default prefetch then brings in the shell; URL-specific content can stream after navigation. If a particular link deserves more eager work, prefetch={true} can also prefetch cached content that depends on its URL. It is a tradeoff between earlier work and faster transitions. Adopting Partial Prefetching

Service workers need a separate caching design

I also use Serwist to persist selected resources beyond the browser's in-memory route cache. Static assets are an obvious starting point. Persisting RSC responses is much more sensitive because their representation can depend on request headers, route state, deployment, and authentication.

My original implementation used Next.js response headers to distinguish responses and applied custom cache rules. I would not treat that snippet as a general recipe for other applications. Removing _rsc from cache keys or caching personalized responses without preserving the relevant distinctions can reuse the wrong response.

For most applications, I would first get framework prefetching and the App Shell right, then add a service worker only for a specific offline or persistence requirement. Next.js CDN caching guide, Serwist

A list already contains part of the detail page

The last improvement in my application came from the screen design.

When someone opens an item from a list, the browser already knows its title, thumbnail, and summary. Replacing all of that with a full-page spinner throws away useful information.

For the showcase in my service, I use Intercepting Routes to distinguish two ways of reaching the same URL:

Entry path	What the user sees
Navigation from the list	Show the cached summary immediately, then fetch the remaining detail
Direct visit or refresh	Render the full detail through the normal server route

The intercepted route uses the list's existing client state as initial content. If there is no matching summary, it falls back to a skeleton. The regular route handles server data loading and metadata for direct visits.

Intercepting Routes provide the routing distinction; the shared client state provides the instant content. They do not, by themselves, guarantee a navigation without any RSC request. Next.js Intercepting Routes

Start with the delay after the click

I still like Next.js. These changes came from using it in Comwit, the service I build, and wanting the navigation to feel better.

When a transition feels slow, I now look at three things: what the browser already has, what it still needs from the server, and what it can show while that request is in flight.

A Server Component does not automatically make navigation slow. Waiting until the click to obtain the UI needed for the next screen is what I look for first.

Adapted from my original Korean article on Velog, published September 27, 2026.

Contact: X @meursyphus.

I made awesome react apps with transition aniamtion

Meursyphus — Mon, 04 Aug 2025 03:08:08 +0000

https://ssgoi.dev/demo

you can see it on mobile phone. It makes animation when navigating other pages

🚨 Still Manually Handling Complex Web Graphics?

Meursyphus — Sat, 21 Jun 2025 16:27:06 +0000

Are you still wrestling with manual calculations, text wrapping, drag-and-drop events, and endless revisions when handling complex web graphics? Are hundreds of lines of code driving you crazy every time there's a small change?

Meet Flitter(https://flitter.dev), your game-changing solution!

😫 Everyday Developer Struggles, Familiar?

Imagine the frequent scenario at a startup meeting:

"We need a workflow editor, something like Figma—nodes you can drag and connect."

Developers panic:

"Using D3.js, that's easily three weeks of work..."
"SVG? Canvas? How will we handle automatic text wrapping?"

Say goodbye to these headaches with Flitter!

🥳 Flitter Magic: Just a Few Lines of Code

Long text wrapping and centering seamlessly:

Here's the only code you need:

Center({
  child: Container({
    width: 200,
    child: Text("Long text automatically wraps and centers", {
      textAlign: TextAlign.center,
    })
  })
})

Declarative code—clear and intuitive
Automatic cursor handling and drag interactions

No more coordinate calculations!

🔥 Unique Advantages of Flitter

🚀 Dual Rendering System (SVG + Canvas)

SVG: SEO-friendly, selectable text
Canvas: High performance, smooth interactions

💡 Server-side Rendering + Canvas Hydration

Rapid initial load with smooth interactions right from the start.

<Widget
  renderer="canvas"
  ssr={{ size: { width: 800, height: 600 } }}
  widget={...}
/>

❌ Still Using Other Libraries?

Library	Issues
D3.js	Manual calculations (coordinates, dimensions…)
Konva.js	Difficult complex layouts
Fabric.js	Limited UI capabilities
Paper.js	Only suitable for vector graphics
Three.js	Overkill for 2D UI

🎯 Flitter Simplifies Everything!

Column({
  children: [
    Text("Title", { style: headerStyle }),
    Container({
      padding: EdgeInsets.all(20),
      decoration: new BoxDecoration({
        color: '#F3F4F6',
        borderRadius: BorderRadius.circular(8)
      }),
      child: Row({
        mainAxisAlignment: MainAxisAlignment.spaceBetween,
        children: [/* Easily implemented layouts */]
      })
    })
  ]
})

👨‍💻 Flutter Developers, You're Already Experts!

Flitter shares nearly identical syntax with Flutter—instant onboarding!

// Flutter code
Container(
  padding: EdgeInsets.all(16),
  child: Text("Hello Flutter"),
)

// Flitter code
Container({
  padding: EdgeInsets.all(16),
  child: Text("Hello Flitter")
})

🎖️ Proven in Real-world Projects

📌 EasyRD – ERD Diagram Editor

Seamlessly handle over 100 nodes.

Visit on GitHub

📌 Headless Chart – Customizable Charts

Easier than D3.js, more flexible than Chart.js.

🚩 Who Should Use Flitter?

SaaS teams regularly developing complex UIs
Teams frequently building node editors and workflows
Data visualization teams needing custom charts
Teams tired of complexity in existing graphic libraries
Teams with Flutter developers

🚀 Get Started Right Now!

npm install @meursyphus/flitter

Just one command to start!

Check out the next page for detailed usage and examples.

"Performance Has Improved!" Can You Really Prove It?

Meursyphus — Tue, 10 Dec 2024 12:25:31 +0000

Every frontend developer has experienced this situation:
"I optimized this part, and it definitely feels faster!"
"Hmm... I don't really notice much difference in my environment."

When you open Chrome DevTools and try to measure performance:

The hassle of opening the tools and clicking Record every time
Measurement environments vary with browser cache, CPU state, network conditions
Sharing performance improvement results with colleagues through screenshots
Difficulty tracking whether performance degrades over time

As a result, we end up saying performance has improved based on "feeling."
However, true performance optimization should be provable with objective metrics.

In this article, we'll explore automated performance measurement methods to:

Collect objective performance data in a consistent environment
Track performance changes over time
Establish performance metrics that the entire team can share

💡 Pro Tip: While Chrome DevTools' Performance panel is a powerful tool, it has limitations with manual measurement. Through automation, we can overcome these limitations while still utilizing DevTools' analysis capabilities.

Scientific Experimentation: Reliable Performance Measurement Methods

Did you know you can control Chrome DevTools' Performance panel programmatically?
Using Playwright, you can automate performance measurements through browser automation.

Getting Started with Automated Performance Measurement Using Playwright

test('Capture performance traces', async ({ page, browser }) => {
    // Start Chrome trace recording
    await browser.startTracing(page, {
        path: `./traces/${formatDate(new Date())}.json`
    });

    // Load page and perform actions
    await page.goto('http://localhost:4173/performance-test');
    await page.click('button#start');

    // Record performance measurement points
    await page.evaluate(() => {
        window.performance.mark('Perf:Started');
        window.performance.mark('Perf:Ended');
        window.performance.measure('overall', 'Perf:Started', 'Perf:Ended');
    });

    // End measurement and save results
    await browser.stopTracing();
});

However, measuring just once isn't enough.

💡 A Habit from Physics Lab Days
"Remember, everyone! One measurement is no measurement!"

This is a habit ingrained from writing physics lab reports. 😄
I still vividly remember that measurement error is inversely proportional
to the square root of the number of repeated measurements.

Scientific Approach to Performance Measurement

Applying principles learned from physics experiments to web performance measurement:

Importance of Repeated Measurements
- Standard error decreases by 1/√n as the number of measurements (n) increases
- With 50 repetitions, error rate reduces to about 1/7 compared to a single measurement
Strict Control of Variables
- Just like controlling temperature and humidity in a lab
- Essential to control browser cache, memory state, CPU load
- Must consider V8 engine's JIT compiler optimizations

Complete Code for Reliable Measurements

test('Scientifically measure performance', async () => {
    const results = [];
    const REPEAT_COUNT = 50;  // Sufficient repetitions for reliability

    for(let i = 0; i < REPEAT_COUNT; i++) {
        // Control variables: fresh browser environment each time
        const browser = await chromium.launch({
            args: ['--no-sandbox', '--disable-dev-shm-usage']
        });
        const page = await browser.newPage();

        await browser.startTracing(page, {
            path: `./traces/trace_${i}.json`
        });

        // Performance measurement
        const result = await measurePerformance(page);
        results.push(result);

        await browser.stopTracing();
        await browser.close();  // Reset browser state
    }

    // Statistical analysis of results
    const stats = calculateStats(results);
    console.log(`
        Average: ${stats.mean}ms
        Standard Deviation: ${stats.stdDev}ms
        95% Confidence Interval: ${stats.confidenceInterval}ms
    `);
});

The Pitfall of JIT Compiler: Code Gets Faster with Execution

Here's an interesting case I encountered:

// ❌ Incorrect measurement method: repeated measurements without browser restart
test('Without browser restart', async ({ page }) => {
    const results = [];
    for(let i = 0; i < 50; i++) {
        const startTime = performance.now();
        await runPerformanceTest(page);
        results.push(performance.now() - startTime);
    }
    console.log('Execution time changes:', results);
});

The results showed:

First 10 runs average: 450ms
Middle 10 runs average: 380ms
Last 10 runs average: 320ms

Why does this happen?
It's because the V8 engine's JIT compiler learns execution patterns and optimizes the code. In other words, the same code gets faster with repeated execution.

// ✅ Correct measurement method: restart browser each time
test('With browser restart', async () => {
    const results = [];
    for(let i = 0; i < 50; i++) {
        const browser = await chromium.launch();
        const page = await browser.newPage();

        const startTime = performance.now();
        await runPerformanceTest(page);
        results.push(performance.now() - startTime);

        await browser.close();
    }
    console.log('Execution time changes:', results);
});

The results showed:

First 10 runs average: 445ms
Middle 10 runs average: 442ms
Last 10 runs average: 448ms

💡 Pro Tip:
JIT compiler optimizations do occur in production environments.
However, the goal of performance measurement is to obtain a baseline value,
so we should measure in an environment without these optimizations.

A physics major turned frontend developer applying experimental methodology...
Who would have thought? 😄 Now, let's dive deeper into analyzing Chrome Trace Reports.

Analyzing Chrome Trace Reports

The Challenge: Flitter's Performance Optimization

I was developing the Flitter visualization framework and felt the need for performance optimization. Flitter uses SVG and Canvas to visualize dynamic data, providing various animations and interactions. While these features enrich data representation, they also cause performance overhead.

For example, when data changes, requestFrameAnimation is repeatedly called to redraw SVG elements. Although we optimized the callback function to trigger only once, we didn't realize that calling requestFrameAnimation itself has a cost. This wasn't noticeable in normal cases but caused performance degradation when rendering complex UI repeatedly (e.g., mouse dragging).

To solve this issue, we initially tried to track the execution time of specific functions and optimize animation routines. However, we couldn't confidently prove the effectiveness of performance improvements based on subjective feelings.

"We need a systematic way to record JavaScript execution time and scientifically verify optimization results!"

This conclusion led us to adopt automated performance measurement using Chrome Trace and Playwright.

Collecting Performance Data with Chrome Trace Reports

Chrome Trace Reports record all major events that occur while the browser executes JavaScript code, allowing us to see how much CPU and memory each event consumes. This is particularly useful for analyzing JavaScript function calls and execution times.

Why Use Chrome Trace Reports?

The biggest advantage of Chrome Trace Reports is being able to see the entire function call stack and execution time of each function at a glance. This allows quick identification of specific functions or repetitive code that burden performance. Especially in visualization frameworks like Flitter that interact with multiple elements, finding specific routines that cause performance load is crucial, and Chrome Trace is very helpful in solving these issues.

Automating Chrome Trace with Playwright

Playwright is a useful tool for automating performance measurements in browser environments and can collect performance data in conjunction with Chrome Trace Reports. With Playwright, you can easily save Trace Reports that track events occurring in the browser. The example code below shows how to record performance data from a specific point and save it as a JSON file.

test('Capture performance traces and save JSON file when diagram is rendered', async ({ page, browser }) => {
    // Start Chrome trace recording
    await browser.startTracing(page, {
        path: `./performance-history/${formatDate(new Date())}.json`
    });

    // Navigate to the page to measure performance
    await page.goto('http://localhost:4173/performance/diagram');

    // Mark the start of performance measurement
    await page.evaluate(() => window.performance.mark('Perf:Started'));
    await page.click('button');
    await page.waitForSelector('svg');
    await page.evaluate(() => window.performance.mark('Perf:Ended'));
    await page.evaluate(() => window.performance.measure('overall', 'Perf:Started', 'Perf:Ended'));

    // End measurement and save results
    await browser.stopTracing();
});

Analyzing CpuProfile Events

Although we can generate a JSON-formatted Trace Report using Playwright and Chrome Trace, analyzing this file directly is challenging. The report contains all events that occurred during execution, but it's difficult to intuitively understand each function's execution time or call count. We need to preprocess the data to extract meaningful information.

CpuProfile Events and Preprocessing

CpuProfile events are recorded in the disabled-by-default-v8.cpu_profiler category and track JavaScript function CPU usage. Each event is recorded with a time interval and includes samples and timeDeltas fields, which can be used to infer each function's execution time.

To calculate each function's total execution time, we need to preprocess the data by:

Iterating through samples and timeDeltas to calculate each node's total execution time
Constructing a node hierarchy based on parent-child relationships and aggregating child node execution times to their parents
Extracting function-level execution times and visualizing or identifying optimization points

This preprocessing step provides a clear understanding of each function's resource usage and helps identify performance bottlenecks.

Implementing the ChromeTraceAnalyzer Class

To automate the analysis of Trace Reports, we'll implement the ChromeTraceAnalyzer class. This class will take Trace data as input, calculate each function's execution time, and provide performance metrics.

ChromeTraceAnalyzer Class

class ChromeTraceAnalyzer {
    nodes: any[];

    constructor(trace) {
        this.setConfig(trace);
    }

    // Return the execution time of a specific function (in ms)
    getDurationMs(name: string): number {
        if (!this.nodes) throw new Error('nodes is not initialized');
        const result = this.nodes.find((node) => node.callFrame.functionName === name);
        return result ? result.duration / 1000 : 0; // Convert to milliseconds
    }

    // Set up Trace data and calculate function execution times
    setConfig(trace: any) {
        const { traceEvents } = trace;

        // Filter 'ProfileChunk' events
        const profileChunks = traceEvents.filter((entry) => entry.name === 'ProfileChunk');

        // Extract CpuProfile nodes and sample data
        const nodes = profileChunks.map((entry) => entry.args.data.cpuProfile.nodes).flat();
        const sampleTimes = {};

        // Aggregate sample execution times
        profileChunks.forEach((chunk) => {
            const { cpuProfile: { samples }, timeDeltas } = chunk.args.data;

            samples.forEach((id, index) => {
                const delta = timeDeltas[index];
                sampleTimes[id] = (sampleTimes[id] || 0) + delta;
            });
        });

        // Construct node hierarchy and aggregate child node execution times
        this.nodes = nodes.map((node) => ({
            id: node.id,
            parent: node.parent,
            callFrame: node.callFrame,
            children: [],
            duration: sampleTimes[node.id] || 0
        }));

        // Establish parent-child relationships and aggregate execution times
        const nodesMap = new Map();
        this.nodes.forEach((node) => {
            nodesMap.set(node.id, node);
        });

        this.nodes
            .sort((a, b) => b.id - a.id)
            .forEach((node) => {
                if (!node.parent) return;
                const parentNode = nodesMap.get(node.parent);
                if (parentNode) {
                    parentNode.children.push(node);
                    parentNode.duration += node.duration;
                }
            });
    }
}

Repeated Measurements for Reliability

Although we can analyze Trace data using ChromeTraceAnalyzer, a single measurement is not enough to evaluate performance. JavaScript execution performance can vary due to environmental changes, so we need to repeat measurements multiple times to obtain reliable data.

Repeated Measurement Code Example

test('Capture analyzed trace when diagram is rendered with multiple runs', async () => {
    const COUNT = 10;
    const duration = {
        timestamp: Date.now(),
        runApp: 0,
        mount: 0,
        draw: 0,
        layout: 0,
        paint: 0,
    };

    for (let i = 0; i < COUNT; i++) {
        const browser = await chromium.launch({ headless: true });
        const page = await browser.newPage();
        await page.goto('http://localhost:4173/performance/diagram');

        // Start tracing
        await browser.startTracing(page, {});
        await page.evaluate(() => window.performance.mark('Perf:Started'));
        await page.click('button');
        await page.waitForSelector('svg');
        await page.evaluate(() => window.performance.mark('Perf:Ended'));
        await page.evaluate(() => window.performance.measure('overall', 'Perf:Started', 'Perf:Ended'));

        // Extract Trace data and analyze
        const trace = JSON.parse((await browser.stopTracing()).toString('utf8'));
        const analyzer = new ChromeTraceAnalyzer(trace);
        duration.runApp += analyzer.getDurationMs('runApp') / COUNT;
        duration.mount += analyzer.getDurationMs('mount') / COUNT;
        duration.draw += analyzer.getDurationMs('draw') / COUNT;
        duration.layout += analyzer.getDurationMs('layout') / COUNT;
        duration.paint += analyzer.getDurationMs('paint') / COUNT;

        await browser.close();
    }

    console.log('**** Average Execution Time ****');
    console.log(`runApp: ${duration.runApp}ms`);
    console.log(`mount: ${duration.mount}ms`);
    console.log(`draw: ${duration.draw}ms`);
    console.log(`layout: ${duration.layout}ms`);
    console.log(`paint: ${duration.paint}ms`);
    console.log('********************************');
});

Visualizing Performance Data

By repeating measurements and analyzing Trace data, we can obtain reliable performance metrics. To better understand performance changes over time, we can visualize the data using Flitter.

Flitter-Based Stacked Bar Chart

We created a stacked bar chart using Flitter to display the average execution time of each function over multiple runs. This chart helps us identify performance bottlenecks and track changes in execution time.

Chart Configuration

X-axis: Measurement dates (track performance changes over time)
Y-axis: Average execution time (ms)
Stacked bars: Each function's execution time (color-coded)

Performance Changes Over Time

By analyzing the chart, we can see how performance changes over time:

Date-based performance changes: We can track how performance changes on each measurement date.
Function-level execution time: We can identify which functions consume the most resources and optimize them accordingly.

The current Flitter library can be used as an efficient visualization solution in situations where performance optimization is important. You can check the related code on GitHub, and if you found this helpful, please give it a Star and thumbs up on GitHub! If you show interest in this project, we plan to continue developing and sharing performance improvements and various features.

GitHub: https://github.com/meursyphus/flitter/blob/latest/packages/test/tests/tracking-performance.test.ts

Docs: Flitter Docs

Thank you for reading!

Portfolio of a 4-Year Frontend Developer

Meursyphus — Tue, 10 Dec 2024 12:19:07 +0000

Hello! In this post, I'd like to introduce the frontend projects I've been working on. Instead of just showing my work, I'll focus on the thought process behind the interactions and UX choices, and how I solved the challenges I faced.

Ultimately, I'll be sharing the choices I made to improve the user experience and the insights I've gained from real-world practice. If you've been curious about my work, I think you'll find this interesting. So, shall we get started?

Project 1: Improving Search UX – Smooth Page Transitions and Slide Interactions

If page transitions in a search interface aren't smooth, users can easily get confused. Especially when browsing through multiple pages of search results, abrupt page changes can make it difficult to understand where they are or what they’ll see next. To address this, I implemented slide interactions for the search results pages.

When moving to the next page, the content slides to the left, and when returning to the previous page, it slides to the right. Maintaining a consistent transition speed was key. For instance, moving directly from page 1 to page 3 required a longer slide duration since the distance covered was greater. This helped create smooth, natural transitions between pages.

Another crucial aspect of UX is maintaining context. Rather than simply refreshing the page, showing the transition visually allows users to better understand where they are and what they'll see next. I also ensured a smooth flow between pages by connecting the last row of the previous page with the first row of the next page.

Technically, managing the DOM was a significant challenge. Preloading all the content during page transitions would overload both the browser and server, so I handled this by removing unnecessary DOM elements as the animation ended. Additionally, I added a fade-out effect for the disappearing page's content to make the transition feel even more seamless. This effect was a designer's request, and though it was challenging to implement, the visual satisfaction was worth it.

As a result, page transitions became smooth and natural, allowing users to explore search results without losing context.

Project 2: Improving Search UX – Analyzing and Applying Naver's Search Interface

Next, I want to talk about search UX. The search bar is one of the key interfaces that provide a search experience, and its usability greatly depends on how quickly and intuitively it delivers search results. So, I analyzed Naver's search UX and applied it to my own search component.

Naver's search bar shows search results in real time as users type and highlights matching terms with color. This structure helps users quickly find what they're looking for by providing rapid visual feedback while typing. This makes the search results clearer and more intuitive.

I also paid attention to the triggers for showing and hiding the search results panel. Naver's search bar opens the results panel when the user starts typing or presses the arrow key, and closes it when they clear the input or click outside. These subtle interactions make the user experience smoother. UX that responds to multiple triggers like this helps users stay immersed in the search task.

Applied Interactions and UX Improvements

Based on this analysis, I incorporated similar UX elements into my search component. I designed it to display search results in real time while typing, highlighting the parts that match the search term to provide feedback to the user. Additionally, users could navigate the results using keyboard arrow keys, which improves usability by enabling navigation without the mouse.

I also handled the triggers for automatically opening and closing the search results panel more meticulously. When the user starts typing, the results panel opens automatically, and when the input is cleared, the panel closes. While the search bar is open, users can also use various keyboard actions (e.g., arrow keys, enter key) to select results, allowing them to check the results more quickly and intuitively.

Project 3: Scroll Animation – Code Typing Effect on Page Scroll

Next, I’d like to discuss scroll animation. Scroll animations are a key element in enhancing the user experience by adding visual effects to a webpage, making the experience more engaging. In particular, I wanted to provide a more lively experience for users of the Flitter.dev project through scroll animations.

Adding scroll animations helps draw users' attention and increases the time they spend on the page. From the user's perspective, it can feel like the page comes alive as they scroll. The scroll animation I applied to Flitter.dev makes it look like code is being typed in real time, giving the impression that the code is actually being written on the screen.

Implementation Method

To implement this animation, I used Lottie animations. The process was as follows:

Write the complete code and then undo it line by line: After completing the entire code, I used the undo function to erase lines one by one, making it look like typing.
Screen recording: I saved this process as a screen recording and converted it to MP4 format.
Lottie conversion: I then converted the MP4 video to a Lottie file, allowing the typing animation to progress as the user scrolls.

Thanks to this approach, I was able to implement a smooth, natural animation without affecting the page loading speed.

UX Impact

The biggest advantage of this scroll animation is that it provides intuitive feedback to users. The real-time typing animation keeps users engaged with the content and draws their attention as they scroll through the page.

Visit https://flitter.dev to check out the animation for yourself! 🌟

Conclusion

I've introduced a few of the projects I've worked on so far. Though they're not perfect, I believe I’m growing step by step through these experiences. I'm constantly realizing how important user experience (UX) is, and I'll keep striving to create better interactions and UI in the future.

Thank you for reading, and I hope these projects might serve as a small reference for your own work. 😄

Can't Ask GPT Properly? Congratulations! You're Growing as a Developer

Meursyphus — Tue, 10 Dec 2024 12:16:13 +0000

"I asked GPT but the answer was weird..."

This is a common message in developer chat rooms. Usually followed by a lengthy error log dump, without context or any explanation of what they tried to do.

"Sorry, but how do I fix this?"

"This isn't working, and GPT doesn't understand what I'm saying 😢"

Even senior developers from prestigious companies like Toss, Musinsa, and Naver can't understand these questions. But this isn't their fault. The questions are simply too vague.

GPT Doesn't Understand You? Congratulations!

Sound strange? But I mean it. If GPT can't understand your questions, it's evidence that you're experiencing growing pains.

Think about it. How can AI understand questions that even senior developers can't comprehend? While GPT is certainly a powerful tool, it's not a magic wand. Without clear context and accurate information, even the world's smartest AI can't provide a proper answer.

Difficulty with GPT Usage is a Sign of Growth

Junior developer A had this concern:
"Infinite scroll isn't working in React. I asked GPT but the answer was weird."

Six months later, A asks like this:
"I'm implementing infinite scroll with React Query, using Intersection Observer. I want to store the scroll position in sessionStorage to restore it on back navigation, but I'm seeing unnecessary re-renders. Should I apply memoization?"

See the difference?

Paradoxically, finding it difficult to use GPT is a signal that you're growing. As you understand technology more deeply, your questions become more specific and clear. And that's when GPT truly becomes your pair programmer.

Prerequisites for Clear Questions

Here's what you need to properly utilize GPT:

Accurate understanding of the problem situation
- What you're trying to achieve
- Current state
- What errors are occurring
Basic knowledge of your technology stack
- Role of each library or framework
- Core concepts and how they work
- Common problem-solving patterns
Solutions you've attempted
- What approaches you've tried
- Results from each attempt

With these preparations, GPT can provide much more useful answers.

How Growing Developers Use GPT

Stop asking GPT questions. Instead, give it commands.

Not "What should I do about this error?"

But "Here's what I tried. Looking at the logs, the problem seems to be here. Suggest how I should modify this part."

Not "How do I build this feature?"

But "Here are the requirements, and this is my tech stack. Analyze the best implementation approach considering performance and maintainability."

This approach leads to remarkable changes:

Deeper understanding of problems
Better control over solutions
Improved technical specification writing skills
Enhanced communication with colleagues

This is Just the Beginning

Still finding it difficult to ask GPT questions? Don't worry. That's evidence you're growing.

As questions become more challenging, you learn more, and as you learn more, questions become clearer. And through this process, you'll find yourself growing from a junior to a mid-level developer.

Start today. Stop asking GPT questions, and start giving it commands. Your real growth begins now.

Think 'use client' Means CSR? Master This Next.js Interview Question

Meursyphus — Tue, 10 Dec 2024 12:15:45 +0000

If you're a junior developer who has worked with Next.js, you've probably encountered this question in technical interviews:

"Is use client exclusively for Client-Side Rendering (CSR)?"

If you can confidently answer "No, components with use client can also utilize SSR (Server-Side Rendering)!", you'll leave a strong impression on your interviewer.

In this article, we'll focus on SSR and Server Components to clearly understand what use client really means and what the Hydration process entails. We'll also explore how all React components were client components before Server Components came along, and examine the performance benefits of Server Components to help you prepare thoroughly for Next.js interviews.

Understanding SSR, CSR, and Hydration

Traditionally, React applications often operated with CSR (Client-Side Rendering). The browser receives basic HTML and JS bundles from the server, but the initial screen only contains an empty <div id="root"></div>, leaving users staring at a blank screen until JS loads and rendering completes. This delays initial loading times and negatively impacts SEO.

One solution to this problem is SSR (Server-Side Rendering). With SSR, React components are rendered to HTML on the server before being sent to the client, allowing users to see actual content instead of a blank screen during initial load. However, this HTML is still in a "dry (Markup-only)" state without interactivity, and only becomes fully interactive after the browser loads JavaScript and React completes its hydration process by registering event handlers.

What is Hydration?

Hydration is the process where static HTML rendered on the server is matched with React's virtual DOM on the client side, and event handlers are attached to create an interactive UI. In other words, after receiving "structure-only" HTML through SSR, once JavaScript loads and hydrate() executes, event and state management logic becomes active on top of this HTML structure.

[Server: SSR] --(HTML)--> [Browser: Initial Display] 
                                      | 
                                      v 
                          (JS Load, hydrate()) 
                                      |
                                      v
                    [Browser: Event Handlers Attached, VDOM Sync]

Now users can see content immediately upon page load, with interactivity becoming available as soon as JS is ready.

Distinguishing Server Components from Client Components

Server Components, introduced after React 18, presented a new paradigm of "components that only run on the server." In Next.js, all components are Server Components by default, and only components that need to run on the client explicitly declare use client.

Server Components are delivered to the client as HTML snippets and are excluded from hydration. This means the HTML returned by Server Components is simply inserted into the browser "as is," without event handlers or state being injected on the client side. As a result, Server Components consume minimal JavaScript bundle size, significantly helping with performance optimization.

On the other hand, components declaring use client behave like traditional React components. They generate initial HTML through SSR, then go through the hydration process to activate interactivity. Therefore, use client components can utilize SSR and support the hydration process that combines SSR + CSR.

Before Server Components: All Components Were Client Components

Before Server Components existed, all React components had to go through hydration on the client side. Even with SSR, all components ultimately needed to have their logic re-injected with JavaScript on the client. This led to large bundle sizes and longer initial loading times in large applications.

After the introduction of Server Components, we can now handle "static parts that only need to be displayed" as Server Components without any declaration, while parts requiring interactivity can be marked with use client. This clear separation enables more efficient bundle optimization and better performance.

How Server Components Work: Slot Insertion and HTML Combination

Server Components render HTML snippets on the server and provide them to the client, while React's render tree leaves a "hole" for these snippets. The final HTML is created by inserting these snippets into the corresponding holes. Here's a simple ASCII diagram illustrating this process:

[Server: RSC(Render)] --> [HTML snippet] 
                                | 
                                v 
                [React Render Tree]: "hole" creation
                                | 
                                v 
                    Combined HTML --> Client transmission 
                    (Server Components excluded from hydration)

In this process, Server Components do not include JavaScript bundles. As a result, they cannot register event handlers or state, but this is actually beneficial for parts that only require static HTML. The reduced JavaScript bundle size leads to faster initial screen display.

Acing Your Interview: Confidently Answering "Is 'use client' Only for CSR?"

For example, you might encounter this question in an interview:

Interviewer: "Do components with use client only support CSR?"

Model Answer:

"No, in Next.js, all components are Server Components by default, and only components that need to run on the client explicitly declare use client. These client components generate initial HTML through SSR and then go through the hydration process to activate interactivity on the client side. Therefore, use client components can also utilize SSR. On the other hand, Server Components are excluded from hydration and only provide static HTML, reducing JavaScript bundle size and improving performance."

If you can clearly explain this, the interviewer will recognize that you have a solid grasp of Server Components, SSR, and hydration concepts.

Server-Side Rendering and Server Components Are Not Mutually Exclusive

Finally, it's essential to note that Server Components do not replace SSR. SSR focuses on displaying content to users immediately during initial load, while Server Components provide an additional layer for optimizing bundle size and data fetching. These two technologies complement each other, and using them together enables you to create a better user experience and improve performance.

Bonus: What Is 'use server'?

'use server' is a different concept from Server Components, used to define Server Actions. Server Actions allow clients to directly call server functions, making them useful for handling server-side tasks like form submissions or data updates.

Recap

All Next.js components are Server Components by default
Client components require explicit use client declaration
Client components can utilize SSR: server-side HTML rendering followed by hydration
Server Components provide static HTML without hydration, reducing JavaScript bundle size and improving performance
'use server' is a separate feature for defining Server Actions
Server Components complement SSR, not replace it: together, they provide optimal user experience and performance

Armed with this knowledge, confidently answer interview questions. Emphasize that "use client components also support SSR" and explain how Server Components lead to bundle optimization and performance improvements. Highlighting that all components are Server Components by default and only client components need the 'use client' directive will demonstrate your deep understanding of Next.js architecture.

If you're a front-end developer, you should at least know how to handle page transitions, right? Can't do it? 😱

Meursyphus — Wed, 09 Oct 2024 07:53:51 +0000

When we use smartphone apps, smooth screen transitions are an expected part of the experience. But on the web, it’s a different story. If developers don’t pay attention to page transitions, websites can feel jarring, with sudden screen changes every time you click, leaving users confused or, worse, making them leave the site.

An experience where the screen suddenly switches, like “teleportation,” places a significant cognitive load on users. Ultimately, good UX should minimize this burden and create a natural flow. So, why are so many websites still overlooking this crucial aspect?

Now, mastering this will give you a competitive edge! By learning page transition techniques, you’ll not only enhance your web development skills but also gain an edge in app development. Thanks to technologies like WebView, web front-end developers can easily start developing apps. If you can handle page transitions on the web, you can pretty much call yourself an app developer, right? 😎

Is your website still outdated?

As a web developer, I’ve always been dissatisfied with how page transitions are handled on websites. Especially when transitioning between pages, the abrupt change of screen often makes users lose track of where they are or what they just clicked. I’ve always thought that such sudden shifts severely degrade the user experience. While smooth transitions are standard in apps, the web often still feels like “teleportation” when changing pages.

To solve this, I initially tried simple CSS tricks to add smoother transitions. However, I quickly realized their limitations. While the transitions themselves became smoother, the issue of completely new screens appearing with every page load remained. I thought that to reduce users’ cognitive fatigue on the web, we needed transitions that not only flowed smoothly but also preserved the overall context.

So, I present to you, SSGOI!!

As I became more frustrated with page transitions, I naturally began thinking about solutions. Abrupt transitions are too common on the web. When the screen changes suddenly, users often find it hard to orient themselves, leading to a loss of focus. This experience made me realize the need for smoother, more intuitive transitions on the web as well.

That’s when I decided to create SSGOI, a library designed to provide seamless, app-like page transitions for the web. SSGOI offers various animation effects and ensures users can clearly understand where they’re navigating.

The biggest advantages of this library are:

Various transition effects: With several built-in animation options, developers can easily implement smooth page transitions.
Customizable transitions: Dynamic transitions based on runtime conditions allow for a tailored user experience.
Browser compatibility: Designed to work consistently across different browsers, SSGOI leverages the latest browser APIs while still supporting smooth transitions in browsers with limitations.

Want to know the secret to smooth transitions like Pinterest?

Implementing Pinterest-like transitions with SSGOI wasn’t just about visual delight; it was about offering a more intuitive user experience. In image-centric layouts like Pinterest, it’s crucial that when a user clicks on an image, the context is maintained while the screen transitions smoothly.

My goal was to have the clicked image smoothly enlarge to the center of the screen, while the rest of the elements naturally fade away. This ensures that users stay focused on their selected content, and the page transitions without the common “disconnect” often felt on the web. It was also vital to ensure that during the image’s resizing, context is maintained, so users clearly understand where they’re navigating.

However, implementing this transition was no easy task. I had to carefully calculate how the image’s size and position would change across various screen sizes during the transition. Especially when the URL actually changes between pages, there was a lot of mathematical work involved in maintaining a smooth transition.

In the end, I was able to overcome the complex calculations and deliver a seamless experience, as if using an app right on the web.

My vision for the future.

There are clear limitations in today’s web UX, especially with browser API restrictions and cross-browser compatibility. While smooth, intuitive page transitions are expected in apps, on the web, we still experience sudden screen changes and loss of context. This is because web browsers don’t yet provide all the necessary APIs to handle transitions smoothly. This makes it difficult for developers to easily implement a variety of page transition effects, and cross-browser compatibility adds to the challenge.

This is where libraries like SSGOI come in. SSGOI bridges the gap, helping to provide an app-like, smooth user experience even on the web. By maintaining context and handling transitions smoothly, it reduces the cognitive load on users during page navigation. This allows developers to offer a better user experience without writing complex code.

The future of web UX will only improve. With new browser APIs and standards emerging, implementing page transitions will become much easier. Furthermore, as technologies like AI become more integrated into the development process, complex tasks will be handled by AI, allowing developers to focus more on the creative aspects.

Want to implement smooth transitions on the web? Check out SSGOI!

Creating smooth, app-like transitions on the web is now a crucial task. Since user experience has a significant impact on the success of a website, it’s important not to overlook even small details like page transitions.

The SSGOI library was designed to address these issues. With this library, you can implement smooth and natural page transitions without writing complex code. Built with cross-browser compatibility in mind, it ensures a consistent user experience across various environments.

If you’re interested, visit the SSGOI GitHub repository! 😄 If you find it useful, don’t forget to leave a Star! ⭐ Your feedback and participation will help improve web UX for everyone.

12 Best ER Diagram Tools to Use in 2024

Meursyphus — Wed, 17 Jul 2024 15:05:37 +0000

ER (Entity-Relationship) diagrams are essential tools for database design. In this article, we'll introduce the best ER diagram tools available in 2024.

1. Lucidchart

Lucidchart allows you to create various types of diagrams, including ER diagrams. It can be integrated with MS Office and G Suite.

Key features:

Real-time collaboration
Automated diagramming
Enhanced security

Price: Starting from $7.95/month for a single user account

2. DeZign for Databases

DeZign for Databases is a tool that helps visualize database structures. It can create new databases as well as reverse engineer existing ones.

Key features:

Drag and drop interface
Various display modes
Industry-standard design notation

Price: €19/month for Standard Edition, €59/month for Professional Version

3. Gleek.io

Gleek.io is a fast diagramming and flowchart application that works through keyboard commands and code.

Key features:

Keyboard-based user interface
Fast diagramming
Version control

Price: Basic app is free, Premium version is €9.95/month

4. EasyRd

EasyRd is a recently emerged innovative ER diagram tool. It operates based on code and utilizes DBML (Database Markup Language), a well-known open-source syntax.

Key features:

Easy generation through GPT with DBML syntax support
Code-based diagram creation
Completely free to use

The biggest advantage of EasyRd is that it can easily generate ER diagrams through AI tools like GPT using DBML syntax. It provides a code-based interface familiar to developers while enabling intuitive visualization. Additionally, it's completely free to use, removing any cost burden.

This tool will be particularly attractive to developers interested in rapid prototyping or AI-based database design.

5. DbDesigner

DbDesigner is suitable for teams that need to create different user classes for projects.

Key features:

Advanced export options
Project and team management
Export and import to SQL

Price: $6/month for basic package, $15/month for unlimited package

6. SmartDraw

SmartDraw is a web-based tool for diagramming and schema creation.

Key features:

Intelligent formatting
Professional results
Visio import and export

Price: Starting from $9.95/month for a single user account

7. Visual Paradigm

Visual Paradigm comes with several ERD templates and can create various types of diagrams.

Key features:

UML diagrams
ER diagrams
BPMN diagrams

Price: Starting from $6/month, perpetual licenses start at $99 for a single user

8. dbdiagram.io

dbdiagram.io allows power users to easily create ER diagrams.

Key features:

SQL statement generation
Export to image and PDF
One-click sharing

Price: Basic plan is free, Pro version is $9/month

9. dBForge Studio for SQL Server

dBForge Studio for SQL Server is an SQL management tool that can also create ER diagrams.

Key features:

SQL coding support
Index manager
Schema comparison

Price: Starting from $249.95

10. Navicat Data Modeler

Navicat Data Modeler creates diagrams for MySQL, Oracle, MariaDB, PostgreSQL, and SQLite.

Key features:

Database objects
Reverse engineering
SQL code generation

Price: Enterprise version $22.99/month or $229.99/year (per user)

11. Creately

Creately claims to be "your visual workspace" and enables remote collaboration.

Key features:

Smart shapes
Easy drawing shortcuts
Real-time collaboration

Price: Team version $6/month (per user)

12. Gliffy

Gliffy is a diagramming tool that can be easily used by non-developers as well.

Key features:

Process flowcharts
Workflow diagrams
Data flow charts

Price: Pro version $7.99/month (per user)

Conclusion

In 2024, there are various ER diagram tools available, allowing you to choose the one that best fits your project requirements. New tools like EasyRd are making the database design process even more efficient through integration with AI. Given that it's provided for free, why not consider EasyRd for your next project?

Flitter vs D3.js: Revolutionizing Data Visualization for the Web

Meursyphus — Sun, 14 Jul 2024 07:33:46 +0000

In the world of web-based data visualization, D3.js has long been the go-to library for developers. However, Flitter is changing the game, offering a fresh approach that addresses many of the challenges developers face with D3. Let's explore why Flitter is becoming the preferred choice for modern data visualization projects.

1. Ease of Use: Simplifying the Complex

D3.js Approach:

const svg = d3.select("body").append("svg")
    .attr("width", 400)
    .attr("height", 300);

svg.selectAll("circle")
    .data([32, 57, 112])
    .enter().append("circle")
    .attr("cy", 60)
    .attr("cx", (d, i) => i * 100 + 50)
    .attr("r", d => Math.sqrt(d));

Flitter Approach:

import { Container, CustomPaint } from "@meursyphus/flitter";

const BubbleChart = ({ data }) => {
  return Container({
    width: 400,
    height: 300,
    child: CustomPaint({
      painter: {
        paint({canvas}, size) {
          data.forEach((d, i) => {
            canvas.beginPath();
            canvas.arc(i * 100 + 50, 60, Math.sqrt(d), 0, 2 * Math.PI);
            canvas.fill();
          });
        },
      },
    }),
  });
};

Flitter Advantage: Flitter's declarative approach and widget-based architecture make it significantly easier to create and understand visualizations, especially for developers already familiar with modern UI frameworks.

2. Performance: Handling Large Datasets with Ease

While D3.js can struggle with large datasets due to its direct DOM manipulation, Flitter's efficient rendering pipeline shines with big data.

Flitter's Optimized Rendering:

import { ... } from '@meursyphus/flitter';
import Widget from '@meursyphus/flitter-react';

const App = () => {
  return(
    <Widget
      width="100vw"
      height="100vh"
      child={
        ...// your widget here
      }

      /**
       * you can choose between "canvas" and "svg". 
       * canvas is faster, while svg is useful for server side rendering
       */
      renderer="canvas"
    />
  )
}

Flitter Advantage: Flitter's rendering approach allows for smooth handling of thousands of data points, maintaining high frame rates even with dynamic updates.

3. Integration with UI: Seamless Component Integration

D3.js often requires additional work to integrate with modern UI frameworks. Flitter, on the other hand, is designed for seamless integration.

Flitter's Unified Approach:

import { Column, Text } from "@meursyphus/flitter";
import { BarChart } from "@meursyphus/flitter-chart";
import Widget from '@meursyphus/flitter-react';

export function Dashboard() {
  return (
    <Widget
      width="100vw"
      height="100vh"
      child={
        Column({
          children: [
            Text("Sales Dashboard"),
            BarChart({ /* chart properties */ }),
            // Other UI components
          ],
        })
      }
    />
  )
}

Flitter Advantage: Create entire applications with a consistent architecture, mixing visualizations and UI components effortlessly.

4. Responsive Design: Adapt to Any Screen

While D3.js requires manual work for responsiveness, Flitter makes it straightforward:

import { Container } from "@meursyphus/flitter";
import Widget from '@meursyphus/flitter-react';

const YourWidget = () => {
  return ... // your widget implementation here
};

const App = () => {
  return (
    <Widget
      width="100%"
      height="100%"
      child={Center({
        child: YourWidget() // your widget will be centered whenever the screen size changes
      })}
    />
  )
}

Flitter Advantage: Built-in responsiveness features make it easy to create visualizations that look great on any device.

5. Learning Curve: Familiarity for Modern Developers

D3.js has a steep learning curve, especially for developers used to modern framework paradigms. Flitter leverages familiar concepts:

class InteractiveChart extends StatefulWidget {
  createState() {
    return new InteractiveChartState();
  }
}

class InteractiveChartState extends State<InteractiveChart> {
  private selectedData = null;

  onDataPointSelected(data) {
    this.setState(() => {
      this.selectedData = data;
    });
  }

  build() {
    return Column({
      children: [
        Chart({
          data: this.props.data,
          onDataPointClick: this.onDataPointSelected,
        }),
        Text(`Selected: ${this.selectedData}`),
      ],
    });
  }
}

Flitter Advantage: Developers familiar with modern UI frameworks can quickly become productive with Flitter, leveraging concepts they already know.




**Flitter Advantage:** Create smooth, performant animations with a simpler, more intuitive API.

## Conclusion: Why Choose Flitter Over D3.js?

1. **Easier Learning Curve:** Familiar concepts for modern developers.
2. **Better Performance:** Efficient handling of large datasets.
3. **Seamless UI Integration:** Build entire applications with a consistent architecture.
4. **Built-in Responsiveness:** Easily create adaptive visualizations.
5. **Simplified Animations:** Create complex animations with less code.

While D3.js remains a powerful tool, Flitter represents the future of web-based data visualization. It combines the flexibility and power needed for complex visualizations with the ease of use and integration capabilities that modern developers expect.

Ready to take your data visualization projects to the next level? Choose Flitter and experience the future of web development today.

Visit here: [Flitter](https://flitter.dev) to get started.

The Complete Guide to CSS object-fit Property

Meursyphus — Sun, 14 Jul 2024 00:05:53 +0000

The Complete Guide to CSS object-fit: Key to Handling Images on the Web

Introduction: Why You Need to Know object-fit

Dealing with images in web development has always been a challenging task. How can we consistently display images of various sizes and ratios? This is where the CSS object-fit property plays a crucial role.

Understanding object-fit means more than just displaying images correctly. Recently, many cloud services that automatically adjust the size of user-uploaded images have been offering object-fit as an option. Therefore, if you don't understand the exact behavior of object-fit, you might unintentionally provide a negative user experience during the image optimization process.

Basic Concepts of object-fit

The object-fit property determines how an image will be cropped or scaled to fit within the specified size (container size) of an <img> or <video> tag, in relation to the original image size.

An important point to note is that when only width or height is specified, the other dimension is automatically determined based on the original image ratio. In this case, for all object-fit values except scale-down and none, the image will fill the container size while maintaining its aspect ratio. However, with scale-down and none, if the container size is larger than the image size, the image will maintain its original size without stretching.

object-fit Values and Their Effects

1. contain

      Container
+--------------------+
|        Image       |
|:------------------:|
|:                  :|
|:                  :|
|:                  :|
|:                  :|
|:------------------:|
|                    |
+--------------------+

Adjusts the image to be fully visible
Maintains image aspect ratio
May result in empty space within the container

2. cover

         Image
:######################:
:#                    #:
:#     Container      #:
:#  +------------+    #:
:#  |            |    #:
:#  |            |    #:
:#  |            |    #:
:#  +------------+    #:
:#                    #:
:######################:

Completely fills the container
Maintains image aspect ratio
May crop parts of the image

3. fill

Completely fills the container
Ignores image aspect ratio (may distort the image)

4. none

Maintains original image size
Ignores container size (image may be clipped)

5. scale-down

Displays the image at the smaller size between none and contain
Prevents the image from stretching

Image Widget in Flitter

The Flitter library also provides an Image widget that implements the behavior of object-fit. Flitter's Image widget is designed to behave as similarly as possible to the native HTML <img> tag and supports various object-fit options.

Image({
  src: 'https://flitter.dev/examples/object-fit/profile.jpg',
  width: 750,
  height: 250,
  objectFit: 'none'
})

If you want to see various examples of object-fit, visit the following URL: https://flitter.dev/examples/object-fit

Conclusion

The object-fit property is a powerful tool for handling images on the web. By properly understanding and using it, developers can effectively manage images of various sizes and ratios, providing users with a consistent visual experience. Understanding object-fit becomes even more important when using image optimization services. We hope this guide helps you handle images more effectively in your web projects.