DEV Community: taiwo

Teaching Machines the Art of Nuance with Google Cloud Natural Language API

taiwo — Wed, 31 Dec 2025 22:47:42 +0000

Keywords are a blunt instrument for a sharp problem. Everyday, all kinds of users leave a digital trail of reviews, tweets, and support tickets on the internet. For a long time, the best we could do was keyword matching, searching for words like "bad" or "excellent." But human language is far more nuanced than a simple checklist of adjectives.

I’ve been exploring Entity and Sentiment Analysis with Natural Language API on Google Cloud, and I think it's pretty cool for developers who want to move past simple text search and into true context-awareness. Whether you’re building an intelligent support desk or a global trend-tracking engine, this API moves the needle from simple data processing to genuine human understanding. Here's why:

1. The Power of Entity.

Traditional search looks for strings. The Natural Language API looks for Entities. Take a look at the request and response below:

Request:

{
  "document":{
    "type":"PLAIN_TEXT",
    "content":"Masashi Kishimoto is a Japanese manga artist who is best known for creating the Naruto series, which became one of the best-selling manga in history."
  },
  "encodingType":"UTF8"
}

Response:

{
  "entities": [
    {
      "name": "Masashi Kishimoto",
      "type": "PERSON",
      "metadata": {
        "mid": "/m/01v8_m",
        "wikipedia_url": "https://en.wikipedia.org/wiki/Masashi_Kishimoto"
      },
      "salience": 0.82,
      "mentions": [
        {
          "text": {
            "content": "Masashi Kishimoto",
            "beginOffset": 0
          },
          "type": "PROPER"
        }
      ]
    },
    {
      "name": "Naruto",
      "type": "WORK_OF_ART",
      "metadata": {
        "mid": "/m/01_f69",
        "wikipedia_url": "https://en.wikipedia.org/wiki/Naruto"
      },
      "salience": 0.12,
      "mentions": [
        {
          "text": {
            "content": "Naruto",
            "beginOffset": 64
          },
          "type": "PROPER"
        }
      ]
    },
    {
      "name": "manga artist",
      "type": "COMMON",
      "salience": 0.05,
      "mentions": [
        {
          "text": {
            "content": "manga artist",
            "beginOffset": 32
          },
          "type": "COMMON"
        }
      ]
    }
  ],
  "language": "en"
}

I fed the API a sentence about Masashi Kishimoto, and it didn't just see a name. It identified him as a PERSON, linked his Wikipedia page, correctly categorized Naruto as a WORK_OF_ART and linked the Wikipedia page as well, and most importantly, calculated his Salience.

What's Salience? It's a 0.0 to 1.0 score that tells you how central an entity is to the text. This allows us to build apps that can automatically summarize what a document is actually about, rather than just listing every name mentioned.

The metadata field is also pretty impressive. The API provides a mid (Machine ID) that links to the Google Knowledge Graph. This means your application instantly gains a massive context knowing that 'Naruto' isn't just a word, but a global franchise with a specific history, all without you having to build a database yourself.

2. Sentiment vs. Magnitude: The Volume of Emotion.

Most sentiment analysis gives you a "positive" or "negative" score. Google Cloud adds another dimension: Magnitude.

Score: Is it positive or negative? (-1.0 to 1.0)
Magnitude: How much emotion is being expressed? (0 to ∞)

Imagine a customer review that says: "The food was amazing, but the waiter was incredibly rude!" A simple sentiment tool might average this to "Neutral" (0.0). But the Natural Language API will show a high magnitude. This tells the developer: "This user isn't indifferent; they are feeling strong, conflicting emotions." That is a signal you can't get from a basic score.

3. The Game Changer: Entity Sentiment Analysis.

This is where the tech gets truly useful. In the past, if a customer wrote a long paragraph praising your meals but hating your restaurant service, the vibe of the review would be mixed.

With Entity Sentiment, the API breaks it down. For example:

Product: Positive (+0.9)
Service: Negative (-0.8)

As a developer, you can now build a dashboard that tells the business owner exactly what to fix. So they aren't just seeing "customers are unhappy"; they’re also seeing "customers love the jollof rice, but the service needs help."

4. Multilingual Support.

One of the most impressive magic tricks of this API is its multilingual capability. I tested it with Japanese text:
日本のグーグルのオフィスは、東京の六本木ヒルズにあります and got the following response:

{
  "entities": [
    {
      "name": "日本",
      "type": "LOCATION",
      "metadata": {
        "mid": "/m/03_3d",
        "wikipedia_url": "https://en.wikipedia.org/wiki/Japan"
      },
      "salience": 0.23854347,
      "mentions": [
        {
          "text": {
            "content": "日本",
            "beginOffset": 0
          },
          "type": "PROPER"
        }
      ]
    },
    {
      "name": "グーグル",
      "type": "ORGANIZATION",
      "metadata": {
        "mid": "/m/045c7b",
        "wikipedia_url": "https://en.wikipedia.org/wiki/Google"
      },
      "salience": 0.21155767,
      "mentions": [
        {
          "text": {
            "content": "グーグル",
            "beginOffset": 9
          },
          "type": "PROPER"
        }
      ]
    },
    ...
  ]
  "language": "ja"
}

Without me telling the API the language, it automatically detected it, identified "Tokyo" as a LOCATION, and even provided the English Wikipedia link! For a developer building global applications, this level of out-of-the-box intelligence is a massive time-saver.

Ultimately, it’s not just about the JSON response, but also the insight that response provides. We’ve moved past the era of simple search and keyword matching. By leveraging features like Salience and Entity Sentiment, we can build systems that actually listen to what users are saying, rather than just scanning what they’ve typed.

The Natural Language API bridges the gap between complex machine learning and real world applications, democratizing high-level AI, making it accessible to any developer with a Cloud Console and a creative idea. It's been a thrill to see how a few lines of code can unlock global context and human nuance (without needing a PhD in linguistics😀). I’m excited to see how we, as a community, use these tools to build more intuitive and inclusive applications🚀

DYOR

Natural Language API Basics

Build an Offline-First Web App with Service Workers

taiwo — Sun, 12 Oct 2025 19:08:41 +0000

Browsing your web app is cool and seamless, until the network connection drops. Suddenly, your users are staring at that sad, gray "You are offline" dinosaur, and just like that, the experience is over. It doesn't have to be that way. Your app should load instantly, feel as reliable as a native app, and work even when the network fails.

Yep. Your web app can work without the internet. That's what Progressive Web Apps (PWAs) and an "offline-first" development gives you.

In this article, you'll learn exactly how to turn any standard web application into a robust, installable PWA. We'll dive into service workers to cache your app's core files, making your UI invincible to network issues. The principles here are universal, so you can apply them to any frontend project you're working on.

Ready? Let's go🚀

What Do You Need?

A single-page web application. It can be as simple as an index.html file with some CSS and JavaScript. The key is that it has a few distinct files we can cache, so the main interface (the "app shell") can load even when offline.

Step 1: Creating The Web App Manifest

We want to tell the browser about our app and how it should behave when "installed." We do this with a manifest.json file.

Create the Manifest: In the root of your project, create a new file named manifest.json.
Add the Configuration: Paste the following JSON into the file. Be sure to customize the name, short_name, description and icons for your own project.

{
  "name": "My Awesome App",
  "short_name": "AwesomeApp",
  "start_url": ".",
  "display": "standalone",
  "background_color": "#ffffff",
  "theme_color": "#007bff",
  "description": "A description of my awesome PWA.",
  "icons": [
    {
      "src": "images/icon-192.png",
      "sizes": "192x192",
      "type": "image/png"
    },
    {
      "src": "images/icon-512.png",
      "sizes": "512x512",
      "type": "image/png"
    }
  ]
}

Remember you'll need to save your own icon files in an images folder for this to work perfectly.

Link the Manifest: Open your index.html and add this line inside the tag:

<link rel="manifest" href="manifest.json">

With this, browsers like Chrome will now show an "Install" icon in the address bar, allowing users to add your app to their home screen.

Step 2: Registering a Service Worker

A Service Worker is a special type of JavaScript file that your browser runs in the background, separate from your web page. It acts like a proxy, allowing network requests to be intercepted and handled in code. This is the key to offline capability.

In your project root, create a sw.js file. Leave it empty for now.
Register the service worker by telling your main application to install it. Add the following script tag to the bottom of your <body> in index.html.

<script>
  if ('serviceWorker' in navigator) {
    window.addEventListener('load', () => {
      navigator.serviceWorker.register('/sw.js')
        .then(registration => {
          console.log('service worker registered successfully:', registration);
        })
        .catch(error => {
          console.log('service worker registration failed:', error);
        });
    });
  }
</script>

This code checks if the browser supports service workers and, if so, registers the sw.js file when the page loads.

Step 3: Caching the App Shell for Offline Use

Now, let's give service worker a job to do. When the service worker is first installed, we'll tell it to download and save all the essential files that make up our app's user interface—the "app shell."

Open sw.js and add the following code:

const CACHE_NAME = 'app-shell-cache-v1';
const ASSETS_TO_CACHE = [
  '/',
  '/index.html',
  '/styles.css', // <-- your main CSS file
  '/app.js',     // <-- your main JS file/entry point
  '/some-other-chunk.js', // other JS files your app needs
  '/favicon.ico',
  '/images/icon-192.png' // <-- remember your own icon file in your images folder
];

// the install event fires when the service worker is first installed
self.addEventListener('install', event => {
  console.log('service worker: installing...');

  event.waitUntil(
    caches.open(CACHE_NAME)
      .then(cache => {
        console.log('service worker: caching app shell');
        return cache.addAll(ASSETS_TO_CACHE);
      })
  );
});

Here, we define a list of files that are critical for our UI. The install event opens a cache with a specific name and saves those files for later. Modern JavaScript tools (like Vite or Create React App) often create multiple JS and CSS files. You must cache all the essential ones for your app to work offline. Use the Network tab in your browser's DevTools to see all the files your page requests on load and add them to this list. It's a bit tedious, but it will make your app work perfectly offline.

Step 4: Intercepting Requests and Serving from Cache

With our files cached, the final step is to tell the service worker to actually use the cache. We'll listen for any network request (fetch event) made by our page. If the requested file is present in cache, it'll be served directly from there, completely bypassing the network.

Add this code to the bottom of your sw.js file:

// sw.js (continued)

// the activate event fires after the install event, good place to clean up old caches
self.addEventListener('activate', event => {
    console.log('service worker: activating...');
    event.waitUntil(
        caches.keys().then(cacheNames => {
            return Promise.all(
                cacheNames.map(cache => {
                    if (cache !== CACHE_NAME) {
                        console.log('service worker: clearing old cache');
                        return caches.delete(cache);
                    }
                })
            );
        })
    );
});


// the fetch event fires for every network request
self.addEventListener('fetch', event => {
  console.log('service worker: fetching');

  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // if the request is in the cache, return it, else fetch from the network
        return response || fetch(event.request);
      })
  );
});

This "cache-first" strategy is perfect for the app shell. Now, even if the user is offline, as long as they have visited the site once, the service worker will intercept the request for index.html and serve it directly from the cache.

STEP 5: Testing Your Offline-First App

The best place to test this is in Chrome DevTools.

Open DevTools (Ctrl+Shift+I or Cmd+Opt+I).
Go to the Application tab.

Under the Service Workers section, you should see your sw.js file is "activated and is running." You can first unregister any old service workers.
Under Cache Storage, you can inspect your app-shell-cache-v1 and see all the files you saved. Feel free to delete your old cache.

Check the "Offline" box at the top of the DevTools window and try refreshing your page. It should still load perfectly.

Voila😁! You've just levelled up your web app in a massive way. It's now faster, more reliable, and provides a native-like experience by being installable and working offline. These are techniques at the core of modern, high-quality web development.

And this is just the beginning of your PWA journey. From here, you could explore caching dynamic API data with IndexedDB or engaging users with push notifications.

Happy hacking!

check out this tutorial on building your own full-stack AI web app to analyze travel images!

taiwo — Thu, 28 Aug 2025 00:54:00 +0000

Architecting a Serverless Vision System with Gemini on Cloud Run - DEV Community

Have you ever wanted to build an intelligent application that can see and understand images? Yes? Me...

dev.to

Architecting a Serverless Vision System with Gemini on Cloud Run

taiwo — Thu, 28 Aug 2025 00:41:26 +0000

Have you ever wanted to build an intelligent application that can see and understand images? Yes? Me too! I was recently inspired by a fellow dev and created my own Colab Notebook for an AI-powered Travel Blogger Assistant. But then I thought, why stop at a notebook? What if we took this idea a step further and built a production-ready and serverless web application that anyone could actually use?

That's exactly what we're going to do! We'll transform the core logic from my notebook into Travel Lens AI; a real web app that analyzes your travel photos, identifies landmarks, and gives you personalized recommendations, all powered by Google's Gemini model.

In this guide, we aren't just coding; we are architecting. We will use Google Cloud Shell as our development sandbox and then transition to Google Cloud Run for production-grade deployment. By using a serverless approach, we ensure our app is highly scalable, secure, and cost-efficient (scaling to zero when not in use).

It was a blast creating this, and now I want to show you how to take an AI concept from a notebook to a live, cloud-native application; all without leaving your browser!

By the end of this tutorial, you'll have a working full-stack application deployed globally. This project demonstrates serverless orchestration, AI integration, and production deployment. Perfect for your portfolio and your journey toward becoming a Cloud expert.

Let's cook!👩🏼‍🍳

Step 1: Setting Up Your Google Cloud Environment

We need a place to build our app. We'll use Google Cloud's free tier. (You have a Google account, obviously.) This gives you everything you need to build this app.

Create or Select a Project.

Head over to the Google Cloud Console. Create a new project (you can name it travel-lens-ai) or select an existing one.

Enable the Vertex AI API.

This is the magic that gives us access to Gemini. In the search bar at the top, type Vertex AI API and select it. Click the blue Enable button. This might take a minute.

Link Billing.

Don't worry. Even though Google requires a billing account for API access (and spam prevention), you won't be charged anything for this project. You can use an existing billing account or create a new one to access the generous free trial credits. Just head to the Billing menu on the sidebar.

Launch Cloud Shell.

In the top right corner of the console, click the >_ icon to Activate Cloud Shell. Once it's running, click the Open Editor button to launch the VS Code-like editor in your browser.

An "Authorize Cloud Shell" prompt might pop up, please do not reject haha

Step 2: Creating the Project Structure

Now that we're in the editor, let's set up our project structure. You'll see the Cloud Shell terminal at the bottom of the editor. If it's not visible, just hit ctrl/cmd + J to toggle it open. Run these commands one by one to create our files:

# Create the main project folder and navigate into it
mkdir travel-lens-ai && cd travel-lens-ai

# Create our Python backend file
touch app.py

# Create a file to list our Python libraries
touch requirements.txt

# Create a folder for our HTML file
mkdir templates && touch templates/index.html

Your file explorer on the left should look like this:

Step 3: Building the Python Backend with Flask

Our backend will be a simple web server using Flask. It will have one job: to receive an image, send it to the Gemini model for analysis, and return the results.

Define Dependencies.

Open the requirements.txt file and add the libraries our app needs:

Flask
flask-cors
google-cloud-aiplatform
Pillow
google-auth

Install the Libraries.

In the terminal, run this command:

pip install -r requirements.txt

Write the Flask App.

Now, open app.py and paste the following code into it. This code sets up the server, defines the AI analysis logic, creates the API endpoint and sets the frontend route.

Setting up & initializing

# app.py
from flask import Flask, request, jsonify, render_template
from flask_cors import CORS
import vertexai
from vertexai.generative_models import GenerativeModel, Part
import os
import google.auth

# Initialize the Flask application
app = Flask(__name__)
CORS(app)

# --- Configuration ---
app.config['MAX_CONTENT_LENGTH'] = 16 * 1024 * 1024 # Allow up to 16MB images

PROJECT_ID = "travel-lens-ai"  # <-- IMPORTANT: REPLACE WITH YOUR PROJECT ID
LOCATION = "us-central1"
MODEL_NAME = "gemini-2.0-flash-exp"

Core AI analysis logic

def analyze_image_from_bytes(image_bytes):
    try:
        credentials, project_id = google.auth.default()
        vertexai.init(project=PROJECT_ID, location=LOCATION, credentials=credentials)

        multimodal_model = GenerativeModel(MODEL_NAME)
        image_part = Part.from_data(image_bytes, mime_type="image/jpeg")

# --- Prompting. You can customize to how you want it ---
        prompt = """
        You are a travel expert. Analyze the image provided and provide the following information in a JSON format:
        - "landmarkName": The name of the landmark, city, or place.
        - "description": A captivating and interesting description of the place.
        - "location": A JSON object with "city" and "country".
        - "personalizedRecommendations": An array of 3-4 actionable travel tips.
        - "photoTips": A creative tip for taking a great photo at this location.
        """

        response = multimodal_model.generate_content([prompt, image_part])
        response_text = response.text.strip().replace("```

json", "").replace("

```", "")

        return json.loads(response_text)

    except Exception as e:
        print(f"An error occurred during AI analysis: {e}")
        return {"error": f"An internal AI error occurred. Details: {e}"}

API endpoint & frontend route

@app.route('/analyze', methods=['POST'])
def analyze_image_endpoint():
    if 'image' not in request.files:
        return jsonify({"error": "No image file provided"}), 400

    image_file = request.files['image']
    analysis_result = analyze_image_from_bytes(image_file.read())

    if "error" in analysis_result:
        return jsonify(analysis_result), 500

    return jsonify(analysis_result), 200

# --- Frontend Route ---
@app.route('/')
def home():
    return render_template('index.html')  # <-- IMPORTANT: remember our setup in the beginning

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=int(os.environ.get('PORT', 8080)), debug=True)

Fear not! You're not just blindly copying a long a** code blocks. I have broken it down with comments so you understand exactly what each section does. This way, you're actually learning, not just following instructions. Remember to replace YOUR_PROJECT_ID with your actual Google Cloud Project ID (unless you're using travel-lens-ai).

Step 4: Creating the UI

Now the fun part. Let's build the user interface. This will be a single HTML file that uses Tailwind CSS for styling and JavaScript to connect with our backend.

Open templates/index.html and you can either build your own custom interface or use my implementation as a starting point. The key elements you'll need are:

styled file input for uploading travel photos
submit button to trigger the AI analysis
results section to display Gemini's insights

Whether you customize it or use my code as-is, make sure you understand the JavaScript, as that's what sends your images to the AI for analysis.

Step 5: Preview Your Application

This is the moment we've been waiting for. With our backend logic and frontend interface in place, it's time to bring Travel Lens AI to life.
In the Cloud Shell terminal, (again, make sure you are in your travel-lens-ai) directory and run this command:

python app.py

After a few seconds, the terminal will show that the Flask server is running. Now, look at the top-right corner of the Cloud Shell window for a Web Preview button. Click it and select Preview on port 8080.

A new browser tab will open, confirming your application loads correctly.

Step 6: Deploy to Cloud Run!🚀

Now that we’ve verified our app works in the Cloud Shell sandbox, the final step is to transition to a production-grade environment. We’ll use Google Cloud Run, a fully managed serverless platform.

Why Cloud Run?

Elastic Scalability: It automatically scales your container up to handle traffic and down to zero when idle.
Cost-Efficiency: You only pay for the exact resources used during request processing. *Infrastructure as Code: It allows us to move away from manual 'previews' to a stable, public HTTPS URL.

Enable Required APIs

Before deploying, we need to enable the Cloud Build and Artifact Registry APIs. These services handle the "magic" of turning your source code into a deployable container image. Run this command in your terminal:

gcloud services enable run.googleapis.com cloudbuild.googleapis.com artifactregistry.googleapis.com

The Production Launch

Deploy your application directly from your current directory with this command. When prompted to "allow unauthenticated invocations," type y to make your travel app public!

gcloud run deploy travel-lens-ai \
  --source . \
  --region=us-central1 \
  --allow-unauthenticated

And we are live!🥳

Once the deployment finishes (it takes about 2 minutes), the terminal will display a Service URL. This is your permanent, production link! Go ahead and upload a photo of your favorite travel spot and watch Gemini work its magic!✨

Troubleshooting Checklist

If you run into an error, don't panic! Here are the most common fixes:

Permissions Error? The most common issue is authentication. Force Cloud Shell to re-authenticate by running gcloud auth application-default login in the terminal, follow the link to authorize, and then restart your python app.py server.
"Project Not Found"? Make sure the PROJECT_ID in your app.py file exactly matches the ID of the project where you enabled the Vertex AI API. You can also reconfirm the project in Cloud Shell by running gcloud config set project PROJECT_ID in your terminal.
Dependencies Missing? If you see an "import error," you may have forgotten to install the libraries. Just run pip install -r requirements.txt again.
If you accidentally close your terminal or clear the screen and need to find the URL again, you don't need to re-deploy. Just run this command in Cloud Shell:

gcloud run services describe travel-lens-ai --format='value(status.url)' --region=us-central1

This will print only the live URL to your screen.

Congratulations!🥳 You've just built and deployed a powerful, full-stack AI application using nothing but your web browser and cloud run. How cool is that?!

You've learned how to set up a cloud environment, build a Python backend, create a modern frontend, integrate with the powerful Gemini model, and deploy on Cloud Run.

But this is just the beginning. You could expand this project by saving analysis history, adding user accounts, or even generating entire travel itineraries.

A huge shoutout to the dev whose Colab Notebook sparked this entire project! It's incredible how inspiration can transform a simple notebook into a full-stack application. That's the beauty of open development and sharing knowledge.

I hope this tutorial has shown you how simple(👀), accessible and powerful modern AI development can be. Happy hacking!

Update (Jan 2026): Added a new section on production deployment using Google Cloud Run to demonstrate how to transition this AI workflow from a development sandbox to a scalable, serverless environment.

Behind The Scenes: How Your Browser Cooks Up a Webpage.

taiwo — Thu, 08 Aug 2024 19:25:10 +0000

Every second, billions of webpages spring to life. It’s a digital feast happening at breakneck speed. But what truly goes on behind the scenes when you simply type a URL into your browser? Seriously, like a million things.

Think of the internet as a colossal, global kitchen. Countless servers, like dedicated chefs, work tirelessly to prepare an endless menu of digital dishes. When you enter a website address in your browser, you are essentially placing an order at this grand culinary establishment.

To understand how your digital meal is prepared and served, let's step into the kitchen.

The Order is Placed (Typing the URL)

Just as you place your order with the waiter, you tell your browser the information you need by typing a URL (Uniform Resource Locator) into the address bar. This unique identifier, often starting with http:// or https://, is like the dish name on a menu. It tells the waiter the exact meal you want, for them to take to the chefs.

Your browser (Chrome, Safari, Edge, etc) acts as your personal waiter, taking your order with precision. When you hit enter, it diligently records the URL, storing it as a specific request. Imagine a knowledgeable and savvy waiter who understands the complexities of the restaurant (the internet) and knows how to relay your order to the appropriate kitchen (server). That's your browser.

Finding the Right Kitchen (DNS Lookup)

While your waiter (browser) has taken your order (URL), they don't actually know where the kitchen (server) is located. This is where the magic of the Domain Name System (DNS) comes in. Think of DNS servers as the restaurant's kitchen directory.

Now you don't expect your waiter to wander aimlessly through the restaurant looking for the kitchen. Remember your waiter is knowledgeable and savvy. So instead of searching the entire restaurant for the kitchen, they consult the directory (DNS server) to quickly locate the right kitchen to send your order. This process, called a DNS lookup, happens in milliseconds, ensuring your meal, or webpage, is on its way swiftly.

This is how your browser sends your URL to a DNS server. This server acts as a translator, converting the human-readable URL into a numerical address called an IP address which looks like this 192.122.56.10. Once the browser receives the IP address from the DNS server, it knows exactly where to send your order. The kitchen, or in this case the server, is ready to start cooking up your webpage.

The Chef Prepares the Food (Server Processing)

Once your browser, acting as the diligent waiter, successfully locates the kitchen (server) using the IP address, it sends your order to the digital chef. This is where the magic of server-side processing begins.

Like a bustling kitchen with different chefs specializing in different dishes, there are different types of servers handling various requests.

Web Servers: These are the main chefs. They receive your request, fetch the requested webpage from the server's storage, and prepare it for serving.
Database Servers: These are the sous-chefs. They manage and store information like product details, user data, or blog posts. Web servers often interact with database servers to retrieve dynamic content.
Mail Servers: These are the delivery experts, handling email-related tasks like sending, receiving, and storing emails.

The server processes your request based on the information it receives. This involves tasks like checking if the requested page exists, gathering necessary data (if required), and generating the HTML code that makes up the webpage. Think of this as the chef combining ingredients and cooking the dish according to the recipe.

The Food is Served (Page Loading)

With the webpage fetched from the server, it's time for delivery. Just as the waiter carries your plate of delicious food to your table, the server sends the webpage, packaged as data, back to your browser. This transfer happens at incredible speed, thanks to the internet's infrastructure.

Once the browser receives the data, it starts the process of presenting it to you in a visually appealing format. This is like the waiter setting the table and arranging the dishes. The browser interprets the HTML code, which is the blueprint of the webpage, and starts building the structure. It then incorporates elements like CSS (Cascading Style Sheets) for styling and JavaScript for interactivity.

Again, remember that your browser as a skilled waiter who not only brings the food but also ensures it's presented elegantly. It arranges text, images, and other components in a way that is easy to understand and navigate. The result is the dynamic and interactive webpage you see on your screen.

Extra Sauce

Caching: Speeding Things Up

To enhance the dining experience, restaurants often keep popular dishes warm to reduce wait times. Similarly, browsers employ caching to accelerate webpage loading. When you visit a website, your browser saves a copy, or cache, of the webpage's files (HTML, images, scripts) on your computer. The next time you visit the same page, the browser checks the cache first. If the files haven't changed, they're loaded directly from your computer, bypassing the server. This significantly speeds up page loading, especially for frequently visited websites.

Security: Protecting Your Digital Meal

Just as restaurants prioritize food safety, the internet emphasizes data security. HTTPS (Hypertext Transfer Protocol Secure) is the digital equivalent of a locked food container in the kitchen. It ensures that the data exchanged between your browser and the server remains private and intact.

When you access a website with HTTPS, your browser establishes a secure connection with the server. This connection encrypts the data, making it unreadable to anyone who might intercept it. Think of it as wrapping your food order in a secure package before sending it. HTTPS also verifies the website's identity, preventing you from being tricked into visiting a fake restaurant.

Troubleshooting: Dealing with Digital Hiccups

Even the smoothest dining experiences can encounter occasional hiccups, like a slow waiter or cold food. Similarly, webpage loading can sometimes be met with challenges. Here are some common issues and potential solutions:

Slow Loading Times:

Check your internet connection speed.
Close unnecessary tabs and programs.
Clear your browser cache.
Consider using a content delivery network (CDN).

Webpage Errors:

Ensure the URL is correct.
Try accessing the website from a different device or network.
Check if the website is experiencing technical difficulties.
Clear your browser cookies and cache.

Security Warnings:

Avoid clicking on suspicious links.
Be cautious of phishing attempts.
Keep your browser and operating system up to date.

Bon Appétit!

While we've merely scratched the surface of this intricate world of web development, grasping these fundamental concepts can make you a more informed and efficient web explorer, help you to diagnose online troubles, admire the engineering behind your favorite websites, and even spark groundbreaking ideas. So, as you savor your perfectly cooked meal, do well to appreciate the skilled chefs and efficient waitstaff who made it possible.

Happy browsing!

React Components: Class vs Functional.

taiwo — Wed, 31 Jul 2024 21:56:35 +0000

My React journey began four years ago with functional components and Hooks. Then came 'Siswe, a fellow participant in the bootcamp and our resident class component enthusiast. While the rest of us were collaborating on team projects with functional components, 'Siswe clung to class components with an unwavering loyalty.

Components are the building blocks of your user interface (UI).

Think of them as Lego bricks – you can combine them in various ways to create complex structures. They are independent and reusable pieces of code that encapsulate UI and logic.

Reusing a component within another component typically looks like this:

import MyComponent from './MyComponent';

function ParentComponent() {
  return (
    <div>
      <MyComponent />
    </div>
  );
}

Class Components and Functional Components are the two primary ways to create components in React.

import React, { Component } from 'react';

class Counter extends Component {
 constructor(props) {
  super(props);
  this.state = { count: 0 };
 }

 handleClick = () => {
  this.setState({  
 count: this.state.count + 1 });
 };

 render() {
  return  
 (
   <div>
    <p>You clicked {this.state.count} times</p>
    <button onClick={this.handleClick}>Click me</button>
   </div>
  );
 }
}

export default Counter;

This is a class component, created using JavaScript classes that extend the React.Component class.

import React, { useState } from 'react';

function Counter() {
  const [count, setCount] = useState(0);

  const handleClick = () => {
    setCount(count + 1);
  };

  return (
    <div>
      <p>You clicked {count} times</p>
      <button onClick={handleClick}>Click me</button>
    </div>
  );
}

export default Counter;

This on the other hand is a functional component, written as a simple JavaScript function.

State Management: The Core Difference.

Class components manage their own internal state using this.state. This is typically initialized in the constructor, accessed using this.state object, and updated using the this.setState method, as seen in the code block above.

Functional components were initially stateless. But with the introduction of Hooks, they gained the ability to manage state and lifecycle logic. Utilizing the useState hook for managing state, it returns a pair of values: the current state and a function to update it, as seen above. This is sufficient for simple state management. For more complex state logic involving multiple sub-values, or when the next state depends on the previous one, you want to use useReducer.
For example:

import React, { useReducer } from 'react';

const initialState = {
  count: 0,
  step: 1,
};

const reducer = (state, action) => {
  switch (action.type) {
    case 'increment':
      return { ...state, count: state.count + state.step };
    case 'decrement':   

      return { ...state, count: state.count - state.step };
    case 'setStep':
      return { ...state, step: action.payload   
 };
    default:
      throw new Error();
  }
};

function Counter() {
  const [state, dispatch] = useReducer(reducer, initialState);

  const increment = () => dispatch({ type: 'increment' });
  const decrement = () => dispatch({ type: 'decrement'   
 });
  const setStep = (newStep) => dispatch({ type: 'setStep', payload: newStep });

  return (
    <div>
      <p>Count: {state.count}</p>
      <p>Step: {state.step}</p>
      <button onClick={increment}>+</button>
      <button onClick={decrement}>-</button>
      <input type="number" value={state.step} onChange={(e) => setStep(Number(e.target.value))} />
    </div>
  );
}

export default Counter;

Here, useReducer is managing multiple state values and complex update logic in a structured and maintainable way. Hooks are exclusively for functional components.

Avoid direct manipulation of the state object in both components.

Never directly modify or mutate the state object, regardless of the component type. Instead, create a new object with the updated values. This approach helps React efficiently track changes and optimize re-renders.

Functional component example:

import React, { useState } from 'react';

function UserProfile() {
  const [user, setUser] = useState({ name: 'Jane Doe', age: 30 });

  const handleNameChange = (newName) => {
    setUser({ ...user, name: newName }); // Create a new object with updated name
  };

  return (
    <div>
      <p>Name: {user.name}</p>
      <p>Age: {user.age}</p>
      <input type="text" value={user.name} onChange={(e) => handleNameChange(e.target.value)} />
    </div>
  );
}

export default UserProfile;

Class component example:

import React, { Component } from 'react';

class UserProfile extends Component {
  state = { user: { name: 'Jane Doe', age: 30 } };

  handleNameChange = (newName) => {
    this.setState(prevState => ({
      user: { ...prevState.user, name: newName } // Create a new object with updated name
    }));
  };

  render() {
    return (
      <div>
        <p>Name: {this.state.user.name}</p>
        <p>Age: {this.state.user.age}</p>
        <input type="text" value={this.state.user.name} onChange={(e) => this.handleNameChange(e.target.value)} />
      </div>
    );
  }
}

export default UserProfile;

In both examples, we're updating the name property of the user object while preserving the original object's integrity. This ensures that a new state object is created, preserving immutability and preventing potential issues with state updates. Adherence to this ensures predictable behavior, performance optimizations, and easier debugging.

Class components are for complex logic.

Complex State Management: When dealing with intricate state logic that requires fine-grained control, class components with this.state and this.setState can offer more flexibility.
Lifecycle Methods: For components that heavily rely on lifecycle methods like componentDidMount, componentDidUpdate, or componentWillUnmount, class components are the traditional choice.
Error Boundaries: To handle errors within a component tree and prevent crashes, class components with componentDidCatch are essential.
Performance Optimization: In specific performance-critical scenarios, PureComponent or shouldComponentUpdate within class components can be leveraged.
Legacy Codebases: If you're working on an existing project that heavily relies on class components, it might be easier to maintain consistency by using them for new components.

Functional components are for simple views.

Simple Components: For presentational components with minimal state or logic, functional components are often the preferred choice due to their simplicity and readability.
State Management with Hooks: Leveraging useState and useReducer in functional components provides a powerful and flexible way to manage state.
Side Effects: The useEffect hook allows for managing side effects like data fetching, subscriptions, or manual DOM (document object model) manipulations.
Performance Optimization: useMemo and useCallback can be used to optimize performance in functional components.

Let your component's needs guide your decision.

The functional approach is generally considered more concise and readable, and it often suffices due to simplicity and efficiency. However, class components offer more control over state management and lifecycle methods, especially when dealing with intricate logic or performance optimization. This means better structure for organizing complex logic.

The choice between class and functional components is not always clear-cut, as there is no strict rule. Evaluate the requirements of your component and go with the type that aligns best with your project requirements.

Which component do you enjoy working with more?

Coding For Everyone: Accessibility in Web Development.

taiwo — Tue, 30 Jul 2024 00:41:03 +0000

The next billion users of the internet will come from a diverse range of backgrounds and abilities. Therefore, incorporating inclusive design principles from the outset of web development is extremely important. Disabilities that affect access to the web such as auditory, cognitive, neurological, physical, speech, and visual, are all encompassed by web accessibility. Websites, tools and technologies must be designed and developed so that people with disabilities can use them. Everyone should be able to perceive, understand, navigate, interact with and contribute to information presented on the web.

Disabilities have impact on web accessibility.

Visual impairments. People with visual impairments such as partial or total blindness, color blindness and low vision rely heavily on screen readers and other assistive technologies to access the web. To accommodate their needs, websites must provide clear and concise alternative (alt) text for images, videos, and other non-text content; ensure sufficient color contrast between text and background for readability; utilize headings and proper HTML structure to create a logical document outline for screen readers; and allow users to adjust font size for optimal viewing.
Hearing impairments. Users with hearing impairments like deafness benefit from visual cues and transcripts. Websites must provide closed captions (CC) and transcripts for audio and video content; use visual indicators for audio notifications and alerts; and ensure compatibility with hearing aids and assistive listening devices.
Motor impairments. Individuals with motor impairments may have difficulty using their keyboards or mouse. To accommodate their needs, websites must implement keyboard navigation; provide sufficient target sizes for clickable elements; and allow users to control the website using voice commands or other assistive technologies.
Cognitive impairments. People with cognitive impairments may have difficulty processing information, understanding complex layouts, or focusing on tasks. To create inclusive experiences, websites must use clear and simple language, avoiding complex sentence structures; provide clear and consistent navigation with well-labeled links and menus; minimize distractions and clutter on the page; and offer options for customizing the display such as font size, color, and layout.

Users with other disabilities, such as speech impairments and seizure disorders can be catered to by websites providing options for text input and alternative communication methods, and avoiding flashing animations or content that could trigger seizures, respectively.

It begins with us, the developers.

Developers build the website. By incorporating accessibility principles from the foundation, we ensure that the web is inclusive and usable for everyone, regardless of disabilities. Our role is crucial, as we are responsible for implementing features like proper semantic HTML, keyboard navigation, and ARIA landmarks that make a significant difference in the user experience for people with disabilities. By prioritizing accessibility, we create a more inclusive digital environment that benefits all users.

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

— Tim Berners-Lee, inventor of the World Wide Web.

The Click-Away Pound survey reports that 71% of users with disabilities will leave a website that is difficult to use, with 82% of those users willing to spend their money on a more accessible website. This goes to show that improving accessibility can lead to higher conversion rates as users are more likely to stay on and interact with a website that is easy to use. Also, accessible websites often rank higher in search engine results, driving more organic traffic. Features like alt text for images, proper use of headings, and descriptive link text enhance search engine optimization (SEO). Clear navigation, better contrast, and keyboard functionality also improve overall user experience, making it easier for everyone to use websites.

Netflix is a perfect case study.

As a leading streaming service, Netflix understood the need to cater to a diverse audience, including those with visual and hearing impairments. They aimed to create an inclusive platform where everyone could enjoy their content and implemented closed captioning and audio descriptions for their content. They also developed features like customizable text size, font, and background color to accommodate users with visual impairments. By prioritizing accessibility, Netflix expanded its audience and strengthened its brand reputation as an inclusive company. They received positive feedback from users with disabilities and this demonstrated their commitment to creating a barrier-free viewing experience for everyone.

The common barriers are often overlooked.

Images.
Making websites accessible starts with something as ‘little’ as adding descriptive alt texts that explain non-text content such as images and videos. Users with visual impairments rely on screen readers to describe these elements and without a descriptive alt text, they miss out on crucial information.

<img src='cat.jpg' alt='a cat'/>

<img src='cat.jpg' alt='an orange cat sleeping on a couch'/>

Users relying on screen readers are more likely to navigate away from a website with vague alt text like the first example, as it is not descriptive enough. They will have a better experience navigating a website with alt texts similar to the latter, as detailed descriptions provide a richer user experience for those using assistive technologies.

Headings.
Using headings correctly establishes the document structure, helping users with screen readers understand the content hierarchy. Do not do this:

<h1>Important Content</h1>
<h2>Less Important Content</h2>
<h1>Even Less Important Content</h1>

Do this instead:

<h1>Main Heading</h1>
<h2>Subheading 1</h2>
<h3>Subheading 2</h3>

Tables.
This table structure cannot be easily navigated:

<table>
  <tr>
    <td>Column 1</td>
    <td>Column 2</td>
  </tr>
  <tr>
    <td>Data 1</td>
    <td>Data 2</td>
  </tr>
</table>

Implement this structure instead, using caption, thead, tbody and th elements to provide structure, making your table accessible to screen reader users.

<table>
  <caption>Table of Products</caption>
  <thead>
    <tr>
      <th>Product Name</th>
      <th>Price</th>
    </tr>
  </thead>
  <tbody>
    <tr>
      <td>Product A</td>
      <td>$10</td>
    </tr>
    <tr>
      <td>Product B</td>
      <td>$15</td>
    </tr>
  </tbody>
</table>

ARIA roles.
Missing or incorrect use of ARIA (Accessible Rich Internet Applications) roles is another common barrier in web accessibility. If you can use a native HTML element with the correct semantics, do so, instead of using ARIA. ARIA should be used as a last resort for custom controls. For example:

<div role="button" onclick="doSomething()">Click me!</div>

While this code makes the element clickable, it is incorrect to use role="button" on a generic “div” element. Screen readers may not interpret the content correctly, leading to confusion and a poor user experience. The button element is specifically designed for clickable elements and provides built-in accessibility features.

<div role="alert" aria-live="assertive">
  Error: Please fill in all required fields.
</div>

Here, role=“alert” indicates that the content is important, while aria-live="assertive" ensures that the alert is announced immediately to users of assistive technologies.

You can easily check the accessibility of your website.

WAVE, Axe, Pa11y, and Lighthouse are some accessibility testing tools that can be used to audit your website and identify areas that may need improvement. Here are the steps to access and use the Lighthouse Panel in your Chrome DevTools:

Open Chrome DevTools. Right-click on your webpage and select Inspect, or press Ctrl+Shift+I (Windows/Linux) or Cmd+Option+I (Mac).
Navigate to the Lighthouse Panel. In the DevTools window, find and click the ‘>>’ icon at the top right to expand the available tabs. Select Lighthouse from the dropdown menu.

Set Up the Lighthouse Audit. In the Lighthouse panel, you can select the categories you want to audit. Make sure Accessibility is checked. You can also choose the device type (Mobile or Desktop) for the audit.

Run the Audit. Click the Analyze page load button at the top of the Lighthouse panel. Lighthouse will analyze your webpage in 30 to 60 seconds and generate a detailed report on the various categories checked, so ensure once again that Accessibility is checked before you run the audit.
Review the Accessibility Report. Once the audit is complete, Lighthouse will display a report with scores and detailed information on your website’s accessibility. The report will highlight areas that need improvement and provide suggestions on how to fix any issues.

For more details, you can refer to the Chrome documentation on using Lighthouse.

Accessibility is a necessity, not an afterthought.

It is crucial for true inclusion. The web should be usable by everyone, regardless of ability. We should be building bridges, not walls.