Show HN: FixBrowser – a lightweight web browser created from scratch | Hacker News Reader

Show HN: FixBrowser – a lightweight web browser created from scratch

fixbrowser.org

320 pointsjezek2147 comments

Hello, I'm working on a web browser that focuses on being truly lightweight and designed for privacy.

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:

https://www.fixbrowser.org/

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.

Open articleView on HN

First off, this is really impressive. After Opera and Microsoft dropped their engines and adopted Blink, and Mozilla gave up on Servo, I've been becoming increasingly worried for the future of the open web. Kudos for trying to get the matters in your own hands, and for getting this far with your project.

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.

i'm not disagreeing with you, just wanted to add another point:

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

> and Mozilla gave up on Servo

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).

They fired the developers and later gave the project to the Linux foundation. Maybe "give up" is not a perfect fit. But they "abandoned" it for sure.

How is what you said different from what I said? Other than your unrealized personal expectations and emotionally-loaded pedantry.

Interesting tid bit:

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

Shown on HN: https://news.ycombinator.com/item?id=34315137

Am I correct in seeing this as a custom language for a custom browser? That kind of makes this a bit more impressive but equally more challenging if nothing else to find other members to help with develop!

Yup, FixScript is a new language. Author says in a blog post[1]:

> 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

I was not able to donate, PayPal again doing its shenanigans (my country of origin not supported to donate).

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.

Honestly that sounds terrible for the web.

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.

Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works.

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?

> Python was an example of my point, but I was thinking even more along the lines of any scripting language that employs pre-processors, so the code inlining works

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?

Seems reasonable to implement a portion of an open spec for niche use cases like this.

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.

https://www.uzbl.org/

A browser which implements a subset of the specs that major browsers implement is still part of the open web.

A browser which implements unique functionality breaks away from the open web.

Python has await/async; what else do you need for non-blocking, snappy, event-driven UI?

JavaScript didn’t always have async await.

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.

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. But of course people wanted interoperability rather than writing separate scripts for IE and Netscape.

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…

> 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.

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

>Python is ill-suited for browser scripting because it boldly claims to have “batteries included”

And javascript simply downloads its own batteries. "Only on first visit, I swear".

could you explain what you mean with batteries? Preloaded bibs? thanks

Yeah, that's what Python's "batteries included" slogan means. Perl and Python not only ship with lots of libraries, but have built-in functions for file manipulation and running arbitrary shell commands as part of the core language: https://news.ycombinator.com/item?id=42509544

Usually, with programming languages, that refers to having a wide standard library that allows you to complete many basic or common functions without downloading 3rd party or additional libraries.

https://protocolostomy.com/2010/01/22/what-batteries-include...

You could actually use Perl and Python with IE 4 through Windows Script Host if you installed the versions from ActiveState (ActivePerl, ActivePython, and also ActiveTcl), which provided ActiveX scripting engines for those languages. I actually wrote some small Perl browser LAN apps using this for myself. It was a huge security hole in that anyone who install ActivePerl, Python, or Tcl could be rooted if they visited a web page with the appropriate malicious script tag, as these languages provide out-of-the-box support for file manipulation and other potentially dangerous actions.

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.

Browser script integration was close to being TCL but JavaScript won or what was called LiveScript from NetScape.

{{ What It is and How It Works

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

Python may not be the best example, but some other languages also exist and are both less "weird" than https://github.com/denysdovhan/wtfjs and fast (e.g. see http://luajit.org/ which is far less complex than V8).

Wow. This is awesome in all the wrong ways. I can't decide if I hate it or love it.

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.

Haha I like this take.

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.

It's good to hear you are supporting Haiku. Are you around on the Haiku forum or IRC?

Yeah, I'm on the Haiku IRC.

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 :)

> I've decided that all my software will get 1st class support for Haiku

That’s seriously awesome. Kudos :)

Since this is using Cocoa and one of the targets is MacOS, have you considered using the GNUstep framework {instead of|in addition to} gtk* for the Linux side of your browser project?

I'm targetting GTK because it's the most common toolkit and it is easy to interoperate from other languages. I will also attempt to do a Qt/KDE support at some point in the future, but C++ is more complicated with binary compatibility. GNUstep seems like something that not many users have installed.

> it uses direct C API for Cocoa on macOS instead of the usual approach of just using a couple of Objective C files

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.

This very approach seems to pre-determine a centralized internet, where the dynamic behaviour that you care about belongs on a short list of websites whose functionality can be implemented by hand...

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.

Huh? We had this exact thing with cgi scripts and html 4.1, and dynamic behavior that we cared about was on a lot of websites.

I think that's what OP was getting at - if FixBrowser was very popular, then servers would use CGI etc. for dynamic behaviours, but its not and they don't.

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

Thanks, author.

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.

This project, the approach contained within, the wording, license, the programming language used, the lack of a publicly accessible repository all have, in my opinion, a highly opinionated, “artisanal” approach (the reasoning behind which I’m not entirely able to comprehend) that seem to scratch the authors itch, but otherwise disregard the state of the web and what basic expectations other users have.

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.

> that seem to scratch the authors itch, but otherwise disregard ... basic expectations other users have

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

the current capitalistic view is that open source is a way for corporations to cooperate and it seems be working fairly well

I understand the ethos of free software, but there’s a significant difference between a personal project with unique quirks and a public project seeking monetary and development contributions.

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.

>you can help, but I’ll privately decide if your help is good enough

That's literally how opensource works.

It definitely is, but it seems like a whole lot of developers do not know it.

Which makes sense: they have to learn about it, and it takes time.

> you can help, but I’ll privately decide if your help is good enough

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?

What do you need a publicly accessible repository for?

The expectations that some users might have are not necessarily what are considered desirable by others, and different approaches do have different advantages and disadvantages than each other. I think that some of the choices made by this project are better than other web browser implementations.

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).)

This is awesome, like a new Dillo!

Thank you so much for making this project.

I'll be adding it to my test suite.

Wow, 25 years old! https://dillo-browser.github.io/

And still under active development! Looks like they had two releases this year.

You have netsurf which is a CSS renderer, better than dillo since it is written in C and not some computer language with a grotesquely and absurdely complex syntax/size.

Thank you for reminding me to give NetSurf another try. No package in Ubuntu for some reason, but relatively easy to compile from source.

Weird, Debian has NetSurf in its repos (netsurf-gtk, or netsurf-fb if you want to render it directly to framebuffer with no UI toolkit)

Thanks, I was able to install netsurf-gtk just fine.

It would be nice if `apt install netsurf` returned something more helpful than "Unable to locate package netsurf"

netsurf is using the GTK+ toolkit.

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...............)

I always do first:

apt-cache search netsurf

Thanks! I'll know to do that in the future.

this is awesome - thank you! I look forward to trying it!

I wonder if you could apply for some funding from https://nlnet.nl/ ?

Im more interested in how FixProxy works, is it basically a filter that disallows tracking and javascript? with optional whitelists for sites you trust. I think this would be more useful for users who like to take privacy and control into their own hands. There is basically no reason to write your own browser if you approach the problem like this. I suppose this is what ublock is to a degree.

Yeah it processes the HTML+CSS, applies the fix scripts so web pages that wouldn't work without JS are fixed to be usable. Then it applies whitelist to all HTML elements/attributes and CSS rules. This is then converted back to HTML+CSS for the web browser to show.

It is very useful, I've been using it myself for multiple years with good results.

Having own browser is to reduce the memory requirements further. Even with FixProxy the normal browsers use a lot of memory, sure it's better than normally but still a lot.

With FixBrowser the memory requirements are much lesser and it's much more portable, for example to older systems or computers with weak specifications.

Love seeing alternative approaches to browsing! If the aim is to avoid Google's dominance in the browser world, also check the efforts by https://ladybird.org/ The author is quite active on X/Twitter and posts regular updates.

Yeah I'm watching that project, it's great. Once it will be mature I will evaluate it against CEF (Chromium Embedded Framework).

I plan to add an optional support of embedding CEF so that you can use it for specific tabs or websites directly from FixBrowser instead of having to switch to another browser.

In the future there could be a similar support of embedding Ladybird engine.

Really cool, I think there are places where something like this could be really useful.

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.

Hot tip: don’t include a field for requests on your donation form!

Good point, I've renamed it suggestions unless someone else has better wording for it :)

Thanks for sharing! I would love to try it with MacOS support.

Also, in case helpful, a few typos we caught: https://triplechecker.com/s/493676/fixbrowser.org

Neat tool! Will try it.

Thanks!

Thanks, fixed.

cool. i support stuff like this even if it isn't quite usable for me or, really, practical even if it was! but i like to know it's there and if it was reasonably complete i would for sure keep a stable version on my machine.

This is my favourite quote now:

> From the development point if there is something that truly requires multiple developers to implement it is most certainly too complex and should be made simpler or a separate project.

[0] - https://old.reddit.com/r/ProgrammingLanguages/comments/zwp51...

The reason why something requires multiple developers could also be time to market. I'm sure a lone developer can build a fully-fledged webbrowser, but it would take them 100 years. And at that point we've probably moved on to holographic interfaces.

Yeah that quote/post is related to the FixScript language and it's libraries. I consider each project individually based on it's characteristics.

As for FixBrowser fortunatelly I'm not working on a full fledged web browser and it has significantly reduced complexity.

With all the SPA out there I find it hard to believe we are building js-less websites today … maybe it’s a browser made to navigate the past and small blogs ?

I think a lot can work this way. Something is intentionally webapps, like google, those won't work, yes.

In my experience, missing out on SPAs is not a particularly extreme hardship.

I mean, as long as you don’t mind not being able to access the vast majority of published content, news and social media, that is.

News? Tripe riddled with advertising and tracking. Social Media? Opium for the masses. "Content"? Increasingly consists of ChatGPT regurgitant.

I don't see any loss of value there.

IME news sites are noscript compatible. The only exception is forbes. Oh and advertising doesn't work without scripts.

Sure, but you’re disconnecting from the things that other people use, you’ll become a social outcast as a result. I’d that’s something you’re personally okay with that’s fine, but humans generally want to fit in and be part of a society of likeminded peers.

There's a few weird ones. I worked with a company that has what in my mind should be a static website, but it's not. It's headless Wordpress, with a Next.js frontend. It's just an informational websites, like what they do, contact information, services offered and a "blog", which is just one or two article published per month. The bloody thing is a single page app, routing is done in Javascript, rendering is Javascript... I don't understand it at all. It's a type of page that needs no Javascript at all, and yet it's built entirely as a Javascript frontend.

> I don't understand it at all. It's a type of page that needs no Javascript at all, and yet it's built entirely as a Javascript frontend.

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.

not sure about the size of this company but I have been involved in more than a few where tech used to build websites, regardless of what they are, is set in stone. “we use angular.” there are no discussions or anything. people are interchangeable and frequently move from project to project - no problem, angular everywhere :)

My guess is developers don't know how to write HTML any more, only JavaScript.

For me it's banks and maps.

telnet mapscii.me :)

Cool, but:

• 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.

while I was joking, the code behind that can be run locally: https://github.com/rastapasta/mapscii

... 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.

A lot of apparent SPAs also offer a simple server side rendered version of the website for search engines and AI agents.

You can for example read medium articles just fine with w3m.

There is a plan for using CEF engine for a specific tab or website. The user would be able to make the website work with a single click and it would remember it. You would still have the advantage of a lightweight browser just in a lesser degree.

>At some point I've realized that much of the complexity and resource requirements of web browsers comes from JavaScript.

I am wondering how much of this is true?

Indeed, CSS is so massive it has long been a collection of standards. Good luck implementing all that.

the author describes how their render-once approach lets them implement CSS in a simpler way since they don't need to retain information for arbitrary dynamic changes in the stylesheets and content

they also probably don't implement most of CSS

I guess this implies that rescaling the window, or rotating your phone, will not update the view. Then you'd have to reload the page. That trade-off seems okay to me.

Constrained features can work great in certain niches, imagine using this in a kiosk (where resizing isn't possible).

Yeah, the layout would still resize but it could be non-ideal in some cases as it would be based on media queries for another width.

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.

I believe Netscape worked like this back in the day. (ETA: as in, resizing the window would reload the page.)

Resizing would just reflow (ie re-render it) the page, not reload it.

>Planned support for systems in the near future: Linux GTK3/4

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!

FLTK is c++, then a definitive nono?

Look at FLTK's source code. It's a minimal set of C++. Like C with classes.

Then it is c++, then a definitive nono.

Plain and simple C99+ port?

>Then it is c++, then a definitive nono.

Language with OOP is good for GUI!

Language with OOP like c++ and similar (rust/java/etc) is ultra-complexity builtin the syntax itself which spills to their compilers (basically clang(apple)|gcc). That reasons alone is enough to do GUI with other languages.

>Plain and simple C99+ port?

C89 bindings https://github.com/MoAlyousef/cfltk

The second your require a gigantic and insanely complex c++ and similar compiler for your SDK, it's over.

As for complexity and gigantism:

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)

You have an "amplification" due to the language used: you cannot compare the "cost" of C lines with c++ lines. They don't pull the same SDK dependency in the end.

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+).

Compare dependencies:

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.

You don't seem to understand my point: the second you are using c++, it is over.

This was also my first thought, but looks like it's already designed to be toolkit-agnostic, like NetSurf. So it should be easy to port to fltk or anything else.

  $ ls -1 fixgui_\*.c
  fixgui_cocoa.c
  fixgui_gtk.c
  fixgui_haiku.c
  fixgui_win32.c

If you're interested in lightweight, zero-JS browsers you might want to check out Dillo, recently brought back to life: https://news.ycombinator.com/item?id=38847613

The opinionated approach feels restrictive to me. My best recommendation to avoid slowness, privacy violations, and other nasty things is to not include certain features as opposed to eliminating JavaScript.

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.

Feels much harder to both implement and debug, though.

That completely misses the point. Privacy and performance advocates don’t care how hard life is for JavaScript developers. JavaScript developer convenience as the top priority results in the very slow privacy violating sites things like this browser exist to ignore.

No, I mean for the developer of the web browser.

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 agree with that about 90%. The standards do not come as a single universal package. Browsers cherry pick what they want to support or what support to drop as they can release new features. The challenge there is picking features to support but ensuring they work independently and without regression. It takes testing the incumbents have spent years developing.

It's a whitelist.

> string parsing: innerHTML, querySelectors, console.log

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.

Yes! This is exactly what I want in a web browser!

Really cool project! Maybe this is a bit nitpicky, but the paragraph on the front page is a bit wonky. Some words are missing

I miss https://www.uzbl.org/

Careful, if you are to get something real-life-working on the major javascript-walled sites out there, Big Tech will try to make your life hell (and that includes shadow-paying hackers to destroy your software).

Any examples of this happening? If so, id really like to read about it

Since, in the end, the benefit of the crime is all for those Big Tech Web engines, the requirement of the proof is inverted (or those hackers are beyond stu..., unlikely). And Big Tech is proven guilty of anti-competitive practices all the time, they are recurring offenders (unless you have been living in a cave for decades).

Basically, untill proven otherwise the recurring offenders which are the sole benefit of this crime are guilty.

In such extreme cases a possible solution is to use this approach: https://www.fixbrowser.org/faq#gatekeepers

You don't say that it's an experiment or just for learning how to write a project. You suggest it will be competitive in simplicity or speed. I find this hard to believe.

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.

> there is no source repo.

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's mostly for practical reasons. I use Monotone for VCS which is not an active project (but a good SW regardless). Then there is the issue with having additional stuff in the repository that is meaningful just for me but I don't intend to release it (or not in the current form).

Using a full browser engine with JS disabled is not the same as you won't get the architectural benefits of not having to support dynamic changes by JS at all.

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.

Idea. Wasm packaging and then running FixBrowser embedded in a webapp. Then use any browser with that webview providing safe whitelisted browsing.

I think that it is a good idea, although I do have some opinions:

- A source code version control repository (using any source code repository service, or hosting your own) should be made available, e.g. in case you want to view only some of the files.

- I think that all of the scripts for fixing/improving web sites should be implemented as extensions (and allow the user to disable and change the settings (e.g. where to apply them to) of any of them), and that you can use C as well as FixScript, that you can load native code files.

- Some programs are used on multiple web sites; it should be able to identify the program in order to apply the scripts to any web site that uses that program.

- It should allow to disable CSS (if it does not already do), and the ability to disable specific features of CSS (e.g. transitions, fonts, etc). The ability for a user to apply custom CSS might also do, and if so then it might support some features that are not allowed in web pages.

- It must allow to disable automatic updates (if they are implemented at all).

- It is OK if you deliberately do not want to implement JavaScripts. If JavaScripts are ever implemented though, it must include the ability to disable JavaScripts and the ability to override any functions of JavaScripts and should include the ability to use JavaScripts to make extensions.

- Video playback support is probably not that important, since you can use external programs to play videos.

- If CEF is implemented, it should probably be made possible to compile the program without that feature in case you do not want it (in order to avoid adding dependencies that you will not use).

- I would also be interested in being able to add extensions for implementing URI schemes and file formats, and also would be interested in proper support for non-Unicode text.

- The ability to use unencrypted proxies even for encrypted connections would be helpful, in case you want to use your own proxy without needing to decrypt/encrypt the data twice.

- I have no debit/credit card, and I have no European money.

No screenshot?

There are several on the about page.

https://www.fixbrowser.org/about

Microsoft Defender flags and prevents the download. Is it just me?

Sorry but doesn't support javascript, will it make websites broken then?

That's why I've introduced the fix scripts that can fix the websites to be usable without JS: https://www.fixbrowser.org/faq#fix-scripts

I've been using this approach for the last few years with good results. Only few websites (typically web applications) I need to open in a regular browser otherwise majority of my browsing works without JS just fine (thanks to the fix scripts).

Yes, most of the web will flat out not work without js. Especially the bit that has lots of users and commerce going on. If your target audience is hermits that don't engage socially online, that don't buy stuff online, and that are stuck in a time bubble in the late nineties when they were young and naive (talking about myself here as well), then this might be the best thing ever. But forget about getting a younger or wider audience showing any interest for this. The web is a content first platform. Interest is content driven, not technology driven. That's why web technology is such a dog's breakfast of meh.

I get the idealism, sentiment, and nostalgia. But the web has always been a mediocre platform, a straight jacket, a bit of a terribly disgraceful kludge. Fixing it by crippling it further doesn't make it better.

The good news is that there are other ways forward. I like what's happening with WASM. WASM fixes browsers to be suitable for running any kind of code. There are some silly examples out there of browsers running emulators with legacy operating systems running a 25 year old browser. Or stuff like winamp. But the main point is that we're no longer restricted to using javascript/css/html. We can now use pretty much any language, any framework, any kind of rendering engine. Browsers can now run hardware accelerated 3D graphics.

Browsers as a virtualization platform are rapidly catching up with Sun's vision of thin client computing a quarter century ago. And just around the same time that the web is rapidly expanding across devices and modalities. Mobile, AR/XR/VR, entertainment consoles, etc.

Browsers are backwards in the sense that they started with a very limited/crippled platform that was then extended slowly and haphazardly over the course of nearly 35 years with enough technology that you can run pretty much anything inside them now.

A more logical architecture would be to start with a minimal VM that is powerful enough to run anything you'd want to run and then run all the rest inside (including legacy crap like CSS/HTML/JS, Flash and all the rest.). Sun had some of the right ideas but got hung up on the wrong technologies.

That's why I've introduced the fix scripts that can fix the websites to be usable without JS: https://www.fixbrowser.org/faq#fix-scripts

With it you can use it to browse most websites. And these that don't work you can open it in a regular browser. There is even a plan to have integration of CEF (Chromium Embedded Framework) that allows to use the full browser experience for a specific tab or website directly from FixBrowser.

I've been using this approach for the last few years with good results.

very cool

Please tell me you are doing this all by yourself, OP.

Does this come bundled in TempleOS?

bruh there's a reason why others gave up on their engines, but i think first, you should implement javascript and don't try to go around it.

If you mean Microsoft abandoning their engine then their reasoning sounded as an excuse because they clearly have the capacity to work on it. They simply decided for other internal reasons to stop and just blamed it on Google/YouTube as it gets good PR points.

Anyway, that's why I've come up with the fix scripts that can make websites work with JS disabled. It can fix problems and even improve the usability of various websites.

I've been using this approach succesfully for a few years already with good results. So there is no reason to just abandon the idea when it's proven to work.

Reply on news.ycombinator.com