Learn Wget - History, Background & Why You Need Wget

#Introduction

After setting up our environment in episode 0 — confirming GNU Wget 1.25.x is installed and verified — in this episode we'll take a brief pause from the hands-on work and understand why wget exists. The history and background of a tool may seem unimportant, but that's precisely where the reasons behind its design lie.

Why should you understand wget's history? Because wget isn't a project born in a corporate boardroom — it came from a very real, very simple need back in 1996. Understanding its origins will explain many of its design decisions — why wget was built to be non-interactive, why it excels at recursive downloads and mirroring, and why it's still the first choice for millions of sysadmins and DevOps engineers today.

#The Beginning: Geturl (1996)

The wget story starts with a developer named Hrvoje Niksic. In 1996, while studying in Zagreb, Hrvoje needed a way to download files from the web automatically — without having to open a browser one at a time. At the time, no practical tool existed for that simple task. So, like any good engineer, he wrote his own small tool and named it Geturl — exactly as the name suggests: a tool to get files via URLs.

Geturl grew quickly. The name wget — short for World Wide Web + get — was adopted shortly after, and in 1998 wget officially became part of the GNU project. From then on, its full name became GNU Wget. These two early decisions became the foundation of wget's design: able to run without interaction and able to fetch many files repeatedly.

#Two Lineages: Wget 1.x and Wget2

What confuses many people: there are currently two wget programs in circulation — classic wget and Wget2. They share the same name, but were rewritten in different ways.

#Wget 1.x: The Stable Workhorse

Wget 1.x is the lineage that's over 25 years old and the default on almost all Linux distributions. It's maintained with a focus on stability and compatibility — wget scripts you write today will still run on next year's version. The latest version is 1.25.x, and this is the basis for the entire series.

#Wget2: The Modern Successor with libwget

Wget2 is a complete rewrite that's under active development. Its core engine is separated into a library called libwget — similar to the relationship between curl and libcurl. Wget2 brings modern protocol support like HTTP/2, much higher speeds thanks to parallel connections, and more resource-efficient processing. Unfortunately, its maturity hasn't yet matched wget 1.x, so most systems still rely on classic wget.

wget --version

wget2 --version

If wget2 --version isn't installed, don't worry — this series uses wget 1.25.x, and you can confirm that with wget --version. Once you master wget 1.x, moving to Wget2 feels natural because its options are designed to be as close as possible.

#The Problems Wget Solves

The core problem wget solves is simple to say, but hard to do well: automatically downloading many files from the web, without human interaction, and doing it reliably.

Think of wget as a courier who never tires: it doesn't need feeding, doesn't need to be told twice, doesn't need a screen, and can work in the middle of the night via cron. This is where wget excels — something a GUI browser can't do, because browsers require an interactive session and a human.

#Non-Interactive in Practice

All the scenarios above share one common requirement: they must run without a human present. Scheduled downloads, nightly backups, asset synchronization in pipelines — all of these run when no one is watching the screen. This is where wget proves its value.

#!/usr/bin/env bash
wget -c -i urls.txt -P /backup/docs || exit 1
echo "Backup selesai"

The script above — which you'll fully understand in episodes 4 and 5 — is already enough to be scheduled via cron. Without wget, this kind of task has to be done manually: opening a browser, downloading, moving files, then repeating. With wget, a single command line replaces dozens of error-prone clicks that can't be automated at all.

#wget vs curl: When to Use Which?

The most common question after people get to know both tools: "can't curl already download? Why do we still have wget?" The answer: the two have different strengths.

A simple analogy: curl is a versatile broadcaster that can send any message to a server — great for API testing and precise requests. wget is an expedition truck designed to haul large quantities of goods — great for mass downloads, mirroring, and automation. In the real world, you'll use both; in this series, we focus on the truck.

#Brief Timeline

#Closing

In episode 1, you've traced wget's journey from a simple need in 1996 — Geturl — to becoming the de-facto standard non-interactive downloader with over 25 years of history. You also understand the two wget lineages (the stable 1.x and the modern Wget2), the real problems it solves, and its fundamental differences from curl.

Key takeaways:

• Wget was born as Geturl (1996) and became GNU Wget in 1998.
• Wget 1.x is the stable lineage used on almost all systems; Wget2 is the modern successor built on libwget.
• Wget's strengths: recursive download, mirroring, timestamping, and batch download — all non-interactive.
• wget vs curl isn't a winner-take-all battle — wget excels at mass downloads, curl excels at request flexibility.

In episode 2, we'll dissect wget's core concepts and main architecture — the non-interactive model that is its soul, the complete flow from URL to a file saved on disk, the role of the wgetrc configuration file, the exit code language, and how to control logging and output. See you in episode 2!