Alternatives

This page is work in progress.

nREPL is certainly not the only project that aims to provide a common foundation for (Clojure) development tooling. ^[1] Here we’ll mostly focus on alternatives in the realm of Clojure, and we’ll briefly go over some (subjective) pros and cons they offer.

It’s always hard to be objective when comparing your project with alternatives, but we’ll do our best. Keep in mind that there’s no universally best solution for every problem, so your mileage might vary depending on your requirements and use-cases.

Socket REPL

A socket REPL server was added in Clojure 1.8. In essence it’s just a socket version of the standard REPL - the input is text (code) and the output is text. Nothing more, nothing less.

Here’s a typical exchange between a client and a socket REPL server:

;;;; Basic evaluation
;; request (plain text)
(+ 10 10)

;; result (plain text)
20

;;;; Handling of output
;; request
(println "Hello, world")

;; response (the output and the result are intermixed)
Hello, world!
nil

As you can see the main issue with the socket REPL is that it’s hard to tell apart values (results) from output in the evaluation responses. That’s fine when you’re interacting with a REPL directly, but is a big issue if you’re using it programmatically. Still, I think it’s fair to say that the main purpose of the socket REPL server is to give you a basic REPL, not building development tools on top of it.

Pros

Very simple
Bundled with Clojure and ClojureScript
Easy to leverage from Clojure(Script)/Java(Script) clients

Cons

Streaming input means tooling has to be built on top of eval
Streaming output makes it hard to tell apart output from results
Updates are constrained to Clojure’s development cycle
Clients have to support EDN, which is a problem in certain environments

prepl

prepl is a structured REPL built into Clojure since version 1.0. Clients feed prepl text to be evaluated and receive the result as a map. That makes it much easier to use the REPL from development tools.

Here’s a typical exchange between a client and a prepl server:

;;;; Basic evaluation
;; prepl request (plain text)
(+ 10 10)

;; prepl response (map)
{:tag :ret,
 :val "20",
 :ns "user",
 :ms 23,
 :form "(+ 10 10)"}

;;;; Handling of output
;; request
(println "Hello, world")

;; response
{:tag :out,
 :val "Hello, world\n"}
{:tag :ret,
 :val "nil",
 :ns "user",
 :ms 8,
 :form "(println \"Hello, world\")"}

Pros

Very simple
Bundled with Clojure and ClojureScript
Easy to leverage from Clojure(Script)/Java(Script) clients

Cons

Streaming input means tooling has to be built on top of eval
Updates are constrained to Clojure’s development cycle
Clients have to support EDN, which is a problem in certain environments

Language Server Protocol

The Language Server protocol is used between a tool (the client) and a language smartness provider (the server) to integrate features like auto complete, go to definition, find all references and alike into the tool.

With LSP you’d end up with a server similar to nREPL providing common editing operations. The communication between an LSP client and a server is done via JSON.

Currently there’s a single implementation of an LSP server for Clojure - namely clojure-lsp. Its functionality is powered internally by static code analysis, one can easily imagine an LSP server implementation that’s powered by a REPL.

Pros

Language-agnostic protocol
Wide support in editors
Different implementations for the same language

Cons

The protocol is controlled by a single company
Clients have to support JSON, which is a problem in certain environments
You still need some REPL server for code evaluation

Comparison

It’s important to understand that while the socket REPL and prepl are pure REPLs (meaning their sole focus is reading, evaluating and printing), nREPL is both a REPL and a development tooling protocol. In this sense it sits somewhere between all other REPL servers and LSP.

nREPL was designed to be used programmatically and build tools on top of it. It was designed to be infinitely extensible when it comes to supported operations, data formats and communication channels.

Table 1. Comparison Table
Name	Input/Output	Data Format	ClojureScript Support	Clojure-agnostic Protocol	Optimized for Tooling
nREPL	Structured Input/Output	Bencode/EDN^[2]	Requires extension (Piggieback)	Yes	Yes
Socket REPL	Streaming Input/Output	EDN	Yes	No	No
prepl	Streaming Input/Structured Output	EDN	Yes	No	Yes
LSP	Structured Input/Output	JSON	n/a	Yes	Yes

1. nREPL was the first such effort in the Clojure community, though.

2. Other data formats (e.g. JSON) are supported via extensions.