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 plus the JS garbage collector cause jitters & frame drops that most people don't consciously recognize, but everyone subconsciously recognizes. These little bits of jank are why consumers can recognize webview-wrapped apps vs. native apps.

Don't get me wrong — HTML and CSS and JS have brought us far, and the zero-trust execution environment that is the browser is an amazing feat of humanity.

I hope the "new ways of doing things" you describe include a major innovation on HTML and CSS and JS. WebAssembly makes this possible today — and I have dedicated the last few years of my life to proving this concept[0], and I hope others explore similar avenues. We deserve a better substrate, and this can be done without reinventing the browser.

[0] www.pax.dev

> There has never been a better markup language.

> It has been the best thing for accessibility we ever came up with.

I observe past tense in both sentences above.

So perhaps we agree, the salient question is: is it the best thing we can come up with? With a focus on the future.

I argue we can do better, while celebrating and building off of what's great about the past & present.[0]

[0] https://docs.pax.dev/intro-priorities-and-prior-art/#:~:text...

All other content representation infrastructures that weren't text first, like java applets or flash died because they were no match for HTML.

That and, of course, the half-page box telling you how much better off you'd be if you were using the app.

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

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

None of these is a perfect technology, but I believe the most practical answer to the question driving this thread[0] is to study/understand the landscape, then build towards a better future.[1]

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

[1] www.pax.dev

Alternate layout engines for the web might be a fun experiment, PhD thesis, or talent retention program, but it's not practical.

Flexbox was once an "alternate layout engine for the web," as was Flash player, as is Figma. Framer, Retool, and Squarespace all offer alternate layout engines tailored for visual building. All of these seem practical to me.

It's one of the core things that has enabled the web to be as useful as it is. One of the things that draws people in, and keeps them using it.

Yes, there are problems with what we have. But if you break compatibility, you'll either not be adopted, or part of the crowd that the audience yells at for taking away their favourite things. You'll kill efforts and bury knowledge bases.

Taken to an extreme, "don't break backwards compatibility" has an insidious failure mode, which is "don't innovate." The car could not have come about without a willingness to break backwards compatibility with horse drawn carriages, plows, mills, hitching posts, etc.

The adoption of a radically new technology like this is voluntary, collaborative, and progressive. Provided it offers enough value to exceed the switching costs, there's no need to kill efforts or bury knowledge bases.

Hi {firstName}

and also requiring double the number brackets

There are modern cleaner markup alternatives like kdl

We predict 95%+ of Pax will be written by machines, especially visual design tools and LLMs, so verbosity becomes less important (LLMs may even benefit from explicit closing tags.) We're innovating on multiple axes, including language, so we chose to make the syntax itself as boring and uninnovative as possible.

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 when you're doing new design?

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/syntaxes could de/serialize from the same persisted data.) So folks who want closing tags can have them; folks who want a YAML-like format could have it; folks who want a KDL-like language could have it.

At the language level, Pax's distinguishing characteristic is that it's the union of an expression language and a markup language; this is the reason we couldn't use an off the shelf markup language / parser. But again, KDL or YAML could be extended with PAXEL to make pax-kdl and pax-yaml flavors alongside pax-xml.

We had to start somewhere, and starting as close as possible to the markup lingua franca (HTML) made sense to us. It'd be a dream for Pax to be loved / adopted enough that we or anyone else cares to make a syntax skin.

(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)

I'm biased but I personnaly find the language really productive to work with, runs fast enough for my needs and let's me target more and more platforms.

> First off, Swift has both memory & data race safety (as of v6). It's also a modern language with solid ergonomics.

> Something that matters to us a lot is OO. Web specs & browser internals tend to be highly object-oriented, and life is easier when you can model specs closely in your code. Swift has first-class OO support, in many ways even nicer than C++.

> The Swift team is also investing heavily in C++ interop, which means there's a real path to incremental adoption, not just gigantic rewrites.

https://x.com/awesomekling/status/1822236888188498031

https://news.ycombinator.com/item?id=41208836

As of Swift 5 there is zero data race protection and the process model (DispatchQueues if memory serves) is woefully. No advantage over fork and much more convoluted

I am well clear of the Apple development world now (thank goodness) but the tools were of very poor quality, albeit very nice looking, as of this time last year

For the sake of my friends still in the world I hope Swift 6 is better, but I fear the dumpster fire that is Xcode is too far gone to rescue.

The comparison with Rust demonstrates the utility of "design by committee ". Rust is far from perfect, but feels like the future where Swift feels like warmed up Objective C

Swift Concurrency is the replacement for Dispatch and has been around since Swift 5.5 in (IIRC) 2021. It’s a completely different system, uses lightweight tasks (a la tokio in rust, or goroutines in go, etc), has a concept of “Sendable” for thread-safety a la rust’s Send, async/await, and a native `actor` type, among other things.

Swift 5.5 didn’t get all the way towards rust-style data race safety due to a few things they had to make warnings instead of errors (to avoid breaking existing code), and introducing keywords like `@preconcurrency` when importing frameworks that predate Swift Concurrency, to facilitate incremental adoption. They’ve also been adding more checks in each minor release to tighten things up.

IIUC Swift 6 is mainly going to turn all the warnings into proper errors and tweak some defaults so that you get proper data race protection on a default compile.

Point is, it’s totally inaccurate to say that Dispatch Queues is all that exists in Swift 5. You’ve had much better stuff for a while now (although SC still has a ton of issues worth discussing.)

When I experimented with it it was trivial for one thread to interfere with another. So Swift got nowhere towards data race safety. Still stuck in the 1990s

I know not what you mean "Swift Concurrency". When I was doing it all we had was DispatchQueue which was an obfuscation of `fork`. Quite shameful really.

I think the main point is that Swift is a failure.

"although SC still has a ton of issues worth discussing" once I would have cared, but this year (decade, century) I am just very glad putting meat in my fridge no longer depends on those rouges from Apple who treated me so badly when I was sweating so hard making software for their platforms (not to mention paying them so much money). In 2024, for a company like Apple, for their flagship developer offering, why would anyone still have "a ton of issues" with it?

Apple is now an example of why popularity is a terrible metric to estimate quality of technical offerings. What a shame. How far the mighty have fallen

Swift has async/await built into the language with many compile time guarantees of thread safety.

I just looked it up. It is Swift's version of async/await. That is a different thing from threads. I know what that is, used it a lot, because using threads was such a nightmare in Swift.

> language with many compile time guarantees of thread safety

From two separate threads you can access the same memory. No trouble (apart from crashes memory corruption....) at all.

Async/await is always a bad idea, and without a garbage collector it is a nightmare (look at the mess Rust has gotten into). Whatever, async/await is no replacement for parallel programming with threads. It is a different beast.

Since you “just looked it up”, maybe don’t make blind assertions about something you clearly don’t know very much about?

It’s a lot more than async/await. It is a way to offer compile time guarantees about thread safety (through Sendable, which is part of SC), it’s an actor model (allowing shared mutable state to be isolated, leveraging async/await for coordination so that callers can pause if the actor is currently servicing another message) and a bunch more stuff.

I explained all this in my post you replied to, maybe read the whole thing before making wrong claims about stuff you spent 1 minute looking up?

Is it not for the vast majority of use-cases?

Sure, you can use async/await without parallelism, via a single-threaded runtime to just get single-threaded concurrency, but with a multi-threaded worker-pool async/await-like tasks or fibers I think mostly cover the use-cases you'd have for parallelism?

You have to make sure that you e.g. don't starve other tasks via having no yield points in a task that does a lot of computation (if you're doing cooperative tasks which Swift is doing iirc), but that's not a big one, and can mostly be solved by the runtime too (e.g. Go had cooperative fibers for a long time, until they chose to introduce preemption).

Have you missed Tasks and Task Groups as well? And Actors? For now, they are an abstraction over threads, and IMO a good one. It’s actors + structured concurrency, borrowing from Kotlin‘s Coroutines and sprinkling some Erlang on top. Additionally, in Swift there is AsyncSequence + AsyncStream, a (woefully incomplete) Kotlin Flow alternative.

If Swift's model is anything like .NET's lightweight Tasks + async/await or Rust's async/await Futures and Tasks as implemented by Tokio or async-std, then it is such replacement.

I had to do a very simple macOS app for my personal consumption recently and XCode dx is nothing to write home about. The only reason I finished the project there was that I couldn't set up vs code quickly for Swift/Cocoa project. I had to endure the slow compilation time, slow reaction time of the IDE UI. You make a change you keep seeing squiggly lines for a while, it's as though the UI is booting up each time. It was a horrible experience coming from IntelliJ and VS Code daily experience.

Computer is 32Gb Apple M1 Pro. Imagine what will happen on some 8Gb i5 macbook.

We tried and tried but there was nothing we could use amongst the blinking lights and wonderful graphics.

I don't know if it's still the case, but there was an annoyance where you couldn't have a type with the same name as the package. But that is hardly a lack of namespaces.

However, Apple's history is very much stacked against Swift becoming a mainstream language outside of Apple's platform.

HN majority doesn't like hearing that ladybird et al might just be wandering around, even if the goal is catnip for the bleachers, and we should be skeptical this is the year of multiplatform Swift, because it wasn't last year if you actually tried it. Or the year before last. Or the year before that. Or the year before that year. Or the year before that one.

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 low enough level that it won’t matter so much.

In the long run, it would be good to have high-level languages other than Java that have garbage collection (at least optionally) and classes, and that are still capable of doing cross-platform system development. I don't know if Swift fits that bill, besides cross-platform ecosystem (a la Java), submitting the language for ISO standardization (not just open sourcing one implementation) would be a good indication of being serious about language support.

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

C#

Ladybird as a separate project has the goal though of something usable in the shorter term. So similarly with switching to 3rd libraries for things I don't think it makes sense to spend potentially years first building the language before building the 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, so we'll put in the effort in to bootstrap a cross-platform ecosystem and UI frameworks. Or maybe we'll just do our business logic in it? It's a confusing mess that is irrational. Even with great blessings of resources. ex. $X00M that Arc has obtained one incremental platform after a year. And "all" they had to do was Swift bindings for WinRT and connect it to the existing C++ engine.

All of this is easy to justify if we treat it as an opportunity to shoot for how we wish software could work in theory, instead of practice. I hope I'm wrong but after being right the last few years, I'm willing to say it's naive wishcasting out loud, even though its boorish. I see it as unfortunately necessary, a younger me would be greatly misled by the conversations about it on HN. "We've decided to write the browser in Swift!" approaches parody levels of irresponsible resource management and is a case study in several solo engineer delusions that I also fall victim to.

It's genuinely impossible for me to imagine anyone in my social circle of Apple devs, going back to 2007, who would think writing a browser engine in Swift is a good idea. I love Swift, used it since pre-1.0, immediately started shipping it after release, and that was the right decision. However, even given infinite resources and time, it is a poor fit for a browser engine, and an odd masochistic choice for cross-platform UI.

It is unfair to compare a twenty first century language with one from the 1980s

Rust is the proper comparison

The only advantage Swift has is an easier learning curve , but the ergonomics of Rust are far superior than Sift's

I’ve written both Rust and Swift while being an expert in neither. I wouldn’t say Swift has no pluses in comparison, reference counting is often a lot easier to reckon with than lifetimes, for one. I’m actually curious what a large multithreaded Swift codebase looks like with recent concurrency improvements. Rust’s async story isn’t actually that great.

I agree. People's perspectives differ. It abhor `async/await` in Rust. It has poisoned the well IMO for asynchronous Rust programming. (I adore asynchronous programming - I do not need to pretend my code is synchronous)

But that is taste, not a comment on poor engineering!

The lack of the borrow checker in Swift is what makes it approachable for newcomers, as opposed to Rust which is a harsh mistress.

But reference counting is such a silly idea. Swift really should have a garbage collector with a mechanism or subset to do that very small part of programming that cannot be done with a garbage collector. That would have been design!

I fear that Swift is going to get a borrow checker bolted on - and have the worst of both worlds....

The great thing about automatic reference counting is you can elide the incrementing and decrementing a lot of the time. Stronger guarantees, such as saying "this object is single-threaded" lead to even more optimizations.

He also built a totally from scratch operating system, and built a very productive and skilled community around it, which branched into building their own web browser as SerenityOS has an 'everything from scratch' policy. How is Serenity not an interesting feat of engineering?

You seem to call it a 'toy' because of where the development is at - this is grossly unfair criticism. By your measure, is all software that isn't at a 100% finished state a toy?

On the (long) odds that you get all the way to a successful class-action suit, the lawyers get rich, and the class members eventually end up with a free year of credit monitoring

(we have seen this over and over again in settlements for high-profile data breaches)

If the development work went into debating, specifying and expressing required behavior as a written spec more exactly (beyond w3c specs and towards the more pragmatic reality of what current browsers actually do) then very long term we can probably have engines that are AI built [or just more easily developed by humans] from a combination of the written specs and the set of tests they need to pass.

Using AI for adversarial development (e.g. one group tries to break and hack it, the other group defends and refines) could get interesting and wasn't really an option before. Anything that's now available to reduce the human resource cost of development could make a big difference.

Edit (with Firefox): the above text is from Verso. Logging in works (though the session is not stored across restarts), as does both commenting and editing comments. Since space can't seem to be entered, word wrapping doesn't work with text entered in Verso, though it does seem to work when there is text with spaces (eg, this edit). A cursor also doesn't appear for me, making editing a challenge.

At least on mobile.

This is most likely a server “feature” and thus a rewrite of the frontend won’t fix it but it seems like at very least the frontend could display a sane error message (assuming the backend forwards some information about the cause of the error).

And Rust can still have unsafe code so it can crash in memory unsafe ways too (though it is very unlikely unless you're doing things very wrong).

From when I grokked the code a bit (back in 2017) there was a non trivial amount of unsafe code, especially related to integration with SpiderMonkey (the js engine) so it wouldn't even be particularly surprising to see segfaults in servo, unlike most rust projects.

There are two window title bars, one by the OS and one from the application. The text in the URL bar is misaligned and is shifted down by half its height. There's a black bar between the browser chrome and the web view. Entering a domain name without http or https and hitting enter crashes the entire application.

Clicking refresh spawns a new window that sort-of-but-not-really shares the same website being rendered.

Very few websites work. Anything with a cookie banner just plain breaks. I can't tell how to edit the URL bar after failing to load/loading a page. Google.com is very wonky. The search box on Google doesn't seem to take space bar for some reason.

For the websites that do work, rendering is very fast and scrolling is pretty smooth. I can see the potential, but there's a lot of work to be done.

¹ https://servo.org/download/

It should be possible to write a simple shell script to navigate the web, to log in to web sites, to extract information. Or something like Visual Basic.

1. Translate the word to another language.

2. Get creative and make up an original name. Mixed translations, word-bashing, not-actual-words, there's a lot of options!

Okay, so the latter isn't super easy but can be a lot of fun to do!

In this case, it seems like a play on the core dependency name than choosing the actual word of "verso": servo -> verso.

Is there some chance, that servo decomposed from SpiderMonkey? If it is not, I don't think anyone can tell difference between firefox and other browser use Servo.

> A web browser that plays old world blues to build new world hope

Old world as in the past? Older technology? Older ideas? Bad ideas?

Blues, as in the musical genre? Or the feeling it conveys? Are we riffing on it here? Plays strongly suggests music, but the blues originated from specific cultural roots tied to the end of slavery (which is implied even further by 'old world blues').

New world, as in a better tomorrow, or something more akin to a new world order?

Hope I think I get.

Git, Python, llvm, cmake, and curl all have perfectly normal windows installers available from their own websites, and if you're a programmer who has to, or chooses to work on Window, it's a good bet you already have either most or all of these already installed, making the job of completing your bonus objective probably one, maybe two installs at most.

Microsoft is the reason alternative package managers exist

Contrast that to brew on MacOS: ever non-devs know about brew.

Like brew does. That why I use scoop.

Chocolatey would rather charge money for that, for some reason, and people are still willing to donate them their free time.

As an aside, if you have the sentence "This is Lewis' reply to the parent comment" the ' at the end of Lewis is used to avoid Lewis's with the extra s at the end.

There is a newer class of generic malware that exploits CPU bugs (e.g. Spectre) - are you perhaps referring to that? If so, that's a fair concern but unlikely to matter much in practice. For Spectre itself, I believe the mitigations were applied within the major JS engines directly (or at least for v8 they were).

Anyway, security issues are best compared when there's a lot more attention to your browser. But given that there's a huge amount of exploits that depend on buffer overflows that are simply impossible in the first place with Rust, it's likely that the browser's likely to mostly suffer only from architectural issues & fewer implementation issues whereas other browsers will still have architectural issues and implementation issues to boot that prevent them from addressing it. Yes, newer browser = likely more immature architecture, but at the same time there's fewer implementation issues to worry about in terms of exploiting architectural issues in the first place.

In general, the sites I want to browse use minimal JavaScript, prudently, if at all, just where it is strictly necessary to add little dynamic features. So, I don’t really care about JavaScript performance at all.

Optimization sometimes introduces additional complexity, which might open up the possibility of security holes (at least it seems to be the case to me, as a not-security-related programmer. I don’t know anything about security on a technical level, so I’m interested in other perspectives on this from people that actually work in those sorts of fields). I wonder if there’s room for a browser engine that ditches performance and just focuses on correctness and safety.

Rendering documents ought to not be computationally intensive, right? Advertisements of blazing fast JavaScript performance make me worry what corners have been cut.

Isn't this just the noscript, which breaks most sites to a degree where they're impossible to use or load?

Sometimes, I just have to load a site that has JavaScript running. Or is unfortunate, but some work sites don’t work without it, etc. I’m fine with those sites being slow (I’ll minimize my use of them naturally), but totally blocking them is slightly inconvenient.

Obviously this isn't the same as making "absolutely no security compromises", but in practice most JS-related security exploits go through the JIT iiuc. Your JS will be executed with a safe interpreter, where by "safe" I mean the dispatching and basic value manipulation are going to be simple enough to be bulletproof, and also slow enough to prevent most timing attacks. The underlying implementation of all of the built-in methods is still going to be more vulnerable, but those tend to be relatively safe as compared to JIT-optimized versions of them. They also don't change much, so have been tested for much longer as compared to the JITs that tend to get refactored and rewritten relatively frequently.

Also doing that doesn't solve the standards problem we currently have.

Google is able to push through any "standard". And those standards "unwittingly" help them maintain their search/ad dominance or prevent competitors. For example see manifest v3 or FloC (a.k.a Topics API).

Once they gain enough traction and become indispensible, you either implement them or risk losing users.

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.