Hacker News new | past | comments | ask | show | jobs | submit login
Show HN: Dillo 3.1.0 released after 9 years (dillo-browser.github.io)
430 points by rodarima 7 months ago | hide | past | favorite | 109 comments
As commented before[1], I've been working on the past months to get the Dillo back to life and today I'm happy to release the 3.1.0 version, after almost 9 years since the last one.

[1]: https://news.ycombinator.com/item?id=38847613

During this time:

- A new mailing list was created[2] which is beginning to get some messages and patches. It is available in gmane via NNTP at gmane.comp.web.dillo.devel.

[2]: https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman...

- A LiberaPay page[3] which received the first donations (thanks!).

[3]: https://liberapay.com/dillo/

- Some more bugs where fixed and new features where added (details in the release page and/or changelog).

Thanks to all the people that contributed with patches and tests. Now let's see if we can make it land in some distros!




Forgot to mention that we are also on Fedi: https://fosstodon.org/@dillo

Here are some cherry picks:

- Dillo on the Kindle: https://fosstodon.org/@dillo/112181258739093008

- Dillo on an old Samsung phone: https://fosstodon.org/@dillo/112327798958777998


Stupid (and unthankful) question perhaps, but have you considered working on https://ladybird.dev instead? Kling and the small team seem to be making great progress.


AFAIK, Ladybird goal is to build an independent web browser from scratch that can render the "modern" web.

Dillo original goal[1] is to provide access to the web to places with very bad internet speed or latency as well as old or resource constrained computers.

[1]: https://dillo-browser.github.io/old/interview.html

I don't think we will ever implement JS support, as that would increase a lot the minimum requirements to run Dillo and make the attack surface on the browser much bigger.


Rather than joining Ladybird, it would be great to see a merge of Netsurf and Dillo as a very lightweight alternative to Blink/Webkit/Gecko/Goanna-based browsers.

For low bandwidth or slow computers, also try Carbonyl Terminal (https://github.com/niutech/carbonyl-terminal).


If you like Carbonyl, but want something simpler, you may also find my TUI browser Chawan[0] interesting. It supports CSS and JS (kind of...), but unlike Carbonyl, it has its own browser engine written from scratch. It also bears similarities to Dillo, in that it's easy to add custom protocols.

[0]: https://sr.ht/~bptato/chawan/


Very nice! Are there any binary packages to test it on Linux/WSL? Have you considered support for UTF-8 half-blocks or Sixel for graphics?


> Are there any binary packages to test it on Linux/WSL?

Some kind strangers have created unstable packages on the AUR[0] and NixOS[1]. The former is quite recent, the latter is somewhat older.

> Have you considered support for UTF-8 half-blocks or Sixel for graphics?

In fact, there is experimental support for the sixel & kitty protocols, but for now it's slow, ugly, and only works with PNG.

You can play around with it by putting the following in ~/.config/chawan/config.toml:

    [[siteconf]]
    host = 'm\.xkcd\.com' # regex for URL matching; .* also works
    images = true # try `cha m.xkcd.com'
but you will see that it's undocumented for a reason...

[0]: https://aur.archlinux.org/packages/chawan-git

[1]: https://search.nixos.org/packages?channel=unstable&show=chaw...


I think not, Dillo it's much faster than Netsurf, and it's often more stable.


If you combine performance & stability of Dillo with better HTML5 support of Netsurf, you could get a great lightweight alternative to mainstream browsers.


Often by using Dillo's minimal CSS web sites get far less broken than with Netsurf.

With Dillo I'd just had as a 'new' feature, audio and video links opened with xdg-open (or any other plumber) and better Unicode support, which might be reduced due to FLTK, but FLTK itself calls XFT, so I doudt it, as I happened to perfectly open Motif based stuff compiled against XFT with the full coverage of the Unifont font set.


Dillo Plus supports external media playback (https://github.com/crossbowerbt/dillo-plus/#external-media-p...), maybe it could be backported to Dillo?


OK, thanks for clarifying the goal.


Brings back memories. I used to use Dillo on Damn Small Linux on my hand me down laptop with 32MB RAM which even then was a pitiful amount for web browsing.


Check out the gallery: https://dillo-browser.github.io/gallery/index.html


Dillo is my daily browser among Links under an N270 netbook.

I might submit a photo with the device running Dillo.


I've never browsed on anything faster than Links with image support and JS support. Before CSS took of it was stil usable and web pages loaded INSTANTLY.

I don't I'll ever see anything like it again, despite 10-100x the computing power and 10-100x the bandwidth increases.


Links+ it's still posting releases, it's 2.29 right now.

http://links.twibright.com/


The thing is, does it support CSS? I remember trying it a few years later and everything was unusable :-(((


Yes, same -- for me a '98 Toshiba laptop running NetBSD. Nicer to use compared to lynx but not bloatware.


2024 is a breakthrough year - first Netsurf 3.11 released after many years (https://news.ycombinator.com/item?id=38804205), Servo picked up from the dust, Ladybird getting better every month and now Dillo 3.1 resurrected after 9 years!


I wonder if we'll see a revival of Grail [0], Guido van Rossum's browser from the the late 90s with support for Python-based applets. :)

His draft paper [1] from 1996 mentions some limitations due to lack of support for threading, which is no longer an issue. And maybe the JIT that's currently being worked on will help with the "rather grim image of performance".

On the other hand, the restricted execution mode in Python that Grail relies on has long since been removed (much like Java's corresponding features). Maybe OS-level sandboxing features (e.g. Capsicum, pledge, Landlock, etc.) could be used instead?

[0] https://en.wikipedia.org/wiki/Grail_(web_browser)

[1] https://grail.sourceforge.net/info/papers/restofus.html


You can run Python in every web browser using PyScript (https://pyscript.net) or Brython (https://brython.info).


By the way, there is a CSS bug in HackerNews that we discovered today[1] that is causing most of the rules to be wrongly parsed. I'm not sure if hn@ycombinator.com is the proper place to report it.

https://lists.mailman3.com/hyperkitty/list/dillo-dev@mailman...

Here is the bad rule:

    input[type=\"submit\"] { font-family:Verdana, Geneva, sans-serif; }


Should be fixed now. Thanks!


5 minute bugfix, on a Saturday no less. Incredible


Dang is a treasure.


Thanks!


Yes, email hn@ycombinator.com. Dang is very responsive.


And another HN bug, I think: Comments are wrapped in "span" elements (which are inline elements) but contain "p" elements (block elements) which is not valid:

  <span class="commtext c00">...<p>...<p>...</span>
The W3C HTML validator says: "Element p not allowed as child of element span in this context."

This causes Dillo to render the text in grey from the second paragraph on.


Thanks, I reported it too by email.


I wonder if HN sticks to the current HTML markup (which is full of validation errors!) to preserve compatibility with third-party clients that scrape and parse it?

In that case, maybe we could get a query parameter along the lines of "useValidMarkup=1" (or a user setting might be better) to produce valid HTML for the benefit of niche browsers that expect it while preserving the current (invalid but stable) markup by default.


> I wonder if HN sticks to the current HTML markup (which is full of validation errors!) to preserve compatibility with third-party clients that scrape and parse it?

I don't think so, but if it does I recommend they instead stick to the HTML (4.01 or 5) spec by default.

> In that case, maybe we could get a query parameter along the lines of useValidMarkup=1" (or a user setting might be better) to produce valid HTML for the benefit of niche browsers that expect it while preserving the current invalid but stable) markup by default.

They can guess the browser by the User-Agent and serve a "patched" version if needed (bluedwarf.top does it). But I would recommend doing against this, as it reduces the incentive for clients to get fixed and moves the responsibility to webmasters.


Fixed at HN side (thanks dang).


btw, "Dillo is a fast and small graphical web browser"


Dillo just shows how fast the web without css, js and fonts is. It loads before you even lift your finger from the keyboard.


20 tabs for less than 1MB of RAM. At one point I used it for programming docs browsing.


People working on developer docs would do well to make them work well in terminal-based browsers, too. This should be the norm.


Dillo supports a minimal amount of CSS. The issue it's mainly JS.


It'd be interesting to make a "less ambitious" JS in the same way that embedded chips have these less ambitious "dialects" of c and c++.

Like a js-mini that doesn't have the bells and whistles like opengl, bluetooth and midi support


It exists, Duktape and Quickjs, but even on bigger browsers the support it's subpar.

Shockingly, edbrowse parses JS pages well enough to login and post in some sites.


Ditch js altogether and just provide a minimal WASM interpreter. A dillo-compatible page could then ship with a js runtime as a shim.


That's a category error. JS is a programming language. All the bells and whistles you mention are part of Web platform machinery with APIs through JS-level bindings accessible to programs written by website authors. The language/dialect has little to do with it; you're envisioning a different stack that would require a new browser engine, not a language.


the best dillo experience on macos is probably with https://github.com/crossbowerbt/dillo-plus/ ( I couldn't get dillo to compile easily on macos, it doesn't seem to detect ssl libraries installed on the system)

you can do this to compile it on macos (tested on M1):

install https://www.xquartz.org/ to have X11

brew install fltk libjpeg #you might also need openssl@3 but unsure

git clone https://github.com/crossbowerbt/dillo-plus/; cd dillo-plus

# update the 1.3.8_1 fltk version sed 's/1.3.8_1/1.3.9/g' Makefile.options.MacOS > Makefile.options

make -j8

# find binary in ./src/dillo

maybe someone should make a brew package (for both this and dillo-plus)..?


Really cool. Will grab it when it hits the arch repos. Might make a comfy set up where I bookmark some low resource websites and use dillo to browse them. Fond memories from tiny linux distros that ran entirely in a few MB of ram using dillo.


It is orphan in Arch, but I will check tomorrow if I can apply for maintainer. In the meanwhile I have the AUR package[1] dillo-git:

[1]: https://aur.archlinux.org/packages/dillo-git


It is on the Arch Linux repository now :-)

  # pacman -Syu dillo


I think it is still the default browser for Tiny Core Linux.


how does dillo compare with netsurf? I've been considering porting netsurf to an unusual platform, but if dillo has substantially better handling of modern pages, I might use it instead


I think Netsurf renders pages closer to what they "should" look like in a mainstream browser. However, a huge bonus for Dillo is that it is really easy to switch off CSS, images, etc if the page doesn't look "good", and only render the text (IMO this is also very much encouraged by the UI). I recall having some rendering annoyances with Netsurf, but this was at least 5 years ago.


What prevents you from doing some tests? We have seen Dillo running in a lot of old and not very common machines (Atari), so you may have some work already done.


nothing! I look forward to testing it out, just haven't had the time yet


Are you also considering ladybird?


I hope to, though I'm a little concerned its design and dependencies will be harder to handle


Ladybird is much more heavyweight at this point, it uses hundreds MB of RAM, not tens MB like Dillo.


Yes! Thank you so much. I love this browser, and I'm really grateful to you for maintaining it.

I test my websites with Dillo diligently, so I have some re-testing to do now. :)


Do you test the engine against acid3?

I think what we need would also be something like acid4 as a test suite, because CSS4 with its flow-root rework is kinda hard to implement for browser engines from the CSS2.1 age. Basically everything has been changed when it comes to the parser's grammar and lexical approach. Things like nested conditions in CSS through media queries or supports queries are impossible to implement without rewriting the parser from scratch.

Do you plan on implementing all the event/media/supports related stuff from an isolated CSS perspective, including pointer events, transitions and animations?

Because having the @supports queries unified across the board would help a lot supporting older browsers without animations or without a tweening engine.


Things like WPT (Web Platform Tests) and Test262 have largely replaced the old Acid test line, albeit they aren't as flashy/fun/user friendly so they don't have as much public attention as the Acid tests did.


is there a document or code reference that describes the subset of HTML/JS/CSS which is supported by dillo? i've seen a number of people wishing for realistically achievable "HTML-lite" that could be targeted as an alternative to separate protocols like Gemini and dillo's baseline feels like it would be a good starting point.


Probably HTML 4.01 spec.


dillo supports some HTML5


I love these minimal browsers. Much better than the modern-style web for sure.


ugh tell me about it. Especially with all the frame works added :(.

And the CSS wizards who remove the underline on the link, so when I'm helping people over the phone they can't find the link :'-(

And the damn trackers :(


TIL of Spartan Protocol. I love Dillon, how is it handling modern security features like new versions of TLS or SSL?


> TIL of Spartan Protocol

You can browse spartan pages with a Dillo plugin[1], as well as Gopher, Gemini and others.

[1]: https://dillo-browser.github.io/#plugins

> how is it handling modern security features like new versions of TLS or SSL

We support OpenSSL 1.1 and 3 (and any other API-compatible), LibreSSL and mbedTLS 2 and 3. You can choose the one you like/trust more at link time.


It's in the changelog summary:

> Add support for OpenSSL, LibreSSL and mbed TLS for HTTPS, which is now enabled by default.


If you are interested in dillo, have a look at netsurf, another css renderer, but this one has the big advantage to require only a plain an simple C compiler, not a gigantically complex c++ compiler.

That said, more noscript/basic (x)html browsers, the better, even written with computer languages with an extremely complex syntax (rust/java/etc).


Unless Netsurf compiles with TinyCC, cparser or cproc, sadly both gcc and clang are bloated.


I did a plain and simple C port of bzip2 busybox code for plain and simple C compilers: on bzip2 compression, tinycc is really slow, ~2 times slower than gcc (13.2 -O2)... but cproc/qbe gets... ~70-80% of gcc speed. Switching to cproc/qbe would clearly be a win for a lean open source stack (which de-facto excludes c++ and similar ultra-complex syntax computer languages).

In my project list: a minimal linux kernel with gcc-cleaned C code.


awesome work! dillo used to be my standard documentation browser when projects started using html for their docs, it was snappy and opened files almost instantly


You may like this plugin[1] to read local man pages as properly formated HTML pages.

[1]: https://github.com/dillo-browser/dillo-plugin-man

More plugins: https://dillo-browser.github.io/index.html#plugins


The gopher one it's broken upon using a URL with no selector: gopher://sdf.org for instance. it defaults to a 0 one so it doesn't show up right, you need to state gopher://sdf.org/1/ by hand. Otherwise, it works great.

On the man plugin, for the users with mandoc/mdoc, I found a bug, '-T html' should be '-Thtml' without spaces. Then works fine.


nice :) thanks for the pointer


Made my day, massive thanks! Dillo must be my all time favorite browser by far. Responsiveness, modular UI and excellent config file -- everything about it is pure joy, really.


I loved Dillo! great to see new activity


I just compiled and uploaded dillo 3.0.5 for NetBSD/m68k... Now I need to try 3.1.0!


...and it compiled just fine, and ran fine on first launch. Excellent!


The coverage on CJK fonts it's still bad, even on supported fonts. Also, a tip: <audio> and <video> tags should be able to be redirected into a media player, or xdg-open.


There are a lot of features waiting to be included in Dillo. We focused on solving bugs first and tried to get as few features as posible to get the 3.1.0 out as soon as posible.

Apart from CJK, there are other issues with fonts that we have to solve too. Feel free to open more issues: https://github.com/dillo-browser/dillo/issues


Thank you very much!!!


Thanks.

Will try this on NetBSD :)


me too :) actually NetBSD is where I use Dillo the most! Congratulations to the Dillo Team.

And https://daemonforums.org/ works great with dillo, with dillo you can even log into daemonforums. The ID ywill not be saved, but AFAIK no other forum allows login when in dillo.


Thanks! You should be able to login most forums that don't require JS. Keep an eye on the cookies configuration[1] which are disabled by default.

[1]: https://dillo-browser.github.io/user_help.html#cookies


screenshots?


In the main page: https://dillo-browser.github.io/

And here are more: https://dillo-browser.github.io/gallery/index.html


Click Home.


Chuck Home.


I can still vaguely remember when the web was mostly just HTML, images, css, and the occasional plugin content like Flash, Java, and RealPlayer. You could really do a lot of stuff in a tiny package. Now you have to run a pseudo-operating system to deliver bizarre bloated applications via text. Technology didn't used to make me sad...

I once shipped Dillo in a tiny memory resident distro, it was fantastic. Happy to see its return.


Anyone ever compile a browser with emscripten to wasm? So that you could try out a new browser without having to download and install it? I think that could be genuinely useful in instances like this (try-before-you-buy-browser-in-your-browser), instead of just a recursive curiosity.


Please bring a new step of “The birth and death of JavaScript” [1] to the real world (but still not the nuclear war part of it, thanks).

[1]: https://www.destroyallsoftware.com/talks/the-birth-and-death...


You probably can't try out a browser in the browser, because of the CORS rules.


You could if the host domain acted as a VPN/proxy


the cloudpilotemu project can use this host browser as a proxy thing so you can sync your emulated (in the browser) to your PC as well as give the emulator internet access, likely one way to have a browser in a browser.

I didn't try it out, though, i just read it in the documentation.


There is WebKit browser in browser: https://trevorlinton.github.io/


That's not a browser (even if you renamed it to "webkit browser"), and not working


Technically it is a web browser engine (WebKit) ported to JS and it works in the latest Firefox (shows a tiger).


It's possible, see https://github.com/trevorlinton/webkit.js/


This was already asked the last time[1], but I think it would miss the point of Dillo.

[1]: https://news.ycombinator.com/item?id=38853053


In some ways it would miss the main use of dillo, but at the same time if you were going to embed a browser like that surely dillo is a great option precisely because of how light it is.


From <https://dillo-browser.github.io/dillo.org.html>

> we have setup a new website based on GitHub pages (so hopefully it won't dissapear soon)

Why cede control of your namespace to GitHub, though? You can host stuff on GitHub Pages without having to go through github.io to get there. Just grab another (cheap) domain and set up a CNAME record to point to GitHub Pages.


Because I considered it a good starting point as I can place a redirect notice there if we move to another place, without worrying we will lose the DNS again. If you want to help, feel free to do so :-)


dilloproject.org

This cost me $17.32 for two years—so this time next year, even if there's not $11 or whatever available, there'll be a whole other year to come up with it.

NearlyFreeSpeech.NET (which this isn't using right now; it's just on a free static host) allows anyone to deposit funds into an account for sites hosted there, not just the person behind the site, which means it can in theory stay up indefinitely, even if the person in charge is incapacitated and/or stops putting their own money into it (so long as they don't actively take an interest against its continued operation).


> Just grab another (cheap) domain

The post explains how they lost their long-held domain name. At least GitHub won't dry up and blow away if you miss a payment.

They're all cheap at the start... and do not necessarily stay that way.

The very end of the post makes it clear this is a temporary situation.


wat

They didn't lose dillo.org because it suddenly became not cheap. They didn't "lose" it at all—they were never in control of it. The post explains that it lapsed because whoever had it didn't renew, and it wouldn't matter much, because the person who was in charge is no longer involved with Dillo, anyway, which would have made dillo.org a true zombie site.

> The very end of the post makes it clear this is a temporary situation

There's no such thing when it comes to namespaces. Which is my whole point.

If they had grabbed dilloproject.org (or whatever) today, they could continue using that no matter where they're actually hosting the pages in the future. Once you're in somebody else's namespace, though, the only thing you can do is abandon it after adopting a new one and hope that a redirect suffices.


Again I love how posts like these have no context what a Dillo is. While it's not hard to find that info out on my own, it could have also been done by the poster.

kudos on shipping code I guess.


TLDR: Dillo is a fast and small graphical web browser. It kind of died in 2017 and this is the first release after 9 years from the last one.

You can read the main website for more details[1].

[1]: https://dillo-browser.github.io/

And the release page[2], which explains a bit of the history of the project and the current state.

[2]: https://dillo-browser.github.io/latest.html


You could have used this comment to tell us what it is.

It’s a minimalistic web browser that works on low powered machines

https://dillo.org/


Please don't link to dillo dot org, see: https://dillo-browser.github.io/dillo.org.html


Thanks


nah someone else in the thread already did that.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: