10 ms·
So we will, in ~5 years time have two new browser, one in Rust and one in Swift. I hope in the process of doing it we will find new ways of doing things.
by ksec 2y ago
So we will, in ~5 years time have two new browser, one in Rust and one in Swift.
I hope in the process of doing it we will find new ways of doing things.
- deleted 2y ago[deleted]
- jitl 2y agoWhat swift browser are you referring to?
- BadHumans 2y agoLadybird has started using Swift.
- monacobolid 2y agoFor UI portion of their Mac OS version? What am I missing?
- Wowfunhappy 2y agoFor everything. Swift is—at least in theory—a general purpose language, it's not exclusively for Apple technologies. > 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://x.com/awesomekling/status/1822236888188498031 https://news.ycombinator.com/item?id=41208836 https://news.ycombinator.com/item?id=41208836
- sesm 2y ago> First off, Swift has both memory & data race safety (as of v6) But v6 is not released yet, right?
- wahnfrieden 2y agonext month
- worik 2y ago> > First off, Swift has both memory & data race safety (as of v6) > But v6 is not released yet, right 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
- ninkendo 2y ago> 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 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.)
- askonomm 2y agoFor non-UI portions as well, more from the horses mouth: https://x.com/awesomekling/status/1822236888188498031 https://x.com/awesomekling/status/1822236888188498031
- deleted 2y ago[deleted]
- bobajeff 2y agoActually, it sounds like they only just decided to use it in the future once Swift 6 is released. I would guess much of it will still be in C++ for a while.
- conkeisterdoor 2y agoMost likely Arc (https://arc.net/ https://arc.net/)
- actinium226 2y agoArc is a fork of Chrome if I'm not mistaken
- _thisdot 2y agoThe rendering uses Chromium engine. But all of the UI is built in Swift. Both on macOS and Windows
- hypeatei 2y agoArc is based on Chromium for anyone wondering. I believe part of the UI is written in Swift but the engine isn't.
- steve_adams_86 2y agoI like Arc and use it (I actually never stopped using it after the first time I opened it), but I wish they weren't building off of Chrome.
- pndy 2y agoCan user enhance it with extensions?
- _thisdot 2y agoYes
- clot27 2y agoLadybird
- deleted 2y ago[deleted]
- RandomThoughts3 2y ago[flagged]
- worble 2y agoAre you trying to say that Ladybird does not exist? https://github.com/LadybirdBrowser/ladybird https://github.com/LadybirdBrowser/ladybird The code is here, you can build and run it right now.
- RandomThoughts3 2y ago[flagged]
- breakfastduck 2y agoLadybird exists and is funded because the main author is an extremely skilled software developer with a background in building web browsers. 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?
- RandomThoughts3 2y ago[flagged]
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ChocolateGod 2y agoI'd like to see Swift adopted more on non-Apple operating systems, some of the recent GTK apps written in Swift are pretty cool.
- nbbaier 2y agoWhat apps are you thinking of? Curious to check them out.
- jamil7 2y agoThere's been a lot of work on this in the last few years with Windows support, preliminary Android support is also being worked on and should appear at some point in Swift 6.
- drekipus 2y agoIs swift going to do what flutter and kotlin multiplatform cannot?
- rodrigobellusci 2y agoIt seems something like that already exists: https://skip.tools/blog/scrumskipper https://skip.tools/blog/scrumskipper I mostly work with flutter but Skip looks pretty cool.
- jamil7 2y agoI think Skip is doing a lot of this via transpilation, so I think you're expected to still write a lot of Android / Kotlin code.
- amelius 2y agoThe problem with these smaller webbrowsers is that you have nobody to sue if the browser turns out to leak your personal information or credentials etc. Therefore it is better to stick with browsers made by big corporations.
- alex_duf 2y agoThis is true for any software though, so if we push that reasoning to its extreme, no one should ever use any free and open source software, which I find a little bonkers.
- amelius 2y agoExcept browsers are more likely to leak your personal info than, say, a vector drawing program.
- swiftcoder 2y agoI'm curious what exactly you think suing Google or Apple in such a case would accomplish? 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)
- RussianCow 2y agoAre you really planning on suing Google for leaking personal info via Chrome?
- lolinder 2y agoSome people just get warm fuzzies at the idea of theoretically being able to sue someone if they need to. Usually these are people who've never actually looked into what it would take to even start a lawsuit.
- ddtaylor 2y agoI'm fairly certain those big corporations are stealing that same information just paying fines and PR people to manage the backlash.
- wslh 2y agoIs there a good software engineering resource about the complexity of a web engine? I mean, we all know that is complex but what are the critical areas. Performance is one, compatibility another.
- abhinavk 2y agohttps://robert.ocallahan.org/2024/06/browser-engine.html https://robert.ocallahan.org/2024/06/browser-engine.html P.S.: This specific post was written in response to announcement of Ladybird.
- jll29 2y agoThis is a good post; as far as Ladybird is concerned while they may have started things as fun, they seem to have taken a turn towards seriousness recently.
- zackbrown 2y ago> 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
- eviks 2y agoInteresting project. Have you tested any non-XML markup languages for the user interface declaration so that metadata doesn't take as much space as data in <Text>Hi {firstName} </Text> and also requiring double the number brackets There are modern cleaner markup alternatives like kdl
- zackbrown 2y agoWe chose an XML-like syntax because it's clear & explicit & established (HTML) — you can know where you are in a hierarchy clearly at any point thanks to closing tags. The major downside is verbosity, both for reading and for typing. Pax's closing tags compile away so they aren't transmitted across the network like they are for HTML. 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.