(评论)
(comments)

原始链接: https://news.ycombinator.com/item?id=40746804

在本文中,作者表达了他们对通过限制特定 JavaScript 和浏览器 API 来限制浏览器功能来简化浏览器的好奇心。 他们认为,现有的纯 HTML 浏览器仍然可以充分执行诸如查看文档或访问简单网站之类的任务,但这种浏览器正在变得越来越少。 尽管他们对允许使用脚本持怀疑态度,但作者承认在该领域创建最小可行产品 (MVP) 所需的初始投资是巨大的。 或者,他们提出了一种方法,涉及创建独立的文档库和模块化浏览器架构,从而实现服务器端和客户端应用程序之间的无缝转换。 他们钦佩 Andreas Kling 等开发人员的努力,但也承认挑战在于摆脱目前主导该领域的单一设计。 他们批评火狐等流行浏览器尽管获得了相关技术,却忽视了核心软件的进步,导致对外部工具的持续依赖和依赖。 在讨论 Discord 作为一个根据视角不同程度的可访问性的平台的例子时,他们建议将基本的、有据可查的、委托的浏览器设计作为潜在的解决方案。

相关文章

原文


For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis.

I’d wildly guesstimate for 70% of use cases you wouldn’t even need 50% of stuff with some slight modifications. The web is just so bloated.

Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas



The problem with targeting a subset is there's a ratchet effect with web APIs, once support reaches critical mass in the major browsers sites will start unconditionally relying on those features and there's no going back from there, any new browser has to also support those features or be considered broken.

I suppose anything that's gated behind a permission prompt in Chrome/Firefox/Safari could be culled without too much trouble at least.



> The problem with targeting a subset is there's a ratchet effect with web APIs

What about starting a new web then only for the supported subset?

Based on my current browsing experience, this may be a plus in the long run.



There is a reason that Esperanto or one of it's siblings is not the language of global understanding and we are discussing in English. The world at large generally does not care about these kinds of fancy. It's half a miracle that we agreed to whatever the Chromium engine implements to be a baseline that most folks build stuff on.



The problem is convining anyone to write a website in this. You will have like 3 sites that use only the subset.

The closest example is AMP, but you must be Google to force people to use it.



> The problem is convining anyone to write a website in this

Could choose a subset that lets certain sites that do not get on everybody's nerves still run fine.

For the remainder, people who need it can run an extension that runs a Chromium converting what's possible to the target subset.



I think people forget the early 2000s. Many sites only worked on IE but Firefox was the better browser. Firefox users had an extension that would open certain links in IE or open the current page in IE via the context menu.

If a lightweight browser could be significantly faster and more secure, people would tolerate using two browsers again. Although Ladybird hasn't reached that bar.

YouTube certainly could use a small set of web standards, although YT regularly breaks on Firefox. It's a video player with links and forms.



Given that a browser is not practically a virtual machine and/or an OS, it is not too surprising that an OS developer is not scared by the task. At the same time, it seems to me that multimedia is a whole different beast.

> For a new project I wonder how much simpler (or secure) a browser could be made if you only allowed a subset of js and browser apis

IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).

I really don't want to drop the all too common negative comment - in particular since I already use an alternative web browser - but the initial investment required just for an MVP seems mind-boggling to me.

I think a basic HTML browser that can automatically delegate all it cannot handle to other apps - PDF viewing to a PDF viewer, video playback to a video player, and JS-requiring things to a big browser - would be interesting (if it already exists, please let me know).



I've been wanting something like that, like a wrapper that hosts three or four engine, so I can use normal for every-day, upscale to FF for some or Chrome for others - all in one UI.



>IMHO the only viable subset is the empty set. There are some surviving HTML-only browsers that are still usable for e.g. viewing documentation or browsing simple-minded websites (like HN, but they are fewer and fewer every year, unfortunately).

I'm curious if throwing out DOM/js would make the task more approachable. My intuition says yes. But I'm thinking CSS would still make it super difficult. Also I've heard that HTML has some rough areas that make it hard.

That being said I find Netsurf is pretty capable even if I don't really use it very often. Yeah some pages don't render right but it's really fast. So who knows maybe we can get away with a reduced set of features or better yet go back to using separate clients instead of web apps for things like chat, email and forums.



I think this is a great point. The majority of my browsing uses text oriented sites (some think they are more, but I read them in reader mode). As I user, I rarely want more. I'd use a slim, secure browser if I could.

Sometimes I play games, or use "web apps" and using a different tool in those instances would be fine. Back in the early 2000s I remember using Firefox with an "open in IE" extension that allowed me to primarily use FF and fall back to IE when sites were broken. As websites modernized I used the extension less and less.

Also consider desktop apps that use election. Bundling a simpler browser and building the app to the capabilities of that browser could greatly reduce install size and memory usage.



> Edit: might as well prune down the css a little too and maybe dump wasm, webgl and canvas

Alternative idea: go the other extreme and stop pretending modern browsers are anything else than virtual machines. Turn browsers into sandboxed VMs that only run Wasm, with backwards compatibility ensured by shared wasm libraries that render HTML and run JS.



If it only does 70% of what a regular browser does would anyone (seriously not as an experiment) use it on a daily basis? Most people just want to get on the web and go. They don’t care how big their is on disk or how much ram it uses (within reason of course), but the first time it doesn’t render their bank page or Jira page, they will drop it. Obviously I’m not talking about beta testers here or curious web devs.



The conversation regarding restrictions on the feature set within the browser always focuses on the browser itself, but there is definitely an opportunity to rally website makers. If Google or Apple came out and said we have a reduced feature set you can use that makes our browser render your website faster it would be a good opportunity, and I think many website makers would jump at the opportunity. A sort of Google AMP, but good! Let's call it Strict HTML.



This is so wildly wrong it hurts. As soon as that one important website (to your user) breaks, they will switch browsers.

Just deciding that you don't want to implement >50% of web specs "for simplicity" and expecting that to be a winning strategy is very HN.



The "very HN" thing for me is assuming a "winning strategy" has to be mass adoption. There's room for a smaller web full of nerds and geeks, we had that before and maybe we can have it again.



To me it’s not wrong at all, why won’t a simpler browser with a “modern mode” rendering succeds? There is no need for that browser to support the space jam website, who really cares? Imo thinking that people need quirks mode because they need to visit old website it’s very HN.



It's not that at all. Imagine some popular website is relying on some weird quirk but it works out in modern browsers. They don't even know they are broken, or in what way, and first discovering the issue and then investing in fixing the issue for <1% of readers is a very difficult cost to justify.



> Use a programming language that lets you write clean, fast, memory-safe, parallel data-race-free code — probably Rust.

But from the lwn article:

    It is written in C++ [..]. 
Oops! :-)


If I were building this, I wouldn't do that.

I would build one piece, as a well-documented Pythonic (not in Python; just in coding / documentation style) library.

The reason this is impossible is the monolithic design of these things. There are good reasons for it -- the pieces interrelate -- but I think it's possible to break it up (with a lot of work).

For example:

- A clean, documented JavaScript engine would be a good start.

- Python-style, independent, isolated JavaScript libraries would help (usable serverside or clientside where possible)

- An independent rendering engine would be nice -- again, documented and independent of the above

- Network libraries

- HTML / XML / CSS parsing libraries

... etc.

If this were in place, code could be interchangeable between serverside and clientside much more than today (and usable in other places, such as using JS as a scripting language in other systems).

Test cases for rendering (or even just making a screenshot) wouldn't need the whole browser. You would import and call into the rendering engine to make a .png without selenium.

Making a new web browser would involve mostly glue code and OS-specific code.



Andreas Kling is a great role model in the world of development I feel. The decision to step away from the Serenity OS makes a lot of sense. There are plenty of them, nice projects to do, but they'll never have an immediate impact if any at all. But the browser space, Ladybird is viable as a daily driver for people. I'm still today astounded the work that has been produced just on this.

> Somewhat ironically, it was not possible to log into Discord using Ladybird. It does a fair job of rendering pages, but speed and stability are still wanting.

Fascinating to see people expecting everything to work out of the box whilst being writter from scratch.

And as an avid rust appreciator, all the comments about "rewrite it in rust" as if that solves anything the OP spoke about is really frustrating.

Let the team cook, if you dont like the dish, help cook it. The project has been super interesting and honestly I feel we need more like this in the browser scope.



I don't think casual observers understand how many new CSS features have been added to the web platform over the last few years.

468 new features have been added since 2018; 148 have been added in the past 18 months alone [1].

I applaud the effort but unless something fundamentally changes in their approach, I don't see how they can catch up.

Sure, you don't need every single spec, but even the core ones like Flexbox, Grid are large and complicated and are constantly being tweaked.

[1]: https://codepen.io/fimion/pen/WNmwJWJ



all of them were written in a way that mostly affect the api, not the underlying implementation models tho.

it's still 500 new things to test and actually implement. but not as bad as the original 1 to 2 change.

html5 was the forever missed opportunity to do things right. but keeping the browser-side effort low was always fought for on the w3 committe.



> Fascinating to see people expecting everything to work out of the box whilst being writter from scratch.

(Sarcastically saying something is interesting is something I find distasteful.)

Anyway the irony is that the project chose to use a discussion platform which uses lots of modern web cruft and would be a big challenge for a new browser, when they could have chosen a (maybe less capable) simpler platform like IRC or some simple web forum which would more likely have run on Ladybird.



Chosing Discord was a deliberate choice. I remember when Serenity was using IRC as the only communication channel and immediately after setting up a new Discord server the community gravitated towards it. Infact, the number of community members sky rocketed.

The fact is, Discord as a platform is more accessible compared to IRC.



> The fact is, Discord as a platform is more accessible compared to IRC.

Guess it depends on what you mean with "accessible". In terms of accessibility for impaired users, IRC is a open protocol vs a service that disallows 3rd party clients. I'm sure there exists better options for IRC than Discord, and at the very least, IRC allows you to access it however you want, be it visual, textual, voice control or whatever.

Besides, Discord being a US company, need to prevent users from Cuba, Iran, Syria (and NK) and is also banned in a bunch of countries like China, UAE and Egypt. So in that sense, Discord seems less accessible than IRC.

Only remaining part is that Discord has a somewhat easier "getting setup" UX than IRC for younger users, as it's more similar to the type of services they're probably already use.



> But the browser space, Ladybird is viable as a daily driver for people.

From the LWM article:

> Users will need GCC 13+ or Clang 17, and Qt6 development packages to play along at home. Ladybird compiles and runs on, for example, Fedora 40 without a problem, *but it is a long way from being suitable for regular use.*

Seems distributed binaries are missing, but that's easy to "fix"/"workaround". Is there something else that makes you say it is suitable as a daily driver while LWM author does not?



I wish rust people spent their time writing software instead of going around telling other people to do the job for them. They only manage to get others annoyed with this attitude.



Although I dont like quite a few Firefox decisions. Like the floating tabs which no easy way to revert. I still think Firefox as a browser is fairly decent. And I also think that ladybird is going to have all the problems that Opera Presto had (and now Firefox has) which is going to be ignored by any small developers, and targeted to generate errors by the big companies (google/microsoft...)

I definitely would have preferred the momentum to go to SerinityOS, and perhaps, importing firefox/librewolf into Serinity OS.



If enough people use different browsers then we'll get effective and slower standards once again. I think the only way to get people on other browsers is to legally require ballots on first use of an OS/device with random order. It worked in the EU, it can work in the US too.



Unfortunately that is not how it works. The only way to get different browsers is to get absolutely every single OS project with some traction to force installation of them, to show advertisement everywhere, and to couple it with the installation of any piece of software, and to set it as default, plus import silently everything.

Anything that is not a dirty tactic will not work.

Also, the moment a user got an error they dont understand in certain browser, they blame the browser and change. How do you think firefox got out of business?

Have you tried using Firefox to request an appointment with the Spanish Drive and Vehicle License Administration? It wont work. The civil servant will tell you use chrome.

When a user get 2 or 3 use chrome to work, they will just use whatever it works. They won the browser war, adding ladybug to steal from firefox, is also not going to help either.



All of those problems can be fixed by legal means. We cannot expect the market to regulate itself into a healthy competitive balance.

Force sites to implement baseline standards and not rely on non-standard features. Disallow major web players from pushing their own browsers and from relying on their own browser's non-standard features. Permanently require browser ballots on all widely used consumer OS's. Heavily fine violators consistently. Use the money to support an independent standards body.

Naive users will get a random, standards compliant browser. This throng will help prevent sites with no concern for the law from testing against only one instead of against the standard.



There has been 30/40 years of internet, and no legal battle has manage to get anything on that regard.

I would even say, topics on the internet with a lot of lobbying, such as pirating software/media, in the same timeframe, has managed to get absolutely nothing done.

I am afraid, it would not be possible to regulate legally.



Yet regulations have happened and continue to, just different ones of varying ... quality/purpose. Even among preservation/piracy there have been moderately successful efforts.

Apathy will not bring change. Only speech and action.



The only thing that resulted in a decline in piracy was an increase in convenience, simplicity, and speed brought by on demand services (cloud game downloads and subscription passes, streaming video and music services, ebook/software subscriptions through app stores). The many billions spent per year in lobbying for deep seated laws like DMCA or equivalents never brought any meaningful change to the problem because the root of the issue was not solved by more restrictions.



In the early 2010s a ballot appeared for new users on Windows [0], though the legal requirement expired only a few years later.

It helped other browsers gain market share. Sadly it's not enough alone. Major web players can promote their own browser and sabotage others, even if only by neglecting to test them. IMO a permanent ballot law is needed alongside restrictions from major web vendors pushing their own browser's and relying on their own browsers non-standard features.

[0] https://en.m.wikipedia.org/wiki/BrowserChoice.eu



Do you perhaps mean to argue you think it helped other browsers lose users slower than they otherwise might have? From your link:

> Competing browsers saw their traffic increase,[16] suggesting that these smaller competing developers were gaining users. However, long-term trends show browsers such as Opera and Firefox losing market share in Europe, calling into question the usefulness of the browser choice screen.[1]

Opera is the smaller competitor referred to in both halves and it lost user share in Europe while this was in effect. About the only thing the ballot can claim is a loss in users of the 1st party browser IE but that effect was already occurring prior to the ballot anyways.



On the whole it did only slow the tide. Yet it wasn't enough alone, limited to one OS, in one market, for only ~4 years, at a time when Google was pushing its own from some of the world's most popular services. Still, every victory is worth celebrating.

Moping every time a (modestly successful) approach is brought up isn't going to move the needle.

Dominant browsers rely on many tricks to gain and hold their position. It will take more than one approach to restore a balance.



I appreciate you consider it key but that several others are disagreeing whether something was successful is not them simply moping it was successful but not enough :). Keep in mind this all started out with this being the only way to get people on other browsers like how it had already worked in the EU so that's going to have steered more disagreement in the conversation than you might expect.

I think the browser ballot style thing may have hurt more than it helped in the long run. E.g. users clicking things they don't understand during the initial setup of their computer (while a whole lot of other things they don't really deal with often are going on too) may have actually resulted in some extra short term download hits that immediately scared those users away from spending time trying other browsers out once they realize what their selection meant in terms of change. How many users that clicked on Maxthon and were confused/disappointed with a (then) Trident based browser that wasn't quite IE? Hard to say but the data isn't jumping out to show the opposite.

I agree it would take more than one approach to restore the balance but I disagree that means all approaches are inherently helpful to roll out, let alone inherently key. The ballot initiative didn't result in any measurable change, even against the tide when compared to other regions, and simultaneously focuses both people and discussion away from major issues like the tricks dominant players actually use to gain market share. E.g. Microsoft had IE (and later Edge) bundled as the default choice after the ballot and share continued to decline up until they used these other working tactics which have resulted in it becoming the 2nd most used desktop browser again.



It's great that we're faced with an explicit choice here in the EU, but I don't think it really done much in terms of affecting Chrome's entrenched market share. Most people use whatever tools they're already familiar with. Almost everyone I know uses Chrome, including the majority of my tech circle.

I think people are only going to switch once the Firefox user experience is noticeably better for the average person. Google is on track to make that happen after they finally disable Manifest v2 extensions and as they continue their crackdown on ad blockers.



Firefox doesn't control major web properties from which it can nag users to switch. Chrome (and similar chokepoint-holders like Safari) won't be unseated by market forces for years, maybe decades. We are on the road to technology feudalism as the web and browsers eat the world.



Not what I would consider easy, that is medium.

Easy should be install a theme/extension, or toggle an option on configurations. Yours can be broken after updates, and requires to know what it is (I do, I just cant be bothered), and redownload and apply after each time an update breaks it.

I have decided to live with the awful floating tabs rather than personalising the userChrome.css, I wish someone could convert it into an extension.



let's all take a moment to appreciate how google managed to get the web to the state it was in 1996, when you had to develop for one browser and then go fix things in another.

/slow clap



For a newbie like me who isn’t like a software eng wizard but is willing to put an hour or two every day, is a project like this a great way for me to learn and contribute? Or is it still so pre-alpha that you need deep domain knowledge to contribute and have an impact?



I think it's a great project to learn and contribute. The scope is very broad, so there are plenty of different areas to contribute to, including not-so-advanced functionality. For example, the initial find-in-page feature was introduced just a few week ago[1] and the core logic relatively simple.

Plus, the build process is well documented and works out of the box (at least on Ubuntu in my experience) and the community is nice and welcoming.

[1]https://github.com/SerenityOS/serenity/pull/24480



Even if not pre-alpha, building a browser needs deep domain knowledge. But on the other hand, after some time you will be rewarded with very, very useful knowledge of how the web actually works. The start would be pretty rough but if your daily work lacks the challenge then I would encourage you to try contribute :)

(Not affiliated in any way)



I’ll be that guy and point out that if you have to ask this question, it may not be the best personal fit. Unpaid open source contributions work the best and last the longest when they scratch your personal itch. Find a bug or a missing feature in a piece of open source software you use all the time; find an abandoned project you need and try to improve it; or build something you want but doesn’t yet exist. Forcing your way into open source through a large project that is not in any way special to you in order to learn, build your personal brand, etc. may not be the most sustainable source of motivation. But who knows, maybe that also works for some people.



> Unpaid open source contributions work the best and last the longest when they scratch your personal itch. Find a bug or a missing feature in a piece of open source software you use all the time

Most of the open source software I use are really rock solid, so I’m not sure what bug or missing feature I would be able to add. I also think as a newbie it’s perhaps useful to work where I can learn a lot in a short amount of time. Those dopamine hits can be pretty awesome :)



I’m irrationally excited for this project. The idea of a community built browser is incredibly appealing considering the current landscape where all browsers are either Chrome, Chrome in a trench coat, or Firefox



I don't understand what is wrong with Firefox. It is open-source, highly configurable and reasonably secure (if you have the time to configure). Yes, it has shortcomings, but what doesn't.



Not every open source software has spyware and ads activated by default, while marketing itself as privacy friendly.

Yes, can all be deactivated, I also use FF, but I do not trust Mozilla anymore.



Ikr. They're up to some questionable decisions since long.

- Acquire companies like Pocket, Anonym in multi-million dollar deals and also the millions in bonuses that the CEO likes to enjoy.

- At the same time, no significant expenditure towards developing its core software. Firefox is still ridden with bugs. They even went as far as firing the people that used to work on Servo, Rust, WASM, etc.

I think it's clear to them that there's not enough money to be made with small tricks like Pocket, VPN, Relay, etc. Firefox is still the only profitable product and contributes ~90% to Mozilla's revenue. Much of it coming from Google which is the one thing that people have been asking them to be less dependent on.

And we shouldn't be surprised if they double down on making more money off of Google and also introduce ads. Acquiring Anonym, an ads company, implies that it might have already started.



"They even went as far as firing the people that used to work on Servo, Rust, WASM, etc."

And at the same time greatly raising compensation for the CEO, despite shrinking numbers.



Servo had so much potential as the flagship Rust project, a fast and memory safe browser engine.

Such a loss to see it jettisoned and abandoned. Myopic decisions like these are filling the cloud of pessimism that now shrouds Mozilla.



FWIW Servo is seeing work as e.g. an Electron replacement. There is hope, even if one wishes the Mozilla Foundation CEO had used some $6M on developer salaries instead of pocketing it.

Full browser feature set is hard, but an app that bundles its own webview can choose to not trigger the edge cases, so that's a realistic path forward.



I see some nice parallels with Wikipedia. Makes me wonder if anyone's yet developed a theory of "foundation capture" where you find some marvellous free thing that is made for and by humanity at large and extract/redirect money from its market share/good will.



I think the pump-and-dump extraction of value from any brand works pretty similarly, whether a non-profit or regular business.

Lots of companies with centuries-long record of manufacturing previously durable goods have in the last decade or two switched to using e.g. inferior quality steel to increase profits. That'll destroy the brand, but in the meanwhile there's great profits to be had!



Yes, a while ago. But fortunately people continue. Just not with the billion dollar budget of Mozilla and with seemingly less traction. I have not heard of them in a while.

But I very much endorse both. And yes, in theory energy should be focused, but I rather have 2 smallish projects, but with potential, than one slightly bigger one, with fighting about direction all the time.



Firefox is open source, it would be far easier for the community to make a stripped down Firefox port with no telemetry, no ads and no upsells for Mozilla services.

With that said, almost all of Mozilla's revenue comes from Google, which might possibly influence what features they implement, their stance on various web standards etc.



As pointed out, these do exist. I've been using several over the decades. And chrome forks too.

They all tend to lag behind over time, until the fork is eventually too old and it's either abandoned, useful changes I was relying on are dropped, or becomes just too old compared to upstream to be fully compatible (and thus just annoying to use).

Just the burden to upkeep the upstream changes, in either firefox or chrome forks, seems to be significant enough that I'm quite pessimistic on the lifespan of these projects.

You might just as well do your own thing, and don't pretend to be a mainstream browser replacement altogether.



> which might possibly influence what features they implement, their stance on various web standards etc.

Unless you’ve got some examples to back this up, it’s FUD. Posting hypotheticals is how rumours start, and this is just stirring the pot.



Conflict of interests is a real thing to worry about. I wouldn't trust scientist working in tobacco company on cigarette harm, even if I have no evidence of wrongdoing.



Sure, there are forks such as LibreWolf. I understand the reservations regarding Mozilla Foundation, although I generally like what they've been doing. Every org has people with stupid ideas. However, the way I see it, it's unlikely that the community will be able to produce a competitive browser in a broader sense (stability, performance, security, cross-platform...), meaning that the likelihood of Firefox being still around ten years from now is significantly higher than that we build and maintain a comparable browser ourselves. Then come the evolving web standards and lobbying power...



The way things are going at Mozilla currently, I wouldn't be surprised if Firefox is just another Chromium wrapper in 10 years. Technology doesn't seem to count as much as the C-suite filling their pockets at this "new" Mozilla.



Install a new version of firefox, have a look in settings under "data" (or whatever they call it in english). There you will see "studies" as activated, which is cryptic talk for ad tracking. And more recently, literal tracking for a advertisement company.

And as a bonus, those were added and activated as features via update, without telling. At least for me.

(and paid ads you have on the home screen)



> And as a bonus, those were added and activated as features via update, without telling. At least for me.

Ouch, they were new to me and also activated.



Yep, stuff like this makes me question many things. I mean in a sane world this should be enough to sue them into oblivion. But the general bar in that regard is so low, that apparently even open source companies can do it as default.



Studies are not ad tracking. It's worse and more like a backdoor for A/B testing of browser features. A few years back an update broke the Metamask extension and it was fixed by pushing via studies. At that point users weren't very aware the feature even existed and it caused some backlash since users realized there was a backdoor to push code into their browsers.

The backlash resulted in studies being opt-in, and I thought it still was but I don't know, I use "policies.json" to setup my browsers.



I don't mind the feature as opt-in, just like telemetry it can be useful. But depending on the threat model it can be a big problem. I still use Firefox as my main browser.



I think the problem is that chrome and firefox are developed for general usage, and as a result, have to deal with general usage constraints. For example, spectre and process isolation mentioned in another blog post here in the comments. I had a project in the past where I needed a browser with good JS support, but that does not make any http requests to any resources not in address bar or in the page rendered at that address. I did not find single browser based on firefox/chrome that fulfilled that requirement. Even the most privacy-focused projects still made continious requests to some mozilla resources (if i remember correctly, it was something about tls or maybe something else). So seeing someone creating an engine from scratch gives me hope that such browser might exist one day if I ever will need one again.



There's a difference between privacy and stealth. Modern browsers need to do things like captive portal sensing, ocsp checks, etc. If you want to disable all requests, you'll need to spend time cutting legitimate features. Or run it in an external sandbox which removes all networking access?



How's that alternative funded? Shouldn't Mozilla want to replace their Google payment with that instead? Or, failing that, wouldn't it be much lower budget to fork Firefox code instead?

And then to do it in C++ when other browsers and kernels are flirting with things like Rust. How long will it take for people to trust this new C++ code? I applaud the effort but am worried it'll be in vain. Then again, with how many projects I start not because they make sense but because I enjoy them, perhaps I should see it more in that way



That might be because Jamie Zawinski's website, which that link links to, does something ... special ... when it sees HN in the "Referer" field, so anyone actually following that link from here would (unless they take special measures) get IIRC a famous obscene image rather than the actual post you were hoping to link to.

(JWZ is not a fan of Hacker News and its community.)



All I see is a testicle in an egg-cup. Hardly special.

(Though it might be a good idea to special-case this to ad a non-referral link at submit time.)



Ah, OK. My hazy memory was that it was the goatse.cx image, which is for most people more unpalatable than a testicle in an eggcup, but I didn't check exactly what it was :-).



Flagged for what? In this case user - me - was unaware that submitted content gets replaced when requested with Referer header mentioning HN. There should be a 'you cannot post this' warning instead of hidden post creation. I only noticed shadowban by accident: switched to logged-in browser to submit and went back to logged-out for browsing.



> Flagged for what?

Flagged for being NSFW and devoid of interesting content. The average user, like you, is unaware that the content they are seeing is different from the content you submitted.



Even Mozilla doesn’t seem to care about Firefox; why should anybody else?

The primary value in Firefox existing right now is that the web standards process becomes dysfunctional when there are only two major browser rendering engines, but that is fading away with Firefox’s market share. Hopefully Ladybird can gain enough momentum to matter there because it doesn’t seem like Gecko can maintain its relevance.



We're in the current situation because Google could spend enough money on promoting Chrome. That's it. A different, or even better browser won't change that. Google can put a chrome ad everywhere again for a few months.



I feel firefox market share is mostly because they actively enshittificate their browser, and not because of google ads, or chrome being better.



I disagree, IMO the main reason they lost so much marketshare to chrome was because for a long time, chrome just was much faster and much more stable. Performance, stability, and compatibility is all that matters to most users.

Firefox (mostly) caught up with quantum and process isolation on the desktop, but by then I think it was too late. And the android version still has horrible performance, stability, and compatibility compared to Chromium browsers.

Mozilla just doesn't have the same engineering resources to poor into the browser that google does, so I'm not sure there's any way they can really maintain pace with google outside of becoming yet another chromium browser.



Doubt it. Things tech people complain about (like integration of Pocket) are completely irrelevant to the masses.

On the other hand, things like performance improved drastically, and it is now competitive with Chrome. Firefox the product is in the best shape it ever was.



There's barely any enshitification in Firefox. People like to complain there, because any tiny addition looks bad in comparison. But it's not even close to Chrome's default. An average user is unlikely to notice either though.

But while Chrome was growing, the ad campaign was crazy. You could not miss it - Google results, Gmail header, every Adsense anywhere. Everyone was told to install Chrome when they used internet, every day - there was no escape.



Technically nothing; the problem lies entirely in the Mozilla Foundation which takes about $500B each year from Google. Officially the motivation is to keep Google as preferred search engine, but seriously the Firefox user base is so small that I don't even think Google would be interested for much less if there weren't strings attached that very likely create a huge conflict of interest if Mozilla become dependent on that money for their own survival.

https://www.bloomberg.com/news/newsletters/2023-05-05/why-go...



Well to put it bluntly, Firefox is Google's bitch.

If we want the web to be a multi-vendor platform based on open, multi-vendor standards, as it has been for parts of its history, how much does Firefox really buy us? Do we really think that Firefox will take a hard stand against Google if their survival depends on not doing so?

I use Firefox, but I think it's no longer true to its original mission in a lot of ways, Safari's global 18% share goes a lot farther toward making the web a duopolized rather than monopolized platform than Firefox's tiny sliver does. The less -opolized it is the better for society, or need I remind you that Google is presently mired in court for its conduct in its other web-adjacent monopolies such as web search and web advertising?



What are you talking about? Mozilla repeatedly stands up to Google on big ticket items. Flock being probably the biggest in recent history, but you can throw Manifest v2 on the pile as well and about half a dozen others.



Around Firefox 4 it became a shitshow of questionable UI redesign every version. And performances where not up to Chrome.

Also Chromium is open-source, and Firefox is mainly funded by Google so it not like Firefox has a real proposition value or independence.



From my limited experience of Firefox-as-a-project, coming from the side of Thunderbird:

* Firefox is effectively not a community project. It seems to be ruled with an iron fist by the commercial side of the operation.

* Firefox broke its extensibility - which was the whole rationale of the Mozilla project to begin with.

* Lots of telemetry and call-home mechanisms, so much so that it is difficult to opt out even if you want to - in Thunderbird, and I believe also in Firefox; see : https://superuser.com/q/1672309/122798 (but correct me if I'm wrong and it's an app-specific thing).



Not irrational at all. It’s the first new engine in decades, started by a single person in the open with no multibillion dollar company behind. We have every right to be exited.



Could it be that the technical nature of your website creates a biased sample? I'd estimate that the difference between Firefox and Chrome users in spoofing their user-agent and blocking trackers is far less than the bias created by sampling HN for example.



Absolutely, but since that's my target audience, that's the number I personally look at. Statements like "no one uses FF" don't apply. How skewed each target audience is from the global average is meaningful.



I hope both Ladybird and Servo succeed in creating a new browser engine. Though I do have a slight preference for Servo as it's using Rust. Not that Rust is magical, but given how much attack surface there is in a browser, it seems picking C++ is a bit odd in 2024.



Personally if I were to attempt a project at this scale, I'd do so using a language I'm proficient in. There might be other reasons, but Rust & C++ really are different beasts.



Sounds like "Its hard, so it can't be done" to me. There are plenty of people making good software in C++, how else would we have what we have. Sure, things get bloated and break over time, but thats not due to programmers not knowing C++, thats just what happens as a product evolves. New coders get brought in, focus shifts, understanding of the code based erodes. Its not that language, its the process.



A related question:

What's the state with Servo?

Do I understand it correctly that Servo is the core of a browser but not the browser itself? How much work would it be to create a browser on top of Servo? And is there such a project?



It looks like the repository for servoshell was archived in 2019. What’s weird is if you go to their website and download the tech demo it’s basically the same thing but may actually be updated.



If they want adoption, maybe a good idea to build a hybrid ladybird/firefox browser, where, if some page does not render well in ladybird, the user can switch to firefox based rendering with a simple mouse click.



What would be the point of writing a whole new browser engine from scratch if you're just gonna fall back on a different one? Ladybird isn't ready and likely won't be for a long time. Treat this more like a "we're working on a new browser" type announcement, not a "We're launching a new browser today" announcement.



I was recently browsing their docs, and kept finding references to choosing a "browser chrome" (options including Qt and AppKit). Is this some new usage of the word "chrome" that I'm not familiar with, or does it use chrome libraries?



Specifically google originally chose that name for chrome because one of their goals was reduction of chrome. They made a bit deal out of it when the browser was new, how it didn't have a bunch of menu bars or whatever



It's a usage that predates and conceivably inspired Google-brand Chrome (and by contrast arguably Rust?), referring to the UI parts of the browser rather than, I think, rendering and javascript and stuff.



The term "window chrome" is common to describe the parts of a window that are outside the client rectangle and managed by the window system (titlebar, scroll bars, resize widgets etc..). AFAIK the term also predates "Chrome, the browser" by a long time.



The "chrome" of an app is the part surrounding the main windows, like toolbars and the such.

IIRC when Chrome appeared, the name was chosen because it was a browser without chrome (ie: it used to be just the rendering windows with the url bar on top), differently from other browsers at the time.



Firefox always referred to its user interface as the chrome (hence userchrome.css) and Google engineers decided that it should be funny to name their browser that.



I was very impressed by the build script. It worked flawlessly, detecting Clang and Ninja, and pulled in all the dependencies automatically. I am hopefully that this will develop into a serious competitor as there really should be more than 2 choices (KHTML-based vs Gecko-based).



From the linked site:

> In the post-Spectre world you must have site isolation. The JS for a site (roughly, eTLD+1) must have its own OS address space separate from other sites.

Wasn't the whole point of Spectre/Meltdown to read the virtual address space of a different process?



As I understand it: Spectre/Meltdown allow reading from the address space of the same process only. If browsers put different origins in the same process - which they used to - then JS code can break the same-origin security barrier and read details of other origins directly from memory. By putting each origin in its own OS address space they are protected from this attack as JS can still only read data from its own origin even when using security flaws to read any part of the address space.



> As I understand it: Spectre/Meltdown allow reading from the address space of the same process only.

Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space? Just a regular code execution exploit should do it.

Here, I found the relevant info (that I was too lazy to find before I posted my first comment, apparently):

https://meltdownattack.com/

> While programs are typically not permitted to read data from other programs, a malicious program can exploit Meltdown and Spectre to get hold of secrets stored in the memory of other running programs.



> Sorry, this does not make much sense. Why would you need a timing attack to read memory from your own address space?

If you're making a VM such that the running code can only access a particular array, Spectre allows a timing attack that can get malicious code in the VM access to the full memory space.

You're right that it's not that scary for most use cases. What it really means is that it's hopeless to make memory inaccessible to a sandbox without putting a process isolation barrier betwixt the two, as there's no real way to close out all of the timing attack possibilities. In principle, if the only thing you needed to foreclose was memory vulnerabilities, then sufficiently good programming™ would let you have the sandbox in the same process space; as a matter of practice, though, anyone looking at product security seriously would still make you put in process isolation, because that kind of good programming just doesn't exist at scale yet.

(Note that Meltdown, but not Spectre, allows timing attacks that cross process isolation domains.)



It is a perfect time for new browser. I long for the days of good old Opera, when each release brought something new and fresh. Multiple browser windows in tiled layout, browser gestures, disabling image loading from UI (although that was standard feature in dial-up era of internet), UI customization, integrated email client and feed reader.



I don't want to discourage the developers working on this project, but I'm curious why we're still writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract?

Have we not learned our lesson yet, or am I misunderstanding the situation? I believe it was a Microsoft study that linked unsafe memory access to ~70% of exploit chains.



I'll take an alternative browser engine, even if it's written in C++.

> I'm curious

Is it really curiosity though? Because the answer is straightforward, the project started as a hobby, the developer picked whatever language they were proficient in. Andreas is open with the fact that he started Serenity OS and LadyBird as a rehab project. Put too much barrier in this setting (like learning a new language and all the ecosystem) and it might not happen at all.



It’s curiosity because I’m involved in software security for the company I work for and I’m a software developer that primarily works with managed languages. I unfortunately lack the technical expertise to make an assessment on interpreters and virtual machines. I am, however, aware that many of the CVEs that I review involve reading/writing memory outside the intended bounds. Many of these while processing user generated content.

I appreciate that the author birthed the project as a way to direct his energies towards more productive means. I don’t think it’s relevant to the question though.



>> I'm curious

> Is it really curiosity though?

I'm kind of annoyed at this whole train of comments ("I'm curious..."). In so many occasion I see something cool and the main comment track is "why hasn't this been writte in rust?" (or some other allegedly safe/better programming language).

It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.

It's so sad.



> It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.

No it is not. You don't use your browser for its artistic value (which is in the eye of the beholder). You also don't make an announcement for a painting.

This is more like using a non-inox screw in a high-humidity environment. Yes, it will hold on for a while. But it is objectively a bad choice. Non-inox may had been the only choice 300 years back, but this is 2024.

And writing a browser from scratch is a huge undertaking. When you invest resources in such a project, you probably want it to be more weatherproof than its C/C++-based predecessors. So it is quite reasonable IMHO to ask why C++ was chosen for this project.



90% of all safety critical software is written in c/c++

There is no good safety language right now to write a browser in, except for c/c++. Rust might sound like an alternative but it's safety story is sad when compared to c/c++.

Ada might be a cool option, so is ATS.



That’s a pretty cynical view. It’s more like asking why a car manufacturer is developing a car without modern safety mechanisms despite knowing those mechanisms save lives.

If this is a work of art whose code is to be admired and only viewed as a creative work, fine I’m sorry I asked the question and that it was criticism of one’s vision.

However, if this is something that is intended to be “driven” by other users in the future I think it’s a perfectly acceptable question to ask why more modern safety mechanisms are not being employed. Maybe there is a rationale I’m unaware of or a reason why those mechanisms are not employed.



It's not cynical. It's how many of us feel when we read a comment like this.

I believe you are right. But I also think that your phrasing is not very nice. It shows a lack of empathy and understanding and feels entitled.

You could convey essentially the same message but be way nicer to everyone involved, and that would be way more efficient.

If your ideal is a browser engine written in a safer language, and want to work towards that goal, phrasing things the way you did in your comment is one of the worst way to do it because you risk putting off people and they will associate this bad feeling to your idea. See how people react to comments about Rust.

Some of your options are:

- writing a browser engine yourself, in a safer language

- contributing to an existing browser engine like Servo

- convince projects to switch to a safer language, or to accept contributions in a safer language

- convince someone or a group of people to do those things

- fund such an enterprise

At this point, the world needs proof that a browser engine can practically be written in something else than C++, because it's what all three major engines are written in. There are strong evidences that Rust can be an option given the existence of Servo, but look how Ladybird is progressing so absurdly faster than Servo.

If you don't work yourself towards your goal, you can only humbly share your wish.

Lobbying is fine too, but you really need to make sure you don't make others hate your idea because of the way you communicate. Specifically in this topic, you need to take in account that many people are already annoyed by the numerous "why not Rust" comments, so you are walking on eggshells.

What's more, don't forget the global picture, and that security (although critical, we agree) is only one aspect. Security is irrelevant in a project that doesn't even exist. C++ is better than other languages for a lot of reasons in other aspects and you will need to address this, in the context of writing a browser.

Good luck in your endeavors, I hope you succeed, I believe it's a good ideal.



I will attempt to word my questions/thoughts in a less confrontational way in the future. I tend to write my questions in the same way they occur in my internal monologue. I understand how that comes across to some.

I’m happy there is someone out there genuinely interested in creating another alternative to the near monoculture that is web browsers. I hope that they gain traction in the open source community as well as wider adoption upon maturity.

I’ll try to follow the project development and maybe I can learn myself why other languages may not be as well suited as C++. It seems that language proficiency is the most common answer I’ve received besides earned criticism of the way I formed my question.



> It's like seeing a beautiful painting being painted and arguing about the kind of paintbrush the painter has used.

It's like seeing a beautiful painting and realizing the painter didn't use lightfast colors. In ten years the painting will not be beautiful anymore.

Yes, the painter / author put in a lot of work, and this deserves acknowledgement. But ones decision to use it or not is not only based on the amount of work put in.



It's more like seeing a beautiful painting and complaining that the painter didn't use your favorite brand of paint which promises to be much better looking than the other paints in ten years but hasn't even been around that long.



On the v8 engine's blog, it is claimed that most of its vulnerabilities are caused by logic issues which Rust wouldn't help with.

Perhaps it's a similar situation for Ladybird.

>Memory safety remains a relevant problem: all Chrome exploits caught in the wild in the last three years (2021 – 2023) started out with a memory corruption vulnerability in a Chrome renderer process that was exploited for remote code execution (RCE). Of these, 60% were vulnerabilities in V8.

> V8 vulnerabilities are rarely "classic" memory corruption bugs (use-after-frees, out-of-bounds accesses, etc.) but instead subtle logic issues which can in turn be exploited to corrupt memory. As such, existing memory safety solutions are, for the most part, not applicable to V8. In particular, neither switching to a memory safe language, such as Rust, nor using current or future hardware memory safety features, such as memory tagging, can help with the security challenges faced by V8 today.

See: https://v8.dev/blog/sandbox



40% may not be a majority, but it's still close to half of all Chrome exploits in the wild, and they could be avoided with a memory-safe toolchain. (Doesn't have to be Rust.)

As for the other 60%, they point to logic errors as the root cause, but that's true of all memory corruption bugs: they wouldn't exist if there weren't logic errors behind them. The actual difference here is that the vulnerabilities are either in the machine code generated by the JIT (e.g. type confusion), rather than V8's own code; or they're in code they insist must be memory-unsafe for performance reasons.

So the takeaway there should be that JS engines for hostile code should either not use a JIT at all, nor memory-unsafe code paths, or use stronger tools to verify the correctness of the JIT and those code paths. But hey, retaining the capability to speed up bloated web apps ever so slightly is more important that



I believe the fact that V8 vulnerabilities are not "classic" memory corruption can be attributed to their developers' experience and review processes.

This doesn't imply, though, that another project in C++ will share these traits.



Andreas (the author of ladybird) started a language[0] that would be memory-safe and in which he would eventually write SerenityOS (and I assume LadyBird too). He hasn't committed to it for 6 months now so not sure what the status is.

At the end of the day, LadyBird is still a hobby project, so one of the main objective is to have fun which does not always coincide with rationality (although the decision to move on from NIH[1] is a sign that this might be changing).

[0] https://github.com/SerenityOS/jakt

[1] https://en.wikipedia.org/wiki/Not_invented_here



Ladybird is sponsored now and I seem to remember that Andreas is paid full time to work on it. I don't think Ladybird is still strictly a hobby project anymore.

But it was definitely started as a hobby project so your point still stands, mostly.

(to be clear, I'm not answering to the question of which programming language should be used to write Ladybird)



Jakt was described more as an experiment and to potentially replace C++ in the codebase, rather than definitely. I haven't seen any official word on this but as you imply I would assume that this effort is essentially dead now. Just as with the operating system itself, the focus eventually shifted elsewhere and Jakt was left behind.



> but I'm curious why we're still writing applications

> Have we not learned our lesson yet,

"We"? Do you speak in the name of the developer? What an odd choice of pronoum.

Either way, if you are adamant about writing a new browser in your "memory-safe language" of choice, be the change you want made. Go ahead and write a new browser from scratch. Show the world how it should be done.



I meant we as in the collective, and I explicitly referenced the collective of those writing applications that process and/or execute user generated content. So no, I don’t think it appropriate to focus my question on the author or this project. I am wondering if C++ is a better choice for reasons I don’t understand when it comes to HTML/JS/CSS, despite potential security implications as the complexity grows.



Because writing a browser in ATS or Frama-C is not possible. Or writing it in Coq and exporting it to ocaml and friends. Ada can be used but its mediocre at best and sucks at places where frama-C shines. A lot of pointer stuff that is easier to prove in ATS or frama-C is impossible in Ada [and by extension of that, rust] TLA+ can be used in mix with C++ just like how 90% of safety critical software is written but the development speed is very slow for it. That leaves Rust, which is a...mediocre language if you really care about safety. It has no idea of linear types that ATS has and cannot carry embedded proofs like Frama-C. Plus the culture regarding safety critical software in C/C++ is humongous and tbh fairly amazing. I cannot remember exactly but there are many projects targeting C++ for safety purposes, even the people behind frama-C are creating something called as frama-Clang to allow writing safety critical code in C++ backed by proofs.

Are there any other languages that im missing? If ATS has a prettier syntax, it'd be my candidate for writing a web browser in.



Note that despite that study, Windows and XBox teams are quite found of their C and C++, and even their own .NET has more success on the Azure side, than replacing all those COM/WinRT C++ workloads, and extension points.

It is Azure that is more keen in adopting memory safe languages, and has the mandate that new systems code should be done using them.



> Note that despite that study, Windows and XBox teams are quite found of their C and C++...

And we all know how secure the average user's Windows computer is.

And Windows' security is so good that it's Windows who's powering tens of billions of servers, smartphones, IoT, appliances, routers etc. throughout the world? Oh, wait, no... These are all running Linux.

And the uptime. Let's not forget the uptime with patch tuesday.

Windows does not strike me as the ecosystem we should strive to immitate.



> in languages that don't maintain strict memory safe contract?

for the same reason people still use the English language, despite being full of crazy inconsistencies and being very hard to become a native speaker, coming from another language: proficiency.

Proficiency is one of the most, if not the most, valuable metric when choosing the tool you will use to take on some complex/daunting task.



The language “legalese” was invented when it turned out that being proficient in English does not protect you against malicious contract partners.

(The success of legalese is still debated, but its existence is generally accepted)



legalese is a subset of English.

BTW Rust (or any other so called "memory safe" language) is not the equivalent of legalese, it's the equivalent of using French because it's the "language of diplomacy" (that's why many English words come from French) instead of English.

If you're not proficient in French, French legalese won't save you.



Could you explain your thinking a bit more? To me the "language of diplomacy" equivalent for computers sounds more like C calling convention, HTTP and XML or JSON.



Nobody is saying there is a programming equivalent of the language of diplomacy. He said that using Rust to achieve memory safety is analogous to using French for diplomacy, in that, whatever value the language itself might bring to that goal, you are not likely to achieve it if you are not proficient.

If you are not proficient in French, you likely ought not to conduct diplomacy in French.

If you are not proficient in Rust, you likely ought not to achieve memory safety by writing everything in Rust.



Ok, I'll try to explain.

- French itself does not add much value to diplomacy. The reason to use is that everyone else who does diplomacy is expected to know French (and probably isn't a native speaker which makes things a bit more equal). English is probably taking over there, like it has done in other domains.

- The recent C++ versions are not actively promoting shooting yourself in the foot like older variants, but they aren't exactly trying to prevent it.

- Rust is going out of its way to prevent writing memory unsafe code. It is still possible if you know what you are doing, but just trying out stuff at random is more likely to give you a compile-time error than undefined behaviour.

- Most programmers aren't very competent, not matter what they believe about themselves. With Rust they are less likely to commit serious errors. Or get anything done, but that's a separate discussion. The French will probably point out your pronunciation mistakes too before continuing discussion, but that's also not the point here.



Don't do this. Requesting an explanation just to get an excuse to launch into a spiel is deeply dishonest. Furthermore, ideological battle is against HN Guidelines.



> - French itself does not add much value to diplomacy.

Funny, given that the word diplomacy is a French word, together with embassy, treaty, alliance, passport and protocol :)

> Rust is going out of its way to prevent writing memory unsafe code

But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.

It's a common complain among non Rust programmers.

> Most programmers aren't very competent

I strongly believe Andreas Kling is very competent.

For the rest of us who are not him, incompetence does not go well in hand with Rust, which is a very complex language.

EDIT: pretending that a very proficient C++ programmer will chose Rust because "it's 2024" it's the same thing as pretending that they will chose Haskell, which is equally memory safe and also equally complex.

Why nobody ever recommend Haskell or Smalltalk?

It doesn't seem much like a discussion about memory safety to me, but rather promoting Rust.



> Funny, given that the word diplomacy is a French word

This is true. But it only tells about the cultural dominance that France had at the time the convention started. If history had happened differently, Chinese, Hindi or something else could be in similar position.

> But if someone is not proficient in Rust it will only slow them down and they'll end up fighting the language and the compiler instead of using the language.

This is indeed the choice. Make it difficult to write code but more likely that the result is correct, easy to achieve high performance but risky (C++ and similar) or just accept the overhead of checking everything over at run time (JVM and CLR languages, etc). I would say there is a niche for the first.

> Why nobody ever recommend Haskell or Smalltalk?

I think at this point it's well known that the pure functional lazy evaluation model rules out too many useful data structures and makes it easy to introduce accidental complexity. As for Smalltalk, it seems (I've never actually used it) to me that most of its once unique ideas have been copied to current mainstream languages. It also seems to have a huge number of fragmented implementations and most of them seem to have a heavy runtime virtual machine.



> This is true. But it only tells about the cultural dominance that France

French is still very much relevant, but it took centuries to make it less relevant than before to the point where we are now.

Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future. See: Ruby on Rails for web development.

> This is indeed the choice. Make it difficult to write code but more likely that the result is correct

I don't buy it.

Making it hard to write code it's nobody's choice, it's accidental complexity, that any sane language designer would avoid if possible, because it severely hinders the language adoption.

The opposite is also true: code easy to write will also be more easily correct.

Elixir is easy to write and will almost automatically be correct in complex scenarios such as distributed systems.

> pure functional lazy evaluation model rules out too many useful data structures

Rust is Haskell with a different syntax though and makes it very hard to write simple linked lists.

> most of its once unique ideas have been copied to current mainstream languages

same happened to FP, ROR and it's happening with Rust

Even Java is more functional than ever, because it's a good paradigm, not because it's a fad.

Again: this seems to me more promoting Rust than a discussion about memory safety and I am really not interested in that. So I'll see myself out.



> Rust in comparison is minutes old and there's no evidence it will dominate the field of system programming in the future.

This is true (for some values of minute). It is also why I was suggesting that C calling convention, HTTP etc, not Rust, would be the computing lingua franca. Now that I think of it, a few years ago TCP/IP would have been on the list but now with HTTP/3 it's not that certain any more.

> Rust is Haskell with a different syntax though...

This is quite bold claim, but if you have a rigorous proof beyond "all Turing complete languages are the same" I would be interested in seeing it. It's a pity you left.

> ...makes it very hard to write simple linked lists.

This is interesting in the light of the beginning of the sentence, because in Haskell linked list is the easiest data structure. Simple linked lists aren't always that simple though. There is a reason why they used to be a recurring technical interview question.

> Again: this seems to me more promoting Rust than a discussion about memory safety

Funny, to me this seems more about promoting JIT and garbage collection. Nothing wrong with that, as long as you admit that there are niches where those are a problem but memory safety is still useful. And so far there haven't been other serious language candidates for that niche.



This makes the most sense and thank you for offering a genuine answer to my question. Which leads to a follow-up question.

Has the rise of these memory safe languages caused any shift in the proficiencies of the average developer?

I see a lot of younger people gush over python early in their careers but see a lot of Java/.NET in enterprise.

I personally grew up learning Delphi, PHP, and HTML. Java and .NET came later, but I rarely had a hand in initiating the projects so my language proficiency typically flowed with the job/project I was working on professionally.



> why we're still writing applications

> Have we not learned our lesson yet

Why are you speaking like this project is asking you to write code in C++? You are free to exclusively write Rust. Other people writing C++ has 0 impact on what you're writing or what lessons you've learned.



Because rust is a cargo cult. We're nearing 10 years since 1.0 and there's still not a single serious, widely used, large software project to prove its viability. Maybe make one instead of trying to passive aggressively convince others to do it for you?



I didn’t mention rust, I don’t know Rust and if I were trying to start a similar project I might do so in .NET Core because of my familiarity with .NET. I’m asking because I don’t know if there is a reason it would not be viable, is the garbage collection too much of a hurdle to get decent performance while trying to interpret JavaScript? Is there too much overhead tracking claims on memory and doing the bounds checks? I’d assume the same checks eventually have to be written in C++ too?



I apologize - when people mention "memory safe" nowadays 95% of the time they're talking about Rust, I made an assumption.

Interpreting JavaScript at all it at all is a problem. Ladybird's LibJS compiles it to bytecode and interprets that (which is usually better than intereprting the AST). The bytecode interpreter is written in C++, and it's still pretty damn slow - websites take a long time to load, and LibJS is the main bottleneck.

The reality is, modern websites throws so much junk at your JS implementation, that you basically need to JIT-compile it in order to have any sort of reasonable performance. And with JIT all memory safety guarantees are thrown out of the window - it doesn't matter if you write your compiler in Rust, C++ or a .NET language - if there's an exploit it's disproportionately more likely to be in the output assembly than it is to be in your compiler.

Browsers nowadays make a best effort, and they have a stack of other mitigations in case the JIT leaks: https://chromium.googlesource.com/chromium/src/+/main/docs/d...



This may be the biggest gap in my understanding. I didn’t realize that at some point the JavaScript is turned into instructions running directly on metal, I thought everything occurred within a synthetic/virtual environment.



> writing applications that will almost certainly execute or process hostile content in languages that don't maintain strict memory safe contract?

That point is 50% FUD. A language which "maintains strict memory safe contracts" but has an `unsafe` keyword; or has a "native code interface", or uses libraries implemented in a different language, doesn't really strictly maintain its guarantees. And on the other hand, a language in which you can, in principle, load and execute arbitrary code from a string you got from the user, can be hardened very well by statically-checkable constraints.

So, it's a matter of degrees rather than absolutes. If you then add considerations such as programming paradigm flexibility and performance, C++ is very much a valid choice even for the use case of a browser.



It's crap programmers that write buggy code, and they will write similarly buggy code in any language. It's not hard to write memory safe code, most people are not skilled enough to do it. I doubt they will be skilled enough to write good rust.



I'm very happy that projects like this exist, and hope that they succeed in their mission.

With the current state of the web, filled with mostly spam content designed to generate ad revenue and to exploit the user, accessed from mainstream browsers produced by large corporations that are increasingly trying to do the same thing, web users are being squeezed from all sides. Using the web today is a hostile experience, and the only safe haven from all this nonsense is using community-supported alternative browsers, that are really stripped down versions of mainstream ones, and relying heavily on ad, cookie, JavaScript and other blockers, which may stop working at any point. This is a difficult task only tech savvy users can realistically do, while most other users have no choice.

A new, independent, browser alone will not solve this, but it's certainly a step in the right direction.



> Using the web today is a hostile experience, and the only safe haven from all this nonsense is using community-supported alternative browsers, that are really stripped down versions of mainstream ones, and relying heavily on ad, cookie, JavaScript and other blockers, which may stop working at any point.

I think the actual root of the problem is that the people and organizations developing and running the sites do want to force the ads, analytics and other things upon you and you as a user basically have to hack around that. If the users actually took a stance with something a bit like https://en.wikipedia.org/wiki/GNU_LibreJS then the sad reality would be that you just couldn't use most sites altogether.



I found NoScript to be a good alternative. It disables JS by default but then you can reenable per page but also per domain. You only enable just what you need for the page to work and sometimes only temporarily.

I still need to enable things here and there but it's a fairly easy straightforward process.

Couple this with uBlock and firefox Container (where I am logged to google only for gmail in a specific container) and the web is pleasant again



uBlock Origin already supports Javascript blocking (both globally and per domain) if you enable advanced mode. Redundant extensions are just extra attack surface.



Ladybird has a good use case on embedded projects where there is a need to use a well understood API for small gadgets acting as clients. I wish success.



> Ladybird now targets Linux and macOS. The SerenityOS target is dropped.

What does this mean, that Ladybird will no longer run on Serenity OS? And that is up to the Serenity peeps to make it run should they wish to do so?



Yeah and I believe the reason given is because Ladybird wanted to use third party code and SerenityOS has a no third party code policy which made targeting Serenity kind of hard.



From GitHub.

> Ladybird is a truly independent web browser, using a novel engine based on web standards.

So I assume they want to build a truly independent web browser instead of leaving the Browser market to Google, Apple, and Firefox (relies heavily on Google ad revenue.) and executives that run them who are primarily motivated by money.

联系我们 contact @ memedata.com