October 15, 2026

Optimzing Images for the Web: Size, Licensing and SVGs



Images make a website feel alive, but they can also slow it down and cause legal trouble if you handle them carelessly. Today, I'll share what I learned about images for use on web.

Optimizing Media Assets

Three things matter when using images on a web page: size, format and compression.

1. Size

If you style an image to display at 640X480 (640px wide & 480 px tall), we should use an image file of the same size. If we use a 1920X1080 image file for this small display space the users are forced to download data that they'll never see. A smaller resolution means smaller file, which in turn means faster page.



2. Format

PNG and JPG are the most common formats for images. But these are no longer the best option for web use. For web, WEBP or AVIF are the most optimized (but may cause compatibility issues for some older browsers)

3. Compression

We can run compression algorithms on our images to shrink the image size. But not all compressions run the same way

  • Lossless formats like PNGs can be compressed without any quality loss, because the original data can be reconstructed perfectly. Using tools like PNGCRUSH it's very easily doable
  • Lossy formats like JPGs lose quality from compression though

Image Licenses
Images are intellectual property, and most of the time they're protected by copyright. By default they're all rights reserved, so we can't just use any image we want from the internet in our page. To use these images we need to:



  • Get written permission from the copyright holder.
  • or Purchase a license from the creator
  • or Use the image in a way that falls under fair use.
Fair use is a tricky one. We must be both limited and transformative in our use case.

Then there are Public Domain images. These images have no copyright attached and can be used freely. Images released under Creative Commons 0 are treated as public domain. Sites like Pixabay, Unsplash etc. have images which are free to use. 

SVGs
PNG and JPG are raster formats: they store color value on every pixel. This means they don't upscale well and get pixalated or blurry.




On the other hand, SVGs (scalable vector graphic) work differently. It stores color values as paths and equations that plot points, lines and curves, so it can be scaled to any size with no loss in quality.

SVG store their data in XML, so we can write SVGs directly inside our HTML code using the svg element

-----
<svg viewBox="0 0 100 100" xmlns="http://www.w3.org/2000/svg">
  <circle cx="50" cy="50" r="45" fill="yellow" />
  <circle cx="35" cy="40" r="5" fill="black" />
  <circle cx="65" cy="40" r="5" fill="black" />
  <path d="M30 65 Q50 85 70 65" stroke="black" stroke-width="3" fill="none" />
</svg>
-----




Basic syntax
svg: The container housing all the elements. Everything else goes inside it.
circle: Used to draw a circle
path: draws curves or lines

Best place to use SVGs: Icons, Logos. Font awesome is the most popular icon library which also use SVGs.

There we have it. Basics of using images on the web.

Thank you for reading!!!
September 23, 2026

Open Graph Tags & Meta Descriptions: The SEO Basics Nobody Explains Well



If you've ever shared a link on Facebook or LinkedIn and watched a clean preview card pop up — complete with an image, title, and description — you've seen Open Graph tags in action. And if you've ever looked at Google search results and noticed that little snippet of text under each blue link, that's a meta description doing its job.

Here's a breakdown of both, why they matter, and how they tie into SEO.

What Are Open Graph Tags?

Open Graph (OG) tags are a set of meta elements you place in your HTML <head> section. They control how your page looks when it's shared on social platforms — Facebook, LinkedIn, and others that support the protocol. Without them, a shared link often looks bare or pulls in random, unflattering content from your page.

The four properties worth prioritizing:

og:title — the headline shown in the preview card.

html
<meta property="og:title" content="10 Habits of Highly Productive Developers" />

og:type — tells platforms what kind of content this is (website, article, video, etc.).

html
<meta property="og:type" content="article" />

og:image — the thumbnail shown alongside the title. Facebook recommends at least 1200×630px for high-res displays, with 600×315px as the bare minimum.

html
<meta property="og:image" content="https://example.com/images/productivity-cover.jpg" />

og:url — the canonical link, so shares always point back to the "real" URL rather than a duplicate or tracking link.

html
<meta property="og:url" content="https://example.com/blog/productivity-habits" />

There are more you can add — og:description, og:audio, og:video, og:locale — but title, type, image, and url form the core set.

How does this connect to SEO?

Open Graph tags don't directly move the needle on Google rankings — search engines aren't reading your OG tags to decide where to place you in results. The connection is indirect but real: a strong preview card makes people more likely to click when your content shows up in their social feed. More clicks and engagement signal to platforms (and indirectly to search engines tracking traffic and engagement patterns) that your content is worth surfacing. Good OG tags are less "SEO hack" and more "don't sabotage yourself by looking untrustworthy or broken when someone shares your link."

What Is a Meta Description?

The meta description is a short summary of a page, also set via a meta tag — but this one is aimed at search engines and searchers, not social platforms.

html
<meta
  name="description"
  content="A no-fluff guide to building a daily routine that actually improves focus and output."
/>

Setting name="description" (instead of property, which OG tags use) tells browsers and search engines exactly what this data represents.

This description doesn't appear anywhere on the visible page itself — its main stage is the search engine results page (SERP), where it shows up as the snippet under your title and URL:

example.com › blog › productivity-habits
10 Habits of Highly Productive Developers
A no-fluff guide to building a daily routine that actually improves 
focus and output. Includes a free weekly planning template...

That snippet is often the deciding factor in whether someone clicks your result or the one above/below it. Keep it short and to the point — search engines will truncate long descriptions anyway, usually somewhere around 150-160 characters, so anything past that risks getting cut off mid-sentence.

Does it affect rankings?

Not directly. Google has been clear that meta descriptions aren't a ranking factor. But indirectly, a compelling description increases your click-through rate (CTR), and traffic/engagement patterns are things search engines do pay attention to over time. So: not a ranking signal itself, but a lever that can drive more of the traffic that does influence your standing.

Quick Recap (for future self)

TagAttributePurposeDirect SEO impact?
og:titlepropertyHeadline on social sharesNo — indirect via CTR
og:typepropertyContent type (article, website, etc.)No
og:imagepropertyPreview thumbnail (1200×630 ideal)No — indirect via CTR
og:urlpropertyCanonical share linkNo
meta descriptionnameSearch result snippetNo — indirect via CTR


The one-sentence version: Open Graph tags make your links look good when shared socially, meta descriptions make your links look good in search results, and neither one directly boosts your ranking — but both drive the clicks that can.

May 21, 2025

Zed: A Vim User's Perspective – Is This My New Daily Driver?

 

 


 Zed is a recent release and is picking up steam. Zed is made by the makers of Atom and Tree-sitter. It's an exceptionally fast, collaborative editor. It's designed to be fast and aims to provide a next-generation editing experience with the capabilities and extensibility of a quality editor. It comes with reasonable defaults and is highly customizable.

  Vim (or Neovim, I should say, as that is what it is for me) has been more than a code editor for some years now; it has been an extension of myself, a precision tool for crafting code. The modal editing, the immediate navigation, the pure productivity – you can't help but wonder once you "get" Vim how you ever did otherwise.

So, when a new editor pops up on the horizon, particularly one with "Vim-inspired" features, my attention is piqued. 

Meet Zed. Created by the masterminds behind Atom and Tree-sitter, Zed offers up a next-generation, high-performance, and collaborative editing experience. But can it really win over an old hand like me who's spent years using Vim?

After spending a some time with Zed, I'm seriously impressed, and bold me if I say, a little stoked. Now, here's why Zed, as the new kid on the block that it is, is so familiar and powerful to a Vim power user:

 

The "Vim-Inspired" Part: It's Not Just a Gimmick, It's the Core 

The biggest hurdle for any Vim user to overcome is muscle memory. Our fingers are trained in `hjkl`, `w`, `b`, `dd`, `yy`, `p`, and all the other Vim keystrokes that result in effortless editing. Zed understands this on a deep level. 

The moment I started using it, the underlying editing gestures were hauntingly familiar. It's not just vanilla keybindings; it's the philosophy. The modal editing model is present, and while it's not a 1:1 translation of Neovim's copious set of modes and operators, it's almost identical. I tended to fall into my Vim habits by default, and for the most part, Zed is a good sport about it.

Out-of-the-Box Genius: LSP & Autocomplete Made Easy

This is where Zed excels and addresses one of the most common annoyances for Vim enthusiasts: 

Language Server Protocol (LSP) and autocomplete. With Neovim, setting up LSP so it's working flawlessly requires a lot of setup, plugin hunting, and often debugging. A rite of passage for some, but definitely time-consuming nonetheless.

 Zed, on the other hand, just *gets it done*. I opened a Rust project, and bang – intelligent autocompletion, go-to-definition, reference lookups, and error highlighting were all present, straight away. No `init.lua` trickery, no `:LspInstall`, no `Mason` setup. This "zero-config" LSP experience is revolutionary and an incredible productivity benefit out of the box. For those who desire immediate productivity and reduced setup overhead, this is a huge win.

Customization: Your Vimrc, Brought to Life

The mark of an truly fantastic editor for the Vim user is how much it can be customized. We spend hours, if not days, fiddling with our `init.vim` or `init.lua` to get the ideal code environment for ourselves. Zed understands this desire for customization intimately.

One of the strengths of Zed is its very flexible keybinding system. I could import *most* of my own custom Neovim keybindings with little effort into Zed. This is not about just remapping basic commands; it can support elaborate key sequences and context-dependent bindings, mimicking the behavior of Neovim's `leader` key and even more advanced mappings.

For Example: 

 

I'd confidently say that you can configure Zed to get approximately **90% of your Neovim workflow** done. That's a bold claim, but my experience tells me it is true. From personalized leader mappings to certain actions run on a sequence of keys, Zed's configurations are robust enough to truly feel like "my editor."

Beyond Vim: Modern Features That Matter

While its Vim-like soul is a big draw, Zed is not a Vim clone. It boasts a wealth of modern features that are totally worth it:

  • Performance: It's fast. There's no wait to startup, and even large files and complex projects respond immediately.
  • Collaboration: Built-in collaborative editing is a great added benefit, especially for pair programming or team projects.
  • UI/UX: A clean, simple interface that is aesthetically pleasing without being distracting

The Verdict (So Far): A Strong Contender

A committed Neovim user, I entered Zed with an appropriately healthy skepticism. But after seeing what it can do, I'm really impressed. It packs an impressive punch combining the efficiency of Vim with contemporary editor niceties, most notably its unobtrusive LSP integration.
 

Will it supplant Neovim for all? Not immediately, perhaps. There will always be some esoteric plugins or very specialized setups that Vim does better due to its sheer age and extensive ecosystem. But for those who value:

  • Minimalistic setup for robust functionality (especially LSP)
  • A richly customizable keybinding system that respects Vim muscle memory
  • Blazing performance and a modern UI
  • Native collaboration

then Zed is a seriously strong competitor. It's becoming a daily driver for me now, and I strongly recommend any other Vim user to try it in good earnest. You might end up with your new favorite editor.

What's your impression of Zed? Have you tried it as a Vim user? Please share with us in the comments below!

My zed config: https://github.com/M4H1-4B1R/dotfiles/tree/main/zed/.config/zed
 

 

 

April 18, 2025

Easiest Neovim Completion

 


While Neovim is a powerful and very pluggable text editor, obtaining the smooth, VS Code-like autocompletion experience has always involved traversing a regime of plugins like "Luasnip," "cmp_luasnip," and "nvim-cmp." It typically formed a significant barrier, especially to newcomers.


Enter `blink.cmp`. This plugin basically simplifies obtaining feature-rich snippets functional in Neovim, with a very rational and simple approach.


It's super simple to get started. Just copy and paste the following lines into your Neovim config (typically your `init.lua` or a standalone plugin config file):


Lua

'saghen/blink.cmp',
dependencies = { 'rafamadriz/friendly-snippets' },
version = '1.*',
opts = {
  keymap = { preset = 'enter' },
  appearance = {
    nerd_font_variant = 'normal'
  },
  completion = { documentation = { auto_show = false } },
  sources = {
    default = { 'lsp', 'path', 'snippets', 'buffer' },
  },
  fuzzy = { implementation = "prefer_rust_with_warning" }
},
opts_extend = { "sources.default" }

That's it. As a long-time Neovim user, I can attest to how remarkably simple this setup is.


### Bonus: Enhancing Completions with LSP Integration


To further elevate your autocompletion experience, seamlessly integrate your Language Server Protocol (LSP) plugins and configurations with `blink.cmp`. Here's how:


Lua

return {
  {
    "williamboman/mason.nvim",
    config = function()
      require("mason").setup()
    end
  },
  {
    "williamboman/mason-lspconfig.nvim",
    config = function()
      require("mason-lspconfig").setup({
        ensure_installed = {"lua_ls", "cssls", "vtsls", "html", "eslint", "pyright"}
      })
    end
  },
  {
    "neovim/nvim-lspconfig",
    config = function()
      local lspconfig = require("lspconfig")

      ---- THESE ARE THE KEY LINES ----
      local capabilities = require("blink.cmp").get_lsp_capabilities()
      -- lspconfig.lua_ls.setup{} -- You can configure individual LSPs here
      lspconfig.cssls.setup{capabilities = capabilities}
      lspconfig.vtsls.setup{capabilities = capabilities}
      lspconfig.html.setup{capabilities = capabilities}
      lspconfig.eslint.setup{capabilities = capabilities}
      lspconfig.pyright.setup{capabilities = capabilities}
      --------------------------------
    end
  }

By including these configurations, `blink.cmp` has access to the rich semantic information that your LSP servers offer, resulting in more intelligent and context-aware suggestions.


`blink.cmp` is actually a game changer for Neovim users seeking an optimal and solid autocompletion setup. It eliminates the hassle and allows you to focus on what matters the most: coding.

February 05, 2025

Unlocking the Power of PDFs with JavaScript APIs



PDFs are often seen as static documents, but they can be much more interactive and dynamic than you might think. One of the key features that enables this interactivity is the support for JavaScript APIs.

How PDFs Support JavaScript APIs

PDFs can incorporate JavaScript code in a few ways:

  • Embedded JavaScript: JavaScript code can be directly embedded within a PDF document. This code can be executed when the document is opened or when specific events occur, such as a button click or a form field being filled.
  • External JavaScript Files: PDFs can also link to external JavaScript files. This allows for more complex and reusable code.
  • PDF Viewers: Modern PDF viewers, such as Adobe Acrobat and web-based viewers, have built-in JavaScript engines that can interpret and execute the code embedded in PDFs.

Cool Things You Can Do with JavaScript in PDFs

The ability to use JavaScript in PDFs opens up a wide range of possibilities:

  • Interactive Forms: Create dynamic forms that validate user input, perform calculations, and even generate customized responses.
  • Multimedia Integration: Embed audio and video content directly into PDFs, making them more engaging and informative.
  • Data Visualization: Use JavaScript libraries to generate charts and graphs within PDFs, presenting data in a visually appealing way.
  • HTTP Requests: PDFs can send HTTP requests to external servers, allowing them to retrieve data, submit form information, or interact with web services.
  • Custom Actions: Develop custom JavaScript functions to handle specific tasks, such as printing specific pages, navigating to URLs, or manipulating the PDF document's content.
  • Dynamic Form Fields: Showing/hiding fields based on user input.



Examples of JavaScript in Action

  • E-commerce: A product catalog PDF could use JavaScript to allow users to add items to a shopping cart and calculate the total cost.
  • Education: An interactive textbook PDF could include quizzes, simulations, and multimedia elements to enhance the learning experience.
  • Business: A contract PDF could use JavaScript to automate the signing process and securely transmit the document to the recipient.

Security Considerations

While JavaScript can add a lot of functionality to PDFs, it's important to be aware of the security risks. Malicious JavaScript code could potentially be used to steal data or compromise a user's system. To mitigate these risks, PDF viewers often have security settings that allow users to control the execution of JavaScript.

The Future of JavaScript in PDFs

As web technologies continue to evolve, we can expect even more innovative uses of JavaScript in PDFs. With the rise of HTML5 and related technologies, PDFs are becoming increasingly integrated with the web, allowing for seamless interaction between online and offline content.

Conclusion

JavaScript has transformed PDFs from static documents into dynamic and interactive experiences. By leveraging the power of JavaScript APIs, developers can create engaging, informative, and functional PDFs that meet the needs of a wide range of users.

I hope this blog post has given you a better understanding of how PDFs support JavaScript APIs and the exciting possibilities they offer. If you have any questions or comments, please feel free to leave them below!


Bonus

One can even run a tiny linux os on a pdf. Watch Mental Outlaws video to know more:

https://youtu.be/9hMh98FHRp4?si=ZnAtfl8cX3bfpP2h