Lightweight Dillo browser springs back to life, still doesn't care about JavaScript The Dillo web browser has returned with a new release, version 3.1. It's nearly nine years after version 3.05 appeared on the last day of June 2015. Version 3.1 incorporates dozens of fixes and improvements, as the official announcement describes. Project lead Rodrigo Arias Mallo announced his resurrection attempt on Hacker …
I'm fighting a losing battle at my current employer. I want all the core functionality on our websites to work even if JavaScript is disabled in the browser, but our front end developers believe that almost everything must depend on JS being enabled and screw any graceful fallback. The worst part is that since they do client side validation in JS, some of the "full stack developers" (AKA jack of all trades, masters of none) skip any validation on the back end.
I'm fighting a losing battle at my current employer. I want all the core functionality on our websites to work even if JavaScript is disabled in the browser, but our front end developers believe that almost everything must depend on JS being enabled and screw any graceful fallback. The worst part is that since they do client side validation in JS, some of the "full stack developers" (AKA jack of all trades, masters of none) skip any validation on the back end.
What about legislated accessibility requirements? Some of the gratuitous JS must play havoc with screen readers.
A large proportion of web resources could be restricted to html5 and css as a lot of JS is only used to "tart up" or "pimp" the appearance of the page or worse for ancillary and often nefarious purposes.
I assume the resurrected dillo browser does some version css?
W3m, lynx and elinks still get a bit of an outing when I need a quick look at html only doco on non graphical host (no firefox etc) and/or at the end of a slow or high latency connection.
Client side input validation without backend validation or verification is an open invitation to Mr Trouble I would have thought?
"It doesn't support frames, embedded media playback, and, biggest of all, JavaScript, so most of the modern web is inaccessible to it."
iFrames are cool, I use them a lot for what Wikipedians call transcluding nav widgets.
Other than that, I get fed up disabling the rest of that shit all the time.
Would be good to see it compiled for RISC OS too.
I like to use Dillo to browse non-commercial websites (and The Register) because everything loads so fast in Dillo. If it works in Dillo, it's a good website. If it looks horrible or won't load at all, I just don't bother using the site. Now of course I still need to log into my bank and that sort of stuff with another browser, but if I'm just poking around or reading tech docs or basically any web page made by someone who's not trying to sell me something then Dillo's my weapon of choice. I'm very glad it's being updated again, although the old version works fine for me.
I was about to moan that this cannot work for anything meaningful because, to choose an example I am familiar with, eCommerce absolutely requires JavaScript. But that's just habit. Payment gateways "require" JS or iFrames or both for their security excuses when JS-less options are available. It's possible to navigate to a payment site that takes secret info through normal forms and then navigates the user back to their origin site.
For those that like multimedia (almost everyone really) then HTML <audio> and <video> elements should work OK without JavaScript if that were implemented. Site owners like Youtube & Netflix won't like it because they can't control the appearance as much nor track your every mouse movement (insert paranoid rant here).
As someone who works in web development, it's not going to happen. Users constantly demand more functionality, more responsiveness and browsers keep rolling out new features. The trend is towards more complexity, not less. It would take a big user revolt to change this and I'm not seeing anything like that, I'm seeing the opposite. Everyone seems to be happy to keep updating Chrome every time a release comes out.
Last time I used Chrome (as opposed to a browser based on it) it automatically updated whether you wanted it to or not. (This was a few years ago, I don't know if it still does this.)
I'm not sure that "happy" is the correct word. Oblivious, unaware, uninterested, disinterested, annoyed might also be used. Unless "everyone" means everyone who works in web development.
I remember a web interface to a piece of hardware which broke (became unusable) after a Chrome update.
"Users constantly demand more functionality, more responsiveness and browsers keep rolling out new features. The trend is towards more complexity, not less."
But who, and what, is driving that trend? It's in the browser maker's interests to add yet more "features", and in developers' interests to use them so they can stay "current".
Users, in the main, don't know shit from clay. Yes, I know, some do. But the average Facebook consuming, tiktok watching passenger on the Clapham omnibus does not. They use what they're given, complain when it's slow or changes suddenly, and scroll on to the next gripping video. I would bet it's not them demanding new stuff; rather they are the hapless victims forced to endure it
"The Dillo web browser..."
Am I the only one to misread that??
Moving on, I can certainly see uses for a lightweight HTML viewer that's not bogged down with JavaScript etc al. And I'm very much in favour of static sites that don't use JS, though I appreciate that most big sites use it willy nilly and are likely to continue to do so. That being the case, I can't see Dillo being the Next Big Thing in browsers, but it could still be incredibly useful as a document viewer, amongst other things.
Here's hoping it thrives!
Add a web translation layer into your router or a standalone box. It could convert any incoming web page for whatever level of browser you have. From the basics of a jpg file with hyperlinks to interactivity and scripting. You could avoid heaps of vulnerabilities by having the WTL strip scripts and content back to basic interactivity. It could feed data to anything: a ZX Spectrum, a smart watch, a 486, a touch screen, a PET or the latest PC. Just tell it what your browser capabilities are with a series of variables, and that is how it would send any web data. YouTube videos on a Speccy? No problem.
You could use any browser, no matter how rudimentary, on any system. The WTL would do the rest.
From the interesting github page...
"A web "proxy" server that enables browsing the modern web on historical browsers. It works by rendering the browser viewport into images, which are then shown by a JavaScript application running on the client browser."
So first half fine, but non-javascript based simplified html preferred for me anyway.
Quote from OA
"The new Gemini protocol aims to be a lighter-weight hypertext web, but we don't see any need for that when web 1.0 is still right there and highly functional."
https://wiby.me/
https://search.marginalia.nu/
Above might help to find simpler non-commercial Web pages since Google is dropping older stable resources from search results (or appears to be doing so to me).
"The new Gemini protocol aims to be a lighter-weight hypertext web, but we don't see any need for that when web 1.0 is still right there and highly functional."
The amatuer radio community aims to be a lighter-weight approach to radio communication, but we don't see any need for that when BBC Radio 4 is still right there and highly functional.
Sure, but the *real* point is to have fun with something you can build entirely by yourself from the ground up. The functionality of what you're building is just an *excuse* to build it. So I'm not going to knock the Gemini crowd. But I continue to publish on Web 1.0. (And mirrored to Gemini as well just for fun.)
> ...users report success on 486 PCs with 32 MB RAM –
Yeahbut-- back in the last century, when Netscape was king, we WWW-ed with less hardware than that. Who had 32 MEGAbytes RAM?? I remember smaller hard drives? The 486 was cool-- I had a 386 *server* which served fine HTTP but would hardly render a page in under a minute. (A friend at UMissou said he had a 286 server but it may have run a proto-unix.)
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2025
