Otter Browser | Hacker News Reader

Otter Browser

otter-browser.org

184 pointsniedzielski94 comments

I'm not well versed enough in the Browser Wars to say one thing or another about except this:

I like the name.

It lends it self to saying "I use the Otter browser" which is not just a great pun but the pun on 'other' defines what Otter is, the "other" browser. The web needs independent browsers. We need to get rid of the idea that websites are designed to work on any one technology. They should work on any browser that supports the standards.

> The web needs independent browsers...[websites] should work on any browser

Unfortunately, independence ends with the choice between WebKit (QtWebKit) or Blink (QtWebEngine), albeit with a faithful Opera 12-like interface that's less resource hungry than Vivaldi. Otter is still in development and it shows in some rough spots and occasional crashes.

I'd love to go back to 1999 and see everyone's reaction when I tell them that almost everyone in the 2020s uses a browser derived from Konqueror, and that you have your choice of Konqueror derivatives from Apple, Google, or Microsoft. Whoever named it was more prescient than they realized.

There’s an old turn of phrase, first comes the Navigator, then comes the Explorer, then…

I guess we’ll all have the browser engines run on Kubernetes in a few years huh?

I think you were going with the “governor” definition of Kubernetes, but “pilot” is closer to the mark.

It is the same stem as "cybernetics", after all,

Never knew this! Thanks for sharing.

There’s also the Gecko engine, Firefox does still exist.

And it's quite good. I switched over a little over a year ago, and I have no regrets.

I was referring to a choice between WebKit and Chromium/Blink in Otter, not the web in general, though the sheer resources required to keep up with the Web(R) from other players may be leading us that way (hopefully not).

For example, after switching the preferred engine in about:config, it's even possible to leave Otter in a transitional state, having one tab load a web page in WebKit, and another in Blink, in the same running application.

QtWebkit has been deprecated for a long time, and removed from Qt6. If you use it, you'll run into 'not supported' messages on most Google websites.

Last time I used a QtWebKit browser, I could get around this easily by user agent spoofing. Not sure if the experience was totally perfect, but there were no glaring problems.

Doesn't change the fact that it's been deprecated/removed upstream, though, unfortunately.

It was used by KDE for some oauth workflows, where changing the user agent string was not possible, and auth consequently impossible. They've switched to the external browser instead.

Who outside of Apple is using WebKit at this point? And how often do the tarballs drop?

> Who outside of Apple is using WebKit at this point?

Gnome/GTK, at least. The one bundled with Gnome (previously called Epiphany) still uses it. I was going to say Midori, but apparently it's recently-ish switched to Electron, which is understandable, but a little disappointing.

There are other niche browsers using WebKitGTK, but with the loss of Midori (?) and Qt's WebKit interface its definitely got a really small presence now.

> And how often do the tarballs drop?

Unlike most open source projects inside Apple, WebKit is developed basically in the open, with a dedicated website at https://webkit.org/ and an SVN repo at https://svn.webkit.org/repository/webkit/. They also link directly to the WebKitGTK project, and provide instructions for building for/on Linux (and Windows).

It's kind of a shame it's not more widely used -- I understand why most people so inclined would prefer Gecko/Firefox, but there may come a time when the only valid choices are a rendering engine backed by Google's dollars, or one by Apple's dollars. And unlike Mozilla, which is still mostly relying on Google's dollars, Apple has a vested financial interest in keeping a separate and at least adequate web stack.

Edit: Worth mentioning one problem with WebKitGTK adoption in linux has been API deprecation. I haven't done any dev work with it, but I know a lot of projects just gave up after the WebKit -> WebKit2 port, and GTK itself can be a PITA. The tooling outside Darwin/OS X is more cumbersome, too.

JavaScriptCore is easier to embed/better documented than SpiderMonkey, though (IMO). And it can even run headless, although getting it to build headless can be, uh, finicky...

There was an effort to revive QtWebKit some time ago, despite its removal from Qt proper

https://www.phoronix.com/scan.php?page=news_item&px=QtWebKit...

it would be cool if just one of those smaller browser projects was based on firefox/gecko

There is SeaMonkey - https://www.seamonkey-project.org/

It's essentially a continuation of the Mozilla Suite (formerly Netscape). However they're falling behind on Gecko integration, with the latest version still on Gecko 60 (2018) with backports.

The reality is that Mozilla doesn't focus on embedded applications of Gecko besides Firefox (even Thunderbird is sidelined these days). Projects that are essentially third-party, like SeaMonkey, really have no visibility at all. This is the reason why the Chromium Blink engine has become so widespread, especially when it's been nicely packaged up by the commercially-backed Qt project.

I presume part of this is that for a long while the KDE/webkit/chrome engine was a separate, isolated thing, whereas the rendering in Firefox was not.

Not sure where Firefox/gecko is now, but pulling the rendering apart from the UI and improving it to be usable by other UIs, projects, would help get this done.

Or just a real browser not a repackaging of other browsers/engines.

I don't know why there aren't more browsers based on Gecko; especially since there are quite a few people who are not exactly thrilled with the general direction Firefox has been going.

There's PaleMoon, which is a fork, and there's SeaMonkey, although the latest version is based on Firefox 60.8 (May 2018), so I guess that's more of a fork than "using the Gecko engine" too? Also the UI is a bit too 1999-esque even for my tastes.

So I guess it's just hard to re-use Gecko? Using QtWebEngine (or QtWebKit before that) is very easy. No really, it's 20 minutes and you have a basic browser. I built a basic "vim-like" browser in the style of Qutebrowser in a day with PyQt (missing a lot of UI stuff and polish, obviously) and I'm not even very experienced in Qt/PyQt (or GUI programming in general).

Yes, Firefox/Gecko is much more one thing, Mozilla apparently even had some problems with that close integration and baked-in assumptions when building the Android variants.

Splitting this out a bit more seems like it would be a good strategic choice, not just for Mozilla, but for the web in general. There are undoubtedly all sorts of technical challenges involved, but betting on only Firefox is putting all eggs in one basket.

Say what you will about Blink/Google, but the easy with which you can build a browser on top of it has spawned a plethora of browsers, ranging from Edge and Vivaldi, to all sorts of more niche ones like Otter and Qutebrowser, and many more.

Half of Vietnam is using Cốc Cốc. Yandex Browser is fairly popular in Russia, UC Browser is popular in China (or rather was, since it was banned) and some other Asian countries.

There's no reason at least some of these couldn't have been a Gecko-based browser.

Hey, I remember that nickname!

Yeah, for smaller projects with only a handful of people behind them, WebKit (via WebKitGTK) or Chromium (via QtWebEngine, Electron, Chromium Embedded Framework) are pretty much the only choices there are. The only exception maybe being Pale Moon.

For browsers which are based directly on the Chromium codebase without being supported by Google, there are definitely many more resources needed - I don't see a particular reason why those couldn't be based on Firefox either. From what I see in QtWebEngine, keeping up with Chromium isn't exactly easy - IIRC they said they need about a person-month to catch up with a new Chromium release, usually with millions of changed lines.

I was hoping for Servo to fill that embedding usecase gap, but it looks like that's been mostly abandoned by Mozilla nowadays. My only other hope is GeckoView: https://mozilla.github.io/geckoview/ - I know at least the people behind Tridactyl would love to see it ported to x86_64: https://tridactyl.xyz/ideas/#port-geckoview-to-x86_64

They should work on any browser that supports the standards.

10-15 years ago I would agree, but now I feel I must add something to that sentence: any browser that supports the standards before they became Google-ified because it is churning the standards so much that its weapon of monopoly is effectively change --- Firefox can barely keep up, and Microsoft already surrendered.

What we really need to get rid of is the idea that websites are designed to work only on the very latest version of Google's browser or one derived from it. Text-and-images "formatted document" pages should absolutely not require JS just to show their content, and readable with a text-based browser too.

Even webapps, which are more sensitive to browser environments due to their heavy use of JS, should not stop working on an older browser just because a newer version appeared --- after all, it did work before. I really don't understand the rabid trendchasing and forced deprecation the webdev community seems to love so much. All I see are webapps getting slower and ceasing to work, namely doing almost the same thing they could be doing decades ago.

And, let's be clear, Google's ability to enact change is a result of their pervasive influence over the internet.

It took _years_ for XMLHTTPRequest to become a dominant influence on site design. Google can push new standard changes in fraction of the time because _their services demand it_.

> Even webapps, which are more sensitive to browser environments due to their heavy use of JS, should not stop working on an older browser just because a newer version appeared

Those are vendor-bound apps.

They're Google Chrome Apps, not web apps.

Well, it's not like the entire web community haven't warned about it for the last 10 years.

At this point, what can we do?

Many have warned, most have not understood or unfortunately cared enough to listen. Now we are fighting the uphill battle for it.

One thing could be to define layered standards for various use cases.

Like the archiving standard for PDF. Perhaps a formalized version of “graceful degradation” if you will with a known set of target.

One target could be a self contained, script-less, bundle f.ex.

10? This was a problem even before 2001, which is when Internet Explorer 6 was released which (unfortunately) quickly became the Internet. Things weren't so multi-platform back then so swaths of the Internet became inaccessible unless you were using IE6 on Windows. Things are a bit different these days with smartphones and Apple's viability, but the landscape is starting to look strangely familiar.

Test everything in w3m, netsurf and other niche browsers.

If I see a website that fails to display text with JS disabled I close it and never come back out of respect to blind people who also can't visit that site.

Screen readers work just fine with regular browsers and JavaScript - it's not like visually impaired users are using Lynx.

Exactly! All big ones like NVDA, JAWS, VoiceOver, etc, are fully capable to read and interact with craziest single page application build and rendered in your browser

This is a common myth. The vast majority of blind and partially sighted users don't use text-based web browsers. They use normal web browsers in conjunction with screen readers; these browsers can execute Javascript normally. There is nothing inherently inaccessible about Javascript-based content.

It will not change until dev stop developing on Chrome as their main browser. Maybe tooling could be an excuse for very large webapps, but otherwise and especially for websites (hello simple forms broken except if you use Chrome) it's definitely not.

Also it's orthogonal with JS usage, anecdotically I mainly work on JS heavy websites and don't use Chrome.

I dev in Firefox. It’s great! The tooling’s really good. It’s subtly different from Chrome and you’ll feel a twinge of friction moving, but by and large, it’s easy.

Just shut it down and restart it every couple of days because it’s memory usage isn’t as tight.

Are you using the Firefox Developer Edition[1], or just the current stable one?

Fellow web-dev here, using Firefox (the one that comes with Ubuntu) as main driver. And I'd like to know if the Developer Editiion offers any benefits over the stable one, for webdevelopment.

[1] https://www.mozilla.org/nl/firefox/developer/

Yes, I use the developer edition. TBH I’m not aure what the benefits are! ;-)

I do too, but what I miss is customized throttling settings (I need to optimize for fast overseas connections: high bandwidth but also high latency). Chrome (and Edge) have this.

Firefox has this too. You can do it the network tab[1] or in the Responsive Design Mode[2]. There's drop downs there where you can control how much you want to throttle

[1] https://developer.mozilla.org/en-US/docs/Tools/Network_Monit...'

[1] https://developer.mozilla.org/en-US/docs/Tools/Responsive_De...

Thanks, I know these settings. One can only choose from the predefined settings. You can't customize those (as for me, to high bandwidth and high latency).

> ...its weapon of monopoly is effectively change...

Rather novel weapon. This won't work, rapid change will just leave the large base of web developers behind. Tutorials and practices based on the Old Way hang around for decades.

Google putting out a standard is only going to help them if it is (a) in demand by web devs and (b) competitive with the old way of doing things.

I don't particularly like web apps, but they are a new field and rapid change in the standards is not really a sign of monopoly.

Unfortunately, this isn't how (web?) devs work. For a whole host of reasons, devs always prefer the new thing. This is likely a combination of factors: fashion (the same general social tendencies that make fashion a thing in any other industry), youth (new people are continuously joining the profession) but probably most of all: curiosity and a desire to learn new things.

You can try and model things on the idea of rational experienced senior devs all making tech decisions based purely on hard evidence-based demonstrations of material benefit of new tech over old tech, but reality is much softer than that.

Another factor is that Google's hold over SEO allows them to drive change through SEO requirements. E.g. there's always been a lot of overlap between new tech introduced and Chrome and requirements for Google search indexing, and that stands to increase with things like Core Web Vitals,

> rapid change in the standards is not really a sign of monopoly

Your statement here seems to be just picked from the ether and not actually based on anything in reality: there's no reason rapid change cannot be associated with monopoly.

There are many differences between how Google is approaching tech and how Microsoft did in the late 90s / early 00s but the its worth noting that second E in their infamous Embrace, Extend, Extinguish strategy most certainly involves rapid change in standards. This is hardly the only example, but it's notable I didn't even have to pick a different industry to find one.

Chrome started forcing tab grouping on mobile so I've tried switching to Firefox. My bank's log in screen doesn't work and posting to Facebook Marketplace is broken. Not sure why basic functionality like that doesn't work but it does force me to keep Chrome around.

Think we're mixing up two things here: Google monopolizes the Web as a runtime with constant forward motion on the standards; no browser vendor can keep up, this is true.

However web dev practice has been driven by Facebook and its quasi-functional programming advocates for at least 5 years now (Redux/React). There's a whole generation of Web Devs that don't know that DOM Event handlers can be objects that bear the handleEvent interface because React prohibits that application for example, but that's a whole world of memory efficient async handling rather than generating throwaway functions for ever little thing

"any browser that supports the standards before they became Google-ified because it is churning the standards so much that its weapon of monopoly is effectively change --- Firefox can barely keep up, and Microsoft already surrendered."

Almost all if they're abusing their search monopoly to force their preferred web "standards" on the rest of us?

> [..] it is churning the standards so much that its weapon of monopoly is effectively change --- Firefox can barely keep up, and Microsoft already surrendered.

https://www.joelonsoftware.com/2002/01/06/fire-and-motion/

It really looks like w3c standard === Chrome at this point. Is "standards body capture" a thing like "regulatory capture?"

Do you like the name better than "Chrome"?

If someone says "I use Chrome" what does than mean to you?

Just curious.

Perhaps some websites do not make use of all the standards, thus browsers do not need support for all the standards for these websites to "work". For example, HN does not require a popular browser. In fact it can even be used without a browser. Why are so many "web devs" using HN but few to none of them can/will design similarly fast and flexible websites. Do "web devs" actually use the sites they design. Why would "web devs" use HN when it does not represent their own taste in websites. What does that mean.

Web devs make the websites they are paid to make. I'm not sure why you think their output would reflect their taste rather than their employer's taste.

Exactly! In a lot of areas, we hear talk of how "the developers"[0] made this decision or that decision (e.g. mobile apps, games, web).

But in reality, most developers have very little agency over technical decisions. Sure, they're the ones actually building it and choosing the exact tools and frameworks, but they have almost 0 control of their own constraints.

Metaphorically, companies decide they only want to use nails because they're cheaper. Even if screws would be better. The conversation inevitably turns into frustration with developers' overuse of hammers.

[0]: I get that we say "developers" to also include publishers/etc, but the term often morphs back into blaming the "technical implementers" on the team.

> We need to get rid of the idea that websites are designed to work on any one technology.

Otter-Browser uses QtWebKit.

So it's still another entry using the "one" technology, WebKit (which Blink is a fork of as well).

Otter-Browser doesn't change anything at all about the erosion of standards. The only WebKit-independent engine we have still is Firefox Gecko.

It lends itself running on a mobile phone with an OtterBox case.

Do you like the name better than "Chrome"?

If someone says "I use Chrome" what does than mean to you?

Just curious.

Perhaps some websites do not make use of all the standards, thus browsers do not need support for all the standards for these websites to "work". For example, HN does not require a popular browser. In fact it can even be used without a browser. Why are so many "web devs" using HN but few to none of them can/will design similarly fast websites. That's a rhetorical question. (That means everyone already knows the answer.) Do "web devs" actually use the sites they design. Why would "web devs" use HN when it does not represent their own taste in websites. What does that mean.

Really disappointed by the marketing of these projects. No information whatsoever regarding why I should both download and use the browser. I understand that's something related to Opera revamping, but I just don't understand why such projects don't invest 5 minutes of time explaining features in plain English, and relegate everything to a niche. What a pity.

the README.md is a bit more informative

> A browser controlled by the user, not vice-versa

> Otter Browser aims to recreate the best aspects of Opera 12 and to revive its spirit. We are focused on providing the powerful features power users want while keeping the browser fast and lightweight. We also learned from history and decided to release the browser under the GNU GPL v3.

That is nice, but it's little to go by. I used Opera once for a while, but no idea what version. What was that "spirit" of Opera 12? What are those features power users want, do I want them too?

Give me at least a screenshot and 1-2 sentences that I as the user of current Firefox or Chrome can say anything about. All I get is fast and lightweight, which seemingly 90% of software projects write somewhere on their homepage.

Nothing against this browser, it's just that there are more open source projects than I could ever try out in my free time, and if I have to take a second look to find a link to screenshots somewhere below the one to the changelog it's not too convincing. It doesn't have to, maybe I'm not the target audience, but that's my impression.

> What was that "spirit" of Opera 12?

https://news.ycombinator.com/item?id=19615411

https://news.ycombinator.com/item?id=23733577 (plus parent for context)

Maybe I can summarise that as "lots of features and customisability".

I think it's mostly because they don't really have much in terms of features to separate them from Chrome. It's almost always more a thing about just not wanting to use Google, and bundling some extension-level features into the core browser (ad block, mouse gestures, this sort of thing).

Past related threads:

Otter Browser – Aims to recreate the best aspects of classic Opera UI using Qt5 - https://news.ycombinator.com/item?id=18830430 - Jan 2019 (47 comments)

Opera 12.15 source code - https://news.ycombinator.com/item?id=13417307 - Jan 2017 (86 comments)

This seems actually viable. And those weekly updates let us know "It's Alive!!" not some zombie. I'm going to make an effort on using this.

I'm currently using a Firefox fork but the maintenance is a little rough and I get conflicts with upstream sometimes that are hard (for me) to resolve.

Firefox doesn't even allow me use my own custom homepage from local file when I open new tab. First tab does allow that though. Talk about consistency.

They do not fix it for years now which for me means one thing: they do not understand how basic this functionality is and if so I think this 'mainstream' has lost it's sight.

For me as long as such idiocy exists in 'mainstream' I consider it doomed. Because if you do not fix such basic things the next question is: what else you did not fix ..

Another idiocy is that they push updates through your throat without option to stop checking for it or stopping dialog asking to update. It always appears when you do not want it to appear and breaks the flow of your work. I consider it a disrespect to a person who uses it. And again in my opinion as long as it exists I think it's doomed.

It's in the Homebrew repo, so installing is as easy as

  $ brew install otter-browser

What's also interesting, is that the tab-close button is on the left of the tab, like every other macOS application. Other browsers (Chrome, Firefox) put it stubbornly on the right.

Here's a Firefox userChrome.css workaround that moves the close button to the left side of the tab:

https://github.com/MrOtherGuy/firefox-csshacks/blob/master/c...

I have something like it, but this one looks better maintained. Thanks!

Vivaldi (Chromium-based) similarly places it on the left for Mac, fwiw, with an optional setting to change it.

I'm all for unmonopolising the web browser but Otter seems to have major stability issues. I'm on macOS 10.15.7. Doing a DDG search consistently crashes Otter. Would liked to have given it a go but I'll stick with Firefox.

Seems to be a nice UI around QtWebEngine which is based on WebKit or blink (chromium), with quite a solid effort through the years.

Depending on your build, you have a choice between:

- QtWebKit: https://wiki.qt.io/Qt_WebKit

- QtWebEngine: https://wiki.qt.io/QtWebEngine

(I realized I replied to a previous version of the parent comment)

> chromium

Are there any Google risks for being chromium-based? Honest question here.

As noted in a sibling to your comment, there's a choice between WebKit and Blink (your build allowing).

Here's QT's note addressing your concern in QtWebEngine: https://wiki.qt.io/QtWebEngine#Relationship_to_Chromium

    Auxiliary services that talk to Google platforms are stripped out

So, if Chromium turns into a bun fight with Google, the Open Source components would just fork?

I can't find a source, but I know Brave has had upstream Google issues in the past. Unfortunately, from what I've heard, Gecko is not very developer friendly, so Google is pretty much the only option.

I feel like Mozilla's decision not to prioritize support for embedding Gecko ended up being a strategic error in the long-term. Other browsers using Blink don't add directly to Chrome's market share but having it embedded everywhere means that its quirks don't end up being perceived as Chrome-specific. If five different browsers all behave the same way and the sixth one differs, then the sixth one ends up looking like the odd one out, even if the reason the other five behave the same is that they're all sharing code.

It was no strategic error. They just took the money and told the users to FO. The strategic error was having a board of directors taking decisions about a browser.

A poor decision that they continued to make with servo.

When safe browsing is enabled ( by default) it send all your browsing habit to google.

Is it safe to trust binaries hosted from sourceforge? Didn't they used to host modified binaries / packages with malware?

I remember there was an announcement from new management. From their Wikipedia page:

> After SourceForge was sold to BizX in 2016, DevShare was discontinued. On May 17, 2016, SourceForge announced that they were now scanning all projects for malware, and displaying warnings on projects detected to have malware.

>Is it safe to trust binaries hosted from sourceforge? Didn't they used to host modified binaries / packages with malware?

Once upon a time, yes. It was awful. Was bought many years ago and turned around, however. The guy who owns/runs it has posted here before describing the journey. He mentioned one of the primary reasons for the purchase was due to the many software projects hosted there and at risk of falling off the face of the earth, potentially causing all sorts of mayhem in the process. I respect that.

Anyhow you can go check it out. It's nice. I'm glad it's still around.

Man, those 7 bugs must be tough. ;)

It seems pretty similar to https://www.falkon.org/ (which is the successor of Qupzilla, i.e. a lightweight browser based on QT5+Blink, already natively integrating an ad-blocker, vertical tabs, and a lot of useful stuffs)

Logo could do with a makeover. Possibility of a really nice cute graphic. Firefox seem to have repeatedly missed that opportunity.

And the O is a bit reminiscent of Opera. ( I read it hopes to ape some of the better bits of Opera's past.)

Certainly space for an innovative - I'm in the driving seat type browser. The space is really lack-lustre, and not in a good way.

Crashed it, before even getting going with it on the content blocking prefs.

Otter 1.0.02 on Manjaro.

qt.qpa.xcb: QXcbConnection: XCB error: 3 (BadWindow), sequence: 580, resource id: 8418551, major code: 40 (TranslateCoords), minor code: 0 Segmentation fault (core dumped)

If I were building a new browser, priority 0 would be uBlock Origin support with a front-page guarantee it will never be neutered by any future "standards".

Shoot. Has uBlock Origin been neutered in Firefox?

I've been using it since the beginning and never bothered to check whether or not support has been reduced in some form.

No, not yet, and hopefully never, but they're not flat out promising it.

I like this browser because it's one of the better options that runs on Haiku OS!

Gotta love the webpage with the commit/issues updates every week.

Well done boys.

Welcome to the otter side

So does this still use Presto, and is there any forward movement on it?

Presto is ancient as this point, and the only source code out there was a leak, so legally unviable.

Reply on news.ycombinator.com