Show HN: FixBrowser – a lightweight web browser created from scratch (fixbrowser.org)
At some point I've realized that much of the complexity and resource requirements of web browsers comes from JavaScript. This is because every part needs to be dynamic and optimized for speed.
So a few years ago I've started to work on a web browser that intentionally doesn't implement JavaScript, instead it contains an updated set of scripts that fix and improve various websites.
I've been using this approach using a proxy server for a few years as my primary way of web browsing with good results. It uses a whitelist approach where no resources are loaded from different domains by default (the fix scripts can override it to load images from CDNs, etc.). This avoids any trackers by default.
You can find more details on the homepage of the project:
I'm currently running a fundraiser to get it really going. All the foundation blocks are there it just needs some more work. Any support is welcome.
153 comments
[ 0.30 ms ] story [ 234 ms ] threadThank you so much for making this project.
I'll be adding it to my test suite.
It would be nice if `apt install netsurf` returned something more helpful than "Unable to locate package netsurf"
The thing is I was about to build my own browser with netsurf components (but probably with my own toolkit)... then I stumbled upon the fact that it won't help much more than to use links or lynx since sites are getting javascript-walled. At best I would get a CSS renderer, coded in plain and simple C99+.
Since Big Tech controls the software to access their online service, they will give hell to any promising real-life alternative.
To say that the only sane way out of this, is not even coding a plain and simple C99+ real-life javascript web engine, but ensure by law/regulation that all "utility/critical" sites have a working and sane noscript/basic (x)html portal (as 100% of them had a few years ago...............)
apt-cache search netsurf
A project based on servo would be more credible. Sure, those developers are building JavaScript engines. However, their browsers are highly modular and you could do a build without JavaScript, a lot more easily than with the major browser engines.
In addition, it uses your own programming language, and there is no source repo.
Edit: I see the purpose of it better now. It would perform very well, but not compared to other browsers that had the same modifications. However, since other browsers don't have the same modifications, it would work comparatively well for the sites it would work with.
If you wanted to make it run fast with while supporting a lot of sites, and still be simple, I think using Servo would be a quicker path. They've already solved a lot of layout problems.
Good luck with it.
However, they do provide a zip file containing source.
At least it’s open source although for some reason they are choosing to not use a version control system.
It allows for a much simpler one-way processing from one stage to another. In comparison a full browser must maintain data structures for fast dynamic changes by JS, making it much more complex. I've written about it in a more detail in the About section.
Embedding of a full browser engine as an option is planned, I've chosen CEF as the most suitable choice. It could be used for specific tabs or websites (eg. applications) while being integrated with the rest of the browser. However CEF is not very portable so it won't be available for all planned systems.
This way you would use it only for websites/applications that need it while saving resources when browsing the rest of the websites.
It must take courage to disclose your product to HN.
We need to return that courage with an attempt.
First, the evaluation. Then constructive comments.
It uses its own language, it's really written from scratch to such an extent that it uses direct C API for Cocoa on macOS instead of the usual approach of just using a couple of Objective C files. The code is not in a version control, and I have not seen a single comment apart from the copyright headers.
Using of C API for Cocoa is for compatibility reasons, using ObjC API is fully supported by Apple so it's not an hack in any way. Normally the used SDK dictates the minimum version of the OS and it's harder to support multiple versions. With using ObjC API directly any MacOS from 10.6 up can be supported easily.
I've used similar approach for Haiku, it uses C++, this is more hacky but given their strong stance on binary compatibility it is fine and worked well across multiple releases without any changes so it's clearly a valid approach :) The reason is that I had big issues to get a C++ cross-compiler working for Haiku - supporting many platforms is not an easy task when you want to provide prebuilt binaries from a single VM.
As stated in other comment, I'm using Monotone VCS for version control and have other reasons as well.
As for the code comments, generally I don't need them, the code tends to be self-describing. And when I need them it is for describing something intricate which I generally find out later when I need it, at that point I document it because it's clearly needed, but also at that point I know exactly what to document. Better to avoid intricate things though.
On the other hand I should focus more on the architectural documentation that I've partially written but needs to be improved and expanded.
Haiku impressed me so much that even when I'm unlikely to use it as an user (mostly because I have already usable setup that I like), I've found it very good and polished. So I've decided that all my software will get 1st class support for Haiku :)
That’s seriously awesome. Kudos :)
This is how almost all other languages implement Cocoa support, btw. With a few weird exceptions like Apple's Objective-C++ compiler, most everyone implements FFI by chaining together LanguageA -> C -> LanguageB.
Otherwise you'd have to build an N-to-N matrix of cross-compilers, and it becomes a whole mess.
I suppose my idealism is running hard into reality. Obviously, this project is feasible and does work for many sites (not YouTube or Netflix, due to lack of <video>, but does work for CNN and HN and acoup.blog and...). I want to live in a world where either this is wildly successful and everybody knocks it off, or a world where this is completely impractical because everyone is doing Cool Art Things and this simply would be impractical. But this world where it's practical, but unloved... do not like that.
Instead the community is relied upon to reimplemented the behavior in FixScript which means by necessity only a smaller number of popular sites will load correctly m
Regardless, good luck to the project. Would be interesting to see the end result.
To the author - there are certain social (and developer) expectations I would suggest you look into, e.g information about you (considering you are asking for donations; who am I donating to?) and a public repository people contribute code to. King of my own castle approach won’t really work here.
Isn't that kind of the whole ethos of free software? The current capitalistic view that open source is a (unpaid) job producing a product seems... unsustainable
Deliberately going against commonly accepted practices—like not providing a public repository—can be counterproductive to the project.
For example, the ‘submit code changes via email’ approach comes across as ‘you can help, but I’ll privately decide if your help is good enough’ which might discourage potential contributors.
That's literally how opensource works.
Which makes sense: they have to learn about it, and it takes time.
That seems pretty much identical to how most of the high-profile open-source projects run.
Ever tried submitting a patch to Android? or even the Linux kernel?
I still think that a publicly viewable version control repository would be a good idea though (there are many advantages to this), even if you do not accept pull requests or other stuff like that. (The version control system does not have to be Git; there are others as well, but it would be good to be well-documented (in my opinion, Fossil has better documentation than Git, anyways).)
I wonder if you could apply for some funding from https://nlnet.nl/ ?
I don't see any loss of value there.
Likely the solution was driven by the developer, not the needs of the people wanting that information, or the needs of the business.
I would hazard a guess that the author of the site either only knew one way to make a site, or they wanted to learn how to make a site that way, possibly as a portfolio piece.
• No option for alternate character aspect ratios; what if your characters are square, like an 8×8 font?
• They are using a quite old database dump of OpenStreetMap.
• No option to jump directly to a coordinate and zoom level.
... it supports pointing at any public or private vector tile server, and does support supplying a starting coordinate and zoom. There is even a bug report explaining how to hack it for different font aspect ratios.
https://github.com/rastapasta/mapscii/issues/26
Realistically, it's not practical, but then, is a map? When I want to know where something is, the map lets you calculate "how far away is it and how do I get there? what's nearby?" at a glance, but you can query those things directly in OSM data (there's a cli for that too). For actual maps, I have several GPS devices and...a map. It folds up.
You can for example read medium articles just fine with w3m.
For example if we know large SPA frameworks and/or slow websites require use of convention A then simply not include support for convention A. This is a fail by design approach instead of a blacklist approach.
Here are some things to block to radically increase performance:
* string parsing: innerHTML, querySelectors, console.log
* allow a quota of load time requests and then stop taking http requests until a person interacts with the page (or just break the page). If you set the quota at 10 then any pages with greater numbers of requests will just stop loading. That alone will eliminate 99% of spyware and dramatically shift user behavior.
* drop requests for JavaScript from different origins than the page will improve both performance and privacy
The biggest thing to help with privacy is to not support CORS. That will do more than eliminating JavaScript.
These things are still highly restrictive but much less so than a blacklist approach.
I have worked on a web browser. It's fricking hard. Remove JavaScript and DOM entirely, and it gets much easier.
Now if you start to implement select parts of the spec, it becomes even harder when something fails to know whether it's a feature (because you don't like that part of the spec) or a bug (because you misunderstood or misimplemented some part of the spec that you wanted to implement correctly).
I don't have numbers, but I doubt an in-browser JS implementation without these APIs would be useful on many websites. Even HN uses innerHTML.
Now for the nit picking. From the FAQ:
> For example the HTTP code has no implementation of features that can be used for tracking (such as ETags).
True, ETags can be used for precise client tracking (just like a cookie with a unique client ID); but they are also useful for caching resources client-side, thus reducing data usage, server resources, client processing, etc.
Since the browser/backend is already using a whitelist approach, I would like to suggest optional support for ETags for websites that the user decides to trust.
Also, unless FixBrowser/FixProxy becomes relevant enough to show up on the pie chart besides Chrome, Firefox, and Safari, individual users can be easily fingerprinted based on e.g. IP ranges and the mere fact that the client behaves differently. This is an uphill battle, but I'm glad that efforts like this even exist.
tracking is buildin into http/browsers, even without JS. Its just no longer on the client, making it harder for 3rd parties to aggregate the information across domains (e.g. google, meta, etc).
e.g. loading images/tracking pixels on hover (css) to track mouse movements
the only way to make tracking impossible is by only allowing pure HTML with a tiny subset of CSS for styling. like a markdown browser.
while thats a valid technology choice, I'm not sure how many ppl would ever use such a thing, it'd be incompatible with the vast majority of websites.
the only one's that come to my mind would be even better as RSS/Atom Feeds, so - from my perspective - it'd have a bigger potential if it just creates these feeds by parsing the websites. But you'd still have to preload them with a browser on a server somewhere for the sites that actually require JS / SPAs without hydration.
And once you're there, youre already in a market with multiple options
They didn't "give up" on Servo. Servo was always intended as a test-bed for Firefox engine technologies. It was just some weird false hope in the OSS community that it would be some new "super browser".
They integrated what they were looking for into Quantum and then the community took the browser portion and forked it off+continued development (albeit, without Mozilla sponsorship).
I am wondering how much of this is true?
they also probably don't implement most of CSS
For the rotation I could process a second layout on the background and switch to it instantly if rotated. Similarly hover effects will be limited. Things affecting visibility of the blocks/layers should work (for menus), small adjustments of layouted text too, but anything that is more complicated won't be. It currently uses a hardcoded hover effect for links.
https://www.fixbrowser.org/about
It could be cool to pair this with a SSR backend and package it into a Electron-like desktop app. You'd get basic UI, but it could be very lightweight. The biggest complaint about electron has long been memory usage. Could work great for kiosks too.
FLTK is better then GTK on linux. Since version 1.4 FLTK supports HighDPI displays and Wayland https://www.fltk.org/articles.php?L1947 GTK3/4 and Qt5/6 are bloatware!
Plain and simple C99+ port?
Language with OOP is good for GUI!
C89 bindings https://github.com/MoAlyousef/cfltk
https://openhub.net/p/qt5 (8,876,034 lines of code)
https://openhub.net/p/gtk (1,031,203 lines of code)
https://openhub.net/p/fltk (467,564 lines of code)
Basically, to be fair, in qt5 and fltk cases you should add an amplification factor of at least "10" (probably not big enough since c++ syntax and tens of times more complex than plain C99+).
GTK3 https://gitlab.archlinux.org/archlinux/packaging/packages/gt... GTK4 https://gitlab.archlinux.org/archlinux/packaging/packages/gt... and FLTK https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=fltk-...
If you build FLTK with Wayland support, then add deps: wayland, libxkbcommon, pango.
Anyway, what I typed there was: I read that you don't support JS intentionally. That's fine and dandy. If I were to create a browser from scratch, I'd probably do that.
However, what I'd really like to see is the ability to plug many scripting engines: Maybe you want to make V8 pluggable, or SpiderMonkey, or let's open the box: plug Python! That might enable the possibility to have a front-end stack that is HTML, CSS and Python (without the JS in the middle).
It would open a whole new spectrum of Web development, one that is not subjugated to the pitfalls of JS.
WebAssembly kind of opened that door, but a native interpreter would be good to have.
P.S.: I'm aware Brython exists, but it feels like a cheat to me.
JavaScript is weird, but it was specifically made and has evolved entirely for making non blocking, snappy, event driven user interfaces.
Python was not.
Also, you’d end up breaking the very standards that make the web open. If websites only work on 1 browser because it’s the only one that supports Python, then you’ve just lost the open web.
That’s the whole idea around WASM. A standard compile target that’s designed for the sandboxes environment of websites.
Much like PHP does with open and closing tags, in the early days of Web development, I remember doing websites with Dreamweaver that way.
How'd you feel about a client-side PHP subset?
I’m sorry, I’m not really understanding what you mean here.
> client-side PHP subset
I’d dislike it for the same reasons as before.
Php was made to and evolved largely for generating HTML on a server. Not to have snappy, non blocking, event driven user interfaces.
And since PHP is not a standardized the same way JavaScript is, any browser may or may not implement it the same was as another.
We’d be back in the early 2000s world of browsers incompatibilities.
What would native browser support for php give you vs a wasm implementation of it?
Every browser takes several gigs of ram once you have more than a couple tabs open. I’m in the niche looking to trade off some functionality to gain some efficiency.
A browser which implements unique functionality breaks away from the open web.
The implementation details also affect runtime performance.
JavaScript rarely blocks execution, it’s what makes it snappy.
For example, Python blocks by default, unless you run your inside a Python async wrapper like asyncio.
Python is ill-suited for browser scripting because it boldly claims to have “batteries included”, i.e. it has a sprawling standard library, and most of it is entirely incompatible with the browser environment’s sandboxing and async execution model.
So Python for browser scripting would be a limited subset. And if you go there, what’s really the point of writing programs in an incompatible version of a language whose sole reason to exist is the supposed ease-of-use…
Per a previous comment[0], Python was an example of my point, but I was thinking even more about any scripting language that employs pre-processors so the code inlining works.
> Back in the late 1990s, multi-language support was part of the original design of the <script> tag. Microsoft’s market-leading browser defaulted to VBScript rather than JavaScript.
That in the context of the browser wars back then. Today that war is kind of settled, still fighting to take down some Chrome's dominance of course.
> But of course people wanted interoperability rather than writing separate scripts for IE and Netscape.
But my point is that it would be a kind of start, JS is too dominant for the front-end community. If you don't know JS you're just dead in the water.
You have to inherently like JS to be an effective front-end developer. That's an unfair constraint.
WebAssembly kind of opened that door, but we are still in these early days.
--
[0]: https://news.ycombinator.com/item?id=42508950
And javascript simply downloads its own batteries. "Only on first visit, I swear".
https://protocolostomy.com/2010/01/22/what-batteries-include...
You could also use the AS distros to write classic, pre-.NET ASP applications. I know of at least one startup that actually did this (ActivePerl + classic ASP + IIS on Windows NT/2000), or at least seemed to based on their job postings.
The "guts" of the LHEATcl plugin is a dynamically loadable library (DLL) containing the compiled object files from Tcl/Tk, FitsTcl, POW, etc. Currently, there is just one, monolithic LHEATcl DLL, unlike the LHEA standalone Tcl scripts such as fv where there one DLL for each package (Tcl, Tk, fitsTcl, POW, etc) . This library is placed in your browser's plugins directory. Currently Netscape4.x and Internet Explorer 3.x, 4.x, and 5.0 are supported. Netscape3.x is not supported because the Javascript we use to setup a window to run the tclet in doesn't work in Netscape 3.x. When your browser starts up it scans the plugins directory. If it finds the LHEATcl plugin library, it adds the LHEATcl plugin to its list of plugins and registers the plugin to process files of mime type "application/x-tcl". For details of how this information is stored in the library file, see the documentation for the Netscape plugin SDK. }}
https://heasarc.gsfc.nasa.gov/Tools/maki/plugin/LHEAapi.html
Also, in case helpful, a few typos we caught: https://triplechecker.com/s/493676/fixbrowser.org
Basically, untill proven otherwise the recurring offenders which are the sole benefit of this crime are guilty.
What language is it written in?
FixBrowser is written in FixScript. [...] FixScript is a memory safe, thread safe and integer overflow safe language with minimal native surface area, greatly reducing any security problems. Ideal for processing potentially malicious websites.
It is also very portable (only a C compiler is needed), it even has an ability to emulate threads for environments that lack it (eg. WebAssembly - important for mobile support).
https://www.fixbrowser.org/faq
https://www.fixscript.org/blog/introduction
> It started as a very simple scripting language for a specific need. But when I caught myself using it also for the main program it became obvious that the language is much more than just for the scripting.
It has some interesting parts; the "base" vs. "classes" syntaxes remind me of Vala. Using syntax to disambiguate some things at compile time reminds me of Raku (including typed variables). It also has syntactic macros (similar to Erlang parse transforms) called "token processors", so the syntax is fully extensible - invalid tokens are kept by the parser and passed to token processor, so in principle you could completely ignore the original syntax (something you can't do in Rust or Nim).
In any case, the language is rather small and simple (it reminds me of Janet a bit); picking it up shouldn't be too big of a hurdle, I think.
[1] https://www.fixscript.org/blog/introduction