We rely on upstream providers of web engines (WebKitGTK+, Qt WebEngine) to test and audit secure web engines for us. We talk about this in our article where we justify some of our technical design decisions: ģ. If websites decide to ban browsers that utilize WebKitGKT+, we'll have another renderer available to us.
This makes us resilient to renderer specific problems. We can use both WebKit and Web Engine (Chromium). Our project is a chrome that is agnostic of the renderer engine. 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).Ģ. So it is irrelevant what part is invoking C, it is still fully funcall'able at runtime. In fact, you can even GENERATE bindings at run time. All of our FFI bindings are also written in Common Lisp ( ). Nyxt is entirely written in Common Lisp, so yes, any part of it can be reprogrammed at any time. 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.Ī welcome critique, though unfortunately mostly incorrect :-D! I'll address some of your comments:ġ. 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. The UI veneer and subsets of the rendering engine library APIs that you expose as programmable in Lisp, are the least interesting ones. 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).īut most important to me, other than security, is the lack of flexibility and power. Doing browsing with the isolated engine libraries was (and still is) a recipe for disaster. 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. Security will always be a serious problem (and getting worse as time flows).
Which leads me to the issues I see with Nyxt: 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. Your project is essentially a thin UI veneer on top of C browser engines. Lisp is cool but it does not enable "any part of Nyxt to be reprogrammed at any time".
0 kommentar(er)
