Why Blink and not Gecko?
-
Yes, but the way the Python stack works, means there are clear limitations to what you can do with a Python thread, without using multi process.
Threading in PythonAs mentioned by Juergen Python threads cannot actually concurrently access state in the interpreter (there's one big lock, the infamous Global Interpreter Lock.) What that means in practice is that threads are useful for I/O bound tasks (networking, writing to disk, and so on), but not at all useful for doing concurrent computation.
-
…No opera is a multi-thread application, and tat is an indisputable fact.
Well that depends on how you define single/multi-threaded. In the browser world, it does not mean that the browser application as a whole only use a single thread. Pretty much every application with a UI use more than one thread.
When it comes to browsers, single-threaded usually means that all tabs share the same so called "Main thread". This is where rendering, JS and other stuff runs.You can even check how many threads a process runs at a given time in process explorer for example.
Just to prove it, i started up Opera 12, and looked how many threads were used by the opera.exe process.
8 threads on cold start. Still 8 threads when I opened 20 tabs. I even tried to reload all tabs at once, still 8 threads. This is what single-threaded means, when it comes to browsers. -
Someone here is confusing multi threading with multi processing.
-
And going with Mozilla — we felt that fewer people were using it.
I'm not a huge fan of any rendering engine, but that is a seriously poor reason. Isn't that nearly the same excuse Opera used to drop Presto?
-
It's the reason why Opera was forced to drop Presto. Too few people used it, so it was discriminated against by developers and could never attain 100% web compatibility. Enormous amounts of manpower were wasted trying to get web developers to test in it, to comply with standards, to develop keeping in mind the Opera existed and, since this was never entirely successful, making continual modifications to Opera to make it jump to hoops to properly display non-conforming sites.
Vivaldi decided to use the engine that had, or would have, the highest usership, and would lead, rather than follow, on the subject of web standards.
-
Regardless of how you look at this subject, it's a little hypocritical that the founder of Vivaldi said that Opera should never have dropped Presto, and then he chooses which browser to fork based on market share…
-
So you're saying Jon still has a large corporation with hundreds of millions of dollars and hundreds of staff to build and maintain his browser? Or it's still 1993 when five hundred people are using the internet and basically anyone can write their own engine? What exactly is your point? That JSvT should ignore current realities and live in the past?
-
No, I understand that HTML/CSS/Javascript have grown to be a mess and it's way too much effort to write a rendering engine nowadays. What I am saying is that the rendering engine should have been chosen on the basis of technological merit and not market share. Which absolutely could have been Blink as well, but I disagree with the way that they chose it.
-
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?"
-
@Ayespy said in Why Blink and not Gecko?:
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.
-
@wojtek said in Why Blink and not Gecko?:
... 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:
https://arstechnica.com/gadgets/2011/04/webkit-best-option-for-camino-as-mozilla-drops-gecko-embedding/https://lwn.net/Articles/436412/
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.
-
@ayespy
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.
-
@jopv said in Why Blink and not Gecko?:
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
https://en.wikipedia.org/wiki/Chromium_(web_browser) -
@ian-coog
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.