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

161–170 of 256 posts

Re: I tried Servo

#161

Post by explodingwaffle »

echelon wrote: post #70
goku12 wrote: post #55

Earlier quoted context omitted.

> (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/browse…

Certainly not a "Rust UX _expert_", but I do find GPUI interesting. Some nice examples here of not-"just text/button widget programs": https://github.com/longbridge/gpui-component

Re: I tried Servo

#162

Post by nielsbot »

fouronnes3 wrote: post #63
nielsbot wrote: post #61

Earlier quoted context omitted.

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.

Or maybe a v2 syntax mode? Akin to `"use strict";` in JS.

Re: I tried Servo

#163

Post by 0points »

paulryanrogers wrote: post #45
xpe wrote: post #28

Earlier quoted context omitted.

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.

Strange. I remember reading nothing but complaints about Pocket when they bought and integrated it. I guess it grew on people.

Not strange, satisfied people don't usually run around declaring how perfectly OK everything is.

Re: I tried Servo

#164

Post by drdaeman »

danelski wrote: post #101
uncircle wrote: post #90

Earlier quoted context omitted.

I've heard the same thing about monetising search engines. Kagi didn't get the memo, and last I've heard they're turning a profit. Sure, only nerds would pay for it, but not all products have to capture 100% market share.

But independent browsers need this metric. Good luck convincing website owners to test against your non-chromium browser with 0.3% market share.

I'm not tracking what's currently going on with the underwater portion of frontend iceberg. Are things still like it was in late '00s and early '10s, where browsers still had plenty of their unique implementation quirks and non-standard features, and plenty of sites were relying on those?

Back in the day, it was not entirely unheard of having two significantly different frontend implementations - one for IE, another for Netscape, with quite unhealthy amounts of parser hacks to hide code from the browsers.

Possibly naively, but I think it's not that bad nowadays? (At least it wasn't so in late '10s.) Some things are Chrome-only, or Apple-only, but I rarely see "not supported in your browser" - the majority of features is generally standards compliant, and all those newcomer engine problems (like in the article) are mostly because there's a lot to implement.

Re: I tried Servo

#165

Post by uyzstvqs »

rrgok wrote: post #126

> This is a danger to the open web in more ways than one. If there is only one functioning implementation of a standard, the implementation becomes the standard. I still don't understand why this is a problem. As long as the engine implementing the spec - governed by committee formed by entities other than Google itself - is open source. The problem and the waste of resource is how we are behaving now. The browser en…

Google is killing Manifest V2, and AFAIK all downstream Chromium-based browsers (Brave, Edge, Vivaldi, Opera, etc) will eventually be affected. That should say enough about why having multiple browser engines is a good thing.

Re: I tried Servo

#166

Post by jenadine »

echelon wrote: post #155
spease wrote: post #120

Earlier quoted context omitted.

Slint recently added Bevy support. I’ve been keeping an eye on it since I’ve used Qt and love working in Qml.

Slint cites Javascript. Is it another Electron/Tauri-like?

Slint does not use a browser. Instead, it has its own runtime written in rust and uses a custom DSL to describe the UI.

It has API for different programming language.

For Javascript, it uses node or deno for the application logic, and then spawn the UI with its own runtime without the browser.

In a way it is the opposite which took the JS runtime out of electron to replace it with a Rust API, while Slint keeps the JS runtime but swaps the browser for its own runtime (for the JS dev point of view)

Re: I tried Servo

#168

Post by airstrike »

echelon wrote: post #135
airstrike wrote: post #104

Earlier quoted context omitted.

In that case, I'm happy to let you know your info is outdated. CJK/IME support has landed. https://github.com/iced-rs/iced/pull/2777

すごい！Japanese is one of our localization targets, so this is amazing! I'm building a graphically heavy app, so two more questions: 1) Is iced appropriate for building a canvas-type drawing app with image inclusions? Right now we're using Konva.js and we'd be losing a tremendous amount of out of the box flexibility in porting to iced, but the performance wins would be a major selling point. 2) Can you include Bevy pane…

Awesome! Glad to hear that and I hope you do give it another try.

1. Yes but not necessarily a "resounding yes" because images right now are drawn on the top of each layer, so if you want to write on top of images you'll need to create different layers for each of them which is more expensive than not doing that. You may be OK with that for now (I am, for my slideshow editor), but there's pending work to be done there to remove the requirement of explicit layering and thus improve performance.

2. I'm not familiar enough with Bevy to opine. I know there's https://github.com/tasgon/bevy_iced but I think that might do the opposite of what you want. Having said that, iced lets you write custom shaders so you can go as deep in the stack as you'd like for any 3D visualization. The caveat then being that you're implementing all that logic yourself, but there's no stopping you.

Importantly, I think it's worth joining the Discord and asking around, seeing what people are building, trying the library, and pointing out where you think you need help. This helps the core team understand use cases better and in some ways guides development IMHO. I'm not part of the core team, so I could be wrong, but that's my perception.

Re: I tried Servo

#169

Post by bowsamic »

mrob wrote: post #129
fabrice_d wrote: post #84

Earlier quoted context omitted.

Ladybird is extremely slow, it's far from being competitive at all.

All browsers are fast enough once you block all the useless web bloat.

But Ladybird's explicit goal is to work on the "real web", i.e. without blocking all that bloat

Re: I tried Servo

#170

Post by usrusr »

echelon wrote: post #70
goku12 wrote: post #55

Earlier quoted context omitted.

> (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/browse…

Makepad is neither gtk generation nor browser based. Might check the "just text/button widget" box though, I'd certainly place it on the minimalistic end of the spectrum. (haven't worked with makepad, just enjoyed the demo)
Post reply on HN