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

I tried Servo

spacebar.news

Post reply on HN
Print view View original

61–70 of 256 posts

Re: I tried Servo

#61

Post by nielsbot »

nicoburns wrote: post #32
fouronnes3 wrote: post #17

Earlier quoted context omitted.

Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? Do you still google "css grid cheatsheet" three times a week like the rest of us?

> Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? I think I'm more concious of what's performant in CSS. In particular, both Flexbox and CSS Grid like to remeasure things a lot by default, but this can be disabled with a couple of tricks: - For Flexbox, always set `flex-basis: 0` and `min-width: 0`/`min-height: 0` if you can without affecting the layou…

I wish there was a CSS analyzer that would give tips like this based on your CSS.

Re: I tried Servo

#62

Post by afavour »

piker wrote: post #37
nicoburns wrote: post #15

> The current roadmap lists Shadow DOM and CSS Grid as priorities I've been working on the CSS Grid support. About to land "named grid lines and areas" support which should make a bunch more websites layout correctly. I'm biased because it's my project, but IMO the approach Servo is using for CSS Grid is pretty cool in that the actual implementation is in an external library (Taffy [0]) that can be used standalone an…

Do you not worry that instead it will lead to feature bloat and fragmentation? If you’re going to strike at Google, you need laser focus.

Shadow DOM and CSS Grid don't strike me as bloat or fragmentation in any way? CSS Grid in particular is table stakes that would be part of any laser focus.

Re: I tried Servo

#63

Post by fouronnes3 »

nielsbot wrote: post #61
nicoburns wrote: post #32

Earlier quoted context omitted.

> Does having experience implementing a web browser engine feature change the way you write HTML or CSS in any way? I think I'm more concious of what's performant in CSS. In particular, both Flexbox and CSS Grid like to remeasure things a lot by default, but this can be disabled with a couple of tricks: - For Flexbox, always set `flex-basis: 0` and `min-width: 0`/`min-height: 0` if you can without affecting the layou…

I wish there was a CSS analyzer that would give tips like this based on your CSS.

Or a straight up fork of CSS that removes the legacy stuff and fixes wrong defaults so that tips like this are unnecessary in the first place.

Re: I tried Servo

#64

Post by keysdev »

YmiYugy wrote: post #23
ObscureScience wrote: post #3

While it's hard to know what comes of it, there is also https://ladybird.org/ to challenge to monopoly of Blink.

I just don't get the point of ladybird. They have full time engineers and are soliciting donations, so it's clearly more than a hobby project. Maybe my assumptions are off, but I just can't imagine they could ever become competitive in terms of features, security and performance with the big engines. Blink is setting the pace, Webkit is barely able to keep up and Gecko is slowly falling behind. All of these teams are…

It was the similar sentiment with 0xide.

Re: I tried Servo

#65

Post by AdmiralAsshat »

I feel like Mozilla is going to join the annals of history with the likes of Xerox in the category of "Companies that created the technology of the future and casually tossed it to the wayside for competitors to scoop up" with Rust and Servo.

It's mind-boggling that for a company so often seemingly playing catch-up with Google, Mozilla actually leapfrogged Google in the browser development space for a time, and then...decided it wasn't worth pursuing any further.

Re: I tried Servo

#66

Post by coredog64 »

xpe wrote: post #28
jqpabc123 wrote: post #2

It's still baffling to me that Mozilla threw out Firefox's technical future Very little about Mozilla makes sense --- until you follow the money.

The end of Pocket is just another sad example. As an April fools joke, Mozilla should announce that they are discontinuing Firefox in order to focus on their core business, which is a beautiful abstraction: the Platonic ideal of discontinuing popular products.

That they're being bought by Google so that they can focus on the Platonic ideal of discontinuing popular products.

Re: I tried Servo

#67

Post by Buttons840 »

ObscureScience wrote: post #3

While it's hard to know what comes of it, there is also https://ladybird.org/ to challenge to monopoly of Blink.

Looks interesting, but they're going to try writing it in Swift?

If you're writing a browser engine in C++, I may not like it, but I can see that you're pragmatic and are focused on the end result rather than the language. If you're writing it in Rust, okay, you maybe have your eyes on that pie in the sky, but you've chosen a language that, at least potentially, has the ability to replace C++ in creating bedrock software.

Any other language and I feel like someone with a lot of political capital at the company just has a personal preference for the language and so, "yeah, we're going to rewrite it all in Swift"[0].

I mean, you're writing a browser. Do you really want to build it in a language that is at the "it's improving" stage of support for the most popular operating systems?

[0]: https://x.com/awesomekling/status/1822236888188498031

Re: I tried Servo

#68

Post by jonkoops »

ObscureScience wrote: post #3

While it's hard to know what comes of it, there is also https://ladybird.org/ to challenge to monopoly of Blink.

I have to be honest that I don't really understand the appeal of Ladybird from a purely technical perspective. It is written in C++, just like all the existing engines (yes there is some Swift, but it is negligible), so what benefit does it provide over Gecko or Blink? With Servo, I can see there is a distinct technical design around security and parallelism.

Re: I tried Servo

#69

Post by nicce »

AdmiralAsshat wrote: post #65

I feel like Mozilla is going to join the annals of history with the likes of Xerox in the category of "Companies that created the technology of the future and casually tossed it to the wayside for competitors to scoop up" with Rust and Servo. It's mind-boggling that for a company so often seemingly playing catch-up with Google, Mozilla actually leapfrogged Google in the browser development space for a time, and then.…

It is difficult to get people to pay for it. People happily pay for 10€ beer but asked ”friends” about how to bypass WhatsApp’s 0,99 lifetime licenses.

Re: I tried Servo

#70

Post by echelon »

goku12 wrote: post #55
nicoburns wrote: post #15

> The current roadmap lists Shadow DOM and CSS Grid as priorities I've been working on the CSS Grid support. About to land "named grid lines and areas" support which should make a bunch more websites layout correctly. I'm biased because it's my project, but IMO the approach Servo is using for CSS Grid is pretty cool in that the actual implementation is in an external library (Taffy [0]) that can be used standalone an…

> (Taffy [0]) that can be used standalone and is widely used accross the Rust UI ecosystem, including in the Blitz [1] web engine (which also uses Taffy for Flexbox and Block layout) This is the first time I hear about Blitz. Looks equally interesting and ambitious. It is probably the real undercover web engine. Servo was widely known around when Rust debuted.

Questions for the Rust UX experts:

Is Dioxus (or Leptos) much more performant than Tauri/Electron?

I want to (1) build blindingly fast, low-latency, super performant UX for users, which precludes Tauri/Electron (something I'm currently using and unhappy about), but I also want to (2) maintain developer velocity, (3) have access to nice UX primitives and widgets, and (4) have it look nice and modern.

Javascript/browser-oriented frameworks make requirements 2-4 easy, and it has the side benefit of also making hiring easy (not a requirement per se). But the results feel so bloated and anti-Desktop/native. It gobbles up RAM and renders slowly, even when best practices are used. It's the very definition of a double-edged sword.

Are these four requirements simply impossible to satisfy together for native Rust UX toolkits right now?

Rust's egui looks amazing, but I doubt you'd be able to build a very complicated UX with it. Or if you could, it might take you half a year to deliver.

Iced also looks cool, but looks less featureful.

Are there any "non-browser" Rust UX toolkits that aren't dated GTK/KDE frameworks, but that can build graphically-oriented (not just text/button widget) programs?

If I were building a "slimmed down photoshop", are there any Rust GUI toolkits to reach for? Or if I were incorporating a Bevy or 3D render pane?

Post reply on HN