Live data from Hacker News

I tried Servo

spacebar.news

211–220 of 256 posts

Re: I tried Servo

#211

Earlier quoted context omitted.

At what point could FireFox had just invested the money from Google into the SP500 and then just ran the company off of passive income? Like for 150M$ I bet you could fund browser development for at least a decade and that was just 1 year of income. (of course also burn the entire $150M).

Not sure that's a realistic assessment of the cost of developing a browser. Mozilla gives Software Development exp names as by far the single largest expense at 260M$ in 2023. According to DuckAI 700 out of 750 Mozilla Co employees work on Firefox. I am sympathetic to the idea that a global remote team, that doesn't pay Silicon Valley salaries could get this done cheaper, and thus would be a better candidate for such…

> so 402/653 is spent on the core activities you favour

I don't think that's correct. IIUC, Software Dev was 260M for Mozilla + Mozilla Corporation + Mozilla Foundation + MZLA Technologies Corp. + Mozilla Ventures + Mozilla.ai. With large increase of 40M from 2023 to 2022 so I'd bet a good chunk of that is going to Mozilla.ai knowing how the rest of the corporate world is acting right now.

Like the Chrome Mobile team is 40 people [1]. I can't image that web + support is going to more than 4x that so you get to ~160 people which at 300k a head is 48 million. I don't see how out of the 6 organizations that 93% (700/750) of the employees are working on FireFox and not a different thing.

48 million just in salaries against the $494 million that Google gave Mozilla in 2023 just seems like it should be extremely possible to save at least half of it. Sure, we've gone beyond the initial ~$150M but for all (?) of Mozilla's life the payments from Google have covered software development [3] and for Safari the payments were in the billions so if Mozilla focused on making a better browser with higher market share their payments would go up as well.

[1]: https://mdwdotla.medium.com/some-thoughts-on-running-success...

[2]: https://assets.mozilla.net/annualreport/2024/mozilla-fdn-202...

[3]: https://en.wikipedia.org/wiki/Mozilla_Corporation#Finances

Re: I tried Servo

#212
post #70
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…

I know it’s usually taken as a given around here that Electron is slow, and many of the big-name apps using it are cited as examples with good reason.

From working on a Tauri app myself for a few years (video editor) I just think the blame is misattributed. These things are not inherently slow. Slower than native? Maybe, probably, at the level of milliseconds. Visibly laggy? No, that’s the badly-written UI code’s fault. (see also: the latest iterations of the macOS System Settings UI, where the search box lags like crazy)

A webview can be extremely responsive. It won’t be if you treat it like a web page (where clicking buttons fires off HTTP requests) or if you let the JS framework code get out of hand, but those are not the fault of the wrapper.

If you like building with HTML/CSS/JS then I’d recommend doing some perf experiments to see how far these tools can take you. Of course if you don’t want to use that stack then pick something else :)

If you’re building photoshop, the main UI will probably be canvas anyway, where drawing is fully under your control, no matter which framework you go with. That stuff can be very fast or very not-fast depending on how the code is written.

Re: I tried Servo

#213

Earlier quoted context omitted.

It is donation funded with no reliance on outside parties. They don't have to inject ads into pages like brave did or sell out to Google compromising their independence on web standards. They're ahead of Servo already anyway, and better funded.

In the last 24h alone Chromium merged almost 900 CLs (their equivalent to a pull request) into the src/Chromium repo, Ladybird had 7. Yes a project that started fresh a couple of year ago with decades of hindsight can be more efficient than one started 16 year ago as the fork of a fork, but if I had to guess they'll sooner or later reach a point where they have implemented the low hanging fruit and chromium moves fas…

I'm not even proximal to webdev, can someone explain why people keep making pages using new stuff? I get why google keeps adding things, but why do people use it? Well over half the pages I go to look better without js. HN looks identical.

Re: I tried Servo

#214
post #89

Earlier quoted context omitted.

And it's impossible to get people to pay for it when you give them no way to pay for it.

You can donate, but who's going to pay $10 for beer when the same stuff is being given away for free?

I'm sure there are plenty of people who will pay for it even though its being given away for free. Maybe not enough to replace the income from google but its worth a shot trying a fund raising drive.

Re: I tried Servo

#215
post #43
post #8

Earlier quoted context omitted.

That's my point... The fewer people use Firefox, the less money they get from Google. If you follow the money, it doesn't make sense for them to neglect Firefox.

Google does not need Mozilla to have a sizable market share. They just need it as a semblance of competition in the browser space.

I can't believe how this is common knowledge, this arrangement between Google and Mozilla as a weak and incompetent "competitor" propped up to avoid being accused of monopoly and anti-competitive practice. Why isn't it considered a form of fraud, not even with extra steps - a direct relationship. Maybe there's enough plausible deniability that it's hard to prove criminal intent.

In the browser space, what Apple is doing is awfully manipulative of the market too. It's almost like this situation is being willfully ignored and effectively encouraged by regulators.

Re: I tried Servo

#216

"Most sites have at least a few rendering bugs, and a few are completely broken. Google search results have many overlapping elements, and the MacRumors home page crashed after some scrolling. Sites like Wikipedia, CNN Lite, my personal site, and text-only NPR worked perfectly." Like many HN readers, I have read countless accounts of web browsers and web browsing over the years. Unfortunately, I cannot recall even on…

[deleted]

Re: I tried Servo

#217

"Most sites have at least a few rendering bugs, and a few are completely broken. Google search results have many overlapping elements, and the MacRumors home page crashed after some scrolling. Sites like Wikipedia, CNN Lite, my personal site, and text-only NPR worked perfectly." Like many HN readers, I have read countless accounts of web browsers and web browsing over the years. Unfortunately, I cannot recall even on…

(Back slashes were accidentally omitted)

   # previous: download and compile w3c-libwww-5.4.2
   pwd|grep "w3c-libwww-"||exec echo wrong directory
   export x=$(pwd)
   export examples=$x/Library/Examples
   export linemode=$x/LineMode/src
   export commandline=$x/ComLine/src
   export robot=$x/Robot/src
   y="
   libwwwinit.a   libwwwapp.a    libwwwhtml.a \
   libwwwtelnet.a libwwwnews.a   libwwwhttp.a \
   libwwwmime.a   libwwwgopher.a libwwwftp.a \
   libwwwdir.a    libwwwcache.a  libwwwstream.a \
   libwwwfile.a   libwwwmux.a    libwwwtrans.a \
   libwwwcore.a   libwwwutils.a \
   $x/modules/md5/.libs/libmd5.a -lm"
   cd $x/Library/src/.libs
   for z in \
   head libapp_1 libapp_2 libapp_3 libapp_4 init chunk \
   chunkbody LoadToFile postform multichunk put post \
   trace range tzcheck mget isredirected listen \
   eventloop memput getheaders showlinks showtags \
   showtext tiny upgrade cookie
   do
   gcc -s -static -O2 -Wall -o $examples/$z $examples/$z.o $y
   done
   gcc -static -s -O2 -Wall -o $linemode/www \
   $linemode/www-HTBrowse.o $linemode/www-GridText.o \
   $linemode/www-ConView.o $linemode/www-GridStyle.o \
   $linemode/www-DefaultStyles.o \
   $x/PICS-client/src/.libs/libpics.a $y
   gcc -static -s -O2 -Wall -o $robot/webbot \
   $robot/webbot-HTRobot.o $robot/webbot-RobotMain.o \
   $robot/webbot-RobotTxt.o $robot/webbot-HTQueue.o $y
   gcc -static -s -O2 -Wall -o $commandline/w3c \
   $commandline/w3c-HTLine.o $y
   # next: symlink binaries to a folder in $PATH 
   # or export PATH=$PATH:$examples:$commandline:$robot:$linemode
Also typo: libww should be libwww

Re: I tried Servo

#218
post #204
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…

Even with the best intentions, the implementation is going to have bugs and quirks that weren't meant to be the standard. When there's no second implementation to compare against, then everything "works". The implementation becomes the spec. This may seem wonderful at first, but in the long run it makes pages accidentally depend on the bugs, and the bugs become a part of the spec. This is why Microsoft has a dozen di…

Is that so bad though? It's essentially what's already the case and as you said the developers already have an incentive to avoid making such bugs. Most developers are only going to target a single browser engine anyways, so bug or not any divergence can cause end users problems.

Re: I tried Servo

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

In theory yes. In practice, only when the interests of the sole maintainer are aligned with the interests of the users; since these can change, it’s best to avoid a monopoly. Case in point, recent manifest v2 deprecation is generally disliked by the community and no long term blink based alternative exists (that I know of).

>is generally disliked by the community

It is disliked by a vocal minority, and of that minority even fewer actually have their own opinion based off the current version of mv3 as opposed to mindlessly parroting others. If it was a true issue then others would be maintaining mv2 support long term. In regards to monopolies in terms of control what is important is the product, browser, market share itself as opposed to that of the browser engine.

Re: I tried Servo

#220
post #127
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…

I disagree. The more browser engines in use the less damage any one security exploit can do. This matters even with memory safe languages, because logic errors can be just as damaging, e.g. the Log4j exploit.

Bugs are proportional to lines of code. More browser implementations with result in many more bugs. All the effort of reimplementing multiple times would be better put towards security a single browser engine if security is what you are trying to go after. Also you don't need a single exploit due to defense in depth of browser engines. You have to chain multiple exploits together.
Post reply on HN