[HN Gopher] Verso - web browser built on top of the Servo web en...
___________________________________________________________________
Verso - web browser built on top of the Servo web engine
Author : pabs3
Score : 555 points
Date : 2024-08-11 12:34 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| wongarsu wrote:
| According to https://servo.org/about/ Servo currently passes ~60%
| of the web platform tests. Does anyone have experience how far
| that subset gets you on the open internet?
| timschmidt wrote:
| Hackernews and LWN render reasonably correctly in recent
| nightlies. Reddit does not.
| jsheard wrote:
| New Reddit or Old Reddit?
| timschmidt wrote:
| New Reddit. Old reddit seems to work OK.
| spankalee wrote:
| The newest Reddit - not the React version, but the Lit
| version that's replacing it - uses very, very modern HTML
| and JavaScript. I'd love to see Servo get to the point of
| rendering it correctly!
| satvikpendem wrote:
| How many times are they going to rewrite the site? And
| how can you see the Lit versus React version, is there
| another link for it?
| StrauXX wrote:
| There is old.reddit.com, reddit.com and new.reddit.com.
| new.reddit.com is not the same site as reddit.com!
| CryZe wrote:
| new.reddit.com seems to be an older layout than just
| reddit.com for me, one where most stuff still works (like
| video embeds).
| timeon wrote:
| At least it is faster and seems to be less bug-y.
| culi wrote:
| TIL. new.reddit seems to be a return to old.reddit in a
| lot of ways. It also seems really really fast unlike the
| current www.reddit. If they remove some annoying ads I
| might even be convinced to stop using old.
| bee_rider wrote:
| The only downside is that new is still being developed.
| Old is nice because it is shielded from their post-
| success incompetence. Whatever bad ideas they decide to
| implement will hit new first.
| oblio wrote:
| new.reddit seems almost... sane. Like they kicked out
| whoever pushed/implemented reddit aka the current version
| and figured out that old.reddit had a lot of virtues.
| jccalhoun wrote:
| 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?
| Izkata wrote:
| They are, but you don't always see all of them on the
| current reddit. Never figured out the pattern.
| spankalee wrote:
| Most pages, logged-in and logged-out, seem to be using
| the Lit version for me. I don't think it contained many
| visual changes, so you have to look for the presence of
| web components.
| hypeatei wrote:
| Pretty amazing how a company can overengineer a basic
| feed that displays images and text (and ads). New Reddit
| is a dumpster fire, can't imagine another rewrite is
| going to fix it.
| 42lux wrote:
| Yeah, I've never thought anyone could build a video
| player worse than realplayer but they achieved the
| impossible.
| throwaway894345 wrote:
| Yeah, one of the weirder things is that if someone blocks
| you, you are not allowed to reply to _any_ comment in the
| thread (for example, if someone posts a toplevel comment
| and doesn't reply to anything, and you reply to some
| comment a dozen layers below and have an exchange with
| some third party, if the toplevel commenter blocks you,
| you can't reply to anything including comments left by
| others in response to your own comment) and you get a
| generic "internal server error"-type pop up with no
| information about why the request failed.
|
| This is most likely a server "feature" and thus a rewrite
| of the frontend won't fix it but it seems like at very
| least the frontend could display a sane error message
| (assuming the backend forwards some information about the
| cause of the error).
| d1sxeyes wrote:
| New Reddit rendering "properly" is as useful as a chocolate
| fire guard. Do you want to view this content on the app?
| You Can Only View This Content In The App, THE APP is the
| WAY, JUST FUCKING DOWNLOAD THE APP!!!
|
| At least on mobile.
| RamRodification wrote:
| You will be registered, email verified and data mined or
| you can just go straight to hell.
| moffkalast wrote:
| Me: Okay fine, I'll download RedReader.
|
| Reddit: Wait no.
| deergomoo wrote:
| Can you imagine being on the team responsible for the
| mobile web Reddit experience? Having to implement a
| feature that tells every user, repeatedly, that their
| work is subpar and to please use something else.
| cge wrote:
| Itappearsthatspacesdon'tworkformewhentyping,butitotherwisesee
| msthatevencommentingonhnworksinVerso.Editingappearstoworkaswe
| ll,thoughlinebreaksdon't(maybebecauseofspaces...).
|
| Edit (with Firefox): the above text is from Verso. Logging in
| works (though the session is not stored across restarts), as
| does both commenting and editing comments. Since space can't
| seem to be entered, word wrapping doesn't work with text
| entered in Verso, though it does seem to work when there is
| text with spaces (eg, this edit). A cursor also doesn't
| appear for me, making editing a challenge.
| nicoburns wrote:
| I have a branch here
| https://github.com/servo/servo/pull/32619 that makes this
| significantly better (by greatly improving flexbox support
| and adding CSS grid support).
| culi wrote:
| 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
| fabrice_d wrote:
| You can compare Servo and Ladybird results on wpt tests here:
| https://staging.wpt.fyi/results/?product=servo&product=ladyb.
| ..
| culi wrote:
| Oh thanks. Seems like Servo is way ahead of LadyBird
| littlestymaar wrote:
| Which isn't that surprising given it has been underway
| for much longer, and as built with people with actual
| browser engine experience.
|
| Ladybird isn't _that_ bad in comparison.
| kevsim wrote:
| FWIW Ladybird is also built by people with actual browser
| engine experience
| peoplefromibiza wrote:
| Ladybird was mostly developed by one person (Andreas
| Kilng) with no financing whatsoever ,Servo was mostly
| developed by a team who was being paid with Mozilla
| money.
| RandomThoughts3 wrote:
| libweb was started in 2019. Anyway, I'm really sour that
| 90% of the discussion on a thread about the incredible
| project that is Servo are wasted on Ladybird.
| moffkalast wrote:
| 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.
| Izkata wrote:
| If you scroll down to the test groupings, there are also
| several where Edge does better than Chrome (such as css,
| html, websockets, workers)
| mminer237 wrote:
| In my tests, it's pretty unusable atm. Probably half of
| websites render very wrong and servo crashes nonstop.
| Galanwe wrote:
| It cannot crash its written in Rust.
| IshKebab wrote:
| Rust can absolutely crash. It crashes ("panics" in Rust
| terminology) in a memory safe way but it's still a crash
| (please don't try to redefine the word "crash" to be more
| specific than it actually is).
|
| And Rust can still have unsafe code so it can crash in
| memory unsafe ways too (though it is very unlikely unless
| you're doing things very wrong).
| littlestymaar wrote:
| > And Rust can still have unsafe code so it can crash in
| memory unsafe ways too (though it is very unlikely unless
| you're doing things very wrong).
|
| From when I grokked the code a bit (back in 2017) there
| was a non trivial amount of unsafe code, especially
| related to integration with SpiderMonkey (the js engine)
| so it wouldn't even be particularly surprising to see
| segfaults in servo, unlike most rust projects.
| jeroenhd wrote:
| Most crashes I've seen trying this out seem to stem from
| panics. As an end user I would call that a crash, but
| from a programmer standpoint you could say it's an
| unexpected normal shutdown.
| jeroenhd wrote:
| I just compiled it following the Linux instructions. I honestly
| thought Servo was better than this. Maybe there's something up
| with the Linux builds? I'd much rather use Ladybird in all its
| pre-beta glory than this.
|
| There are two window title bars, one by the OS and one from the
| application. The text in the URL bar is misaligned and is
| shifted down by half its height. There's a black bar between
| the browser chrome and the web view. Entering a domain name
| without http or https and hitting enter crashes the entire
| application.
|
| Clicking refresh spawns a new window that sort-of-but-not-
| really shares the same website being rendered.
|
| Very few websites work. Anything with a cookie banner just
| plain breaks. I can't tell how to edit the URL bar after
| failing to load/loading a page. Google.com is very wonky. The
| search box on Google doesn't seem to take space bar for some
| reason.
|
| For the websites that do work, rendering is very fast and
| scrolling is pretty smooth. I can see the potential, but
| there's a lot of work to be done.
| AndyKelley wrote:
| If it's anything like learning Japanese, it gets you
| approximately nowhere.
| ksec wrote:
| So we will, in ~5 years time have two new browser, one in Rust
| and one in Swift.
|
| I hope in the process of doing it we will find new ways of doing
| things.
| jitl wrote:
| What swift browser are you referring to?
| BadHumans wrote:
| Ladybird has started using Swift.
| monacobolid wrote:
| For UI portion of their Mac OS version? What am I missing?
| Wowfunhappy wrote:
| For everything. Swift is--at least in theory--a general
| purpose language, it's not exclusively for Apple
| technologies.
|
| > First off, Swift has both memory & data race safety (as
| of v6). It's also a modern language with solid
| ergonomics.
|
| > Something that matters to us a lot is OO. Web specs &
| browser internals tend to be highly object-oriented, and
| life is easier when you can model specs closely in your
| code. Swift has first-class OO support, in many ways even
| nicer than C++.
|
| > The Swift team is also investing heavily in C++
| interop, which means there's a real path to incremental
| adoption, not just gigantic rewrites.
|
| https://x.com/awesomekling/status/1822236888188498031
|
| https://news.ycombinator.com/item?id=41208836
| sheeshkebab wrote:
| Swift is useless outside of macOS/iOS dev... the thing
| doesn't even have namespacing. I don't know for what
| reason someone would use it outside for Apple
| environment.
| factotvm wrote:
| You can disambiguate two types with the same name from
| different libraries, e.g. `Factotvm.URL` and
| `Foundation.URL`. Do you mean something more full-
| featured? You are not prefixing types with three letters,
| if that's what you think has to be done.
|
| I don't know if it's still the case, but there was an
| annoyance where you couldn't have a type with the same
| name as the package. But that is hardly a lack of
| namespaces.
| refulgentis wrote:
| You're right but this touches the hot stove.
|
| HN majority doesn't like hearing that ladybird et al
| might just be wandering around, even if the goal is
| catnip for the bleachers, and we should be skeptical
| _this_ is the year of multiplatform Swift, because it
| wasn 't last year if you actually tried it. Or the year
| before last. Or the year before that. Or the year before
| that year. Or the year before that one.
| afavour wrote:
| I'm slightly more ambivalent than you about it. Swift
| _is_ a nice language and has better ergonomics than C++
| and I imagine a Swift codebase might find more
| contributors than a C++ one (maybe I'm wrong about that!)
|
| I also think it's separate from the dream of
| "multiplatform Swift". For that you need a healthy
| package ecosystem that all works cross platform, Swift
| doesn't have that. But a lot of Ladybird is written at a
| low enough level that it won't matter so much.
| refulgentis wrote:
| Problem is Swift engineer supply is low, there's not a
| viable business case to learn Swift because it's not
| _actually_ viable cross-platform for development unless
| you have $X00 million to throw at your macOS /iOS team to
| build it from scratch, platform by platform (to wit,
| sibling comment re: Arc Browser)
|
| So best case we're looking at: Swift isn't ready yet, the
| next major version will be, and we can't build UI with
| it, so we'll put in the effort in to bootstrap a cross-
| platform ecosystem and UI frameworks. Or maybe we'll just
| do our business logic in it? It's a confusing mess that
| is irrational. Even with great blessings of resources.
| ex. $X00M that Arc has obtained one incremental platform
| after a year. And "all" they had to do was Swift bindings
| for WinRT and connect it to the existing C++ engine.
|
| All of this is easy to justify if we treat it as an
| opportunity to shoot for how we wish software could work
| in theory, instead of practice. I hope I'm wrong but
| after being right the last few years, I'm willing to say
| it's naive wishcasting out loud, even though its boorish.
| I see it as unfortunately necessary, a younger me would
| be greatly misled by the conversations about it on HN.
| "We've decided to write the browser in Swift!" approaches
| parody levels of irresponsible resource management and is
| a case study in several solo engineer delusions that I
| also fall victim to.
|
| It's genuinely impossible for me to imagine anyone in my
| social circle of Apple devs, going back to 2007, who
| would think writing a browser engine in Swift is a good
| idea. I love Swift, used it since pre-1.0, immediately
| started shipping it after release, and that was the right
| decision. However, even given infinite resources and
| time, it is a poor fit for a browser engine, and an odd
| masochistic choice for cross-platform UI.
| jll29 wrote:
| I wonder what convinced Andreas Kling to abandon his own
| language Jakt [1] in favour of Swift.
|
| In the long run, it would be good to have high-level
| languages other than Java that have garbage collection
| (at least optionally) and classes, and that are still
| capable of doing cross-platform system development. I
| don't know if Swift fits that bill, besides cross-
| platform ecosystem (a la Java), submitting the language
| for ISO standardization (not just open sourcing one
| implementation) would be a good indication of being
| serious about language support.
|
| [1] https://github.com/SerenityOS/jakt
| refulgentis wrote:
| You might be powerfully dry here, imparting a Zen lesson.
| If not, or if you, dear reader, doesn't see it: it is
| worth meditating on that there was a language, an OS, and
| a web browser. Then, on common characteristics in
| decision-making that would lead to that. Then, consider
| the yaks that have to be shaved, the ISO standardization
| / more than one implementation hints at this.
| robryan wrote:
| One of the major differences between ladybird as part of
| serenity and ladybird the separate project is using 3rd
| party libraries. When what you are building are is for
| fun and you build everything yourself it makes sense to
| also build a language.
|
| Ladybird as a separate project has the goal though of
| something usable in the shorter term. So similarly with
| switching to 3rd libraries for things I don't think it
| makes sense to spend potentially years first building the
| language before building the browser.
| worik wrote:
| > 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
| afavour wrote:
| 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 improvements. Rust's async story isn't
| actually that great.
| worik wrote:
| > 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....
| charrondev wrote:
| I mean this year we did have the porting of Arc browser
| to windows. I use it my gaming PC and it is starting to
| feel like it has a similar level of polish to the MacOS
| version.
|
| https://speakinginswift.substack.com/p/swift-meet-winrt
|
| https://speakinginswift.substack.com/p/swift-tooling-
| windows...
|
| Now that's not an engine but the UI.
| oblio wrote:
| Objective-C had some minimal adoption outside of Apple
| (probably due to NextStep nostalgia), so if Objective-C
| managed to get some traction, Swift will do it to,
| probably.
|
| However, Apple's history is very much stacked against
| Swift becoming a mainstream language outside of Apple's
| platform.
| sesm wrote:
| > First off, Swift has both memory & data race safety (as
| of v6)
|
| But v6 is not released yet, right?
| wahnfrieden wrote:
| next month
| worik wrote:
| > > First off, Swift has both memory & data race safety
| (as of v6) > But v6 is not released yet, right
|
| 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
|
| I am well clear of the Apple development world now (thank
| goodness) but the tools were of very poor quality, albeit
| very nice looking, as of this time last year
|
| For the sake of my friends still in the world I hope
| Swift 6 is better, but I fear the dumpster fire that is
| Xcode is too far gone to rescue.
|
| The comparison with Rust demonstrates the utility of
| "design by committee ". Rust is far from perfect, but
| feels like the future where Swift feels like warmed up
| Objective C
| ninkendo wrote:
| > 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-safety a la rust's Send,
| async/await, and a native `actor` type, among other
| things.
|
| Swift 5.5 didn't get all the way towards rust-style data
| race safety due to a few things they had to make warnings
| instead of errors (to avoid breaking existing code), and
| introducing keywords like `@preconcurrency` when
| importing frameworks that predate Swift Concurrency, to
| facilitate incremental adoption. They've also been adding
| more checks in each minor release to tighten things up.
|
| IIUC Swift 6 is mainly going to turn all the warnings
| into proper errors and tweak some defaults so that you
| get proper data race protection on a default compile.
|
| Point is, it's totally inaccurate to say that Dispatch
| Queues is all that exists in Swift 5. You've had much
| better stuff for a while now (although SC still has a ton
| of issues worth discussing.)
| worik wrote:
| > 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 failure.
|
| "although SC still has a ton of issues worth discussing"
| once I would have cared, but this year (decade, century)
| I am just very glad putting meat in my fridge no longer
| depends on those rouges from Apple who treated me so
| badly when I was sweating so hard making software for
| their platforms (not to mention paying them so much
| money). In 2024, for a company like Apple, for their
| flagship developer offering, why would anyone still have
| "a ton of issues" with it?
|
| Apple is now an example of why popularity is a terrible
| metric to estimate quality of technical offerings. What a
| shame. How far the mighty have fallen
| ezfe wrote:
| 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.
| worik wrote:
| > 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.
| cube2222 wrote:
| > Whatever, async/await is no replacement for parallel
| programming with threads.
|
| Is it not for the vast majority of use-cases?
|
| Sure, you can use async/await without parallelism, via a
| single-threaded runtime to just get single-threaded
| concurrency, but with a multi-threaded worker-pool
| async/await-like tasks or fibers I think mostly cover the
| use-cases you'd have for parallelism?
|
| You have to make sure that you e.g. don't starve other
| tasks via having no yield points in a task that does a
| lot of computation (if you're doing cooperative tasks
| which Swift is doing iirc), but that's not a big one, and
| can mostly be solved by the runtime too (e.g. Go had
| cooperative fibers for a long time, until they chose to
| introduce preemption).
| askonomm wrote:
| For non-UI portions as well, more from the horses mouth:
| https://x.com/awesomekling/status/1822236888188498031
| bobajeff wrote:
| Actually, it sounds like they only just decided to use it
| in the future once Swift 6 is released. I would guess much
| of it will still be in C++ for a while.
| conkeisterdoor wrote:
| Most likely Arc (https://arc.net/)
| actinium226 wrote:
| Arc is a fork of Chrome if I'm not mistaken
| hypeatei wrote:
| Arc is based on Chromium for anyone wondering. I believe
| part of the UI is written in Swift but the engine isn't.
| steve_adams_86 wrote:
| I like Arc and use it (I actually never stopped using it
| after the first time I opened it), but I wish they
| weren't building off of Chrome.
| pndy wrote:
| Can user enhance it with extensions?
| clot27 wrote:
| Ladybird
| ChocolateGod wrote:
| I'd like to see Swift adopted more on non-Apple operating
| systems, some of the recent GTK apps written in Swift are
| pretty cool.
| nbbaier wrote:
| What apps are you thinking of? Curious to check them out.
| jamil7 wrote:
| 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.
| synergy20 wrote:
| sadly Gtk's support for MacOS is best efforts only
| ninepoints wrote:
| I'd really rather not, personally. All my Swift experiences
| have been fighting the abysmal compilation times.
| amelius wrote:
| The problem with these smaller webbrowsers is that you have
| nobody to sue if the browser turns out to leak your personal
| information or credentials etc. Therefore it is better to stick
| with browsers made by big corporations.
| alex_duf wrote:
| This is true for any software though, so if we push that
| reasoning to its extreme, no one should ever use any free and
| open source software, which I find a little bonkers.
| amelius wrote:
| Except browsers are more likely to leak your personal info
| than, say, a vector drawing program.
| swiftcoder wrote:
| I'm curious what exactly you think suing Google or Apple in
| such a case would accomplish?
|
| On the (long) odds that you get all the way to a successful
| class-action suit, the lawyers get rich, and the class
| members eventually end up with a free year of credit
| monitoring
|
| (we have seen this over and over again in settlements for
| high-profile data breaches)
| RussianCow wrote:
| Are you really planning on suing Google for leaking personal
| info via Chrome?
| ddtaylor wrote:
| I'm fairly certain those big corporations are stealing that
| same information just paying fines and PR people to manage
| the backlash.
| solardev wrote:
| Sounds like a good way to get a $2 coupon off your next
| Google/Microsoft service after the class action resolves ten
| years from now.
| wslh wrote:
| Is there a good software engineering resource about the
| complexity of a web engine? I mean, we all know that is complex
| but what are the critical areas. Performance is one,
| compatibility another.
| abhinavk wrote:
| https://robert.ocallahan.org/2024/06/browser-engine.html
|
| P.S.: This specific post was written in response to
| announcement of Ladybird.
| jll29 wrote:
| This is a good post; as far as Ladybird is concerned while
| they may have started things as fun, they seem to have
| taken a turn towards seriousness recently.
| clot27 wrote:
| Isn't servo is in development for more than a decade? They
| already have legacy code before it even became stable, lol.
| another-dave wrote:
| What do you mean by legacy code here?
| orangepanda wrote:
| Any code is legacy code once pushed upstream
| jhatemyjob wrote:
| Not only that, but Mozilla all but killed the project in 2020
| https://www.zdnet.com/article/mozilla-lays-off-250-employees...
|
| The project is as good as dead. You'd be insane to build
| something on top of it. Then again, you'd be insane to think
| Rust is more capable than C, but that's a whole other topic
| that I have no interest in discussing in an upvote-ordered
| comment tree owned by the guy who apparently has nothing better
| to do than take pot shots at the rainman.
| Aerbil313 wrote:
| This is wrong. Servo development has picked up steam after
| merged into Linux Foundation, and multiple increasingly used
| Rust projects are all betting on Servo for the long term:
| Dioxus, Tauri, some others I forgot.
| jhatemyjob wrote:
| https://youtu.be/1vBesOFURek
| ummonk wrote:
| As opposed to Blink / WebKit, which ultimately descend from the
| 25 year old KHTML?
| mariusor wrote:
| I'm happy to see work being done in integrating Servo into custom
| browser chrome. My dream browser would be a servo based
| Qutebrowser. I can only hope.
| dijit wrote:
| I have the same dream, QTWebengine is super cool (chrome based
| as of version 4 afair) but seems to limit Qutebrowser a fair
| bit.
| erlend_sh wrote:
| In other exciting Servo-browser news, Servo and Redox OS have
| submitted a joint proposal to fund the porting of SpiderMonkey
| and WebRender to Redox: https://www.redox-os.org/news/this-
| month-240731/
| ape4 wrote:
| Typo dont' -> don't
| revskill wrote:
| Actually i prefer the dont', easy to comprehend and spell.
| azangru wrote:
| Wouldn't dont be even easier?
| jeffhuys wrote:
| Wow. Every single day I'm still amazed by people.
| rubymamis wrote:
| The x64.dmg release[1] requires macOS 13+, why?
|
| [1] https://web.crabnebula.cloud/verso/verso-nightly/releases
| Keyframe wrote:
| it's five years old release. Sounds reasonable or you're
| expecting release to work all the way back to commodore 64?
| abhinavk wrote:
| macOS 13 was released in Q4 2022.
| Keyframe wrote:
| My bad, I was thinking 10.13.
| mdaniel wrote:
| I'd hypothesize it's due to https://github.com/versotile-
| org/verso/blob/07a88a86347c6763... and I thought maybe that was
| the lowest GH offered since they used an actual number versus
| "-latest" but no, GH does offer 12
| https://docs.github.com/en/actions/using-github-hosted-runne...
|
| Since they already went to the trouble of writing the GHA, I
| just downgraded and gave it a whirl and it both completed and
| the resulting artifact launched a-ok on my 12.7.6 x86_64:
| https://github.com/mdaniel/verso/actions/runs/10341237698/jo...
|
| I'm posting this reply from that build, although I had to
| compose the answer over in FF because the textarea doesn't
| scroll :-D
| rubymamis wrote:
| Thanks a lot! It works, but it's pretty unusable, even Google
| doesn't work and just hangs (like almost all other sites).
| Only HN seemed to work.
| IshKebab wrote:
| Apple makes it relatively difficult to support old versions of
| their OS. You pretty much have to keep an old computer around
| and just not update its software. So it might not have been a
| conscious choice, rather they just didn't go to the extra
| effort to support older versions.
| nequo wrote:
| I hope that this project will succeed.
|
| Incidentally, Verso is also the name of Lean 4's DSL for
| typesetting documentation.[1] We are running out of words in the
| English language.
|
| [1] https://github.com/leanprover/verso
| mroche wrote:
| There are two simple solutions to this:
|
| 1. Translate the word to another language.
|
| 2. Get creative and make up an original name. Mixed
| translations, word-bashing, not-actual-words, there's a lot of
| options!
|
| Okay, so the latter isn't _super_ easy but can be a lot of fun
| to do!
|
| In this case, it seems like a play on the core dependency name
| than choosing the actual word of "verso": servo -> verso.
| 627467 wrote:
| > we are running out of words
|
| in a 1000 years we'll be making this observation across the
| galactic internet.
| Emma_Goldman wrote:
| It's also the name of the most successful left-wing press in
| the English-speaking world:
|
| https://www.versobooks.com
| Avshalom wrote:
| Verso is a latin word.
| nequo wrote:
| It's also English. It means the left side page of a book.
|
| https://en.wiktionary.org/wiki/verso#English
| franzkappa wrote:
| Still latin...
| F3nd0 wrote:
| And of course, they've gone with a pushover licence. Or two of
| them, it looks like.
| ericyd wrote:
| It might be the head cold I'm recovering from, but it took me
| about 3 passes to comprehend their tagline:
|
| > A web browser that plays old world blues to build new world
| hope
| NBJack wrote:
| I'm healthy at the moment and I'm still not sure I understand.
| Poetic perhaps, but a bit nonsensical.
|
| Old world as in the past? Older technology? Older ideas? Bad
| ideas?
|
| Blues, as in the musical genre? Or the feeling it conveys? Are
| we riffing on it here? Plays strongly suggests music, but the
| blues originated from specific cultural roots tied to the end
| of slavery (which is implied even further by 'old world
| blues').
|
| New world, as in a better tomorrow, or something more akin to a
| new world order?
|
| Hope I think I get.
| onli wrote:
| Sounds like a Fallout New Vegas reference to me. Or maybe it is
| referencing what FNV was referencing?
| tcper wrote:
| Have a read about Servo, it is binding with SpiderMonkey as JS
| engine.
|
| Is there some chance, that servo decomposed from SpiderMonkey? If
| it is not, I don't think anyone can tell difference between
| firefox and other browser use Servo.
| culi wrote:
| There's a lot more to a browser than the JS engine. And in
| general, we would want all of the browsers JS engines to be
| essentially the same. I think starting with an existing engine
| is the most logical approach
| abhinavk wrote:
| True but at this point of time, Firefox and Servo are using
| the same CSS engine, same JS engine and same compositor and
| rendering engine.
| fabrice_d wrote:
| That still leaves you with at least the layout engine, all
| the DOM apis, all the networking, multi process model &
| sandboxing, web extensions support, that are different
| implementations.
| akira2501 wrote:
| > we would want all of the browsers JS engines to be
| essentially the same
|
| You say until there is a CVE found.
| tvshtr wrote:
| They plan to abstract it (work is underway) to make it even
| possible to use chromium's js engine.
| https://www.phoronix.com/news/Servo-JavaScript-Engine-
| Modula...
| jijojohnxx wrote:
| Interesting perspective!
| hanniabu wrote:
| There'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?
| 38 wrote:
| I agree, no one should ever bother writing a new browser again,
| too risky. We should just use chrome forever
| hanniabu wrote:
| Why not just fork chromium with all the Google
| analytics/tracking removed?
| devsda wrote:
| There's ungoogled chromium for that.
|
| Also doing that doesn't solve the standards problem we
| currently have.
|
| Google is able to push through any "standard". And those
| standards "unwittingly" help them maintain their search/ad
| dominance or prevent competitors. For example see manifest
| v3 or FloC (a.k.a Topics API).
|
| Once they gain enough traction and become indispensible,
| you either implement them or risk losing users.
| hanniabu wrote:
| But why would this change with a new browser written from
| scratch?
| 38 wrote:
| are you being intentionally ignorant? the more browsers
| in popular use, the less control each has. currently
| Chrome has more usage than the other browsers combined:
|
| https://gs.statcounter.com/browser-market-share
|
| which means Google has significant control over web
| standards
| hanniabu wrote:
| A chromium fork is not chrome. Why assume a fork has to
| accept upsteam changes?
| 38 wrote:
| why fork chrome rather than another browser, or starting
| from scratch?
| phil294 wrote:
| Because it's infinitely less work than starting from
| scratch. It's a valid argument.
| 38 wrote:
| infinitely doesn't mean what you think it means
| hanniabu wrote:
| Less work, more features, proven, security lindy
| 38 wrote:
| good point about the lindy
| swiftcoder wrote:
| Maybe if Chromium was written in a memory-safe language there
| would be fewer zero-days?
| fabrice_d wrote:
| Yes, and that's why Chromium moved to allow Rust code (pretty
| much like they did for Android).
| mrkramer wrote:
| They said some of the code can be rewritten in Rust but
| majority of the code cannot. Therefore they are stuck with
| C++ forever. Scary thing to think about.
| bee_rider wrote:
| I somewhat wonder--Firefox and Chrome are in a constant race to
| have the best JavaScript performance.
|
| In general, the sites I want to browse use minimal JavaScript,
| prudently, if at all, just where it is strictly necessary to
| add little dynamic features. So, I don't really care about
| JavaScript performance at all.
|
| Optimization sometimes introduces additional complexity, which
| might open up the possibility of security holes (at least it
| seems to be the case to me, as a not-security-related
| programmer. I don't know anything about security on a technical
| level, so I'm interested in other perspectives on this from
| people that actually work in those sorts of fields). I wonder
| if there's room for a browser engine that ditches performance
| and just focuses on correctness and safety.
|
| Rendering documents ought to not be computationally intensive,
| right? Advertisements of blazing fast JavaScript performance
| make me worry what corners have been cut.
| hanniabu wrote:
| > wonder if there's room for a browser engine that ditches
| performance and just focuses on correctness and safety
|
| Isn't this just the noscript, which breaks most sites to a
| degree where they're impossible to use or load?
| bee_rider wrote:
| Haha, well that's what I use now. I think it is the
| opposite though. I'd like a JavaScript implementation that
| doesn't break any sites, but which makes absolutely no
| security compromises, even if that means they have to give
| up a lot of performance.
|
| Sometimes, I just have to load a site that has JavaScript
| running. Or is unfortunate, but some work sites don't work
| without it, etc. I'm fine with those sites being slow (I'll
| minimize my use of them naturally), but totally blocking
| them is slightly inconvenient.
| sfink wrote:
| Disabling (all of) the JITs is a decent approximation of
| this. It's very site-dependent as to how much of a
| performance impact it makes, but for many sites it'll be
| fine.
|
| Obviously this isn't the same as making "absolutely no
| security compromises", but in practice most JS-related
| security exploits go through the JIT iiuc. Your JS will
| be executed with a safe interpreter, where by "safe" I
| mean the dispatching and basic value manipulation are
| going to be simple enough to be bulletproof, and also
| slow enough to prevent most timing attacks. The
| underlying implementation of all of the built-in methods
| is still going to be more vulnerable, but those tend to
| be relatively safe as compared to JIT-optimized versions
| of them. They also don't change much, so have been tested
| for much longer as compared to the JITs that tend to get
| refactored and rewritten relatively frequently.
| fngjdflmdflg wrote:
| I assume he means something like turning off the JS JIT,
| not turning off JS completely. IIRC iOS turns off Safari's
| JIT when in lockdown mode. Ladybird browser also abandoned
| its JIT apparently due to security concerns. JS JIT is one
| important example but also in general if you write your
| code to only focus on correctness and not performance then
| you will get safer code (all else being equal).
| cwalv wrote:
| That arguably ignores correctness completely
| TheRealPomax wrote:
| It'd be nice if people stopped recommending "yet another new and
| exciting package manager for Windows" that you have no idea of
| whether you can trust it or not.
|
| Git, Python, llvm, cmake, and curl all have perfectly normal
| windows installers available from their own websites, and if
| you're a programmer who has to, or chooses to work on Window,
| it's a good bet you already have either most or all of these
| already installed, making the job of completing your bonus
| objective probably one, maybe two installs at most.
| ncruces wrote:
| Scoop is nice because, like homebrew, it's easy for package
| creators to create their own "buckets" and distribute packages
| that way.
| TheRealPomax wrote:
| I'm sure, but it's also "yet another package manager" because
| everyone has their own favourite package manager. It's a nit,
| but it's nice when a README.md goes "you need X, Y, and Z"
| and doesn't pretend you need a specific method for that. Tiny
| phrasing change, zero real world difference of course, but
| it's a nice little sign that the folks running a project know
| that you know what you're doing on the OS you're working with
| (either by choice, or by paycheque =)
| abeltensor wrote:
| Scoop is the main package manager I've been using for years
| on windows apart from chocolatey. Dunno many others aside
| from the official windows one: winget.
| TheRealPomax wrote:
| I've been using Windows as dev platform since it was
| called "DOS but don't look too closely", I know
| chocolatey, ninite, winget, and powershell's own built-in
| nonsense, and yet had never head of scoop until just now.
| So... that really just tells us that any application
| manager we think is popular, ubiquitous, and the obvious
| choice is still really just a niche program =(
|
| Contrast that to brew on MacOS: ever non-devs know about
| brew.
| ncruces wrote:
| And from all of those, which I'd heard of, I think scoop
| is the only one to allow a package author to just create
| a git repo, and publish a package that way.
|
| Like brew does. That why I use scoop.
|
| Chocolatey would rather charge money for that, for some
| reason, and people are still willing to donate them their
| free time.
| beart wrote:
| Ideally, winget would be the way to go, but I haven't had good
| luck with it. There are a number of limitations and it doesn't
| feel like a polished and curated repo. It just feels like a
| wrapper around chocolatey, which has its own problems.
|
| Microsoft is the reason alternative package managers exist
| samstave wrote:
| Serious Question: With risk of being hated, this is an honest
| question:
|
| I've never sought out another browser than using pretty much any
| of the big three...
|
| Just because I have never had any sort of personal
| workflow/painpoint/interest in any of these other
| browsers/engines, that frankly I had never heard of and then
| another thing pops up every few years with yet another new one
| that I havent heard of -- but they all seem to have lively
| communities...
|
| The question is:
|
| What is the primary drive/utility that you/others are
| seeking/gaining with these none FF/chrome/edge things?
| dale_glass wrote:
| Servo is written in Rust so one big aim would be to have better
| security. I believe it's supposed to also be much better
| parallelized.
|
| On my part, I'm very much looking forward to an embeddable
| browser engine. Neither Firefox nor Chrome are interested, and
| QtWebEngine exists, but takes extensive patching, and so
| depends on the Qt project remaining to exist and keeping up
| with upstream.
| Aerbil313 wrote:
| Diversification and modern codebases. Without these two we're
| locked to made in US browsers full of CVEs. I don't think any
| nation state can audit Chromium today, not even US DoD.
| ummonk wrote:
| I primarily use Safari on Mac / iPhone because it's integrated
| with iCloud Keychain. I also use Brave because it's the only
| browser with which I've been able to screenshare streaming
| sites for group viewing without getting a black page due to
| DRM.
| rhabarba wrote:
| Every time a new browser appears and is applauded by HN, a
| NetSurf dev opens a beer...
| manwithaplan wrote:
| And a Dillo developer pours _un cafe con cana_.
| rhabarba wrote:
| That's a name I haven't heard in a long time.
| bravura wrote:
| I prefer the term caffe corretto, since the coffee clearly
| needs to be corrected by applying booze.
| 38 wrote:
| doesn't work with windows
|
| https://github.com/versotile-org/verso/issues/118
| cosmicradiance wrote:
| If anyone is willing to put an effort in building a new browser,
| I have just one wish - allow embedding open-source transformers
| in the browser; available for both the user and
| websites/extensions.
| Aerbil313 wrote:
| Do you mean transformer as in AI algorithm or transformer as in
| some sort of content transformer?
|
| Browsers have already STT engines embedded and stuff like that.
| Not LMs but close.
| nickpinkston wrote:
| Lots of great technical documentation here too ;-)
|
| https://www.versobooks.com/
|
| Kidding: They're a well known lefty publisher.
|
| I recommend "Fully Automated Luxury Communism" for people here.
| Really gets into the details, and there's plenty of practical
| research applicable to post-AI economies:
|
| https://www.versobooks.com/products/476-fully-automated-luxu...
| kwhitefoot wrote:
| 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.
| miohtama wrote:
| The websites unfortunately do not want to co-operate with this
| idea.
| mtlmtlmtlmtl wrote:
| I guess the closest thing to what you're describing is either
| conkeror(javascript) or nyxt(common lisp).
| porphyra wrote:
| 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...
| thawab wrote:
| that's really an interesting case, most puppeteer and
| playwright deployments are using chrome. If Verso will be
| faster they might have an advantage in crawl/scrap/QA.
| ibeff wrote:
| "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."
| einpoklum wrote:
| 1. The repository README doesn't explain what Servo is. From its
| own repo README:
|
| https://github.com/servo/servo
|
| "Servo is a prototype web browser engine written in the Rust
| language. It is currently developed on 64-bit macOS, 64-bit
| Linux, 64-bit Windows, and Android."
|
| So, this browser seems to be about using Rust, and somewhat Mac-
| centric. Not criticizing, just emphasizing.
|
| ------------------------------------------
|
| 2. The repository does not explain:
|
| * How far along the project is.
|
| * What are the benefits / points of attraction of the browser (or
| - perhaps it's more of a proof-of-concept?)
|
| ------------------------------------------
|
| 3. The project has a highly repressive Code of Conduct:
|
| * Forbidden behavior is open-ended and at the discretion of
| whoever handles a complaint.
|
| * No due process: Anonymous complaints, in-abstentia proceedings,
| no right to face accuser, no right to access and review evidence,
| etc.
|
| * The project leaders/owners presume to forbid community members
| from interacting with people whom project leaders decided to ban.
| This is a bit like how when the US sanctions a state, it also
| strong-arms everybody else to observe its sanctions or themselves
| get sanctioned by the US.
|
| Bottom line: I would avoid getting close to that project, if the
| CoC is actually applied. If it isn't - very much recommend
| removing it.
| tills13 wrote:
| "a web browser that plays old world blues to give new world hope"
|
| Um... what?
___________________________________________________________________
(page generated 2024-08-11 23:00 UTC)