You are being disingenuous here. Lisp is cool but it does not enable "any part of Nyxt to be reprogrammed at any time".
Your project is essentially a thin UI veneer on top of C browser engines. That latter part, which is by far the most interesting, can not be reprogrammed in Lisp except through the very limited exposed C library API. Which leads me to the issues I see with Nyxt:
Security will always be a serious problem (and getting worse as time flows). You don't have the resources of Google or even Mozilla, that ship self-contained browsers and can implement security solutions in a holistic, systemic manner. Doing browsing with the isolated engine libraries was (and still is) a recipe for disaster.
Then, for the same reasons, the big corporations can essentially kill your project at any point by treating it as unsafe/insecure and having their sites stop working (which is actually happening at Google).
But most important to me, other than security, is the lack of flexibility and power. The UI veneer and subsets of the rendering engine library APIs that you expose as programmable in Lisp, are the least interesting ones. Why would anyone want to reimplement uBlock or other popular extensions in some convoluted mix of Lisp and Javascript, rather than use the superior originals? This is the final tombstone for me.
It's clear that you're trying to build an ecosystem and deliver "apps" on top of, like an Emacs-like for the web maybe, but for the reasons I mentioned I see it as fundamentally flawed and want no part of it.
A welcome critique, though unfortunately mostly incorrect :-D! I'll address some of your comments:
1. Nyxt is entirely written in Common Lisp, so yes, any part of it can be reprogrammed at any time. All of our FFI bindings are also written in Common Lisp (https://github.com/atlas-engineer/cl-webkit). In fact, you can even GENERATE bindings at run time. So it is irrelevant what part is invoking C, it is still fully funcall'able at runtime. This is what makes Nyxt not a 'thin veneer', but rather a deep integration which exposes all resources to the end-user (something unique to Nyxt).
2. Our project is a chrome that is agnostic of the renderer engine. We can use both WebKit and Web Engine (Chromium). This makes us resilient to renderer specific problems. If websites decide to ban browsers that utilize WebKitGKT+, we'll have another renderer available to us. We talk about this in our article where we justify some of our technical design decisions: https://nyxt.atlas.engineer/article/technical-design.org
3. Security is very important to us. We rely on upstream providers of web engines (WebKitGTK+, Qt WebEngine) to test and audit secure web engines for us. We can't do everything, you're right about that. For this reason, we give users the choice, and hope for the best!
4. "Lack of flexibility and power"- I think this point is probably the most inaccurate. If you look through our articles you'll see a couple of things that make Nyxt powerful and flexible.
4.A. Composability, all extensions (plugins, as you may call them) can call and utilize each other. That means, as our ecosystem grows, so does the power grow exponentially!
4.B. Flexibility: We give the user access to the complete Common Lisp compiler, all packages on Quicklisp, and the ability to override and change literally any aspect of Nyxt. I often speculate that Nyxt is potentially the most flexible browser to have ever existed.
5. Lastly, no, we are not trying to deliver "apps" on top of Nyxt. Nyxt is a browser, and a programmable platform, not an app delivery mechanism.
I hope that the above was informative, and if not changed your mind, at least exposed you to our view point!
Once again, thanks for the critique, and happy hacking!
1. You're arguing semantics in a disingenuous fashion which reinforces my point and make me like Nyxt even less. Nyxt, the end-user product, "is not entirely written in Common Lisp". Your rendering and browsing engine, the core of your application, Webkit, is not a Lisp library.
2. This doesn't solve the problem. Being able to use both webkit and web engine in no way makes you resilient to the issue I brought up. Google has plenty of reasons to disallow and prevent their engine to be used by Nyxt and they have said that they will do so. Your answer strengthens my point.
3. Again, the issue is systemic and there's nothing upstream providers of web engines can do. Using these libraries in isolation will always expose you to significantly more security issues than using them as part of the browsers they were meant to be used in.
4. Flexibility and power (as I explained) is me using uBlock origin and coutless other extensions without reimplementing them from zero. Do you have uBlock origin for Nyxt? I rest my point.
Your project is essentially a thin UI veneer on top of C browser engines. That latter part, which is by far the most interesting, can not be reprogrammed in Lisp except through the very limited exposed C library API. Which leads me to the issues I see with Nyxt:
Security will always be a serious problem (and getting worse as time flows). You don't have the resources of Google or even Mozilla, that ship self-contained browsers and can implement security solutions in a holistic, systemic manner. Doing browsing with the isolated engine libraries was (and still is) a recipe for disaster.
Then, for the same reasons, the big corporations can essentially kill your project at any point by treating it as unsafe/insecure and having their sites stop working (which is actually happening at Google).
But most important to me, other than security, is the lack of flexibility and power. The UI veneer and subsets of the rendering engine library APIs that you expose as programmable in Lisp, are the least interesting ones. Why would anyone want to reimplement uBlock or other popular extensions in some convoluted mix of Lisp and Javascript, rather than use the superior originals? This is the final tombstone for me.
It's clear that you're trying to build an ecosystem and deliver "apps" on top of, like an Emacs-like for the web maybe, but for the reasons I mentioned I see it as fundamentally flawed and want no part of it.