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

261–270 of 343 posts

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

#261

Post by lnrd »

refulgentis wrote: post #131
afavour wrote: post #119

Earlier quoted context omitted.

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…

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…

> 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

The Swift business case is that in many situations native is strongly preferable than cross-platform. Excluding some startups that wants to go to market super fast and consulting companies that have to sell the cheapest software possible, usually the benefits of native outweighs the ones of cross platform.

For this reason now there are plenty of companies of all sizes (faangs included) that build and maintain native apps with separate iOS/Android teams. There are very good business reasons to learn Swift or Kotlin in my opinion.

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

#262

Post by einpoklum »

fabrice_d wrote: post #207
einpoklum wrote: post #164

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. -----------------------------------------…

Not sure how you concluded that it's a "somewhat Mac-centric" project. Can you elaborate?

Their best deployment/installation instructions are for Macs, and for Linux they suggest things like nix-shell or flatpak, rather than straight-up packages for the popular distributions/package management systems. That's my reading of things, anyway.

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

#264

Post by eviks »

zackbrown wrote: post #248
eviks wrote: post #245

Earlier quoted context omitted.

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/syntax…

syntax flavours / "skins" sounds like a great idea if Pax isn't so tightly coupled with the current one

(HTML makes sense as the target to start with, but I'm not sure most people "speak" raw HTML, they'd design apps/pages in other languages)

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

#266

Post by zackbrown »

madeofpalk wrote: post #259
zackbrown wrote: post #227

Earlier 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…

HTML and CSS is the worst layout system except all others. But actually, HTML and CSS is pretty good considering the problems is solves.

> HTML and CSS is pretty good considering the problems is solves.

Agreed: pretty good. Shouldn't we pursue excellence?

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

#267

Post by devsda »

hanniabu wrote: post #169
38 wrote: post #151

Earlier quoted context omitted.

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

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

They don't have to. But we have seen how Google can play this game of open core & official versions with AOSP and blessed Android versions with playstore.

There will be two classes of products one officially sanctioned version and the others that are used by enthusiasts. Apps or sites in this case may chose to work on one and not on others. Imagine the new wave of "works best on IE" with "best viewed on chrome variations a,b,c". Its not farfetched as some sites already do this.

As much as it is easy to maintain a fork, it is that much easy to give up or change path and accept upstream changes.

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

#268

Post by zackbrown »

atoav wrote: post #256
zackbrown wrote: post #227

Earlier 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…

Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? Don't get me wrong, I also could imagine better markup languages for that purpose. But everything I have seen in the wild was worse in multiple, show-stopping ways. Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and put the solutions into CSS4 and HTML6

> Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces?

HTML/CSS is pretty good!

SwiftUI's HStack and VStack are solid, though they suffer from ambient API complexity & Conway's law.[0]

Figma's autolayout is a strong reference, but it's not a tool for creating software.

> Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and put the solutions into CSS4 and HTML6

Why not both? Innovate freely and independently (the prerogative of any builder) and adopt as spec any innovations that pass committee.

[0] arguably same diagnosis, different course of disease vs. HTML/CSS

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

#269

Post by madeofpalk »

zackbrown wrote: post #268
atoav wrote: post #256

Earlier quoted context omitted.

Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? Don't get me wrong, I also could imagine better markup languages for that purpose. But everything I have seen in the wild was worse in multiple, show-stopping ways. Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and put the solutions into CSS4 and HTML6

> Care to point us to a better combination than HTML/CSS when it comes to layouting flexible interfaces? HTML/CSS is pretty good! SwiftUI's HStack and VStack are solid, though they suffer from ambient API complexity & Conway's law.[0] Figma's autolayout is a strong reference, but it's not a tool for creating software. > Maybe instead of coming up with a new thing, we just need a clear way to solve the pain points and…

Isn't Figma's "auto layout" just a GUI for a canvas-based implementation of flexbox? Likewise, HStack and VStack are ports of flexbox to SwiftUI.

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

#270

Post by pona-a »

zackbrown wrote: post #227
ksec wrote: post #5

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.

> 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…

Doesn't the rendered page run in a different thread to its JS? If the website does use some SPA framework to lazy-render the components, load the new view, or execute some logic, maybe then, but when I say run `(() => { const s = Date.now(); while (Date.now() - s < 10000); })();` and try to scroll the page, it doesn't freeze.
Post reply on HN