Forem: Asaolu Elijah 🧙‍♂️

[Boost]

Asaolu Elijah 🧙‍♂️ — Tue, 19 May 2026 19:53:48 +0000

Asaolu Elijah 🧙‍♂️ for Hackmamba

May 19

Why you must switch to a hybrid AI building model now

Comments

7 min read

Why you must switch to a hybrid AI building model now

Asaolu Elijah 🧙‍♂️ — Tue, 19 May 2026 19:53:38 +0000

There is a big difference between generating code and delivering software. You have likely seen the demos where someone types a prompt and a screen appears, so it looks like the hard work is over. But when you try to turn that demo into a real business product, progress stops. The app that looked ready suddenly turns into weeks of meetings about security, integrations, ownership and infrastructure. This is the major gap between a prototype and a V1 Alpha.

A prototype, which is what most AI tools generate, is a visual argument. A V1 Alpha, on the other hand, is an operational commitment. It is software that can be shipped, secured, owned and extended. The mistake many teams made was treating these as the same category of work. That assumption is now breaking down in the market.

Teams are starting to recognize these gaps, which explains a clear shift in decision-making. Leaders are no longer impressed by generation speed alone if it does not lead to a usable outcome. They are starting to pay for certainty plus speed, meaning the ability to reach a working result quickly without inheriting delivery risk or long setup cycles.

Still, achieving that certainty and speed depends on choosing the right delivery model. To help you choose the right path, this article compares the three dominant delivery models on speed, cost and risk. We will explore why AI-only projects often lack ownership and why traditional shops are too slow for modern needs. Then, we will demonstrate how the hybrid model bridges this gap to deliver verifiable software immediately.

Comparing the three software delivery models

Here are the three different delivery models that teams use when developing software today.

Model A: AI builder only

In this model, an internal team uses an AI coding tool directly. The workflow is simple. Someone opens a tool like Lovable or Replit and types a prompt describing a feature, such as a dashboard with a sales chart and user login. Within minutes, the tool produces a clean and working UI.

The limitation shows up when the application needs to interact with real systems. As soon as the team tries to connect the app to a production database, authentication provider or internal API, gaps appear, especially in areas like:

Error handling and edge cases
Authentication and access control
Data contracts and schema validation
Environment and deployment configuration

The generated code looks correct, but does not behave like owned software. There is also no clean handoff point. The AI returns syntax and structure, but the responsibility for making it production-ready falls entirely on the internal team. Many teams discover that turning the demo into a product requires rewriting large portions of the system.

Model B: The traditional dev shop

This is the traditional service model that prioritizes risk management through rigorous processes. It assumes that the safest way to build software is to define every requirement before writing a line of code. The engagement usually begins with a heavy upfront phase focused on:

Discovery workshops and stakeholder interviews
Detailed requirement documents and specifications
Architecture diagrams and technical planning
Approval cycles and sign-offs

You might spend the first three months paying for meetings and documents, feeling secure because of the paper trail. However, when the agency finally delivers the software in month four, you often discover that the agreed-upon vision in the PDF does not actually feel right in the browser. At that point, changes are possible, but they are slow and expensive. Teams pay for safety early, but clarity arrives late.

Model C: Hybrid AI delivery

The hybrid model changes the order of delivery. It replaces fragile demos and long preparation cycles with a working V1 Alpha delivered in days.

In this model, tools like Hope AI accelerate construction, while experts ensure the software is properly structured. Rather than producing a single large application, the system builds independent and reusable components, such as authentication modules, data connectors and core workflows. Compared to the previous models, this approach works well because it:

Produces real, running software instead of static documents or throwaway demos
Integrates with production systems early, reducing late-stage surprises
Applies structure, testing and access control from the start

Each component is designed to deliver tests and documentation, which makes the V1 Alpha inspectable, maintainable and safe to hand off to an internal team.

To better understand how these models differ in practice, let's compare how each one answers the questions decision makers care about. These questions map directly to speed, cost, risk and clarity.

Stakeholder question	Model A: AI builder only	Model B: Traditional dev shop	Model C: Hybrid AI delivery
When do I see something real?	Minutes (fragile prototype)	Months (after discovery)	Days (Verified V1 Alpha)
What does "done" mean?	Syntax is returned.	Contract scope is fulfilled.	Screens and logic and tests are verified.
How do we scale?	Hard to refactor; usually a start over	Slow, manual and expensive	Add/update components independently
Who owns accountability?	The prompter	The Agency (until handoff)	Shared (Service builds V1 and Stakeholder decides V2)
What happens after the demo?	Likely rebuild for production	Expensive maintenance retainers	Assets ready to deploy or iterate
Scope control	Endless prompting	Change orders	Purchase specific Expert Hours
Cost predictability	Low (time sink)	Low (estimates slip)	High (Fixed start and hourly blocks)

Looking at the operational realities of these three paths, it is clear that the hybrid model offers a more balanced outcome than the traditional and AI-only models.

That conclusion, however, only describes the result. To understand why the hybrid model works, it helps to examine where the other two break down operationally.

Why the traditional and AI-only models break

The AI builder flaw: The missing owner

The AI-only model usually works right up until someone asks a simple question: "Who is responsible for this?"

Unlike traditional software projects, there is no natural transition from creation to ownership. The system appears complete, but responsibility never formally transfers, leaving the work suspended between a demo and a product. Even at the individual level, users often stall immediately after prompting because they cannot explain or defend the code they just built. This creates a fundamental disconnect where the person is the prompter while the AI is the architect, and neither is truly the owner.

Another reason an AI-only workflow fails is that it treats software as a visual task rather than an operational one. Within a real organization, software must survive an ecosystem of existing security standards, data privacy laws and technical debt. Because the AI has no knowledge of these constraints, and the prompter lacks the depth to bridge them, the model collapses the moment an official owner is required to vouch for the integrity of the system.

The dev shop flaw: The slow start

The traditional model fails because it separates spending from seeing. It starts with months of planning and meetings, which feels safe but is actually high risk. During this time, you are paying for a plan instead of a working product.

Because you are looking at documents instead of a live app, you have no way to verify if the vision is correct. You are essentially flying blind while the budget burns. By the time the software is finally delivered months later, you have usually spent too much money to change course. You are stuck with what was built, even if it no longer fits your needs.

The mechanism that makes hybrid delivery work

The core mechanism behind hybrid delivery is component-level isolation. It breaks the system into independent, reusable units that teams can inspect and adjust without introducing instability elsewhere.

This model reduces uncertainty by flipping when verification happens. Instead of validating late, it validates early. It uses AI to accelerate construction while enforcing structured output. Features are generated as reusable components with documentation and tests. Experts review the system continuously to keep it coherent and maintainable.

Additionally, since the output is production-grade from the beginning, the organization is not locked into a single vendor. Once the V1 Alpha is delivered, there is a clear decision point. The internal team can take ownership of the repository immediately, or the same team can continue execution using scoped expert hours.

Here's a typical workflow it follows to achieve that:

Define vision: The requirement is provided, such as a Figma design or technical spec.
AI augmented construction: Experts use Hope AI to generate the application by creating verified and reusable bits rather than messy raw code.
Delivery of V1 Alpha: Within days, the initial result is received. This is a functional V1 Alpha where screens and logic are verifiable.
The gap assessment: The team immediately identifies what is missing, usually requiring specific expert hours to handle tweaks, integrations and polish.
Strategic handoff: The stakeholder decides whether to take ownership of the code or retain experts for further execution.

The hybrid software delivery model structures the engagement as a safe test and moves validation from month three to day three, allowing leadership to confirm viability before committing significant resources.

Final thoughts

If the project is a demo, then AI-only builders are fine. They are fast and free, and it does not matter if the code breaks under pressure. If the project is a product with users, risk and accountability, then you need a delivery model that produces an inspectable baseline early. That is the hybrid model.

Projects requiring massive legacy overhauls may still find comfort in traditional dev shops. However, new products that need to exist in the real world, with real users, real security and real timelines, require a different approach. Waiting six months to see if an idea works is not affordable, nor is inheriting a broken AI demo.

Bit Cloud delivers a V1 Alpha in days rather than months. For teams looking to build with AI while maintaining delivery accountability, the hybrid model is becoming the practical default. If you have a vision that needs to be tested in the real world, start the hybrid process with Hope AI on Bit Cloud to get your V1 Alpha today.

The AI stack every developer will depend on in 2026

Asaolu Elijah 🧙‍♂️ — Tue, 19 May 2026 19:53:30 +0000

The past few years have been the era of AI copilots. Tools like Cursor and Claude Code showed what happens when intelligence is integrated directly into a developer's workflow. They can generate and refactor hundreds of lines of code in seconds. But teams that use them at scale also see their limits.

These tools are good at producing output but weak at continuity. They forget context, repeat past mistakes and aren't deeply integrated across the development pipeline. Their intelligence stops at the editor instead of extending into planning, testing and deployment. By 2026, that limitation is expected to fade with the rise of new frameworks and orchestration tools built for continuity.

From next year, the differentiator will not be model size. It will depend on whether your AI stack has persistent memory, reusable artifacts, versioning and orchestrated workflows that keep systems stable after the first prompt.

This article will explore the AI stack of 2026, drawing from current research, developer trends and early infrastructure experiments. You'll see how each stack layer fits together, the technologies worth exploring around each one and what steps you can take as a developer to prepare for the shift.

The 2026 AI stack at a glance

Before diving into each layer, here's a quick overview of how the AI stack fits together and what role each part plays.

Layer	Purpose	Example technologies	Key trend in 2026
Composable models	Combine specialized models for different tasks	vLLM, Replicate, Ollama, LangChain, CrewAI	Model orchestration replaces single-model workflows.
MCP and interoperability	Connect models and tools across environments	Model Context Protocol SDK, AutoGen	A shared context protocol becomes the default way systems coordinate.
Persistent memory components	Maintain long-term context and recall	MemOS, Pinecone, Weaviate, Milvus, Chroma	Memory becomes a durable, queryable runtime layer.
Versioned artifact registry	Track and version AI-generated outputs	Hope AI, Windsurf Cascade Memory	Versioned artifacts become the standard output of AI systems.
Human-AI collaboration interface	Connect developers directly with AI systems	Cursor, Windsurf, Claude Code	IDEs evolve into AI-first workspaces that blend memory and tooling.

With that overview in mind, let's start with the foundation of the stack and look at how composable models are reshaping AI development.

Composable models

In 2025, most AI workflows still depend on a single model. You send a prompt and get a response, and the interaction ends there. The models are powerful, but they work in isolation. Some platforms now let you swap models, such as switching from Gemini to Claude in the same interface, but it's still a manual process. You pick the model yourself; the platform doesn't yet decide which one fits the task best.

By 2026, that's expected to change. AI workflows will begin to use semantic routing, where an orchestrator automatically selects the best model or tool for each step. A typical workflow could look like using ChatGPT-5 for planning, Gemini for reasoning and Claude for fast code generation.

As shown in the image above, models will become composable components, working together like microservices in a distributed system. This shift is already in motion, and the tools driving innovation in this space include:

vLLM: Focuses on efficient multi-model serving and inference optimization
Replicate: Provides APIs for integrating diverse hosted models into shared pipelines
Ollama: Enables developers to run open-source models locally for testing and experimentation
LangChain and CrewAI: Orchestration frameworks evolving toward intelligent coordination across models and workflows

Scaling model size alone has already shown diminishing returns in many workflows. Research and production experience both show that context handling, memory and structured workflows drive more value than simply adding parameters. Composable models are the first indication that we are transitioning from a single, monolithic model approach to a stack-based approach.

From next year, intelligence will no longer reside in a single model but will flow across a network of interconnected systems, each optimized for a specific task.

MCP and interoperability

Once models become composable, the next challenge is getting them to work together across different environments. The Model Context Protocol (MCP) is already making its mark in this area. MCP defines a shared standard for how AI systems exchange context, capabilities and data.

By 2026, MCP will become the backbone of system-level interoperability. Instead of just linking models, it will connect entire development environments. A local build agent could coordinate with a cloud-hosted reasoning model, pull stored memory from a shared vector database and push validated outputs directly to a CI pipeline, all through a unified context layer.

An MCP-aware IDE will also sync project state, model preferences and access tokens across tools like Cursor, Replit and GitHub Codespaces. Context will move with the task across systems, not just across models. Multiple technologies and resources are already taking shape around this space, including:

Model Context Protocol SDK: The official toolkit for building MCP clients and servers
Spec-workflow-mcp: A workflow-oriented project showing how MCP integrates with developer operations and dashboards
LangChain and AutoGen: Frameworks beginning to adopt MCP-style orchestration to connect models, tools and agents across clouds and runtimes

For developers, this trend will shift AI from tool-by-tool integration to a shared context bus. By 2026, composable models and their orchestration layers will use MCP-like protocols to move tasks and memory between agents, CI systems and runtime environments.

Persistent memory components

Memory is still one of the weakest components of large language models. Even the latest models still rely on fixed context windows and don't have real memory. They can process huge amounts of text and give the feeling of continuity, but once a session ends, everything disappears. Each new interaction starts from zero, and the only way to maintain context is to resend past information, which is expensive.

This limitation comes from how transformer-based models work. They read and process the context you give them at a moment, but don't actually store anything. There is no persistent state, only temporary attention over recent tokens. What we call AI memory today is mostly clever caching that looks like recall but isn't.

That is beginning to change. Persistent memory is starting to form its own runtime layer, separate from the model. Instead of reloading context on every call, systems are starting to use external stores that track what a model learns, produces and references. These stores are structured, queryable and shareable across agents, turning context into a durable state rather than a disposable input.

By 2026, memory will act like a runtime layer. Models will read and write to persistent memory graphs that store embeddings, reasoning traces, dependencies and artifacts. Agents will build on existing state instead of recreating the same logic from scratch.

Technologies leading this shift include:

MemOS: A prototype architecture for persistent, composable and queryable agent memory
Pinecone: Expanding beyond vector storage to handle metadata, relationships and versioned embeddings
Milvus: Optimized for large-scale, distributed memory operations
LanceDB and Chroma: Lightweight local layers for fast recall and offline persistence

Other notable mentions include user-facing tools such as ChatGPT Projects and Perplexity Threads, where context now persists across sessions instead of resetting to zero.

These tools represent a transition from fixed context windows to memory graphs that store embeddings alongside reasoning traces, dependencies and results.

Versioned artifact registry

As AI systems gain memory, the next challenge is traceability. When a model generates a file, it's often unclear which version of the model produced it, what context it used or how that output has evolved. This lack of lineage makes debugging, testing and reuse difficult.

That gap is beginning to close. From next year, AI-generated code, documentation and data will be treated as versioned artifacts, with metadata describing their source model, parameters and compatibility. Registries will track how these artifacts change over time, making it easy to audit, reuse and refactor them like open-source libraries.

Each artifact will carry metadata such as persistent IDs and namespaces, version history, capabilities, compatibility notes, dependency graphs and test and validation results, including the inputs used to check it and the conditions where it's safe to reuse.

A new generation of platforms forming around this idea includes:

Hope AI (by Bit Cloud): An AI development agent that turns natural language into production-ready applications and manages a registry of reusable components with versioned capabilities, tests, docs, dependency graphs and a global memory of previous builds
Windsurf's Cascade Memory: A feature in the Windsurf editor that links AI outputs to their generative history, blending persistent memory with artifact management for better traceability and reuse

Git solved collaboration for human-written code. The 2026 AI stack needs the same for AI-generated artifacts, and Bit Cloud is building that layer.

Human-AI collaboration interface

The top layer of the stack is where humans and AI systems meet. AI coding tools such as Cursor, Windsurf and Claude Code are already making waves here, analyzing project files, generating multi-file implementations, explaining reasoning and even drafting pull requests.

Still, they mostly operate within the local workspace. They understand your codebase but rarely connect to the broader system context. Once code leaves the IDE, the AI often loses awareness of how it fits into your build process. That's the gap the next generation of environments is aiming to close.

By 2026, IDEs will be less of a text editor and more of a control plane for the AI stack. They'll surface memory graphs, orchestration flows and artifact history alongside the code itself. A developer might inspect how an agent arrived at a decision, which dataset or model it used and how its output evolved, all from within the same interface.

The next wave of IDEs will also track code beyond the local workspace. They'll follow it through build, runtime and deployment so the AI keeps the bigger picture even after changes leave the editor.

As all these layers come together, your role as a developer will evolve along with the tools you use.

What this shift means for developers

Over the next few years, your day-to-day work will undergo visible changes. You will still write code, but you will also take on new tasks that come with AI-native development. You will:

Review AI-generated artifacts in pull requests and treat them as first-class components
Decide when to reuse an existing artifact instead of regenerating one
Debug memory graphs, dependency links and reasoning traces when something breaks
Manage persistent memory as part of the normal workflow
Choose orchestration engines the same way teams choose CI systems
Curate shared component libraries that span multiple projects

For team leads, practices such as versioning AI artifacts and using orchestration frameworks are already becoming standard across AI infrastructure teams. Adopting these habits early will make the move toward AI-native development much smoother as the ecosystem matures.

Looking forward

From next year, most teams will move from single-model prompting to composable models, managing memory graphs and curating AI artifacts as part of their core engineering workflow. The teams that treat memory, reuse and versioning as infrastructure will move faster and ship more stable systems.

Platforms like Bit Cloud and Hope AI are early examples of this stack in action, combining composability, global memory and artifact versioning into a production-grade workflow.

Web scraping for AI agents: How to give your agents web access

Asaolu Elijah 🧙‍♂️ — Mon, 13 Apr 2026 19:28:45 +0000

AI agents are only as useful as the information they can act on. A reasoning model with a January knowledge cutoff can't tell you today's pricing, yesterday's news, or what your competitor just changed on their homepage. Giving your agent a way to reach out and pull fresh data from the web is how you fix that.

Web scraping is how you do that. This guide walks through how it works, what breaks, and how to wire it cleanly into an AI agent workflow.

Why agents need live web access

Most LLMs are trained once and frozen. They know a lot, but that knowledge has an expiry date. This creates a fundamental problem for agents doing anything time-sensitive:

A research agent summarizing a competitor's product page will surface stale pricing.
A lead generation agent building contact lists from directories misses companies founded last month.
A news monitoring agent trained on data from six months ago isn't monitoring anything.
A price tracking agent with no live feed is just guessing.

Equipping your agent with a tool call that fetches current HTML, parses it intelligently, and returns structured data is how you solve this.

What scraping looks like in an agent loop

In practice, scraping fits into an agent's tool-use loop the same way a database query or API call does. The agent decides it needs information from a URL, calls the scraping tool, gets back structured data, and continues reasoning.

Agent needs: "What's the current price of product X?"
  → calls scrapeUrl(url, prompt)
  → gets back: { "name": "Product X", "price": 49.99, "currency": "USD" }
  → continues: "The price is $49.99, which is $5 lower than last week..."

This workflow is also represented in the diagram below:

The key design question is: what does scrapeUrl actually do under the hood?

Different scraping approaches

There are a few ways to implement web access for an agent. They sit on a spectrum of complexity vs. reliability.

Raw HTTP + HTML parsing

The simplest approach: fetch the URL with fetch, parse the HTML with a library like Cheerio, extract what you need with selectors.

import * as cheerio from "cheerio";

async function scrape(url) {
  const res = await fetch(url, { headers: { "User-Agent": "Mozilla/5.0" } });
  const html = await res.text();
  const $ = cheerio.load(html);
  return $("body").text();
}

The problem: Most modern websites don't return meaningful HTML on the first HTTP request. They're JavaScript-rendered. The above returns a shell. The content loads after JS executes. You'll also get blocked quickly with no proxy rotation.

Headless browsers

Tools like Playwright and Puppeteer launch a real browser, wait for JS to execute, then let you extract content. More reliable for modern sites.

import { chromium } from "playwright";

const browser = await chromium.launch();
const page = await browser.newPage();
await page.goto(url);
await page.waitForLoadState("networkidle");
const content = await page.content();
await browser.close();

The problem: This is expensive to run at scale. Infrastructure, browser pools, proxy management, and CAPTCHA handling all become your problem. And sophisticated anti-bot systems will still block you based on browser fingerprinting.

Scraping APIs

The third option: delegate all of that to a purpose-built API. You send a URL and a description of what you want. The API handles browser automation, proxy rotation, CAPTCHA solving, and returns clean structured data.

For agents, this is almost always the right call. You get a simple async interface, reliable results, and you're not managing headless browser infrastructure.

The real challenges (and why they matter for agents)

Before picking an approach, understand what actually breaks in production:

Anti-bot detection: IP rate limiting, CAPTCHA challenges, browser fingerprinting. If your agent scrapes the same site repeatedly, naive implementations get blocked fast.
JavaScript-rendered content: Most product pages, social feeds, and dashboards render content after the initial HTML loads. Raw HTTP fetches get empty shells.
Unstructured output: Raw HTML or even extracted text isn't what your agent wants. Agents reason better over {"price": 49.99} than over a wall of text that contains the price somewhere.
Async workflows: Scraping takes time (seconds, not milliseconds). Your agent can't block waiting for a result. You need job submission, polling, and async result handling baked in.
Scale: If your agent processes 100 leads at a time, you need batch processing. Running 100 sequential scrape calls is slow and fragile.

What agent-ready scraping looks like

Here's what the ideal scraping tool looks like from an agent's perspective:

Natural language prompts: The agent describes what it wants, not how to get it. "Extract the job title, company, and salary range" rather than a CSS selector.
Structured JSON output: Returns a typed object matching a schema the agent defines. No parsing, no regex, no string manipulation.
Async with polling: Submit a job, get a job ID, poll for results. Non-blocking.
Proxy and anti-bot handling built in: The agent doesn't care about IP rotation. That's infrastructure.
Batch support: Submit 50 URLs at once, get 50 results back.

Let's build this.

Practical Implementation

The following examples use Spidra, an API built specifically for this pattern: browser automation, proxy rotation, CAPTCHA solving, and AI-powered extraction in one endpoint. The concepts translate to any scraping API with similar capabilities.

Setup

Get an API key from app.spidra.io → Settings → API Keys.

Base URL: https://api.spidra.io/api
Auth: x-api-key header on every request.

Example 1: Simple scrape tool for an agent

The pattern is always the same: submit a job, get a jobId, poll until complete.

const API_KEY = "your-api-key";
const BASE_URL = "https://api.spidra.io/api";
const HEADERS = { "x-api-key": API_KEY, "Content-Type": "application/json" };

async function scrape(url, prompt, schema, options = {}) {
  const payload = {
    urls: [{ url }],
    prompt,
    output: "json",
    useProxy: true,
    ...(schema && { schema }),
    ...options,
  };

  const res = await fetch(`${BASE_URL}/scrape`, {
    method: "POST",
    headers: HEADERS,
    body: JSON.stringify(payload),
  });
  const { jobId } = await res.json();

  while (true) {
    const status = await fetch(`${BASE_URL}/scrape/${jobId}`, {
      headers: HEADERS,
    }).then((r) => r.json());

    if (status.status === "completed") return status.result.content;
    if (status.status === "failed") throw new Error(status.error);

    await new Promise((r) => setTimeout(r, 3000));
  }
}

Now your agent has a clean tool call:

const result = await scrape(
  "https://news.ycombinator.com",
  "List the top 5 stories with title, points, and comment count",
  {
    type: "object",
    required: ["stories"],
    properties: {
      stories: {
        type: "array",
        items: {
          type: "object",
          required: ["title", "points", "comments"],
          properties: {
            title: { type: "string" },
            points: { type: "number" },
            comments: { type: "number" },
            url: { type: ["string", "null"] },
          },
        },
      },
    },
  }
);

// result.stories → [{ title, points, comments, url }, ...]

The agent gets back a typed list it can iterate, filter, and reason over. No parsing.

Example 2: Structured output with JSON schema

The schema field is the most important feature for agent use. Instead of getting unpredictable text, you define the exact shape of the response and the API enforces it.

Here's a job listing extractor:

const result = await scrape(
  "https://jobs.example.com/senior-engineer",
  "Extract all details about this job listing.",
  {
    type: "object",
    required: ["title", "company", "remote"],
    properties: {
      title: { type: "string" },
      company: { type: "string" },
      location: { type: ["string", "null"] },
      remote: { type: ["boolean", "null"] },
      salary_min: { type: ["number", "null"] },
      salary_max: { type: ["number", "null"] },
      employment_type: {
        type: ["string", "null"],
        enum: ["full_time", "part_time", "contract", null],
      },
      skills: {
        type: "array",
        items: { type: "string" },
      },
    },
  }
);

// Guaranteed shape: fields in `required` always present, nullable where marked
// {
//   title: "Senior Engineer",
//   company: "Acme Corp",
//   location: "Austin, TX",
//   remote: true,
//   salary_min: 140000,
//   salary_max: 180000,
//   employment_type: "full_time",
//   skills: ["TypeScript", "React", "AWS"]
// }

Two rules worth knowing:

Fields in required always appear, as null if the data isn't found.
Optional fields are omitted entirely if unavailable.
Mark anything that might be missing as ["type", "null"] to avoid surprises.

Example 3: Crawling an entire site

Sometimes your agent doesn't know which pages to scrape. It needs to discover them. The crawl endpoint handles this: give it a base URL, tell it which pages to find, and what to extract from each.

async function crawlSite(baseUrl, crawlInstruction, extractInstruction, maxPages = 20) {
  const res = await fetch(`${BASE_URL}/crawl`, {
    method: "POST",
    headers: HEADERS,
    body: JSON.stringify({
      baseUrl,
      crawlInstruction,
      transformInstruction: extractInstruction,
      maxPages,
      useProxy: true,
    }),
  });
  const { jobId } = await res.json();

  while (true) {
    const data = await fetch(`${BASE_URL}/crawl/${jobId}`, {
      headers: HEADERS,
    }).then((r) => r.json());

    if (data.status === "completed") return data.result;
    if (data.status === "failed") throw new Error("Crawl failed");

    console.log(data.progress?.message ?? "crawling...");
    await new Promise((r) => setTimeout(r, 5000));
  }
}

// Example: crawl a competitor's blog for content strategy research
const posts = await crawlSite(
  "https://competitor.com/blog",
  "Find all blog post pages published in the last 6 months",
  "Extract the title, author, publish date, and a one-sentence summary",
  30
);

// posts → [{ url, title, data: { title, author, publish_date, summary } }, ...]

Example 4: Geo-targeted scraping

Some sites show different content based on the visitor's country: prices in local currency, region-specific inventory, geo-restricted offers. Use proxyCountry to scrape from a specific location.

// Scrape a German Amazon page with a German IP
const result = await scrape(
  "https://www.amazon.de/gp/bestsellers/electronics",
  "List the top 10 bestselling electronics with name and price in EUR",
  {
    type: "object",
    required: ["products"],
    properties: {
      products: {
        type: "array",
        items: {
          type: "object",
          properties: {
            name: { type: "string" },
            price_eur: { type: ["number", "null"] },
            rank: { type: "number" },
          },
        },
      },
    },
  },
  { proxyCountry: "de" }
);

// Spidra supports 50+ country codes: us, gb, de, fr, jp, au, ca, br, in, ...
// Use "eu" for rotating EU proxies, "global" for worldwide rotation

Example 5: Authenticated scraping

For pages behind a login: dashboards, account pages, paywalled content. Pass session cookies directly.

// Export cookies from your browser DevTools (Application → Cookies)
// or grab them with document.cookie from the console

const result = await scrape(
  "https://app.example.com/dashboard/reports",
  "Extract monthly revenue, active users, and conversion rate for the last 3 months",
  {
    type: "object",
    required: ["months"],
    properties: {
      months: {
        type: "array",
        items: {
          type: "object",
          properties: {
            month: { type: "string" },
            revenue: { type: "number" },
            active_users: { type: "number" },
            conversion_rate: { type: "number" },
          },
        },
      },
    },
  },
  { cookies: "session=abc123; auth_token=xyz789; csrf=def456" }
);

Wiring it into an agent (full example)

Here's a minimal but complete research agent using the Vercel AI SDK with scrapeUrl as a tool. The SDK handles the agentic loop: the model decides when to call the tool, the tool fetches live data, and the model reasons over the result.

import { generateText, tool } from "ai";
import { anthropic } from "@ai-sdk/anthropic";
import { z } from "zod";

const result = await generateText({
  model: anthropic("claude-opus-4-6"),
  maxSteps: 5,
  tools: {
    scrapeUrl: tool({
      description:
        "Fetch and extract structured data from a URL. Use this when you need current information from a website.",
      parameters: z.object({
        url: z.string().describe("The URL to scrape"),
        prompt: z
          .string()
          .describe("What to extract from the page, in plain English"),
      }),
      execute: async ({ url, prompt }) => {
        const data = await scrape(url, prompt);
        return JSON.stringify(data);
      },
    }),
  },
  prompt:
    "What are the top 3 trending repositories on GitHub today, and what do they do?",
});

console.log(result.text);

maxSteps lets the model make multiple tool calls in sequence if it needs to follow links, cross-reference sources, or refine its query. The scraping layer handles everything else. The model just decides what to fetch and what to ask for.

Practical agent use cases

To make this concrete, here are a few agent patterns that become viable with web access:

Competitive intelligence agent: Crawls competitor sites weekly, diffs pricing and feature changes, surfaces meaningful deltas to a Slack channel.
Lead enrichment agent: Given a list of company names, scrapes their websites, LinkedIn pages, and job boards to build structured profiles: company size, tech stack, recent hires, open roles.
Research agent: Given a topic, searches the web, scrapes the top results, synthesizes findings into a structured report with citations.
Price monitoring agent: Tracks SKUs across multiple retailers, alerts when prices drop below a threshold or when a product goes out of stock.
News digest agent: Crawls a configured list of sources each morning, extracts headlines and summaries, sends a curated briefing tailored to the user's interests.

Each of these follows the same fundamental pattern: the agent knows what it wants, the scraping layer fetches and structures the data, and the agent reasons over clean output rather than raw HTML.

Wrapping up

Web access expands the category of problems an AI agent can tackle. A scraping tool lets it monitor competitor pages, research live topics, track prices, and respond to things happening right now. Without it, your agent is limited to reasoning over whatever it already knows.

The implementation is straightforward: a submit-and-poll pattern, a JSON schema for the output shape, and a proxy-enabled API to handle the infrastructure. The agent doesn't need to know how any of that works. It just needs a reliable tool call that returns structured data. That's the interface worth building toward.

Thanks for reading!

Understanding JavaScript Deobfuscation in Web Scraping

Asaolu Elijah 🧙‍♂️ — Sat, 19 Apr 2025 15:34:05 +0000

Obfuscation is the process of deliberately making information more complex and harder to understand. Deobfuscation, on the other hand, is the method of reversing obfuscation to reveal the original information.

Since web browsers have to expose webpages' source code, developers usually use different obfuscation techniques to make their code harder to read. This, in turn, makes life harder for web scrapers trying to pull useful content from such web pages.

In this article, you’ll learn about obfuscating and deobfuscating web pages and practical tips for scraping data from obfuscated content.

How Web Pages are Obfuscated

Common methods for obfuscating web pages include:

CSS Obfuscation

Modern front-end build tools like Webpack and CSS modules provide features to obfuscate class names and IDs in HTML. They achieve this by generating unique or hashed class names that are difficult to predict. For example, a simple CSS class-based styling might look like this before obfuscation:

.button {
    color: blue;
}

After obfuscation with Webpack, the class might look like this:

._3iJ7sK {
    color: blue;
}

Now, in the HTML, a button that previously used class="button" might use class="_3iJ7sK", which limits scrapers that rely on known class names to locate elements.

JavaScript Obfuscation with btoa

JavaScript also has a native btoa() function that converts a string into a base64-encoded string. While it’s a simple form of obfuscation, it does make raw text less readable. For example:

const originalString = "Hello, World!";
const encodedString = btoa(originalString);

console.log(encodedString); // Outputs: "SGVsbG8sIFdvcmxkIQ=="

This technique is mostly used in HTML attributes, where encoded data is stored directly. For example, instead of seeing plain text in a data-* attribute, you might find something like data-value="U29tZSBzZWNyZXQgdGV4dA==". Here, btoa has been used to encode "Some secret text," which makes it less obvious to identify at a glance.

Deobfuscation Techniques in Web Scraping

There are multiple strategies for scraping obfuscated web pages. Some common methods I've found useful include:

CSS Selectors with Substring Matching

When CSS classes are obfuscated, matching the exact class name can be tricky, as they may look like random strings that change frequently. To handle this, you can use substring matching in your CSS selectors. This way, you can match any class name containing a specific pattern, even if the entire name isn’t consistent.

For example, let’s say you’re scraping a site where the "buy" button has a class name that always includes the substring _buyBtn_, but the full class name might look something like _buyBtn_3iJ7sK or _buyBtn_x9L2kT. Instead of trying to match the whole class name exactly, you can use:

[class*="_buyBtn_"]

This selector matches any class containing _buyBtn_. You can implement it in your scraper, as shown in the Node.js and Cheerio example below.

const axios = require("axios");
const cheerio = require("cheerio");

// Sample URL
const url = "http://example.com";

axios.get(url).then((response) => {
    const $ = cheerio.load(response.data);

    // Find the button using substring matching
    const buyButton = $('[class*="_buyBtn_"]');

    // Output the text inside the matched button element
    console.log(buyButton.text());
}).catch(error => {
    console.error("Error fetching the page:", error);
});

This way, you can focus on a stable part of the class name (buyBtn) and reliably locate the necessary elements, even with obfuscation.

XPath with Wildcards

XPath is another way to locate elements in HTML, similar to CSS substring matching; however, XPath allows for more complex logic. You can search for elements based on attributes, match elements by text content, navigate the document structure, and much more.

For example, if you’re targeting an element with an obfuscated class attribute, you can use a wildcard like this:

//div[contains(@class, '_3iJ7sK')]

This XPath expression matches any <div> element where the class attribute includes _3iJ7sK. You can then implement the expression in a puppeteer and Node.js scraper, as shown below.

const puppeteer = require("puppeteer");

(async () => {
    const browser = await puppeteer.launch();
    const page = await browser.newPage();

    // Sample URL
    const url = "http://example.com";
    await page.goto(url);

    // Find a div element with a class containing "_3iJ7sK"
    const [targetElement] = await page.$x("//div[contains(@class, '_3iJ7sK')]");

    if (targetElement) {
        // Extract and print the text content
        const text = await page.evaluate(element => element.textContent, targetElement);
        console.log(text);
    } else {
        console.log("Element not found");
    }

    await browser.close();
})();

As mentioned earlier, XPath can also select elements based on any attribute, not just class:

// Searches for a button element with type='submit'
page.$x("//button[@type='submit']")

Select elements based on their text content.

// Selects an <a> tag with the exact text 'Click here'
page.$x("a[text()='Click here']")

XPath’s advanced logic makes it useful for scraping complex HTML structures with a level of precision that CSS selectors don't provide.

Decoding Base64 with atob

If you come across content encoded with btoa(), you can easily decode it using the atob() function, as shown below:

const encodedString = "SGVsbG8sIFdvcmxkIQ==";
const decodedString = atob(encodedString);

console.log(decodedString); // Outputs: "Hello, World!"

While this might not be useful for scraping selectors, it can help you better understand the targeted content’s markup structure, especially in data attributes.

Conclusion

Obfuscation is becoming increasingly common in web development, creating challenges for web scrapers that rely on structured data. This tutorial explored how these obfuscation techniques are implemented and provided methods to help overcome them.

Cover photo by Chris Stein on Unsplash

How to Integrate Ollama in Next.js

Asaolu Elijah 🧙‍♂️ — Thu, 06 Feb 2025 12:03:38 +0000

There’s no ignoring how AI and and large language models (LLMs) have dominated conversations lately. Nearly every week, new models are released, and new integrations (e.g AI agents and operators) are developed. It’s crazy not to want to jump on this exciting train.

In this article, we’ll explore how to integrate Ollama with Next.js to build LLM-powered applications. We’ll cover how to download and interact with open-source LLMs (such as Llama, DeepSeek, and Mistral), as well as how to send messages and process LLM responses in Next.js using ollama.js. Our final application will look like the image shown below.

Prerequisite

To follow along, you should have a basic understanding of Next.js and how LLMs work behind the scenes.

What is Ollama?

Ollama is an open-source framework founded by Michael Chiang and Jeffrey Morgan to simplify LLM integration with other applications. Ollama itself is not an LLM; instead, it allows you to download LLMs, interact with them, and create custom models. It also provides pre-configured API endpoints with which you can integrate downloaded or customized LLMs into other applications.

It’s also worth mentioning that Ollama should not be confused with Llama (without the "O"). Llama is an open-source LLM developed by Meta AI. In contrast, Ollama is an independent open-source tool that enables integration with various LLMs. With that clarified, let’s explore these integrations in practice.

Setting up ollama

To get started, download Ollama from its official website. If you’re using other Unix/Linux distro, you can also download it by running the following command.

curl -fsSL https://ollama.com/install.sh | sh

Once you’ve successfully downloaded and installed Ollama, run the following command to verify that it is now executable on your terminal/command line.

ollama -v

If everything went well, you should see the version number printed in your console. Next, let’s install and interact with our first model.

Pull and run a model

As mentioned previously, Ollama provides access to multiple open-source models, including DeepSeek, Llama, Mistral, Qwen, and Phi. You can also view the list of supported models here.

From the model list, Llama 3.2 (by Meta AI) presently stands out as a small-sized model with impressive benchmark stats. It is available in two variants: 1B parameters (1.3GB) and 3B parameters (2GB). For this tutorial, we’ll use the Llama 3.2 1B model, as its smaller size makes it more manageable. To proceed, download the model by running:

ollama run llama3.2:1b

This command will pull the Llama 3.2 (1B parameters) model from Meta’s registry. Once the download is complete, the model will launch, and you can start chatting with it right away, as shown in the screenshot below.

Feel free to spend some time interacting with the LLM directly from your terminal. Once you're ready, let’s dive into bringing it into a Next.js application.

Interact with LLMs in Next.js with Ollama.js

Ollama provides REST API endpoints that allow you to interact with downloaded models. Once the desktop app is running, it exposes an endpoint at http://localhost:11434/api, where you can send custom HTTP requests to perform interactions.

For example, to generate an answer to the question "What is Exorcism?", we can send a POST request to the /api/generate endpoint, specifying our preferred model and question, as shown below:

curl http://localhost:11434/api/generate -d '{
"model": "llama3.2",
"prompt": "What is Exorcism?"
}'

You should then see the response objects streamed to your command line or terminal in real-time:

To simplify the process, the Ollama team created a JavaScript library (ollama-js) that comes pre-configured with various methods for referencing these endpoints and performing different tasks. We’ll leverage this library in our application.

To proceed, create a new Next.js app by running the following command:

npx create-next-app next-ollama

During the installation process, select Tailwind CSS and the pages/ router to ensure consistency with this tutorial. All other configuration options can be customized to your preference.

Once your new Next.js app is successfully created, navigate to the project directory and install ollama-js by running the following commands:

cd next-ollama
npm install ollama

Next, let’s create a simple chat interface to interact with the LLM we installed earlier. Open the default pages/index.js file and replace its contents with the following code:

import { useState } from "react";

const Index = () => {
  const [messages, setMessages] = useState([]);
  const [input, setInput] = useState("");
  const [isLoading, setIsLoading] = useState(false);

  const handleSubmit = async (e) => {
    e.preventDefault();

    const userMessage = { role: "user", content: input };
    setMessages((prevMessages) => [...prevMessages, userMessage]);
    setInput("");

    /* ====
    ⚠️ Main logic to be added later
    ==== */
  };

  return (
    <div className="max-w-2xl mx-auto p-4">
      <div className="bg-white min-h-[400px] p-4 mb-4 rounded-xl border-2 border-gray-500 overflow-y-auto">
        {messages.map((message, index) => (
          <div
            key={index}
            className={`mb-4 ${
              message.role === "user" ? "text-right" : "text-left"
            }`}
          >
            <div
              className={`inline-block p-3 rounded-2xl max-w-[80%] ${
                message.role === "user"
                  ? "bg-blue-600 text-white"
                  : "bg-gray-100 text-gray-800"
              }`}
            >
              {message.content}
            </div>
          </div>
        ))}
        {isLoading && (
          <div className="text-left">
            <div className="inline-block p-3 rounded-2xl bg-gray-100 text-gray-400">
              Thinking...
            </div>
          </div>
        )}
      </div>
      <form onSubmit={handleSubmit} className="flex gap-3">
        <input
          type="text"
          value={input}
          onChange={(e) => setInput(e.target.value)}
          className="flex-1 p-3 rounded-xl border-2 border-gray-500"
          placeholder="Type your message..."
        />
        <button
          type="submit"
          className="bg-blue-600 text-white px-6 py-3 rounded-xl hover:bg-blue-700 transition-colors font-medium"
        >
          Send
        </button>
      </form>
    </div>
  );
};

export default Index;

The code above creates a basic chat interface that allows us to send messages and receive responses. It also includes a handleSubmit() function, which doesn’t do much at this point, but this is where we’ll add the logic to process our messages with Ollama.

Start your application by running:

npm run dev

You should then see a chat interface similar to the image below.

Now, let’s create an API endpoint to send our message to Llama 3.2 via Ollama and process the response. To do this, create a new chat.js file inside the default pages/api/ directory and paste the following code into it.

import ollama from "ollama";

export default async function handler(req, res) {
  if (req.method !== "POST") {
    return res.status(405).json({ error: "Method not allowed" });
  }

  try {
    const { message } = req.body;

    const response = await ollama.chat({
      model: "llama3.2",
      messages: [{ role: "user", content: message }],
    });

    return res.status(200).json({ message: response.message.content });
  } catch (error) {
    console.error("Ollama API error:", error);
    return res.status(500).json({ error: "Failed to get response from LLM" });
  }
}

Here, we imported Ollama and created a Next.js API endpoint that accepts POST requests with a message in the request body. Next, we called Ollama’s .chat() method, specifying the LLM model we installed earlier (llama3.2) and passing the received message as part of the request object.

To complete our integration, let’s update the main chat interface to communicate with the newly created endpoint. Open the pages/index.js file and replace the existing handleSubmit() function with the code below.

 const handleSubmit = async (e) => {
    e.preventDefault();
    if (!input.trim()) return;

    const userMessage = { role: "user", content: input };
    setMessages((prevMessages) => [...prevMessages, userMessage]);
    setInput("");
    setIsLoading(true);

    try {
      const response = await fetch("/api/chat", {
        method: "POST",
        headers: {
          "Content-Type": "application/json",
        },
        body: JSON.stringify({ message: input }),
      });

      if (!response.ok) {
        throw new Error("Failed to get response");
      }

      const data = await response.json();
      const aiMessage = {
        role: "assistant",
        content: data.message,
      };
      setMessages((prevMessages) => [...prevMessages, aiMessage]);
    } catch (error) {
      console.error("Error:", error);
      const errorMessage = {
        role: "assistant",
        content: "Sorry, I encountered an error while processing your request.",
      };
      setMessages((prevMessages) => [...prevMessages, errorMessage]);
    } finally {
      setIsLoading(false);
    }
  };

At this stage, your pages/index.js file should match the one provided here. Finally, start your app by running:

npm run dev

Go to the URL displayed in your console (typically http://localhost:3000/), and you should now be able to chat with the Llama 3.2 LLM directly from your Next.js app, as shown in the image below.

And we’re done! You can now start interacting with a locally downloaded version of Llama 3.2 directly from your Next.js application. You can also pull other open-source models and interact with them.

Conclusion

In this tutorial, we covered how to install and download open-source large language models (LLMs) with Ollama, as well as how to use the ollama-js library to integrate these LLMs into a Next.js application. You can find the complete code used in this tutorial in this GitHub repository.

In an upcoming follow-up article, we’ll explore how to stream responses and display them in real-time instead of waiting for the final computed response. We’ll also cover how to make the LLM remember our previous conversations, along with other ollama-js methods and community integrations. In the meantime, enjoy chatting with your custom-built LLM friend!

Thanks for reading!

Captio: Video Subtitles in Different Languages

Asaolu Elijah 🧙‍♂️ — Mon, 11 Apr 2022 23:41:00 +0000

Overview of My Submission

Language has always been a barrier, but now, with recent technologies, we can translate live text in real time.

However, this does not apply to video; it is still quite difficult to do so. And I'm sure we've all been in a position where we've seen a video clip on the internet (usually with a lot of interaction) and couldn't get the gist of it because it wasn't in our native language. Captio solves this barrier.

Captio is a powerful bot that will generate subtitle for video files in any preferred language. Available via the following medium:

Twitter Bot - Twitter is inarguably one of the most used social media platform in the world, and it does make sense that a technology like this one is available on there.
Check out caption on Twitter.
CLI Application - Captio is also available as a CLI application, so that you are able to generate translated subtitles offline.

Submission Category:

Accessibility

Link to Code on GitHub

AsaoluElijah / generate-sub

Captio: Video Subtitles in Different Languages

Twitter bot x Cli program to generate subtitles in different languages.

Read article on Dev.to

Installation

git clone https://github.com/AsaoluElijah/generate-sub captio
cd captio
npm install

API Keys

Once the installation is completed, make sure to rename .env.example to .env and replace all the Twitter API keys and the Deepgram API key with yours.

Learn how to retrieve your Twitter API keys here, and Deepgram's here too.

Usage

Cli

npm run start:cli video="path/to/video" language='spanish'
# Replace spanish with preferred language.

Twitter Bot

npm start:bot

License

MIT

View on GitHub

How it works

Behind the seen, Captio uses a lot of open source API to perform it's operation, the diagram below sums it up pretty much.

Nevertheless, you can checkout the full information on how it works here

Usage

On twitter, to let captio generate translated subtitle for a video tweet, you'll only need to reply the tweet mentioning captio (@generate_sub) like below:

Getting Started With Nuxt.js - The How & Why

Asaolu Elijah 🧙‍♂️ — Tue, 24 Nov 2020 22:03:12 +0000

What is Nuxt.js

Nuxt.js is an intuitive vue.js framework (yeah, a framework’s framework) for building faster and scalable - static, server-side rendered (SSR) & single page applications (SPA’s).
Nuxt.js is lovable because its included with vue core plugins by default (vue-router, vuex, vue-head,...), so no extra effort in installing them.

Features (why 🤷🏽):

Auto import component: You do not have to...

import componentName from ‘componentFolder’
export default {
  components: {
     componentName
   }

...for each of your components. Nuxt.js does that for you already, all you need do is keep all of your components in a folder and you could start referencing them anywhere in your application without doing the extra import.

P.S: there’s an option to disable this feature, in a case where you’re not interested in using it.

Auto generate router: Yeah, routers are also generated automagically. For every new page or page/:slug you create, the routers are immediately generated/updated (awesome right?).
Middleware support: Nuxt.js makes authentication in a vue.js based application seamlessly easy. You get to easily create and specify which middleware belongs to what page.
More awesome features: The why list is literally endless. There are more features that nuxt.js provide for each pages, for example asyncData - that lets you render data before your page is mounted into view. But these features won’t be covered in this article, another one maybe.

Installation (How 🚀):

Nuxt.js can be installed by downloading the nuxt package from npm via:

npm install nuxt —- save

But, with this installation process, you’ll need to go through an extra step of creating the nuxt configuration file plus the folders required for your application (which is quite exhausting, IMO).

Another option is using - create-nuxt-app : an npx package created by the nuxt community.
With this installation option, you will be prompted to select your type of application (SPA, SSA or static), select a front-end framework (bootstrap, vuetify or tailwind css) plus your preferred test and linting tool. And the nuxt configuration file will be generated automatically for you along with a sample nuxt.js application.

Getting Started

Lets go ahead and create a basic Nuxt.js application. Open your terminal/command line CD to your project folder and...

npx create-nuxt-app sample-project

Select rendering mode: Here you select the type of application you are building. Universal - support for server side rendered applications. And Single page application - For static/JAMStack based application.
Deployment target - Here you specify how your application will be deployed. Static for Jamstack based hosting (like Netlify, github pages) and Server for Node.js based hosting (like Heroku and AWS). The other required information are quite descriptive, like selecting programming language of choice (JavaScript/typescript), front-end framework and other related stuffs.

After completing the above installation process, lets go ahead and open the project in your text-editor. I use vscode, so -

cd sample-project
code .

Directory structure

.nuxt/ - This folder is automatically generated and regenerated any time you start/build your projects - this is where routers, middleware and other related configs are created. we shouldn’t worry so much about this.
assets/ - This is where you keep your un-compiled assets including images, CSS, sass and fonts files.
components/ - This is where you keep your components files, of course.
pages/ - This folder contains your application views and routes, Nuxt.js reads all the .vue files inside this directory and automagically creates the router configuration for you.
static/ - Here you keep static files that likely won't be changed. Unlike the assets dir, these files will be accessible through your project root URL. For example: /static/robots.txt will be available at http://localhost:3000/robots.txt
nuxt.config.js - This file contains nuxt based configuration settings, here we can easily configure the default head (title, meta-tags) for each pages, add a global css file, configure build option, and many more.

Running/Building

To run our app locally, all we need do is:

npm run dev

And our app should be served at http://localhost:3030 (or some other port, if :3030 is unavailable).

If you’re building a static site, the distribution files can be generated by running..

npm run generate

After the build is completed, a new dist/ folder will be created in your root directory. The content of this folder is what you host on your preferred platform - Netlify, GitHub pages, e.t.c.

And if you are building a server side rendered application (SSR), here is an extensive article that should be helpful.

Conclusion

I guess I’ve been able to introduce you to what Nuxt.js is, why you should use it, plus how to get started.

Where to go from here?

The Nuxt.js documentation is quite extensive and pretty straightforward. It’s included with everything you need to know about Nuxt.js.

Fell free to also reach out to me on Twitter. 🕺 I’m open to discussing literally anything tech related.

Thanks for reading. 👏

How I Made My Personal Website 10x Faster ⚡

Asaolu Elijah 🧙‍♂️ — Fri, 28 Aug 2020 15:12:15 +0000

I'd recently recreated my personal website, and the page load time reduced to < 1.6s 😮.
You don't believe it? Check it out here to clear your doubts.

Note: While my personal website is built with Nuxtjs (Vue.js), all of the tips I'll be sharing could be easily implemented in whatsoever technology/framework you use.

Light house Report 🚀

Without much Ado, let's dive into the tips.

1. Lazy load image:

Lazy loading image in it's simplest term means waiting for your website contents to appear before displaying images asynchronously. Although you should show a placeholder - like a gray box - notifying the user that an image will be loaded here.

Why lazy load images?

Images could weigh alot most time, and this can have a negative impact on the time visitors have to wait before they can access your website content.

How to lazy load image

Most front-end frameworks (bootstrap, materialize, chakra ui) these days provide a component to easily lazy load images on your website, kindly consult their documentation for more info; And if you're using just traditional HTML, CSS and JavaScript - this article might be helpful

Below is an example of lazy loading with BootstrapVue

<template>
  <div> 
     <b-img-lazy v-bind="mainProps" :src="getImageUrl(80)" alt="Image 1">
     </b-img-lazy>
  </div>
</template>
  <script>
  export default {
   data() {
    return { 
    mainProps: { 
    center: true, fluidGrow: true, blank: true, blankColor: '#bbb', width: 600, height: 400, class: 'my-5' 
   } 
  }
 },
 methods: {
 getImageUrl(imageId) {
   const { width, height } = this.mainProps
   return `https://picsum.photos/${width}/${height}/?image=${imageId}`
    }
  }
}
 </script>

2. Avoid unused component

In the first version of my website, I was using vue-ionicons and I'd imported a whole icon set globally 🤦‍♂️.
You could image how long a user will have to wait before hundreds of icon components (that I'm not really using in the website) are loaded. That wasn't funny really 😬

If using an icon component for example, avoid declaring the whole icon set as a global component.

Import only the icons you'll be using - unless your website will be using 90% of the icons, which is very unlikely.

✔️

import IconName from 'vue-ionicons/dist/js/icon-name'
Vue.component('my-icon', IconName)

✖️

import AllIosIcon from 'vue-ionicons/dist/ionicons-ios.js'
Vue.use(AllIosIcon)

3. Delete useless code block

90% Developers are guilty of this - We all have that useless code block (although its commented), but we wouldn't want to delete them thinking they might be an answer to our questions later on 😅
One thing I do is create a temp file where I keep such code. So as not to make my main files bulky

Extra: Minify your CSS and JS files

If your website is built the traditional way, with no front-end library. Minifying your assets could also help in making your web pages load really faster.
There's this awesome VSCode extension I use - minifyAll - it helps you minify your files in one click. It's blazing fast and.... it's the best out there.

Conclusion

This tips are in my own opinion (IMO), if you have a conflicting view, a better approach or tips like this generally. Kindly drop them in the comment box, I really enjoy learning.

And..., my portfolio source code is hosted publicly here on GitHub. I'll appreciate your ⭐.

You can always reach out to me on twitter, if there is anything I can help you with.

Thanks for reading 🤝

Vue.js For Absolute Begineers

Asaolu Elijah 🧙‍♂️ — Thu, 30 Jul 2020 15:51:35 +0000

I've got my hands on vue.js lately and most tutorials I'd seen out there are not so beginners friendly, so i'd decided to start this series to help #codeNewbies go from beginners to intermediate in Vue.js.

Please Note ⚠️: You should have a basic understanding of HTML, CSS and JavaScript before learning Vue.js. If you do not, here are great resources to help you get started.

Introduction

Vue.js is a pogressive JavaScript framework for building interactive user interface. Vue.js is considered as a goto framework by many developers because it is:

Easier to learn compared to other frameworks/libraries like react, angular,...
Have an easily understandable structure.
Better runtime performance ...

What can i build with Vue.js ?

Below are some stuffs you can build with vue.js

Single Page Applications (SPA)
Multi Page Applications
Native Android and iOS application - With Vue native

Getting started

Open your favourite text editor, create a new index.html file and copy the basic html code below.

<html>
  <head>
    <title>Vue.js Tutorial</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <div id="wrapper">
    </div>
  </body>
</html>

And, lets include the vue.js library source file in our code.

[+...]
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
</body>

Now, lets go ahead and create a new vue instance using the new keyword.

<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
[+...]
<script>
  var app = new Vue({
  el: "#wrapper",
  data: {
     myMessage: "Welcome to my vue app."
  }
});
</script>

So what have we done?

The new Vue(.. keyword is to create a new instance from the Vue class. And this requires one important parameter which is the el.

The el is to specify where we want to wrap our vue application, and in this case it's our <div> with the attribute id = wrapper

Recall: In DOM manipulation that # (hash) is to id, while . (fullstop) is to class. So that's why our el value is #wrapper.

Data

During our new vue initialization, we'd added a second parameter data - This is basically where we are going to house all the local properties we will be using while rendering our application, which is 100% reactivate (more on this later).

To access our property myMessage for example, our index.html file should look like this.

<html>
  <head>
    <title>Vue.js Tutorial</title>
  </head>
  <body>
    <h1>Hello World</h1>
    <div id="wrapper">
        <p>{{myMessage}}</p>
    </div>
  </body>
</html>
<script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>
<script>
  var app = new Vue({
  el: "#wrapper",
  data: {
     myMessage: "Welcome to my vue app."
  }
});
</script>

You'll notice we wrapped our myMessage in a mustache {{}} structure. Other ways we can display our local properties is using the v-text and v-html attribute.
The difference between the v-text and v-html is that.

v-text will display the data as plain text, while
v-html will output the real html. > Run the pen below to see the difference in action.

Conclusion

This article is just an introduction to what vue.js is, and how to get started. In coming articles, I'll be covering crucial topics under Vue.js including:

Binding data
Methods
Components
Looping in Vue
Conditional rendering (if & else)
Vue CLI
Nuxt.js maybe?

And... we will be learning all this by building real world applications 🎊

Okay, why not follow me on twitter so you'll be notified first when I write a new article.

Thanks for reading 👏

Text To Speech In 3 Lines Of JavaScript

Asaolu Elijah 🧙‍♂️ — Tue, 19 May 2020 17:14:42 +0000

If you're curious about trying this out, that's the 3 lines of code below 👇

var msg = new SpeechSynthesisUtterance();
msg.text = "Hello World";
window.speechSynthesis.speak(msg);

But if you're not in a hurry, this article explains everything you need to know about converting text to speech (spoken words) on the web with JavaScript.

Introduction

In a previous article, we'd explored the Web Speech API and also how to convert Speech To Text
Another amazing feature of the Web Speech API is to convert Text to Speech.

Note: Text To Speech != Speech To Text 🧐

Text To Speech is when we give the computer some words and the computer will say this words out loud in some robotic/human voice. While
Speech To Text is when we say some words to the computer, and what we'd just said will be converted to text (I guess this is explanatory enough)

Getting Started

The first thing we'll need to do is check if our browser supports the speech synthesis API. And the code below does that:

if ('speechSynthesis' in window) {
 // Speech Synthesis supported 🎉
}else{
  // Speech Synthesis Not Supported 😣
  alert("Sorry, your browser doesn't support text to speech!");
}

Next step is to create a new speechSynthesis object, add required property and make our app talk 👇

var msg = new SpeechSynthesisUtterance();
msg.text = "Good Morning";
window.speechSynthesis.speak(msg);

Code Explanation

Line 1: We created a variable msg, and the value assigned to it is a new instance of the speechSynthesis class.
Line 2: The .text property is used to specify the text we want to convert to speech
And finally, the code on the 3rd(last) line is what actually make our browser talks.

Altering Default Output

The speechSynthesis API gives room to also change alter the default output like changing the voice, volume, speech rate, language, pitch and more:

var msg = new SpeechSynthesisUtterance();
var voices = window.speechSynthesis.getVoices();
msg.voice = voices[10]; 
msg.volume = 1; // From 0 to 1
msg.rate = 1; // From 0.1 to 10
msg.pitch = 2; // From 0 to 2
msg.text = "Como estas Joel";
msg.lang = 'es';
speechSynthesis.speak(msg);

Getting Supported Voices

The code below helps you retrieve the list of all supported voices:

speechSynthesis.getVoices().forEach(function(voice) {
  console.log(voice.name, voice.default ? voice.default :'');
});

Conclusion

Well, there's nothing to conclude here I guess 🙃
But you could follow me on Twitter, I tweet and retweet interesting technical stuffs; you sure want to see em.

Thanks for reading 👏

Covid-19 Reports - Get Updates Even When Offline

Asaolu Elijah 🧙‍♂️ — Thu, 30 Apr 2020 15:30:44 +0000

In most African/Asian countries, most citizens tends not to get updates about the global covid-19 pandemic. One of the reasons being the lack of steady internet connection.

The reports in Nigeria for example are updated every night around 8:00pm GMT and when this happens, it's only published on the Nigeria Center For Disease Control (NCDC) social handles. So if you have no access to the internet during this time, you'll be in the dark 🧟.

This was why we'd brainstormed to create a solution for solving this, and then we came up with Covid-19 Reports 💡

What We built

Covid-19 Reports helps you channel your super power of getting the latest information about the covid-19 pandemic even when you're offline.

You'll only need to access the web app once and prompted to add your mobile number in order to get the updates. After this you'll get all the updates you need everyday (automatically) 🎉

Also:

Visiting the app automatically detect your location (country precisely) and you'll only get reports based on this side, this was implemented so as not to bore 😴 you with large statistical data.

Another awesome feature is performing self test right on your mobile phone. Since the covid-19 symptoms are known, we'd decided to automate self test without even having to visit the hospital.

Other amazing features including dark mode support🤹

Category Submission:

Covid-19 Solutions
SMS API Integration

Demo Link

https://inventorsdev.github.io/covid-hack/

Link to Code

https://github.com/inventorsdev/covid-hack/

How We built it

Covid-19 Reports is a progressive web app built with

HTML, CSS, JavaScript, Framework 7 [Front End]
PHP and SQL [Back End]

And SMS solution was made possible with Twilio SMS Api

Also, automation was done with cron job on a Linux web server