Why Blink and not Gecko?
You weren't in the meetings, so you don't know the way they chose it.
That said, all current browser engines are of roughly equivalent technical merit. That leaves, in terms of comparisons to consider, economic and web-compatibility concerns. In short, "Will the engine be broadly supported and written for in ten years?" "Is it platform-agnostic?" "Can we develop on top of it and accomplish our development goals with relative ease?" and "Which engine will provide us the fastest and deepest market penetration?"
wojtek last edited by
economic and web-compatibility concerns. In short, "Will the engine be broadly supported and written for in ten years?"
That's very disappointing reasoning given that supposedly we have "web standards"... and in the end we end up with poor chrome-clones and terrible and bloated engine...
Also: mozilla is making it's ways with servo et al - maybe it Vivaldi could adopt it in the future...
@wojtek Yes. "Web Standards." Opera Presto died fighting on that hill.
Blackbird last edited by Blackbird
... That's very disappointing reasoning given that supposedly we have "web standards"... and in the end we end up with poor chrome-clones and terrible and bloated engine...
There are "web standards", and then there are the ways that site coders choose to do things... and they're too often not the same. Many of the popular websites are continually bending or "interpreting" the 'standards' in order to get their sites to do "creative" things - or else ignoring some of the 'standards' entirely because of poor-quality coding. However, all that matters to the vast majority of browser users is whether the website they're trying to view renders properly in the browser they're using, regardless of how that site may be coded.
Websites discover very quickly that their coding variants often don't work well in every flavor of browser, hence they frequently only test and debug their site code against the idiosyncrasies of the biggest-name browser engine(s) and sniff out all the other kinds of browsers in order to block them (thus not having to wrangle in support with the thorny incompatibility issues encountered by users of less popular browsers that respond differently to the site's unique coding variants).
This has actually been going on for many years in largely the same way, though the standards involved have themselves changed a fair amount. To see the extremes to which this has been carried at times, simply check out what MSN did to Olde Opera and what Opera did in retaliation back in 2003 (ref: the now-legendary Opera Bork version)... and note: in Internet years, 14 years ago is a very long time.
The point is that there's more to making a successful browser than just the technical creativity poured into it or the existence of "standards"; the browser must be compatible with the maximum number of websites "out of the box" in order to be successful to its users, and that implies it must be built on a rendering engine that is inherently accepted for compatibility by most websites. That means you either have to have the financial clout to push your own engine design for many years to gain big-name status with the site-coders or adopt an existing engine that already has maximum website compatibility. As @ayespy notes, Presto Opera fought such an incompatibility battle and lost. That loss should be instructive.
I most definitely wasn't in the Vivaldi meetings but I can take a pretty good guess at what some of the team's major design dilemmas would have been. Part of the design process (for anything) is creating a vision for what you want your product to be and deciding on what tools and technologies you intend use for development going forward. You also have to give serious consideration to the integration challenges that you'll face repeatedly with respect to the browsing engine knowing that there are essential modules that you'll need to keep and unwanted elements that you will need to exclude... and the ongoing work that will be involved during each and every development cycle as you integrate upstream components.
Many years ago, if you wanted to build your own browser, it was relatively easy to embed Gecko into your product... and many Linux-based browsers did. You didn't have to build your browser with XUL either; Camino was popular on OS X because its UI was built with native Cocoa widgets and it integrated seamlessly with the native platform, but still used the Gecko core for its browser engine.
Then Mozilla decided to drop embedding support leaving many teams in a lurch:
When Vivaldi was being designed, Gecko was already a pretty "challenging" piece of technology to integrate with and Mozilla's market share was heading into a pretty steep downward spiral. Although Gecko still had its merits, it's also understandable why it wouldn't have been (and hasn't been) anyone's first choice for a browser engine in a new browser.
Fast forward to today and even the Thunderbird and SeaMonkey teams are stuck having to make some difficult decisions now that XUL, Gecko and related technologies are being shelved in favour of Quantum, Stylo, and components of Servo.
It will certainly be interesting to see what directions other new browsers choose to go into and the technologies they adopt, but as Vivaldi continues to gain momentum and market share, it doesn't make sense for them to make any radical changes.
JopV last edited by
No, it didn't. Most websites worked fine in Presto. And after the switch to Blink, Opera's market share did not increase. In fact, it decreased (Nintendo switched to NetFront, for example).
Currently, I have yet to find a desktop website that works in Chrome but does not work in Firefox. And even on the mobile side, where Gecko's marketshare is miniscule, most websites still display pefectly.
Meanwhile vivaldi.net has multiple posts bashing Google for how evil they are, even though Vivaldi is Chrome. It has completely killed the company's credibility for me.
iAN CooG last edited by iAN CooG
Vivaldi is Chrome
No, Vivaldi is not CHROME but uses CHROMIUM with a heavily personalized and way more customizable UI.
Tells a lot about your I-know-it-all-and-better-than-you-attitude.
A little refresh of the difference for you
JopV last edited by
I could have known I was going to get this reply...
Chromium is the Chrome open source project. As a browser/engine, there is no distinction between the two.
@jopv As a browser/engine, there are some relatively important differences between the two. Yes, they are highly similar, but Chrome has several tens of thousands of lines of proprietary code it does not share with Chromium or anyone.
Say what you will about Presto, it grows less compatible with the modern web every day. No one is maintaining it for the desktop. I think Opera may have even ceased development of it for mobile. And they have control of it, so that's that.
That said, Gecko will soon be dead and unmaintained as an engine by any major concern. Firefox is transitioning to Quantum/Servo/Rust, and will be using the new platform to keep up with web changes forced by Chromium (and in many ways copying Chromium thereby). WebKit/WebEngine will also be tagging along.
Smaller browsers built on Gecko are going to have a devil of a time keeping up, because the web will be developed in directions not contemplated in that code - and none of these small browsers have a big enough team to make wholesale changes at pace.
So, when Jon, who's been building web browsers and innovating with them for his whole life, and his team, who've been building web browsers and innovating with them for their whole lives, put their heads together and debated at length the pros and cons of adopting each existing browser engine, I think it's likely they saw (and some from the inside) which ways the winds of the web were blowing, and made their decision based on pretty much every argument that is likely to ever be raised here - and more. If you weren't a part of this debate in the beginning, a) don't expect to change the outcome now; and b) don't expect anyone writing here to be able to explain all of the thought that went into it.