Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Verso – Web browser built on top of the Servo web engine

github.com

Post reply on HN
Print view View original

171–180 of 343 posts

Re: Verso – Web browser built on top of the Servo web engine

#171

Post by Izkata »

moffkalast wrote: post #143
culi wrote: post #64

Earlier quoted context omitted.

I'm assuming that's in reference to these tests? https://wpt.fyi/results/?label=experimental&label=master&ali... For comparison, there are 1.9 million tests Chrome passes 97.14% Edge passes 96.98 Firefox passes 95.96 Safari passes 95.22 I wonder where Ladybird stands in this

Edge being a Chromium based browser and somehow scoring lower is genuinely hilarious. Congrats Microsoft, on taking something almost perfect and only slightly running it.

If you scroll down to the test groupings, there are also several where Edge does better than Chrome (such as css, html, websockets, workers)

Re: Verso – Web browser built on top of the Servo web engine

#172

Post by Izkata »

jccalhoun wrote: post #72
StrauXX wrote: post #37

Earlier quoted context omitted.

There is old.reddit.com, reddit.com and new.reddit.com. new.reddit.com is not the same site as reddit.com!

It is so crazy. I normally use "reddit.com" but a few weeks ago i followed a link to an article on "old.reddit.com" and saw I had notifications. I clicked the item and it was all notifications from days ago. So the read status of notifications on old reddit and current reddit aren't linked?

They are, but you don't always see all of them on the current reddit. Never figured out the pattern.

Re: Verso – Web browser built on top of the Servo web engine

#173

Post by gkbrk »

pityJuke wrote: post #137
klohto wrote: post #113

Earlier quoted context omitted.

Enlighten us which BigCo gave Ladybird money?

Shopify [0] [0]: https://ladybird.org/#gi

Why is it weird that a company that built their entire business on the web wouldn't want there to be a web browser monopoly controlled by an advertising company? Shouldn't you fund projects that will be beneficial for your company in the future?

Re: Verso – Web browser built on top of the Servo web engine

#174

Post by ezfe »

worik wrote: post #166
ninkendo wrote: post #148

Earlier quoted context omitted.

> As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted Swift Concurrency is the replacement for Dispatch and has been around since Swift 5.5 in (IIRC) 2021. It’s a completely different system, uses lightweight tasks (a la tokio in rust, or goroutines in go, etc), has a concept of “Sendable” for thread-safe…

> Swift 5.5 didn’t get all the way towards rust-style data race When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really. I think the main point is that Swift is a fai…

Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure.

Swift has async/await built into the language with many compile time guarantees of thread safety.

Re: Verso – Web browser built on top of the Servo web engine

#176

Post by porphyra »

kwhitefoot wrote: post #158

Does this do anything to improve the browser as a user agent? That is an agent that obeys the user over the server. None of the current browsers are user friendly and none are scriptable except by experts wielding large external programs. It should be possible to write a simple shell script to navigate the web, to log in to web sites, to extract information. Or something like Visual Basic.

Puppeteer, which recently added official Firefox support, allows you to write a simple script to navigate the web and such. [1]

btw using the phrase "user agent" in the context of browsers is mildly confusing as it is a specific jargon term.

[1] https://hacks.mozilla.org/2024/08/puppeteer-support-for-fire...

Re: Verso – Web browser built on top of the Servo web engine

#177

Post by worik »

afavour wrote: post #167
worik wrote: post #144

Earlier quoted context omitted.

> and has better ergonomics than C++ It is unfair to compare a twenty first century language with one from the 1980s Rust is the proper comparison The only advantage Swift has is an easier learning curve , but the ergonomics of Rust are far superior than Sift's

It’s not really a question of fairness. The existing codebase is C++, the new stuff is Swift. Hence the comparison. I’ve written both Rust and Swift while being an expert in neither. I wouldn’t say Swift has no pluses in comparison, reference counting is often a lot easier to reckon with than lifetimes, for one. I’m actually curious what a large multithreaded Swift codebase looks like with recent concurrency improvem…

> Rust’s async story isn’t actually that great

I agree. People's perspectives differ. It abhor `async/await` in Rust. It has poisoned the well IMO for asynchronous Rust programming. (I adore asynchronous programming - I do not need to pretend my code is synchronous)

But that is taste, not a comment on poor engineering!

The lack of the borrow checker in Swift is what makes it approachable for newcomers, as opposed to Rust which is a harsh mistress.

But reference counting is such a silly idea. Swift really should have a garbage collector with a mechanism or subset to do that very small part of programming that cannot be done with a garbage collector. That would have been design!

I fear that Swift is going to get a borrow checker bolted on - and have the worst of both worlds....

Re: Verso – Web browser built on top of the Servo web engine

#178

Post by phil294 »

38 wrote: post #170
hanniabu wrote: post #169

Earlier quoted context omitted.

A chromium fork is not chrome. Why assume a fork has to accept upsteam changes?

why fork chrome rather than another browser, or starting from scratch?

Because it's infinitely less work than starting from scratch. It's a valid argument.

Re: Verso – Web browser built on top of the Servo web engine

#179

Post by ibeff »

kwhitefoot wrote: post #158

Does this do anything to improve the browser as a user agent? That is an agent that obeys the user over the server. None of the current browsers are user friendly and none are scriptable except by experts wielding large external programs. It should be possible to write a simple shell script to navigate the web, to log in to web sites, to extract information. Or something like Visual Basic.

"Let me throw shade on this open source project that does incredibly ambitious thing X and that tons of people are devoting lots of time to, by suggesting they should instead do this other esoteric thing Y that 99% of users don't care about but that I, the entitled power user, think they should be doing instead."

Re: Verso – Web browser built on top of the Servo web engine

#180

Post by worik »

ezfe wrote: post #174
worik wrote: post #166

Earlier quoted context omitted.

> Swift 5.5 didn’t get all the way towards rust-style data race When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really. I think the main point is that Swift is a fai…

Okay, so you're saying you don't know what Swift Concurrency is and they say Swift is a failure. Swift has async/await built into the language with many compile time guarantees of thread safety.

> Okay, so you're saying you don't know what Swift Concurrency

I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift.

> language with many compile time guarantees of thread safety

From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption....) at all.

Async/await is always a bad idea, and without a garbage collector it is a nightmare (look at the mess Rust has gotten into). Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.

Post reply on HN