In un certo senso le servlet sono l'equivalente lato server delle applet. Le due tecnologie infatti presentano molte analogie. Le applet sono di fatto una API che il Web Browser utilizza per interagire con programmi in Java caricati dinamicamente dalla rete. Una applet infatti è tecnicamente analoga ad una DLL, e le convenzioni per utilizzarla rappresentano una API. Naturalmente le classi Java sono multipiattaforma , è molto più semplice svilupparle e sono molto più sicure. Le applet quindi vanno considerate estensioni del browser che gli consentono di ampliare le sue capacità, implementando nuove funzionalità come animazioni, interfacce grafiche o altro.

Le servlet ripercorrono questa impostazione per i Web Server. Si tratta infatti sostanzialmente una API, utilizzata dal Web Server per interagire con programmi in Java che lo estendono, rendendolo capace di fornire nuovi servizi. Sia servlet che applet girano in una virtual machine incorporata rispettivamente nel server e nel browser.

Oltre alle somiglianze ci sono delle differenze. Le servlet web forniscono sostanzialmente nuovi servizi per il Web Server e non presentano solitamente nessuna interfaccia grafica. L'interazione con l'utente avviene, come nei normali programmi CGI, tramite la generazione di pagine Web, che possono anche (ma non necessariamente) contenere delle applet. Il caricamento dinamico delle servlet, pur essendo una interessante possibilità che apre nuove prospettive (per esempio agenti mobili), non è così importante come per le applet. Una servlet web gestisce le richieste inviate tramite URL oppure processa l'output proveniente da moduli. Le servlet quindi svolgono la stessa funzione della CGI, ma rispetto a quest'ultima presentano numerosi vantaggi.

Innanzitutto viene risolto alla radice il problema dell'efficienza. Una servlet viene caricata all'avvio del Web Server e rimane in memoria a servire le richieste. L'overhead per la gestione di una richiesta è pari alla chiamata di un metodo, non al bootstrap dell'interprete, quindi di gran lunga inferiore. Una conseguenza di questa architettura è che le servlet possono mantenere uno stato (per esempio una servlet può "ricordare" le volte che è stata chiamata senza dover salvare lo stato su un file oppure può mantenere aperta una connessione a database). Ancora le servlet possono comunicare tra di loro, e possono essere concatenate: una richiesta può essere gestite con una pipeline di servlet.

Potendo utilizzare Java in particolare, si accede immediatamente alle sue numerose qualità: l'accesso a database utilizzando una interfaccia standard; il multithreading , le API per il semplice utilizzo dei protocolli di rete, il caricamento dinamico del bytecode dalla rete, la security per restringere la pericolosità di una classe di dubbia origine, infine le numerosi librerie e componenti di terze parti che ormai cominciano ad essere facilmente reperibili sul mercato.

Potendo utilizzare un solo linguaggio sia per lo sviluppo client e server, il programmatore deve imparare a gestire API complesse come quelle per l'accesso a database una volta sola. Per esempio, programmando in Java sul client e in Perl sul server, non solo si devono imparare due linguaggi, ma si deve anche imparare sia il JDBC di Java che la DBI del Perl, talvolta per accedere allo stesso database. Vanno considerati anche i vantaggi derivanti dalle interazione che è possibile realizzare sfruttando la combinata di Java sia sul server che client. Per esempio, una applet può richiedere dati ad una servlet, ottenendo in risposta un oggetto Java serializzato trasmesso via http, e sfruttare questa caratteristica di Java invece di dover utilizzare una codifica apposita.