DEV Community: Hamdi LAADHARI

The Sunset of General-Purpose Apps: Why Bespoke Tools are the Future

Hamdi LAADHARI — Thu, 25 Sep 2025 21:29:23 +0000

For years, our digital lives have revolved around a constellation of applications. From project management suites to sophisticated photo editors, we've come to expect a tool for every task. But what if this paradigm is fundamentally flawed? What if the very apps we rely on are becoming obsolete, replaced by a new era of instantly generated, perfectly tailored solutions?

I believe we're on the cusp of a significant shift: the majority of today's general-purpose applications are destined to disappear, or at least become niche utilities.

The Inherent Flaw of the One-Size-Fits-Most App

The core problem with most existing applications boils down to two critical points:

Imperfect Fit: No matter how feature-rich, most apps are rarely a 100% match for your specific needs. They come with a bloated set of features you'll never use, or, more frustratingly, they lack that one crucial function you desperately require. We contort our workflows to fit the app, rather than the app adapting to us.
Maintenance Burden: Every application, whether it's a SaaS product or a self-hosted solution, carries a maintenance cost. This isn't just about financial subscriptions; it's about updates, bug fixes, learning new interfaces, and integrating with other imperfect tools. This collective burden saps productivity and innovation.

Why bother with these compromises when you can, or soon will be able to, instantly create the precise tool you need for a punctual task?

The Rise of Instant, Tailored Solutions

The emergence of powerful AI-driven development and content generation tools is flipping the script. Imagine a world where, instead of searching for an app, you simply describe your immediate need, and a functional tool is generated on the fly.

Tools like Google's AI Studio Build, GitHub Copilot, ChatGPT Canvas, and even creative platforms like Figma Make (when viewed as a rapid design generation tool) hint at this future. These aren't just intelligent assistants; they are nascent developers and designers, capable of understanding intent and materializing it into functional output.

Pros of this Bespoke Future:

Perfect Fit, Every Time: You get exactly what you need, nothing more, nothing less. No extraneous features, no missing functionalities.
Zero Maintenance (for you): The ephemeral nature of these generated tools means you use them for the task, and then they're gone (or easily regenerated/modified for the next task). The "maintenance" is handled by the underlying AI model.
Unprecedented Agility: Respond to new challenges and opportunities with lightning speed. A sudden data analysis requirement? Generate a custom script. A unique content formatting need? Generate a specialized converter.
Empowerment: This democratizes development, allowing anyone to be a "creator" of digital tools, regardless of coding expertise.

Cons and Challenges:

Reliance on AI: The quality and reliability of generated tools will be entirely dependent on the AI's capabilities and the clarity of user prompts.
Security Concerns: How do we ensure the generated code or tools are secure, especially when dealing with sensitive data?
Ethical Implications: Who is responsible when an AI-generated tool produces an incorrect or biased outcome?
Vendor Lock-in (New Form): While freeing us from traditional apps, we might become reliant on the specific AI platforms that do the generating.
The "Human Touch" Gap: For truly complex, nuanced, or highly creative applications, human insight and iterative design might still be irreplaceable.

A Real-World Example: My Draft.js to HTML Viewer

Let me illustrate this concept with a personal anecdote. In my current workflow, I utilize an LLM (Large Language Model) to generate content. My CMS, however, stores this content in Draft.js format – a rich text editor framework for React.

During development, I found myself in a bind: I needed a rapid way to preview the Draft.js content as actual HTML. Why? Because the LLM's output sometimes required quick checks for formatting, structure, and overall presentation before being committed. There wasn't an off-the-shelf, simple tool that did exactly this. Existing solutions were either full-blown editors or complex libraries to integrate.

So, instead of searching for an imperfect app or spending hours building a robust, production-ready solution, I created precisely what I needed for my punctual task: a simple Draft.js to HTML viewer.

My tool allows me to paste the raw Draft.js content state in JSON format into an editor on the left, and instantly renders the corresponding HTML on the right. It's not a commercial product; it's a bespoke utility born out of a specific, temporary need.

This exemplifies the future: if I had a more advanced AI assistant, I could simply tell it, "I need a web tool that takes Draft.js JSON on the left and shows rendered HTML on the right," and it would instantly generate that specific application for me.

Conclusion: Adapt or Be Replaced

The era of meticulously crafted, all-encompassing applications might be drawing to a close. As AI and instant generation tools mature, the value will shift from owning a vast array of generic tools to the ability to define and conjure highly specific, temporary, and perfectly tailored solutions.

Developers, product managers, and even end-users will need to adapt their thinking. The focus will move from "which app should I use?" to "what exact functionality do I need, and how can I instantly manifest it?"

What are your thoughts? Are you ready for a world where apps are generated on demand, or do you see a continued need for the established giants? Share your perspective in the comments below!

Chrome Extension Network Interception: The Modern Way to Scrape Instagram (and Beyond)

Hamdi LAADHARI — Fri, 13 Jun 2025 17:02:54 +0000

How to reliably extract data from Instagram (and similar sites) by intercepting network calls in a Chrome extension—robust, minimal, and production-ready.

Why Network Interception?

Traditional DOM scraping is fragile: UI changes, dynamic loading, and anti-bot measures make it unreliable. Instead, intercepting network calls lets you capture the raw data the site uses—before it even hits the DOM.

Advantages:

Immune to UI/layout changes
Access to complete, structured data
Faster (no DOM parsing)
Stealthier (less likely to trigger anti-bot)
Works for any site using XHR/fetch APIs

Architecture Overview

┌─ Page Context (Script Injection) ─┐
│   Patch fetch/XHR, intercept API  │
│   Dispatch CustomEvent w/ data    │
└───────────────────────────────────┘
           │
           ▼
┌─ Content Script ──────────────────┐
│   Listen for events, forward data │
│   to background via messaging     │
└───────────────────────────────────┘
           │
           ▼
┌─ Background Script ───────────────┐
│   Process, deduplicate, store,    │
│   or forward to external API      │
└───────────────────────────────────┘

Minimal, Robust Implementation

1. Manifest Setup (MV3)

{
  "manifest_version": 3,
  "name": "Instagram Network Interceptor",
  "version": "1.0.0",
  "permissions": ["scripting", "storage"],
  "host_permissions": ["https://*.instagram.com/*"],
  "background": { "service_worker": "background.js" },
  "content_scripts": [
    {
      "matches": ["https://*.instagram.com/*"],
      "js": ["content.js"],
      "run_at": "document_start"
    }
  ],
  "web_accessible_resources": [
    {
      "resources": ["public/page-interceptor.js"],
      "matches": ["<all_urls>"]
    }
  ]
}

2. Page Interceptor (public/page-interceptor.js)

Runs in the page context, patches fetch/XHR, and dispatches a CustomEvent with the response data.

(function () {
  if (window.__instaInterceptor) return;
  window.__instaInterceptor = true;

  const originalFetch = window.fetch;
  window.fetch = async function (input, init) {
    const resp = await originalFetch.apply(this, arguments);
    try {
      const url = typeof input === 'string' ? input : input.url || '';
      if (url.includes('/graphql') || url.includes('/api/')) {
        const cloned = resp.clone();
        const text = await cloned.text();
        window.dispatchEvent(new CustomEvent('instaApi', {
          detail: { url, body: text, status: resp.status, method: init?.method || 'GET' }
        }));
      }
    } catch (err) { /* ignore */ }
    return resp;
  };

  const originalXHROpen = XMLHttpRequest.prototype.open;
  const originalXHRSend = XMLHttpRequest.prototype.send;
  XMLHttpRequest.prototype.open = function (method, url) {
    this._method = method;
    this._url = url;
    return originalXHROpen.apply(this, arguments);
  };
  XMLHttpRequest.prototype.send = function () {
    this.addEventListener('load', function () {
      if (this._url && this._url.includes('/api/')) {
        window.dispatchEvent(new CustomEvent('instaApi', {
          detail: { url: this._url, body: this.responseText, status: this.status, method: this._method }
        }));
      }
    });
    return originalXHRSend.apply(this, arguments);
  };
})();

3. Content Script (content.js)

Injects the interceptor and relays events to the background script.

// Inject the page script
const url = chrome.runtime.getURL('public/page-interceptor.js');
const script = document.createElement('script');
script.src = url;
script.type = 'text/javascript';
document.head.appendChild(script);

// Listen for intercepted data
window.addEventListener('instaApi', (evt) => {
  chrome.runtime.sendMessage({ type: 'API_PAYLOAD', payload: evt.detail });
});

4. Background Script (background.js)

Processes, deduplicates, and stores or forwards the data.

const processedShortcodes = new Set();

chrome.runtime.onMessage.addListener((msg, sender) => {
  if (msg.type === 'API_PAYLOAD') {
    try {
      const json = JSON.parse(msg.payload.body);
      // Example: extract Instagram post shortcode
      const shortcode = extractShortcode(json);
      if (!processedShortcodes.has(shortcode)) {
        processedShortcodes.add(shortcode);
        // Store, process, or forward to external API here
        chrome.storage.local.set({ [Date.now()]: json });
      }
    } catch (e) {
      // Non-JSON or irrelevant response
    }
  }
});

function extractShortcode(json) {
  // Minimal example: adapt to your API structure
  return json?.data?.shortcode || '';
}

Best Practices & Gotchas

Always clone() responses before reading body.
Deduplicate by post ID/shortcode to avoid reprocessing.
Rate limit if forwarding to external APIs.
Handle CSP by injecting a file, not inline code.
Respect privacy and ToS: only process public data, implement delays, and avoid logging sensitive info.

Extending to Other Platforms

You can adapt the same pattern for Twitter, LinkedIn, etc., by changing the URL detection logic in the interceptor.

const isTargetApi = (url) =>
  url.includes('instagram.com/graphql') ||
  url.includes('twitter.com/i/api') ||
  url.includes('linkedin.com/voyager');

Conclusion

Network interception in the page context is the most robust, future-proof way to extract data from modern web apps. With a minimal Chrome extension, you can capture structured data directly from the source—no more brittle DOM scraping.

Understanding Composer Version Constraints: A Comprehensive Guide

Hamdi LAADHARI — Thu, 24 Apr 2025 12:28:41 +0000

When managing PHP dependencies with Composer, understanding version constraints is crucial for maintaining stable, secure, and compatible packages in your projects. This guide explores the different operators and patterns you can use to specify version requirements.

The Big Three: Caret, Tilde, and Asterisk

Caret (`^`) Constraint - The Recommended Default

The caret constraint follows semantic versioning principles, allowing updates that maintain backward compatibility.

Behavior: Allows updates to everything except the leftmost non-zero component

Examples:

^1.2.3 allows updates to any version from 1.2.3 to <2.0.0
^0.3.2 allows updates to any version from 0.3.2 to <0.4.0
^0.0.5 allows updates to any version from 0.0.5 to <0.0.6

The caret is generally recommended for most dependencies as it provides a good balance between stability and receiving bug fixes and minor improvements.

Tilde (`~`) Constraint - More Conservative

The tilde constraint is more restrictive than caret and allows only for minor or patch version updates, depending on how it's used.

Behavior: Allows the last specified digit to increase

Examples:

~1.2.3 allows updates to any version from 1.2.3 to <1.3.0 (only patch updates)
~1.2 allows updates to any version from 1.2.0 to <1.3.0 (patch updates only)
~1 allows updates to any version from 1.0.0 to <2.0.0 (minor and patch updates)

Use tilde when you want to be more cautious about updates, especially for packages with a history of breaking changes in minor versions.

Asterisk (`*`) Constraint - The Wildcard

The asterisk represents a wildcard and can be used to allow any version in a specific position.

Behavior: Matches any version in the position where it appears

Examples:

1.2.* allows any version from 1.2.0 to <1.3.0
1.* allows any version from 1.0.0 to <2.0.0
* allows any version (not recommended for production)

Wildcards are convenient but should be used with caution, especially in production environments.

Other Version Constraints

Exact Version

When you need a specific version with no flexibility:

"monolog/monolog": "1.25.0"

This is useful for packages where you've verified compatibility with exactly one version, but it means you won't automatically get bug fixes.

Version Ranges

Composer supports explicit version ranges using comparison operators:

"symfony/symfony": ">=4.0 <5.0"

This allows any version from 4.0.0 up to, but not including, 5.0.0.

Hyphen Ranges

A more concise way to specify inclusive ranges:

"doctrine/orm": "2.0.0 - 2.9.9"

This is equivalent to >=2.0.0 <=2.9.9.

Stability Flags

You can specify minimum stability for a particular package:

"vendor/package": "1.0.0@dev"
"vendor/package": "1.0.0@stable"
"vendor/package": "dev-master"

Common stability flags include:

@dev: Development versions
@alpha: Alpha releases
@beta: Beta releases
@RC: Release candidates
@stable: Stable releases

Minimum Stability Setting

The minimum-stability setting in your composer.json file defines the default minimum stability of packages that Composer will consider when resolving dependencies:

{
    "minimum-stability": "stable",
    "require": {
        "vendor/package": "^1.0"
    }
}

Possible values (from least to most stable):

dev: Development snapshots and branches
alpha: Alpha releases
beta: Beta releases
RC: Release candidates
stable: Stable releases (default)

This setting affects all packages, but you can override it for specific packages using stability flags:

{
    "minimum-stability": "stable",
    "require": {
        "stable/package": "^1.0",        // Will only use stable versions
        "new/feature": "^1.0@beta"      // Will allow beta versions for this package
    }
}

The prefer-stable option can be used alongside minimum-stability to prefer stable versions when available:

{
    "minimum-stability": "dev",
    "prefer-stable": true,
    "require": {
        "vendor/package": "^1.0"
    }
}

This configuration will allow Composer to consider development versions but will prefer stable releases when they exist.

Version Aliases

Aliases allow you to treat branches as if they were version numbers:

"vendor/package": "dev-master as 1.0.x-dev"

Real-World Examples

Here's how you might use different constraints in a typical project:

{
    "require": {
        "php": "^7.4|^8.0",                    // Compatible with PHP 7.4+ or 8.0+
        "symfony/framework-bundle": "^5.4",    // Any 5.4+ version, but less than 6.0
        "doctrine/orm": "~2.8.0",              // Any version from 2.8.0 to <2.9.0
        "monolog/monolog": "1.25.*",           // Any version from 1.25.0 to <1.26.0
        "twig/twig": "^2.0 || ^3.0",           // Either Twig 2.x or 3.x
        "experimental/package": "dev-main@dev" // Development version from main branch
    }
}

Best Practices

For most dependencies: Use the caret (^) constraint to follow semantic versioning
For less stable packages: Use the tilde (~) constraint to limit updates to patch versions
Avoid wildcards in production: The asterisk (*) is too permissive for production environments
Lock file is crucial: Always commit your composer.lock file to ensure all team members and environments use the same versions
Regular updates: Run composer update regularly in development to catch compatibility issues early
Security updates: Use composer update --with-dependencies package/name to update a package and its dependencies for security patches

Updating Dependencies: Constraints vs. Commands

A common question is whether you should update your composer.json constraints when you want to update a dependency. For example, is it better to use ~1.2.3 or 1.2.*?

The answer depends on your update strategy:

Strategy 1: Flexible constraints + composer.lock

Use somewhat flexible constraints like ^1.2 or ~1.2 in your composer.json
Run composer update periodically to get new compatible versions
Let the composer.lock file track the exact versions in use
This approach requires less maintenance of the composer.json file

Strategy 2: Explicit constraints + manual updates

Use more specific constraints like ~1.2.3 (which is more precise than 1.2.*)
Manually update constraints in composer.json when you want newer versions
Run composer update package/name after changing constraints
This approach gives you more explicit control over when updates happen

Which is better?

The first strategy is generally recommended because:

It reduces maintenance overhead
It still gives you control via the lock file
You can run composer update --dry-run to preview changes before applying them

However, the second strategy might be preferred in environments where:

You need strict control over dependency updates
You have a formal review process for dependency changes
You're working with mission-critical applications where every update must be explicitly approved

In either case, the composer.lock file is your safety net, ensuring that all environments use the exact same versions until you deliberately update them.

Preventing Unwanted Downgrades

One important reason to use specific version constraints is to prevent unwanted downgrades. This can happen when:

You update a package to a newer version with important security fixes
Another package in your project depends on the same package but with a loose constraint
When you run composer update, you might unexpectedly downgrade to an older, vulnerable version

Here's a real-world example with hotfix versions:

Scenario:

Your project directly requires symfony/http-foundation: "^4.4"
You specifically update to version 4.4.50 which contains a critical security fix: composer update symfony/http-foundation
Later, you run composer update to update other packages
Another package in your project requires symfony/http-foundation: ">=4.4 <6.0"
Composer might downgrade you back to 4.4.30 (an older, vulnerable version) based on other constraints

By using more specific constraints, you can prevent this downgrade:

{
    "require": {
        "symfony/http-foundation": "^4.4.50",  // Ensures we never go below 4.4.50 (with the security fix)
        "some/package": "^2.0"               // This package might also depend on symfony/http-foundation
    }
}

In this example, the explicit version constraint ^4.4.50 ensures you'll never downgrade below the security patch level, while still allowing compatible updates (up to, but not including, 5.0.0).

This is particularly important for:

Security patches and hotfixes
Packages with known bugs in specific versions
Ensuring consistent behavior across environments

This is another reason why the explicit constraint strategy can be valuable in certain scenarios.

Conclusion

Understanding Composer's version constraints helps you balance between stability and receiving updates. The caret (^) constraint is usually the best default choice, but knowing when to use alternatives gives you fine-grained control over your project's dependencies.

Remember that the composer.lock file is just as important as your constraints—it ensures consistency across environments by locking the exact versions used.

By mastering these version constraints, you'll be better equipped to maintain robust PHP applications with well-managed dependencies.

Understanding `self` vs `static` in PHP

Hamdi LAADHARI — Wed, 23 Apr 2025 12:11:35 +0000

Understanding `self` vs `static` in PHP

In PHP, the keywords self and static are both used to refer to class properties and methods. However, they behave differently, especially when it comes to inheritance and late static bindings. Understanding the distinction between these two keywords is crucial for effective object-oriented programming in PHP.

What is `self`?

The self keyword in PHP refers to the class in which it is used. It is resolved at compile time and always points to the class where it is defined, regardless of whether it is called from a parent class or a child class. This makes self useful for accessing static properties and methods that are specific to the class where self is used.

Example of `self`

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        return self::$name;
    }
}

class Dog extends Animal {
    protected static $name = 'Dog';
}

echo Animal::getName(); // Outputs: Animal
echo Dog::getName();    // Outputs: Animal

In this example, even though Dog extends Animal and overrides the $name property, calling Dog::getName() still returns 'Animal' because self refers to the class where it is defined, which is Animal.

What is `static`?

The static keyword, on the other hand, refers to the class that was called at runtime. This is known as "late static binding," which allows static to adapt to the context in which it is called. This means that if a child class overrides a property or method, static will refer to the child class's version.

Example of `static`

class Animal {
    protected static $name = 'Animal';

    public static function getName() {
        return static::$name;
    }
}

class Dog extends Animal {
    protected static $name = 'Dog';
}

echo Animal::getName(); // Outputs: Animal
echo Dog::getName();    // Outputs: Dog

In this example, calling Dog::getName() returns 'Dog' because static resolves to the class that was called at runtime, which is Dog.

When to Use `self` vs `static`

Use self when you want to ensure that the reference remains fixed to the class where it is defined. This is useful when you want to prevent subclasses from overriding the behavior. It is ideal for maintaining consistency and preventing unintended overrides by subclasses.
Use static when you want the reference to adapt to the class that is called at runtime. This is useful for implementing polymorphic behavior, where subclasses can override properties or methods. This feature enables more dynamic and flexible code, as it adapts to the context in which it is called.

Practical Example

Consider a scenario where you have a base class Logger and a subclass FileLogger:

class Logger {
    protected static $logLevel = 'info';

    public static function log() {
        echo 'Logging at level: ' . self::$logLevel;
    }
}

class FileLogger extends Logger {
    protected static $logLevel = 'debug';

    public static function log() {
        echo 'Logging at level: ' . static::$logLevel;
    }
}

Logger::log();    // Outputs: Logging at level: info
FileLogger::log(); // Outputs: Logging at level: debug

In this example, Logger::log() uses self to ensure that it always refers to the $logLevel in the Logger class, while FileLogger::log() uses static to refer to the $logLevel in the FileLogger class.

Community Insights and Examples

Developers often share practical examples to illustrate the differences between self and static. For instance, when defining a method that returns a new instance of a class, using new self() will always return an instance of the class where the method is defined, while new static() will return an instance of the class that was called at runtime. This behavior is crucial for implementing factory methods or singleton patterns.

Online forums and Q&A platforms like Stack Overflow have numerous discussions where developers seek clarification on the nuances of self and static. These discussions often highlight common pitfalls and best practices, such as understanding how self and static behave in the context of inheritance and method overriding.

Example from Community Discussions

Here's an example that often comes up in community discussions:

class ParentClass {
    protected static $name = 'Parent';

    public static function getName() {
        return self::$name; // Always refers to ParentClass::$name
    }

    public static function getStaticName() {
        return static::$name; // Refers to the class that was called at runtime
    }
}

class ChildClass extends ParentClass {
    protected static $name = 'Child';
}

echo ParentClass::getName(); // Outputs: Parent
echo ChildClass::getName();  // Outputs: Parent

echo ParentClass::getStaticName(); // Outputs: Parent
echo ChildClass::getStaticName();  // Outputs: Child

In this example, self::$name always refers to ParentClass::$name, regardless of whether it is called from ParentClass or ChildClass. In contrast, static::$name adapts to the class that was called at runtime, demonstrating the power of late static binding.

Conclusion

Understanding the differences between self and static is essential for writing robust and maintainable PHP code. By leveraging community insights and practical examples, developers can make informed decisions about when to use each keyword, leading to more effective and flexible object-oriented designs.

DEV Community: Hamdi LAADHARI

The Sunset of General-Purpose Apps: Why Bespoke Tools are the Future

The Inherent Flaw of the One-Size-Fits-Most App

The Rise of Instant, Tailored Solutions

Pros of this Bespoke Future:

Cons and Challenges:

A Real-World Example: My Draft.js to HTML Viewer

Conclusion: Adapt or Be Replaced

Chrome Extension Network Interception: The Modern Way to Scrape Instagram (and Beyond)

Why Network Interception?

Architecture Overview

Minimal, Robust Implementation

1. Manifest Setup (MV3)

2. Page Interceptor (public/page-interceptor.js)

3. Content Script (content.js)

4. Background Script (background.js)

Best Practices & Gotchas

Extending to Other Platforms

Conclusion

Understanding Composer Version Constraints: A Comprehensive Guide

The Big Three: Caret, Tilde, and Asterisk

Caret (^) Constraint - The Recommended Default

Tilde (~) Constraint - More Conservative

Asterisk (*) Constraint - The Wildcard

Other Version Constraints

Exact Version

Version Ranges

Hyphen Ranges

Stability Flags

Minimum Stability Setting

Version Aliases

Real-World Examples

Best Practices

Updating Dependencies: Constraints vs. Commands

Preventing Unwanted Downgrades

Conclusion

Understanding `self` vs `static` in PHP

Understanding self vs static in PHP

What is self?

Example of self

What is static?

Example of static

When to Use self vs static

Practical Example

Community Insights and Examples

Example from Community Discussions

Conclusion

Caret (`^`) Constraint - The Recommended Default

Tilde (`~`) Constraint - More Conservative

Asterisk (`*`) Constraint - The Wildcard

Understanding `self` vs `static` in PHP

What is `self`?

Example of `self`

What is `static`?

Example of `static`

When to Use `self` vs `static`