How much is Nyxt dependent on jAvasCript/HTML technology?

Depending on web technology does not seem to be a problem for now. Nyxt, at the moment, is targeted as a browser after all. However, the “contemporary” web has lived much shorter than Lisp and I think it’s better to at least maintain the possibility of developing a pure Lisp variant. Maybe someday “contemporary” web will die, maybe Lisp takes over again, who knows.

I think the main obstacle would be replacing the parenscript part with pure Lisp. Nyxt abstract over web engine using RPC and make it easy to switch between web engine, which is good. Trying to maintain a Lisp interface (which has a parenscript backend) instead of calling parenscript directly from arbitrary places would make hypothetically switch to non-JS technology easy. Do people think this principle is desirable? Is it already being followed in current practice? I haven’t read through all the codebase, so am not sure about the second question.

I see the benefit of Lisp, but I also see the benefit of HTML/CSS and maybe even JavaScript.


HTML/CSS is the simplest, most accessible and popular way to build interfaces ever existing, there’s not much one can say agains this. I personally thing that everyone should stick with HTML… until Lisp takes over everything as the universal interface-writing notation :stuck_out_tongue:


Replacing JS with pure Lisp actions is impossible, given that abstractions that all the rendering engines provide are insufficient to closely interact with the web page. The only omnipotent tool engines have is JavaScript evaluation. That’s why Parenscript is the best we can do in this situation—hide low-level auto-generated ugly JavaScript behind the beautiful Lisp facade.

The idea of the Lisp interface to page interaction is cool, but it’s doomed to be awfully incomplete for any non-trivial task, given how much work JavaScript can do.


We don’t use RPC for renderer communication. We did, but this time is long gone. Right now, all three renderers that we have (GTK, GI-GTK, and a terribly abandoned Qt) use CFFI (C Foreign Functions Interface) to call C functions and create C objects in Lisp code. In a sense, we’re more dependent on C than JavaScript here. That I’m not keen on fixing, as C is the “most portable Assembly” out there, and most engines have some form of C interface. This helps us interface with the engine without re-implementing half of it in Lisp.

It would be cool to resurrect Closure, and I’d personally be the first person to join this resurrection. However, updating Closure to the level of modern renderers is just too much work for one, five (Atlas Engineer) or hundred (active and Lisp-speaking part of Nyxt userbase) people to manage.

P.S. Wow, what a whiney I am :smiley:

1 Like

I mostly agree with this. One thing to clarify: what’s good is HTML/CSS the model, not. HTML/CSS the language, and I think people also agree (no one writes HTML/CSS strings in Nyxt)! Given that, HTML/CSS the model is far from something mutually exclusive with Lisp, and it’s totally reasonable that someday it (or, an improved variant) is implemented in pure Lisp.

I’m not proposing removing JS in the implementation at all. I’m talking about keep JS/PS in one place, so it can be potentially replaced – if there is hypothetically to be a pure Lisp Nyxt variant that does not use web renderer. Implementing a HTML/CSS like GUI model in such variant is very desirable, but, a JavaScript like language, not so much. And JavaScript would become non-essential because the DOM tree will happily live inside Lisp image itself. That’s what I’m worried about – if ParenScript is interleaved with Lisp across the codebase it may eliminate such possibility.

But after second thought, maybe I’m just being paranoid. ParenScript has relatively similar syntax to original Lisp, and I might overestimate the complexity to convert it to pure Lisp.

Thanks for the information! I always thought GI-GTK and GTK is the same thing. Time to actually read this part of code.

GTK and GI-GTK renderers are mostly the same, except that GI one extends the GTK one to avoid some window management bug that we cannot fix directly :upside_down_face: