vox-browser
vox-browser copied to clipboard
vlang
What are the goals of the new creation?
If we can prove that existing browser implementations don't need to be as complex as they are, to me that would be a huge win; people need to stop being so confident that the shit software that exists today is well-designed and that it had to be as complex as it is -- that's nonsense!
Removing bloat that browsers usually have, while still maintaining a nice-to-look-at UI and extensibility (plugins) would be a nice target I think
Web standards are complex enough now that if you want to actually make the majority of sites work sensibly, you probably can't actually have a simple (in terms of code size/complexity) browser, let alone with enough optimizations to run at reasonable speed.
It's not like the companies developing browsers now wouldn't want the code to be simpler if they actually could make it that way without big sacrifices.
It's not like the companies developing browsers now wouldn't want the code to be simpler if they actually could make it that way without big sacrifices.
Just because someone wants their implementation to be simple doesn't mean they succeed at doing so.
Just because someone wants their implementation to be simple doesn't mean they succeed at doing so.
Sure, but there is a lot of investment in this space and simplicity would be a significant benefit, so I think if it was practical to have a browser which was generally usable and very simple it would already have been done. Web standards are, as I said, extremely complex, especially performant implementations of them which cover all the necessary edge cases.
A simple browser supporting some small subset is probably practical (and to some extent this already exists, for example lynx and other CLI browsers), but websites are increasingly moving towards using complex JS-heavy frontends.
- Small
- Fast
- Secure
- Private by default
I think those are the main things people want in a browser. Can you get all of them at once? I don't know.
The most fun would be the "Private by default". There are so many things that could be done there, that aren't really thought of in existing browsers.
For example: cookies.
Right now, any site can look at any cookies in your browser. There is no security on them, and if they happen to be storing a password or access token to another site, well... you just gave it away to a new one.
I'd like so see a browser that either a) ONLY allowed a site to look at it's own cookies, or at least b) a browser that automatically deleted cookies for a site when the site is closed (either the tab or the whole browser).
The User should be allowed to choose to keep certain cookies, but let's make cookies match the GDPR... they must be "opt-in" rather than "opt-out".
Right now, any site can look at any cookies in your browser.
Nope, each website can only see cookies for its own domain, not other domains.
Alright, so it's been a while since I checked on cookies. Glad to see some progress is being made.
That doesn't mean there aren't a lot of other ways browsers could be made more secure.
Fine, let's forget about cookies. I formed some opinions long ago, and have not seen anything to cause me to change those opinions, but am open to finding reasons. I now have a reason to change my opinion about cookies.
Please, just let it go, and focus on the things that are still broken.
I've added the goals to the readme:
The goal is to develop a free, clean, fast to compile (a couple of seconds), easily embeddable (like Electron),
efficient and low memory (like Opera's old Presto) browser engine.
Today's web is dominated by the Chromium engine. It's slow to compile (5 hours on top tier 2020 desktop hardware),
hard to develop because of the huge and complicated C++ code base, uses a huge amount of resources.
Firefox, the last alternative to Chromium, has unfortunately strayed away from its initial focus on privacy (it
has huge amounts of telemetry and questionable partnerships), it's not embeddable at all, is even harder to
build and develop than Chromium due to an older code base, has worse performance and battery usage.
There's a clear room for a new fresh alternative. Have more browsers is healthier for the open web.
Developing a browser is a very difficult task because of the ever increasing complexity of the web. Companies
like Opera and Microsoft gave up developing their own engines and switched to Chromium. However it's not
impossible. For example, a new proprietary browser Flow now successfully works with Gmail, one of the most
complicated web apps. The NetSurf browser works quite well with websites that don't rely on JavaScript for
rendering.
We will not be developing a new JavaScript engine, that simplifies the task significantly. The graphics/text
rendering is handled completely by V's builtin libraries, and cross platform UI is handled by V UI.
All we need to do is write a simple CSS & HTML engine. With the V language which focuses on simple and
maintainable code with fast compilation time, this will be a much easier task.
(edited to be readable here)
If it's not cookies, there must be other things... otherwise, why would Firefox have developed "container tabs"?
"Container tabs are like normal tabs except that the sites you visit will have access to a separate slice of the browser's storage. This means your site preferences, logged in sessions, and advertising tracking data won't carry over to the new container. Likewise, any browsing you do within the new container will not affect your logged in sessions, or tracking data of your other containers."
If not cookies, what "tracking data" are they talking about?
That's the type of thing that needs to be prevented in a new browser.
I've been planning a browser project for a while and have decided to write a custom scripting language specifically for it, but I think V is a fantastic idea. I'd love to ditch javascript, html and css altogether and go with a close-to-native, GUI framework like approach. That way all the incompatibilities between engines are completely overcome and users (the initial focus and idea behind my idea) would be able so specify themes that all apps and sites automatically obey. It would work over HTTP/S the way websites do today, except would be compiled code. I'd love some feedback on my Idea, and perhaps some help, if anyone would be interested in working on this. Please let me know
@J-Cake I just discovered https://gemini.circumlunar.space/ , which may interest you. It's trying to be an alternative to HTTP + HTML by creating a dramatically simpler protocol and markup language (which is similar to Markdown but even simpler... too simple, IMO).
EDIT: In Gemini, the user/viewer controls how sites are themed, not the site creator. Intro to Gemini: https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e
@J-Cake I just discovered https://gemini.circumlunar.space/ , which may interest you. It's trying to be an alternative to HTTP + HTML by creating a dramatically simpler protocol and markup language (which is similar to Markdown but even simpler... too simple, IMO).
EDIT: In Gemini, the user/viewer controls how sites are themed, not the site creator. Intro to Gemini: https://toobnix.org/videos/watch/8ee54700-971c-4da3-a8b4-7a78ed9ac42e
That's awesome! I love that I'm not the only one who sees this is cool, but my idea was to completely get rid of markup entirely, to have a completely logic based UI. So that Accessibility settings can affect how the entire UI is layed out. But Gemini is definitely on the right track. Thanks for sharing
If it's not cookies, there must be other things... otherwise, why would Firefox have developed "container tabs"?
There are many web APIs allowing for sites to do persistent storage. There are also a lot of observable differences between browsers and even each user's install/system configuration, which is used for fingerprinting.
I think the README is still underestimating the difficulty of this, though. CSS/HTML are very complicated, and so are the web platform APIs (V8 doesn't implement these itself, being basically just a very fast JS interpreter/JIT compiler). I don't know exactly what capabilities "V UI" has, but I wouldn't be massively surprised if implementing some features, or some performance optimizations, would require working around it a lot, unless HTML/CSS map really neatly to it.
@J-Cake Something like this might interest you: https://gioui.org/
Yes, that's basically exactly what I'm referring to. What do you search to find this kind of projects?
Just a random link I saved. I often find gems like that while searching for something completely different.
If it's not cookies, there must be other things... otherwise, why would Firefox have developed "container tabs"?
"Container tabs are like normal tabs except that the sites you visit will have access to a separate slice of the browser's storage. This means your site preferences, logged in sessions, and advertising tracking data won't carry over to the new container. Likewise, any browsing you do within the new container will not affect your logged in sessions, or tracking data of your other containers."
If not cookies, what "tracking data" are they talking about?
That's the type of thing that needs to be prevented in a new browser.
Tracking Data is a lot of things. Desktop resolution, Client (web engine, browser name, resolution of browser frame etc.), Desktop Operating System (a lot of details), geographic information via IP address and and time usually used for browsing. I could easily do a profile of you with that data and your social media tracks - given enough data and in my case time (I'm no professional profiler/data scientist or any sort of that). The less tracks one leaves the lesser complete is the profile and one is not as predictable as one would be without those gaps in the profile.
I am aware of those details. I also would prefer that my browser didn't give them out to anyone. without my explicit permission.
For some of them, like IP address and time when you look at things, you literally can't not give them out and still visit the page. For other ones (user agent information, so OS/browser version/etc.), you probably could hide them, although it would probably be possible to infer them from other stuff. For some of them, such as resolution and fonts and other stuff fingerprinting cares about, you can't really unless you constantly have permission popups saying "allow this website access to information which might help identify you" (which would appear frequently even on "normal" sites which just need to know that) or break everything by denying access.
Isn't servo a good stating point?
Yes it would be, although it's very complex and written in Rust (keep in mind the learning curve wall named borrow checker - I'm struggliing with that currently). But otherwise yes, it is a good starting point.
Or it could just give all the false information they wanted.
Sorry I didn't notice this and reply for a while, but no, not really. If you give stuff fake window sizes or fonts or anything like that (fingerprinting data), it could render wrong.
