nyxt
nyxt copied to clipboard
atlas-engineer
Common Lisp as a JS replacement for web pages
Nyxt is certainly an awesome tool for powerusers. I haven't had the time to invest in it yet, but I was wondering if being written in Common Lisp means that Nyxt can also enable DOM manipulation using Common Lisp instead of Javascript? Or would Common Lisp mainly be reserved for extensions?
Yes, that's certainly possible, as every buffer has document-model slot as a duplicate of the real page DOM (although refreshing it with update-document-model is sometimes necessary). You can search it with clss:select and do actions on it with nyxt/dom:(click|focus-select|scroll-to|hover|check)-element functions. And if that's not enough, you can always resort to JavaScript using our define-parenscript and peval macros that translate Lisp code to JavaScript (using Parenscript, as the name implies).
Ookay, interesting :). That means, I can use Common Lisp for front-end scripting, so long as I have to worry about other browsers!
You mean using Lisp instead of JavaScript (that is not possible, afaik)? What do you mean?
What I wanted to do was to provide a script.lisp instead of providing a script.js with my index.html - is it possible with Nyxt?
No, sorry, that's not yet possible. And I'm not sure whether it'd be easy to add, given how much work is poured into JS-based Internet :D
I see, hmm, if the browser can fetch a lisp file from a server, just like the way it can fetch a js file, and if the browser can also run the lisp file, I'm curious where the difficulty stems from.
The difficulty stems from making the API rich enough to make anything practical (like modifying the DOM), and making it safe enough to not leak any user data.
Our custom schemes allows Lisp code evaluation, for example, but only on a strictly defined set of pages, and I still am not certain of whether they are safe. I wouldn't want to expand the attack surface by adding arbitrary lisp evaluation capabilities there.
I see, and yup, that makes sense. This is a relatively simple problem in theory, but in practice, the security implications might be huge.
I think we should let user decide if they want to enable script on any page, it would be a built-in greasymonkey for them.
@glyh users can already disable JS on any buffer with the command no-script-mode. Together with auto-rules, you get a powerful way to set whether JS is enabled on URLs you frequently visit.
@aadcg I think this can solve the security concern right? by default we can forbid any lisp script on any webpage, and let user decide if they really want to enable lisp script on the webpage.
Also, I think we may use some of the technique that haskell use to restrict the effect we may have by using a better type system. But I don't know how hard it is to implement on a dynamic typed language.
My understanding is that we allow the execution of Lisp code on extremely restricted conditions. As @aartaka mentioned, only in custom schemes that are designed to be isolated from the world (for obvious reasons). This is actually facilitated by renderer so it is not on our direct control. In other words, if there's a hypothetical security breach on the handling of these custom schemes, it is not our direct responsibility.
Another completely different subject is how we generate JS code that runs on typical web pages with the HTTP(S) scheme. We do that with CL (via the parenscript library). So the proposition "disabling Lisp script on web pages" has no meaning. Either JS is enabled or disable on those pages.
@aartaka correct me if I'm wrong.
My understanding is that we allow the execution of Lisp code on extremely restricted conditions. As @aartaka mentioned, only in custom schemes that are designed to be isolated from the world (for obvious reasons). This is actually facilitated by renderer so it is not on our direct control. In other words, if there's a hypothetical security breach on the handling of these custom schemes, it is not our direct responsibility.
We're talking different things here, I believe:
- You mean evaluation of unrestricted CL code on web pages as a way to interact with the browser and the OS. This indeed is dangerous and we take all the precautions to not spill this ability to unprivileged pages.
- While this issue is concerned with a restricted and sandboxed subset of CL being available as a JS replacement for dynamic webpage building. This should be totally safe when done right, as it is mostly safe running JS. Especially safe it would be with something like CL-Isolated.
Another completely different subject is how we generate JS code that runs on typical web pages with the HTTP(S) scheme. We do that with CL (via the
parenscriptlibrary). So the proposition "disabling Lisp script on web pages" has no meaning. Either JS is enabled or disable on those pages.
It does make sense in the second perspective I outlined—using CL as a scripting page-specific language. In this regard, we can indeed disable it like we can disable JS.
I do not think that unless we get serious market share, anyone would use such a facility. Why write a script that only works in a subset of the existing browsers? A more popular solution would be compiling to JS, which parenscript can already do. All of this said, I think this is outside of the scope of what we are doing right now. I'd rather not write a renderer, when we don't yet have a suitable chrome.
