Technologies behind Vivaldi browser
-
Could you guys explain in more detail, what technologies Vivaldi browser is based on? Is it discussed anywhere? How they're different from Chrome and Firefox used web technologies? What rendering engine Vivaldi is using - the same as Chrome or its own? Any advantages of this engine?
-
Could you guys explain in more detail, what technologies Vivaldi browser is based on? Is it discussed anywhere? How they're different from Chrome and Firefox used web technologies?
What rendering engine Vivaldi is using - the same as Chrome or its own? Any advantages of this engine?
Uses the Blink rendering engine, and uses its own interface built from HTML, React.JS, CSS and I think JS.
-
There were arguments on Chrome forum about Blink won't allowing to create Sidebar, and therefore keep all extra functionality together in a consistent way via Sidebar access to the most popular core features and extensions. How Vivaldi team was able to overcome this Blink limitation, if really exists?
What other technical challenges are the most prominent in Vivaldi development now? What technologies differentiate Vivaldi from other popular browsers, and what are their perceived advantages?
-
The engine is Blink ( the same than chromium/chrome ) the interface use web technologies ( html5 , reactjs, js, css3, etc )
-
There were arguments on Chrome forum about Blink won't allowing to create Sidebar, and therefore keep all extra functionality together in a consistent way via Sidebar access to the most popular core features and extensions. How Vivaldi team was able to overcome this Blink limitation, if really exists?
What other technical challenges are the most prominent in Vivaldi development now? What technologies differentiate Vivaldi from other popular browsers, and what are their perceived advantages?
The main perceived advantages are configurability and development speed. Using web technologies rather than native elements, the UI is not limited to the properties of the OS and its display elements, and so essentially can incorporate any function in any visual style. Further, because the UI does not have to be compiled, new iterations can follow right on the heels of older ones with greater speed. The chief liability of using non-compiled code is that every window and every page must be built by the CPU and GPU newly every time one is displayed, rather than the convenience and efficiency of simply invoking a native framework without doing any computing. This slows the UI's speed and responsiveness by a few milliseconds (or longer on old, weak hardware).
Because the target user is someone who seeks infinite ability to customize the browser UI and who wants maximum access to built-in functionality, it was considered that the "made just for me" aspect was worth the trade-off of slightly reduced UI speed and slightly increased processor load.
On my system, the loss of UI speed is not detectable. On older systems, some users complain of it.
-
Thanks for the interesting intro! I think in this forum section discussion of technologies namely around Vivaldi should be a center piece, with developers arguing possible solutions, their pros and cons, and optimal choice.
Considering perceived Vivaldi user as someone expecting borderless customization feels an overstatement. Many Opera users were rather comfortable with optimized well integrated uniform set of browser features leading to productivity, such as mail client, sessions, shortcuts, custom buttons, bookmarks, tabs grouping, etc. In further Vivaldi development, it might make sense to concentrate first on what worked well for Opera 12, still driving folks to use it. I doubt easy customization of the old browser is users primary motif now, but productivity is, though its in part based on customization. Of course, now usage is limited by obsolete web technologies used in Opera 12.
The prime advantages of chosen in Vivaldi technologies are clear - it allows to keep company staffing down, critical at this point in company history. Looking at drawbacks you mentioned, what tech approaches might allows to bring a JS based GUI rendering up to speed shown by leading browsers now with integrated UI?
Returning to enriched Sidebar as one of key Vivaldi differentiators (I use All-in-One-Sidebar extension in Firefox for now as a replacement), allowing to add key browser features and extensions in a common way and cleanup GUI, how it become possible to draw it in Vivaldi, while not possible to have one in Chrome, which was stressed by several Chrome extension devs?
-
anymars:
I don't fully understand the supposed Blink limitation whereby a side panel cannot exist, especially given that two years into development, Opera ASA has finally produced one in their Blink version. It can only be invoked on the left side of the browser, and has precisely zero features of its own, but its accompanying API makes it possible to build and install extensions which give it features (tabs, bookmarks, history, notes, etc.) So though the limitation is obviously not absolute, it took forever for Opera with their relatively huge development team to write it, and it still is rigidly limited. You have to install extensions, with the natural accompanying process bloat to make any use of it, and you can't opt to have it on the right side of the browser, or to have two of them, one on each side. Further, there is no space-saving trade-off of being able to disable the obligatory tab bar at the top.
I'm quite sure more optimization than we have seen is possible with the Vivaldi web-technologies choice for its UI.
If course "infinite" customization is a slight overstatement, but only a slight one. The numbers of customizable combinations of form and function in Opera 12 runs literally into the millions, and there is essentially no work flow or pattern of behaviors and preferences which cannot be accommodated. Truly, this sense of being able to completely personalize the browser and its capabilities has been put forth from the very beginning as the raison d'être of Vivaldi - and I hesitate to second-guess Jon on that account.
As to debating better ways to do this, that's beyond my technical expertise. I know a good deal ABOUT tech, but I'm not an actual competent techie, if you know what I mean.
-
Ayespy, as a follow up of our conversation on one of the Vivaldi blogs, it looks like Vivaldi is mode with many web technologies, some of which include: React.js, Node.js/node-webkit, Polymer, and a ton of others. If you look at node-webkit, it's the former name of NW.js, so it looks like Vivaldi is most likely using NW.js.
Now, I'm hoping that eventually, Vivaldi will be able to strip Chromium code they're not using, that they're already using their own stuff with these web technologies, and become independent and control their development. But anyway, I'm pretty sure they do use NW.js.
-
The trajectory of Vivaldi will always be toward maximum efficiency and maximum customizability. If this ultimately means that they will eventually replace everything but Blink and V8 with their own product, then I think it's safe to predict that will come to pass.
-
Yes, I would definitely hope so! If they replace everything but the rendering part of Blink and V8, and build everything themselves, strip away all the Chromium parts they don't use, then there won't be so much bloat from using Chromium, and they won't get screwed over in the future if Google decides to change something. This should make development so much better, which is what I was worried about a little bit. It only makes sense that they do this eventually.
-
Yeah, BUT…
It's not quite as simple as that. The ability to run extensions is doubtless built into the Chromium browser layer, not the Blink engine. That will have to be rebuilt from the ground up. Then, too, the more places where the built-in hooks to the Blink engine written for Chromium are not present, these will also have to become part of the browser layer built by Vivaldi, and every time that engine changes (which it does once a month, to every two weeks) these hooks may break and cause a bug and a re-write on Vivaldi's end. For everything they gain in browser efficiency, they will lose development efficiency, taking more time, more personnel, more resources to build the browser itself. It's as though one were operating a car factory, but the motors that are being shipped from another factory keep arriving a different size, weight and shape with differently placed, sized and shaped mounting points, causing you to have to re-design the frame, suspension and body of the car every time a new motor shows up. Stripping everything back to the engine is no "gimme." It's a paradigm shift, requiring a new allocation of resources.
-
Ayespy,
I see what you mean on the extensions thing. For other features, like the history, sync, notifications, flags, etc. That's probably something they would be able to fully replace with Vivaldi's own code using NW.js/node-webkit/node.js or whatever they choose, and then dispose of the Chromium counterpart, so there's no extra bloat, and you have more browser efficiency with resource usage and browsing speed/stability.
However, when it comes to extensions, would that API bundling be made to be a minimal problem if Vivaldi: creates as many features so people need less extensions, creates their own "Vivaldi" extension store like Opera, and creates their extension code for Chrome, and/or improve Chrome's extension API? I would imagine that there are definitely solutions that Vivaldi can do in order to get full control of the browser that they want to create, and that we, as users, want to have.
And with security fixes, they could always backport from new Chromium versions. Now, how they fix other codes and whatnot like extensions, I don't know, but I imagine they can make that problem as small as possible by doing above.
-
I have never tried Brave. Does it support extensions? I'm thinking no, or maybe only one or two. I think extension support must be written from the ground up, if you jettison Chromium layer.
Of course already known is, Brave does not have side tabs, tab thumbs and previews, notes, panels, flexible placement/reveal of tool bars, page actions, favicon-only option in bookmark bar, UI scaling, stacking, tiling, UI flexibility, etc. So one thing to be considered is: What are you looking for in your browser? So far as I can tell, Brave offers me nothing I am looking for or have ever looked for in a browser. On the other hand, Vivaldi offers the ability to adjust to my work flow. And Email (when it arrives). Priorities matter. It will make sense, I think, to strip out chromium layer elements piecemeal, as Vivaldi is able to re-write these elements, one at a time, for themselves.
Plus, speed is not an issue on my main rigs. On some, I suppose it is.
-
Ayespy,
I see what you mean on the extensions thing. For other features, like the history, sync, notifications, flags, etc. That's probably something they would be able to fully replace with Vivaldi's own code using NW.js/node-webkit/node.js or whatever they choose, and then dispose of the Chromium counterpart, so there's no extra bloat, and you have more browser efficiency with resource usage and browsing speed/stability.
However, when it comes to extensions, would that API bundling be made to be a minimal problem if Vivaldi: creates as many features so people need less extensions, creates their own "Vivaldi" extension store like Opera, and creates their extension code for Chrome, and/or improve Chrome's extension API? I would imagine that there are definitely solutions that Vivaldi can do in order to get full control of the browser that they want to create, and that we, as users, want to have.
And with security fixes, they could always backport from new Chromium versions. Now, how they fix other codes and whatnot like extensions, I don't know, but I imagine they can make that problem as small as possible by doing above.
I don't really know the details of how they could do it "best." They are pros at this, most of them have been for decades, and I am not. It has never actually occurred to me to second-guess the methodology whereby a company that I don't own, where I don't work, and of whose inner workings I actually have zero knowledge, makes their product. I don't even offer that advice to clients in my regular life, who DO hire me to advise them on technical matters where I AM a pro, even though I have knowledge of their inner workings and experience with their product.
-
They have it easier, because they do less. To do more, as Vivaldi is dedicated to doing, requires a different strategy. I do not doubt the package can be made lighter and faster over time by cutting out, and/or eventually replacing Chromium layer code. That process can even be automated to a degree over time, so that it doesn't have to be done by hand with each new engine release. But we are talking about future dreams, while the developers are up to their elbows in present-day realities.
For us to sit here in our comfy chairs, far from the workbenches of the developers and their screens and keyboards, and fantasize "wouldn't it be nice if…" is all well and good. There's nothing against that. But we should not assume that our speculations are relevant to the actualities the developers must deal with, unless we, ourselves, are competent browser developers. Is anyone here?
-
Which, again, means nothing to me. I don't want, and have never wanted, anything Brave so far has to offer.
-
Granted - according to you and I, who don't actually build browsers for a living.
-
I know that Vivaldi won't do all this right away. Brave, is very barebones in a lot of ways. They have No Script, HTTPS Everywhere, and their ad replacement thing coming up, but that's about it and could be done fast. Vivaldi has everything I need right now, and they're adding more and more. I'm not saying that Vivaldi should try to dispose of Chromium code like UI stuff right now, as they are probably very tied up at the moment. But once they get a lot of things they need, a lot of monetization and can expand, hopefully they can hire a Chromium programmer who knows the engine and can help them dispose of Chromium code they're clearly not using at the moment, while Vivaldi, bit by bit, replaces features in Chromium with their own code, using web technologies.
Vivaldi will then have far less Chromium bloat that it suffers, and can become much lighter, and smoother. Old Opera was feature-rich, and very light and fast. I'm sure Vivaldi probably could be the same as well, but not now, in the future, when they've gotten their browser more established and have expanded. So of course they need a different strategy than Brave.
So, they are probably most likely going to replace things here and there, until they're at the point Brave is where they've already replaced things. But Brave is too bare bones for me, so of course I'm not going to use it, but Vivaldi does have the means to potentially get to that point as well. They're already built on web technologies. Now it's just a matter of time and money needed to get there eventually.
-
Not yet. It has a couple of security features.
But its ambition is to block web advertising and replace it with advertising content specific to Brave, which is supposed to send micropayments to content creators in exchange for being allowed to place their ads in or with the created content. Hence, content creators can make some money from advertising, and popups, audio/video ads, various scripts, etc. will be blocked for users of the browser.
The way only six senior developers can create it, so far, is that there has been nothing to create.
-
It strikes me that Vivaldi methods offer every option that Electron does, (and more, since there is built-in extension support), with just a bit more hands-on by the developers, and less automation on the software side, and that Vivaldi is a full-feature browser, already gone to market.
Brave is slick and fast, is not yet an actual browser, and doesn't even render many of its web pages right (I've tried it now). (One wonders how the performance will hold up once it begins to delete others' ads and find and insert their own.)
So Electron, if used, would only offer Vivaldi developers a SLIGHTLY faster build time, potentially smaller package, and less control over the final product. Opera ASA went to one end of this spectrum, building their own native interface from the ground up, and still do not have a feature set comparable to OldeOpera12 after more than 3 years. Their interface can't even integrate side tabs or turn toolbars on and off.
In a year and a half, Vivaldi, with one-fifth the manpower of Opera or less, has already surpassed them in feature-set, but has a fractionally slower and more bloated product. In fact, on my system, the speed differential is undetectable. YMMV
In few months, with fewer developers still, Brave has launched a Blink window with no features and faulty rendering that runs fast, and is useless for a large segment of the Vivaldi community.
For what they are aiming at, it seems, shockingly, that the technical professionals at Vivaldi took a long and hard look at how to proceed and have adopted a strategy and a technology package which offers them the best of both worlds. Their development speed is lightning fast, the feature-set they are aiming for is quickly taking shape and winning over a significant user base both from OldeOpera and from "modern" browsers, and the developers retain full control over the ultimate shape of the user experience. The ONE hit they have to take by pursuing this path is that performance could be slicker. And for my money, I'd bet it will become slicker, and slicker, over time. Already this snapshot loads pages visibly faster than the last.
One has to wonder why they didn't ask US how to proceed, before they even began coding, yeah? 'Cause certainly we forum commenters who don't build browsers for a living could have put their feet on a better path from the outset.