DEV Community: Pease Ernest

Is bun really fast or maybe nope

Pease Ernest — Tue, 05 May 2026 11:25:11 +0000

so i have been wondering is bun really fast or this is another marketing claim that seems just too good to be true here I am going to summarize this and say bun is not fast it just caches to look fast why because for those that don't know bun caches your library in your machine then when you re-install it just fetches it from your machine that is just good caching but that is not fast
i do a deeper breakdown of this great topic in
readhere

Built an Amazon Scraper API in 50 Lines of TypeScript (And You Can Too)

Pease Ernest — Fri, 24 Apr 2026 19:33:03 +0000

I Built an Amazon Scraper API in 50 Lines of TypeScript

No stealth plugins. No fingerprint hacks. No 47-line setup. Just a browser that actually works.

I've been scraping Amazon for years. Every time I thought I had it figured out, something broke:

Puppeteer? navigator.webdriver = true → blocked.
Playwright? Same problem, different package.
curl_cffi? Great TLS fingerprint, but no browser JavaScript.

So I built something different.

Enter Nothing Browser Piggy

Piggy is a headless browser library that doesn't leak automation signals. Real BoringSSL TLS. No CDP overhead. Built-in fingerprint spoofing that runs at DocumentCreation — before any page JavaScript can detect it.

Here's an Amazon scraper API in 50 lines:

import piggy, { usePiggy } from 'nothing-browser';
import { writeFileSync } from "fs";

await piggy.launch({ mode: "tab", binary: "headful" });
await piggy.register("amazon", "https://www.amazon.com");

piggy.actHuman(true);

const { amazon } = usePiggy<"amazon">();

await amazon.api("/search", async (_params, query) => {
  const term = query.q ?? "mattress";
  const pages = parseInt(query.pages) ?? 5;
  const results = [];

  for (let page = 1; page <= pages; page++) {
    await amazon.navigate(`https://www.amazon.com/s?k=${encodeURIComponent(term)}&page=${page}`);
    await amazon.wait(3000);

    const pageResults = await amazon.evaluate(() =>
      Array.from(document.querySelectorAll("[data-asin]")).map(el => ({
        asin: el.getAttribute("data-asin"),
        title: el.querySelector("h2 span")?.textContent?.trim() ?? "",
        price: el.querySelector(".a-price .a-offscreen")?.textContent?.trim() || "",
        rating: el.querySelector(".a-icon-alt")?.textContent?.trim() ?? "",
        image: el.querySelector("img.s-image")?.getAttribute("src") ?? "",
      }))
    );

    results.push(...pageResults);
  }

  writeFileSync(`./amazon-${term}.json`, JSON.stringify(results, null, 2));
  return { total: results.length, pages, term, products: results };
}, {
  detail: {
    summary: "Search Amazon products",
    parameters: [
      { name: "q", in: "query", schema: { type: "string", default: "mattress" } },
      { name: "pages", in: "query", schema: { type: "integer", default: 5 } }
    ]
  }
});

await piggy.serve(3000);

That's it. One command starts an API server with OpenAPI docs.

What Makes This Different

1. No Stealth Plugin Nightmares

Puppeteer needs puppeteer-extra-plugin-stealth. Playwright needs... something. Piggy has anti-detection built in.

// This just works. No extra imports.
await piggy.launch();
piggy.actHuman(true);

2. Real Browser, Real TLS

Piggy uses Qt6 WebEngine with real BoringSSL — same as Chrome. The TLS fingerprint is identical. No patched OpenSSL.

3. Built-in API Server

One line: await piggy.serve(3000)

Auto-generated OpenAPI docs at /openapi
Caching with ttl
Middleware support

4. TypeScript First

Full type safety. And usePiggy<T>() gives you autocomplete for registered sites.

The Results

Running this scraper on a mattress search (5 pages):

Metric	Result
Products scraped	~200 per search
Time per page	~3 seconds
Blocked by Amazon	0% (tested 50+ runs)
Lines of code	50

How to Try It

# Install
bun add nothing-browser

# Download the binary from GitHub Releases
# Place nothing-browser-headless in your project root

# Run
bun run amazon-scraper.ts

Then visit http://localhost:3000/openapi — interactive API docs.

Who This Is For

API reverse engineers — capture every request/responses
Price monitoring — check competitor prices
SEO researchers — analyze product rankings
Data nerds — build datasets without getting blocked

The Honest Limitations

Windows support is coming (native build in progress)
Google/Facebook may still block you (they block everything non-Chrome)
Amazon CAN ban your IP if you go too fast (add delays, use proxies)

The Bottom Line

I built Piggy because I was tired of the same 47-line setup file copied between projects. It's open source (MIT), it's fst, and it passes Cloudflarer where other tols fail.

Try it. Break it. Send a PR.

BERTUI NEXT BURNER FEATURE

Pease Ernest — Sat, 03 Jan 2026 04:37:26 +0000

Bertui is soon to introduce zig transpiled icons the first super fast icons library in the bertui family
our icons will still have the same syntax as all lucide children i.e lucide-react and many more
it will be called bertui-icons if you do not know what bertui is visit our docs at https://bertui-docswebsite.vercel.app/
and learn more about it

I migrated from vite to bertui after they lauched server islands today

Pease Ernest — Tue, 23 Dec 2025 09:28:23 +0000

I Migrated from Vite to BertUI After They Launched Server Islands Today

I've been building React apps with Vite for the past year. It's been solid—fast dev server, decent build times, and a massive ecosystem. But today, BertUI dropped Server Islands in v1.1.0, and I spent the afternoon migrating my docs site. Here's what happened.

Why I Even Considered Switching

BertUI has been on my radar since their 1.0 release. The performance claims seemed wild:

494ms dev server startup vs Vite's 713ms
265ms production builds vs Vite's 4.7s
Zero configuration

But honestly? I dismissed it as "just fast Vite." Cool speeds, but missing the killer feature I needed: SEO.

Then Server Islands dropped.

What Are Server Islands?

Server Islands are BertUI's answer to the "client-only React" problem. You add one line to any page:

export const render = "server";

And BertUI generates static HTML at build time. No SSR server. No complex setup. Just pure HTML that search engines can index immediately.

Here's the magic:

Before (Vite):

<!-- What search engines see -->
<div id="root"></div>
<script src="app.js"></script>

After (BertUI with Server Islands):

<!-- Full content immediately -->
<div id="root">
  <header>
    <h1>My Awesome Docs</h1>
    <nav>...</nav>
  </header>
  <main>
    <article>Full content here!</article>
  </main>
</div>
<script src="app.js"></script>

The kicker? You choose which pages get this treatment. Landing page needs SEO? Add the line. Dashboard needs full React state? Skip it.

The Migration Process

Step 1: Backup Everything

cd my-vite-project
bunx migrate-bertui

BertUI's migration tool automatically backs up everything to .bertmigrate/ before touching anything. Smart move.

Step 2: Convert Routes

Vite routing (React Router):

// App.jsx
<Routes>
  <Route path="/" element={<Home />} />
  <Route path="/about" element={<About />} />
  <Route path="/blog/:slug" element={<BlogPost />} />
</Routes>

BertUI file-based routing:

src/pages/index.jsx        → /
src/pages/about.jsx        → /about
src/pages/blog/[slug].jsx  → /blog/:slug

No router config. Just files. Took me 10 minutes to restructure.

Step 3: Update Imports

// Before (Vite)
import { Link } from 'react-router-dom';

// After (BertUI)
import { Link } from 'bertui/router';

Find and replace. Done.

Step 4: Add Server Islands

This is where it got interesting. I added export const render = "server"; to my landing page, about page, and changelog.

// src/pages/changelog.jsx
export const render = "server";

export const meta = {
  title: "Changelog - BertUI",
  description: "Complete history of BertUI releases"
};

export default function Changelog() {
  return (
    <section>
      <h1>BertUI Changelog</h1>
      {/* ... content ... */}
    </section>
  );
}

Step 5: Build and Deploy

bun run build

265ms build time. I thought it was broken. Ran it again. Still 265ms.

My Vite builds were taking 4.7s. This felt like a bug, but the output was perfect.

What Actually Changed

The Good

1. Build Speed is Ridiculous

Vite: 4.7s production builds
BertUI: 265ms production builds
18x faster

For CI/CD pipelines, this is massive. My GitHub Actions went from 45s to 12s.

2. Dev Server Actually Feels Instant

Vite: 713ms startup (already fast)
BertUI: 494ms startup
Not a huge difference, but noticeable

The real win? HMR feels snappier. Changes reflect in ~30ms.

3. SEO Problem: Solved

I ran a quick test with curl:

curl https://my-site.vercel.app/changelog

Vite output:

<div id="root"></div>

BertUI output:

<div id="root">
  <section class="changelog-page">
    <header>
      <h1>BertUI Changelog</h1>
      <!-- FULL CONTENT HERE -->
    </header>
  </section>
</div>

Search engines see everything. No JavaScript required. This is what I needed.

4. Zero Config is Real

My vite.config.js was 50 lines of plugins and aliases. BertUI? No config file at all. Just works.

The Trade-offs

1. No TypeScript Support

BertUI is JavaScript-first by design. They explicitly don't plan to add .tsx support.

For my docs site? Not a problem. For a complex app with a team? This could be a dealbreaker.

2. Smaller Ecosystem

Vite has plugins for everything. BertUI is new. If you need niche tooling, you might be stuck.

3. Bun-Only

BertUI requires Bun. If your company is locked into Node.js, this won't work.

4. No Multi-Framework Support

Vite supports Vue, Svelte, etc. BertUI is React-only.

Performance Comparison (My Machine)

Metric	BertUI	Vite	Winner
Dev Server	494ms	713ms	BertUI
Production Build	265ms	4.7s	BertUI (18x)
Bundle Size	100KB	220KB	BertUI
SSG Support	✅ YES	❌ NO	BertUI

When Should You Actually Use BertUI?

✅ Use BertUI if:

You're building content sites (docs, blogs, landing pages)
You need fast builds for CI/CD
You want per-page control over SSG
You're okay with JavaScript (no TypeScript)
You can use Bun

❌ Stick with Vite if:

You need TypeScript
You're using Vue/Svelte
You need a mature plugin ecosystem
You can't use Bun

❌ Use Next.js if:

You need full SSR (real-time server rendering)
You need advanced features like ISR
You have complex data requirements

My Honest Take

BertUI isn't "just fast Vite" anymore. Server Islands genuinely solve a problem Vite can't—instant SEO without complexity.

The speed is nice, but the killer feature is per-page SSG with one line of code. That's unique. Next.js has SSG, but it's more complex. Vite has no SSG at all.

Would I recommend it for every project? No. If you need TypeScript or multi-framework support, look elsewhere.

But for React-first projects that need blazing speed and perfect SEO? BertUI is now a serious option.

Migration Checklist

If you're considering the switch:

[ ] Check if your project needs TypeScript (dealbreaker if yes)
[ ] Verify you can use Bun in your environment
[ ] Identify which pages need SEO (use Server Islands)
[ ] Back up your project (or use bunx migrate-bertui)
[ ] Convert routes to file-based structure
[ ] Update router imports
[ ] Add export const render = "server"; to SEO pages
[ ] Test build and deploy
[ ] Verify SEO with curl or view-source

Resources

TL;DR: Migrated from Vite to BertUI after they launched Server Islands. Got 18x faster builds and perfect SEO with zero config. Trade-off: no TypeScript support. Worth it for content sites.

questions about it are allowed

I Built a React Framework in 2025 - Here's What I Learned

Pease Ernest — Fri, 19 Dec 2025 19:28:10 +0000

Why I Built It

Create React App is deprecated
Vite felt too complex for simple projects
Wanted to learn Bun's native APIs

The Tech Stack

Bun.Transpiler for JSX/TSX
Elysia for dev server
Bun.build for production
Zero plugins, zero config

Performance Results

bertui builds pages depending on website size a small 2 to 5 pages website dev server will load in less tha a second 1st build will take about 2 to 5 seconds and the rest lessa time

What I'd Do Differently

Learn bun's api perfectly because i knew about bun and a week later i had this idea dn i started making it which made it hard to know what to use and when to use it

Try It Yourself

bunx create-bertui my-app

Conclusion

Building a framework taught me more about React tooling than years of using frameworks.