> I've never thought about it until I saw this! Now I'm really irked about there not being a solid, mature browser based on extensibility. Where the base is basically an address bar and history awareness (i.e. back/forward) and even bookmarks is a module
If you guys are really into the idea of an extendable virtualized browser API, an extendable browser that you can hack on, and customize programmatically fully (including all the browser UI, the so-called “chrome”), then my BrowserBox project might be for you.^0^1^2
That open extendable browser is actually my vision of BrowserBox and I think it’s a really powerful thing. For example: I imagine being able to create an "extension store" using the more powerful set of APIs enabled by this (compared to the more limited APIs available to regular browser extensions). Similar to the idea you related where bookmarks is a module--which is something we've wanted to do for a long time--but not sure about the API contours!
The other ideas you talk about are all great, too: a UI that can be fully customized (vertical tabs!) or even tree tabs / history. Or all kinds of crazy things. Browser UIs are pretty uninnovative mostly, but a fully customizable UI could really open that up.
Modules ideas (that in some sense we've been exploring at Dosyago over the last few years, through DiskerNet, client projects, GraderJS and so on):
- web scraping / automation script builder
- vim shell
- vertical tabs UI
- bookmarks
- public / shared bookmarks
- full text searchable bookmarks (DiskerNet)
- NodeJS shell (GraderJS)
And I think BrowserBox may have the right model for that extensibility (maybe not totally right but the idea of: instead of using a WebView tag you’re using the much more extensible and powerful set of APIs for browser instrumentation and automation in other words, the "remote debugging protocol" APIs) to create the surface of extensibility. And our company has already built the the application with the browser UI at the front, and the instrumented browser engine at back to enable that building out an API. Our system is already a fully functional browser: with multiple tabs, back/forward history, but no other modules!
The main modules we have built so far have been: web scraping / automation script building for clients. We've experimented with other modules, but the majority of the work we need to do is around carving out the contours of that API. What surface do we provide in order to make modules really great? That's the key question and one we are looking for help answering.
Having that API for the browser to allow like a modules type thing is something that’s been on our plans for a long amount of time we always thought it was a good idea, but we’ve never been sure if there was much demand for it. Like you say here this Nyxt project really highlights the fact that this is something that really is a good idea or at least it seems like it and definitely people seem like they want it. There's still a lot of problems with this approach, but I believe they all have achievable solutions!
While our project may not be as technically elegant as using lisp, but I think it has the prosaic advantage of: having a simple client/server architecture (browser UI at the front, instrumented engine at the back); using a highly extensible set of powerful API‘s that are on essentially standard track with the WebDriver specifications (making, at least in theory, the future ability to swap out the browser engine between Chrome, Firefox, Safari, or whatever else that supports WebDriver); and I think most importantly--it’s written in JavaScript, Node.JS, HTML, CSS--greatly widening the field of potential contributors
I’m encouraged today by this project and the thread you have started to push our BrowserBox project more in this direction and I would like to encourage people to come on and check it out and because of that we are opening up our projects today to contributions. I think there's a lot of work to do and we can't do it alone!
If you guys are really into the idea of an extendable virtualized browser API, an extendable browser that you can hack on, and customize programmatically fully (including all the browser UI, the so-called “chrome”), then my BrowserBox project might be for you.^0^1^2
That open extendable browser is actually my vision of BrowserBox and I think it’s a really powerful thing. For example: I imagine being able to create an "extension store" using the more powerful set of APIs enabled by this (compared to the more limited APIs available to regular browser extensions). Similar to the idea you related where bookmarks is a module--which is something we've wanted to do for a long time--but not sure about the API contours!
The other ideas you talk about are all great, too: a UI that can be fully customized (vertical tabs!) or even tree tabs / history. Or all kinds of crazy things. Browser UIs are pretty uninnovative mostly, but a fully customizable UI could really open that up.
Modules ideas (that in some sense we've been exploring at Dosyago over the last few years, through DiskerNet, client projects, GraderJS and so on):
- web scraping / automation script builder
- vim shell
- vertical tabs UI
- bookmarks
- public / shared bookmarks
- full text searchable bookmarks (DiskerNet)
- NodeJS shell (GraderJS)
And I think BrowserBox may have the right model for that extensibility (maybe not totally right but the idea of: instead of using a WebView tag you’re using the much more extensible and powerful set of APIs for browser instrumentation and automation in other words, the "remote debugging protocol" APIs) to create the surface of extensibility. And our company has already built the the application with the browser UI at the front, and the instrumented browser engine at back to enable that building out an API. Our system is already a fully functional browser: with multiple tabs, back/forward history, but no other modules!
The main modules we have built so far have been: web scraping / automation script building for clients. We've experimented with other modules, but the majority of the work we need to do is around carving out the contours of that API. What surface do we provide in order to make modules really great? That's the key question and one we are looking for help answering.
Having that API for the browser to allow like a modules type thing is something that’s been on our plans for a long amount of time we always thought it was a good idea, but we’ve never been sure if there was much demand for it. Like you say here this Nyxt project really highlights the fact that this is something that really is a good idea or at least it seems like it and definitely people seem like they want it. There's still a lot of problems with this approach, but I believe they all have achievable solutions!
While our project may not be as technically elegant as using lisp, but I think it has the prosaic advantage of: having a simple client/server architecture (browser UI at the front, instrumented engine at the back); using a highly extensible set of powerful API‘s that are on essentially standard track with the WebDriver specifications (making, at least in theory, the future ability to swap out the browser engine between Chrome, Firefox, Safari, or whatever else that supports WebDriver); and I think most importantly--it’s written in JavaScript, Node.JS, HTML, CSS--greatly widening the field of potential contributors
I’m encouraged today by this project and the thread you have started to push our BrowserBox project more in this direction and I would like to encourage people to come on and check it out and because of that we are opening up our projects today to contributions. I think there's a lot of work to do and we can't do it alone!
0: https://github.com/dosyago/BrowserBox
1: https://github.com/dosyago/BrowserBoxPro
2: https://news.ycombinator.com/item?id=35996647