Re: Lightweight Browser By: Folderol to All on Thu Aug 13 2020 10:32 am
Lynx -> text only interface. Netsurf -> gui, javascript support severely lacking. Surf -> As much of a barebones Webkit based browser as you can get.
Piece of advice: run your web browser through an advertising removing proxy or through and advertising removing DNS service. It will prevent your browser from wasting lots of resources.
Can anyone recommend a browser with as little overhead as possible, and reasonably performant - doesn't have to have all the bells and whistles. I'm running devuan beowulf - not easy to set up initially, but much leaner than raspbian.
nginx?
That's a server, he wants a browser. There are many lightweight browsers, all of them flawed in that they don't match anyone else's bugs and of course nothing quite fully implements any of the standards. It boils down to try them and see if you can live with any of them. I keep winding up back at Firefox or Chromium and cursing about it every time I go on a browser hunt.
Lynx.
Its so lightweight it doesn't do graphics: only text, but on the plus side, when you visit a website it lets you specify which, if any, types of cookie it will accept.
You could try Netsurf
The memory footprint is remarkably small and it is *very* fast, it's a pity that the rendering is off on several pages, it may well be doing what the page asked for but not what the designer intended. The biggest weakness for modern sites is the lack of good JavaScript support which means nothing AJAX based can work at all.
Oops...
On Thu, 13 Aug 2020 10:32:40 +0100, Folderol declaimed the following:
Least overhead... Probably Lynx... But I really suspect you wouldn't be happy with it...
On 2020-08-13, Folderol wrote: [rewrapped]
As others on this thread have stated, it's quite a challenge to find a browser that is both lightweight *and* can display most modern sites. Most sites are so over-loaded with JavaScript, HTML5 and other elements that they *need* quite a bit of overhead to fully display at all.
For basic browsing of text/image-based sites that don't have that requirement to display dynamic content, I recommend `links', which you can run graphically by running `links -g', which provides a very lightweight graphical browser which can be run in X, a framebuffer console and (I believe) wayland.
That's not the main point. Very few sites come even near to being valid.
90 % of the bloat (and the same share of the malware entry points) come from trying to second guess, whatever the author might have meant by the utter nonsense he wrote.The world would be a much better place now, if early on all browser vendors had agreed *not* to guess but simply display nothing but "syntax error" on all non-valid pages.
Alas, that chance is long gone and so far away I find it hard to even dream.
On Thu, 13 Aug 2020 13:54:01 +0100, Ahem A Rivet's Shot declaimed the following:
Well -- that is what original HTML was for... To describe the page and let the browser do the rendering of that description. It was not a "page design" system.
Don't any of the web page editors and/or the people using them use HTMLtidy to check HTML pages before publication?
I'm still unreconstructed enough to create web pages with a text editor (microemacs in case you're wondering) but they *always* have to pass a:
$ tidy -e mypage.html
inspection before being published.
I don't agree with that at all. I'd say that accounts for some of the overhead, but a very small percentage.
The real issue is that webpages have stopped becoming *pages* and are now essentially applications in and of themselves, all being run through essentially slow, interpreted languages.
In comp.sys.raspberry-pi, Ahem A Rivet's Shot wrote: [Netsurf]
Edbrowse is text-only and does Javascript.
It's been a few years since I used it regularly, but it was my browser of choice for Twitter for a while. The UI *does* take some time to get used to.
Elijah
------ but it works well with Braille displays
the problem here is the loose standard. If it were XML, then it would be true, but HTML allows too much BS per design. Perhaps someone convinces W3C to tighten the standard - especially now when "everybody" is a web designer.
Maybe, but they[1] test them on a specified list of browsers[2] and any deviation from pixel perfect and intended interactions has to be fixed on *those* browsers no matter what it does to standards compliance.
[1] At least in the bigger teams. I have seen this in more than one place. [2] The list comes from log analytics and aims to catch some high percentage of users - the rest don't matter.
HTML is one end of the problem, CSS is another. With the best will in the world laying stuff out with stylesheets and semantic markup is far from easy to get right - actually it's pretty near impossible in general.
If you think XML would help think again - look at the state of the art in open source XSL-FO support:
Notice how many red lines there are, even for 'basic' elements. Don't get me started on debugging XSLT - I've done it and escaped with most of my sanity.
On Thu, 13 Aug 2020 16:04:07 -0000 (UTC), Martin Gregorie declaimed the following:
I used to use HomeSite but that got swallowed by medium fish MacroMedia which in turn was swallowed by big fish Adobe -- and they pushed DreamWeaver or some other /graphical/ HTML editor in place of HomeSite's intelligent pure text editing.
You are the reason -- alright, one the very few ones -- why I wrote "90 %" and not 100.
It has always been and still is the easiest and most efficient way. GUI bloat users wouldn't know how to dream about all the automation a good editor provides.
My favourite example is scripting a graphical page, e.g. a map. Agreed, it would be faster and easier to place graphic elements using a mouse, scripting does take longer. But when done I say "Alright, that's fine now. Now do the other 4999 pages exactly the same please" press
Have something to add? Share your thoughts — no account required.
Ask the community — no account required