Ga naar de inhoud
cutty.dev
All posts

Auto-prefix URL — een klein detail dat minuten bespaart

cutty.dev herkent wanneer je een adres zonder https:// plakt en voegt het zelf toe. Klinkt banaal. In de praktijk is dit het verschil tussen twee seconden en op 'probeer opnieuw' klikken.

Je typt allegro.pl in het formulier. Je klikt. En wat nu?

In de meeste verkorters krijg je op dat moment een foutmelding. Iets in de stijl van "dit is geen geldige URL". Omdat er geen https:// voor staat. Dus je gaat terug, voegt het protocol toe, klikt nogmaals, en pas nu heb je je korte link.

cutty.dev doet dit niet. Hij plakt gewoon zelf https:// eraan vast en gaat gewoon door, alsof er niets aan de hand is.

Ik weet hoe het klinkt. Als een feature die nauwelijks een alinea verdient, laat staan een hele post. En toch zit ik hierover te schrijven, omdat dit kleine detail voor mij een klein manifest is van hoe ik in het algemeen denk over het bouwen van de auto-prefix URL tool en de rest van al die onzichtbare gemakken.

Twee seconden tegenover twintig

Laten we gaan rekenen. Echt waar, op basis van de cijfers, want anders is het slechts gepraat.

Eerste pad: je plakt het, je hebt de link, je sluit het venster. Twee seconden. Misschien drie.

Tweede pad: je plakt, fout, leest de melding (een seconde of twee om te begrijpen waar het over gaat), voegt het protocol toe, klikt nog een keer, pas nu de link. Vijftien, twintig seconden. Plus dat kleine moment van irritatie, dat stille "oh ja, protocol", wat individueel niets kost, maar zich opstapelt.

Vermenigvuldig dit nu met hoe vaak je per maand een adres plakt. Bij mij zijn dat tientallen. Bij iemand die professioneel links beheert — honderden. Plotseling telt dit "nauwelijks vermeldenswaardige" detailtje op tot minuten per maand. Per persoon.

Dit is precies die rekenkunde die de meeste mensen over het hoofd zien, omdat elk individueel geval te klein lijkt om serieus te nemen.

Wat zit er eigenlijk onder de motorkap

Het mechanisme is banaal en ik verberg dat helemaal niet. Je plakt de tekst in het veld. Voordat er iets naar de server wordt verzonden, controleert een stukje JavaScript of wat je hebt ingevoerd begint met een bepaald protocol — http://, https://, ftp://, mailto:, wat dan ook. Als het niet zo begint, gaat het systeem ervan uit dat je een gewone domeinnaam bedoelt en plakt https:// ervoor.

In de praktijk:

  • allegro.pl verandert in https://allegro.pl
  • github.com/twoj-profil/projekt in https://github.com/twoj-profil/projekt
  • www.gazeta.pl in https://www.gazeta.pl

En als het protocol er al is, hoe vreemd ook, overschrijft het systeem het niet. Het laat het staan en kijkt verder wat ermee te doen. http://example.com gaat door (toegestaan). ftp://example.com gaat naar de prullenbak, omdat we alleen http en https accepteren. En javascript:alert(1) vliegt direct eruit, want dit is geen adres, maar een poging om iets vies te injecteren (klassieke XSS, bedankt, nee).

Waarom heb ik dit, terwijl de helft van de markt het niet heeft

Hier wordt het interessant, want het antwoord is een beetje grappig.

De standaard manier om een adres te valideren in de browser is de constructor new URL(string). En deze constructor is hard. Onverzettelijk. Er is geen protocol — hij gooit een foutmelding. new URL("allegro.pl") geeft je gewoon een TypeError en dat is alles.

En weet je wat? Dit is correct gedrag. Voor het overgrote deel van de applicaties is dit precies wat je wilt. Maar in een formulier om links in te korten, waar iemand een adres kopieert uit de adresbalk van de browser of uit iemands bericht, verandert deze strengheid van een voordeel in een hindernis. Plotseling dwingt een hulpmiddel dat je tijd moet besparen je om iets te corrigeren wat het eigenlijk perfect begrijpt.

De workaround hiervan is letterlijk een paar regels:

function sanitizeUrl(input) {
  const trimmed = input.trim();
  const hasProtocol = /^[a-z][a-z0-9+.-]*:/i.test(trimmed);
  const normalized = hasProtocol ? trimmed : "https://" + trimmed;
  // dalej leci normalna walidacja przez new URL(normalized)
}

Vijf regels. Een tiental seconden minder wrijving, per dag, voor iedereen die adressen plakt. Ik weet eerlijk gezegd niet waarom dit niet overal de standaard is. Ik vermoed dat het eraan ligt dat "de URL-constructor gewoon zo werkt" en niemand de moeite wilde nemen om het aan te raken. Inertie, geen kwade wil.

Een kleine zijstap over wat "standaard" betekent

Want dit verhaal met new URL() is een geweldig voorbeeld van iets groters. Veel dingen in software die worden beschouwd als "zo wordt het gedaan", zijn in werkelijkheid "zo is het voortgekomen uit de standaardinstellingen van een bibliotheek die niemand heeft aangevochten". De strict mode van de constructor is geen beslissing van de ontwerpers van cutty of de concurrentie — het is een beslissing van de auteurs van de URL-specificatie, genomen in een totaal andere context, voor totaal andere toepassingen.

En daarna erft de hele markt deze standaardkeuze en noemt het een "standaard". Ik heb het gevoel dat de beste producten precies ontstaan op de plekken waar iemand stopte en vroeg: wacht even, dient dit gedrag mijn gebruiker, of alleen mijn bibliotheek? Meestal is het antwoord: de bibliotheek. En dan is het de moeite waard om met vijf regels code over te stappen naar de kant van de mens.

Er zijn meer van deze details dan je ziet

Auto-prefix is slechts een van de vele dergelijke elementen die je op geen enkele lijst met functies zult vinden. Want als ze daar zouden worden vermeld, zou elk afzonderlijk element er belachelijk klein uitzien:

  • het trimmen van spaties voor validatie, zodat een per ongeluk geplaatste spatie aan het einde van een geplakt adres niet alles verpest
  • het behouden van de anker, oftewel #section in https://example.com/page#section verdwijnt niet na het inkorten
  • queryparameters (?utm_source=test) worden volledig overgenomen, niets wordt onderweg afgebroken
  • domeinen met Poolse tekens, źdźbło.pl, worden automatisch omgezet naar punycode
  • Poolse letters in de eigen slug worden omgezet naar ASCII (różowy-link wordt rozowy-link)
  • onveilige protocollen — javascript:, data:, file: — worden geweigerd met een specifieke, begrijpelijke melding

(Er is nog een automatische upgrade van http:// naar https:// gepland, wanneer de doelserver versleuteling ondersteunt. Dit werkt momenteel nog niet live, dus ik zal niet doen alsof.)

Elk van deze details bespaart iemand vijf, tien, dertig seconden en één zucht. Afzonderlijk niets. Samen is het het verschil tussen "werkt oké" en "ik vind het fijn om dit te gebruiken".

Wat ik nog zou willen bijverdienen

Wensenlijst voor de toekomst, want erover nadenken geeft me gewoon plezier:

  • intelligent plakken — een adres dat midden in een zin verborgen zit detecteren en alleen de URL uit de woorden halen
  • bulkplakken — een lijst met adressen, één per regel, en direct voor elk adres een aparte korte link maken
  • voorgestelde extensies — op basis van de titel van de doelsite drie merkwaardige slugs aanbieden om uit te kiezen
  • Open Graph-voorbeeld direct na het plakken, nog voordat je op "verkorten" klikt

Elk van deze is weer een "vijfregelige functie die nergens op lijkt". En ze allemaal samen? Dat is precies de grens tussen een hulpmiddel dat prima is, en een hulpmiddel waar je elke dag zonder nadenken naar grijpt. Als je wilt zien hoe het nu werkt, plak dan in cutty.dev alles zonder protocol — allegro.pl, github.com, news.ycombinator.com — en zie dat het je geen enkel obstakel in de weg legt.

Ten slot, even wat persoonlijker

Ik dacht lang dat producten winnen met grote functies. Dat ene spectaculaire ding dat je op een slide kunt laten zien en waar mensen over zullen schrijven. En ja, soms is dat zo.

Hoe langer ik cutty bouw, hoe sterker ik voel dat gebruikersloyaliteit ergens anders ontstaat — in die honderden microseconden die niemand bewust opmerkt. Je herinnert je niet dat de tool zelf https:// heeft toegevoegd. Je herinnert je alleen de algemene indruk dat "het prettig werkt" of "niet irriteert". Die indruk komt niet uit het niets. Het bestaat uit tientallen beslissingen van vijf regels lang, die niemand individueel zou verdedigen als "de tijd waard".

Misschien is dat precies waar vakmanschap in bestaat. Niet in die ene grote beweging, maar in de volharding om keer op keer de kant van de mens te kiezen bij een formulier — zelfs als het gaat om slechts twee magere seconden. En jij? Wat heeft je onlangs zo erg gefrustreerd in een tool, dat het zo klein was dat het bijna gênant is om toe te geven? Want meestal zit daar juist het beste werk te wachten om gedaan te worden.