As Mozilla chose to abandon it, is Firefox still using servo?
Verso – Web browser built on top of the Servo web engine
241–250 of 343 posts
Re: Verso – Web browser built on top of the Servo web engine
#242Earlier quoted context omitted.
> I hope in the process of doing it we will find new ways of doing things. HTML & CSS themselves have become a major bottleneck to quality and creativity. The arcane layout model, the baggage of backwards compatibility, the cognitive dissonance — played out over decades of design-by-committee — between "this is a document engine" and "this is an app engine." The rendering-thread-is-the-main-thread architecture of JS…
I disagree. There has never been a better markup language. HTML allows precise control of atomic elements that make up a component. It has been the best thing for accessibility we ever came up with.
It sounds like we agree about the good parts of HTML.
> There has never been a better markup language.
> It has been the best thing for accessibility we ever came up with.
I observe past tense in both sentences above.
So perhaps we agree, the salient question is: is it the best thing we can come up with? With a focus on the future.
I argue we can do better, while celebrating and building off of what's great about the past & present.[0]
[0] https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text...
Re: Verso – Web browser built on top of the Servo web engine
#243There's still zero day exploits found in chromium, wouldn't using using this put you at a huge risk of running into malware in the wild that this browser can't protect against?
Malware generally can't just "hijack" any arbitrary browser. You have to have exploits for a specific browser / browser family / JS engine. Chromium has defense in depth techniques to try to raise the difficulty bar and to try to limit the fallout of an exploit in various parts of the tech stack, but that still requires a Chrome-specific attack in the first place. Attacks for Safari / WebKit / JavascriptCore would similarly require a different vector for the exploit (even if some techniques are common, the specific details should be quite different).
There is a newer class of generic malware that exploits CPU bugs (e.g. Spectre) - are you perhaps referring to that? If so, that's a fair concern but unlikely to matter much in practice. For Spectre itself, I believe the mitigations were applied within the major JS engines directly (or at least for v8 they were).
Anyway, security issues are best compared when there's a lot more attention to your browser. But given that there's a huge amount of exploits that depend on buffer overflows that are simply impossible in the first place with Rust, it's likely that the browser's likely to mostly suffer only from architectural issues & fewer implementation issues whereas other browsers will still have architectural issues and implementation issues to boot that prevent them from addressing it. Yes, newer browser = likely more immature architecture, but at the same time there's fewer implementation issues to worry about in terms of exploiting architectural issues in the first place.
Re: Verso – Web browser built on top of the Servo web engine
#244Earlier quoted context omitted.
> I hope in the process of doing it we will find new ways of doing things. HTML & CSS themselves have become a major bottleneck to quality and creativity. The arcane layout model, the baggage of backwards compatibility, the cognitive dissonance — played out over decades of design-by-committee — between "this is a document engine" and "this is an app engine." The rendering-thread-is-the-main-thread architecture of JS…
Interesting project. Have you tested any non-XML markup languages for the user interface declaration so that metadata doesn't take as much space as data in Hi {firstName} and also requiring double the number brackets There are modern cleaner markup alternatives like kdl
We chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML.
We predict 95%+ of Pax will be written by machines, especially visual design tools and LLMs, so verbosity becomes less important (LLMs may even benefit from explicit closing tags.) We're innovating on multiple axes, including language, so we chose to make the syntax itself as boring and uninnovative as possible.
Re: Verso – Web browser built on top of the Servo web engine
#245Earlier quoted context omitted.
Interesting project. Have you tested any non-XML markup languages for the user interface declaration so that metadata doesn't take as much space as data in Hi {firstName} and also requiring double the number brackets There are modern cleaner markup alternatives like kdl
We chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML. We predict 95%+ of Pax will be written by machines, especially visual design tools a…
But clarify is exactly what's lacking because it's verbose, it obscures content at no benefit to simple matching bracket highlights
Also, will it be read 95% of the time by machines during design? That's not what the demo shows with the side-by-side xml and output, which I expect is a much more common workflow than 5%
The innovating part is what puzzled me and prompted this question - why cling to the old garbage when you're doing new design?
Re: Verso – Web browser built on top of the Servo web engine
#246Earlier quoted context omitted.
You can compare Servo and Ladybird results on wpt tests here: https://staging.wpt.fyi/results/?product=servo&product=ladyb...
Oh thanks. Seems like Servo is way ahead of LadyBird
It's hard to summarize like that since Ladybird is still ahead in many individual tests including important ones (e.g. acid3 at https://staging.wpt.fyi/results/acid/acid3/numbered-tests.ht...).
Re: Verso – Web browser built on top of the Servo web engine
#247Earlier quoted context omitted.
> I hope in the process of doing it we will find new ways of doing things. HTML & CSS themselves have become a major bottleneck to quality and creativity. The arcane layout model, the baggage of backwards compatibility, the cognitive dissonance — played out over decades of design-by-committee — between "this is a document engine" and "this is an app engine." The rendering-thread-is-the-main-thread architecture of JS…
Don't break backwards compatibility. It's one of the core things that has enabled the web to be as useful as it is. One of the things that draws people in, and keeps them using it. Yes, there are problems with what we have. But if you break compatibility, you'll either not be adopted, or part of the crowd that the audience yells at for taking away their favourite things. You'll kill efforts and bury knowledge bases.
I don't think the world should abandon HTML, nor break backwards compatibility across the HTML spec. The first cars drove on roads designed for horses, and horses are still around. At no time did we gather a committee and decree that horses were deprecated.
Taken to an extreme, "don't break backwards compatibility" has an insidious failure mode, which is "don't innovate." The car could not have come about without a willingness to break backwards compatibility with horse drawn carriages, plows, mills, hitching posts, etc.
The adoption of a radically new technology like this is voluntary, collaborative, and progressive. Provided it offers enough value to exceed the switching costs, there's no need to kill efforts or bury knowledge bases.
Re: Verso – Web browser built on top of the Servo web engine
#248Earlier quoted context omitted.
We chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML. We predict 95%+ of Pax will be written by machines, especially visual design tools a…
But clarify is exactly what's lacking because it's verbose, it obscures content at no benefit to simple matching bracket highlights Also, will it be read 95% of the time by machines during design? That's not what the demo shows with the side-by-side xml and output, which I expect is a much more common workflow than 5% The innovating part is what puzzled me and prompted this question - why cling to the old garbage whe…
Point taken! And yes, especially for developers (our core target demographic,) you are right that hand-writing should account for >5% of code volume.
Syntax is fairly contentious. "One man's trash is another man's treasure," on your note of "old garbage." It's hard to please everyone, however:
We could offer syntax "skins," since the data storage mechanism is a layer separated from the AST (thus different ASTs/syntaxes could de/serialize from the same persisted data.) So folks who want closing tags can have them; folks who want a YAML-like format could have it; folks who want a KDL-like language could have it.
At the language level, Pax's distinguishing characteristic is that it's the union of an expression language and a markup language; this is the reason we couldn't use an off the shelf markup language / parser. But again, KDL or YAML could be extended with PAXEL to make pax-kdl and pax-yaml flavors alongside pax-xml.
We had to start somewhere, and starting as close as possible to the markup lingua franca (HTML) made sense to us. It'd be a dream for Pax to be loved / adopted enough that we or anyone else cares to make a syntax skin.
Re: Verso – Web browser built on top of the Servo web engine
#249Earlier quoted context omitted.
Is swift going to do what flutter and kotlin multiplatform cannot?
It seems something like that already exists: https://skip.tools/blog/scrumskipper I mostly work with flutter but Skip looks pretty cool.
I think Skip is doing a lot of this via transpilation, so I think you're expected to still write a lot of Android / Kotlin code.
Re: Verso – Web browser built on top of the Servo web engine
#250Earlier quoted context omitted.
There's been a lot of work on this in the last few years with Windows support, preliminary Android support is also being worked on and should appear at some point in Swift 6.
Is swift going to do what flutter and kotlin multiplatform cannot?
There probably won't be a cross-platform UI layer and many Apple frameworks won't work, although apparently the Foundation Swift rewrite already works. For a lot of companies though, simply being able to share business logic will be a big plus. At my current company we have a lot of talented Swift people and existing code written in the language so being able to share anything would be a huge advantage.
I'm biased but I personnaly find the language really productive to work with, runs fast enough for my needs and let's me target more and more platforms.