Swift in the Browser with ElementaryUI (Swift FOSDEM 2026 Talk) [video](youtube.com)
youtube.com
Swift in the Browser with ElementaryUI (Swift FOSDEM 2026 Talk) [video]
https://www.youtube.com/watch?v=OmQ881sOTIc
15 comments
> - Modern Ergonomics
What does this even mean? Modern Swift looks like a haphazard mishmash of conflicting features where every problem is solved by "just one more keyword bro". In 2024 it had 217 keywords: https://x.com/jacobtechtavern/status/1841251621004538183 and that was reduced slightly, to 203, in 2025: https://x.com/jacobtechtavern/status/1962242782405267617
According to Lattner they never even had the time to design anything due to time pressure from Apple [1]. So Swift ended up with a type system that the compiler can't even check and is impossible to fix. So the compiler routinely just gives up and complains on even the most trivial code.
[1] https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400
--- start quote ---
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
What does this even mean? Modern Swift looks like a haphazard mishmash of conflicting features where every problem is solved by "just one more keyword bro". In 2024 it had 217 keywords: https://x.com/jacobtechtavern/status/1841251621004538183 and that was reduced slightly, to 203, in 2025: https://x.com/jacobtechtavern/status/1962242782405267617
According to Lattner they never even had the time to design anything due to time pressure from Apple [1]. So Swift ended up with a type system that the compiler can't even check and is impossible to fix. So the compiler routinely just gives up and complains on even the most trivial code.
[1] https://youtu.be/ovYbgbrQ-v8?si=tAko6n88PmpWrzvO&t=1400
--- start quote ---
Swift has turned into a gigantic super complicated bag of special cases, special syntax, special stuff...
We had a ton of users, it had a ton of iternal technical debt... the whole team was behind, and instead of fixing the core, what the team did is they started adding all these special cases.
--- end quote ---
It’s not necessary to use all or even most of those features, though, and so a nice balance of expressiveness and functionality is possible. I’ll take it over dying on weird hills in language design in pursuit of ideological purity or mountains of ceremonial code and unavoidably ugly syntax.
> mountains of ceremonial code and unavoidably ugly syntax.
you... just described Swift, really :)
Also, all those features exist even if you don't use them all. Which makes the language complex, cumbersome, and makes its compiler slow, complex and brittle. A language shouldn't be a collection of one-off edge cases, and this has nothing to do with ideological purity
you... just described Swift, really :)
Also, all those features exist even if you don't use them all. Which makes the language complex, cumbersome, and makes its compiler slow, complex and brittle. A language shouldn't be a collection of one-off edge cases, and this has nothing to do with ideological purity
I dunno, with a handful of exceptions I'm still mostly writing Swift the same way I did 5+ years ago. Unless you're using SwiftUI, new features haven't changed a whole lot in real world use.
Whatever the case, I don't enjoy writing languages more obsessed with theory or design purity (like Kotlin) as much.
Whatever the case, I don't enjoy writing languages more obsessed with theory or design purity (like Kotlin) as much.
I agree the language itself has gotten more complex, but for day-to-day productivity in terms of actually using it to write code, I don't think it makes a difference.
I've found writing Swift code very pleasant, but I've been doing it for ten years, so that helps I suppose. The biggest productivity impact for day-to-day use for me in the last few years has been the new concurrency model.
I've found writing Swift code very pleasant, but I've been doing it for ten years, so that helps I suppose. The biggest productivity impact for day-to-day use for me in the last few years has been the new concurrency model.
You listed “corporate backing” as a good thing and “no adoption outside Apple ecosystem” as a pain point. Why would it get adopted outside Apple ecosystem if Apple decides what happens to it?
[deleted]
I agree, but it's already been 15 years since it was released so I'm losing hope..
[deleted]
Speaker here — I’m responsible for the slides and the flower shirt.
Happy to answer questions.
From where you stand currently, what do you feel are the greatest challenges lying ahead on the road to making this viable for production use?
I think the balancing act of code size (how fat your WASM binary will be) and DX/comfort in Swift is tricky.
Just as an example: JSON data - Including a Swift serializer adds code size, but bridging to JS is a bit less comfortable. And for each similar feature we will need to find a good compromise. We need to be careful not to create a "parallel universe" of Swift, where everything works completely differently from "normal Swift" - but at the same time things like 'import Foundation' won't fly on the web.
And, of course, things like HMR or "module splitting" and other more dynamic features are much, much tougher to do with a compiled language and Wasm. So, trying to reach "DX-parity" with JS frameworks can be a very pricy endeavor.
I think Swift adoption in general is also a ... factor. I personally think it is way more ergonomic to write than most languages, especially for UI and app-level stuff, while bringing a lot to the table. But as - we all know - it is still hasn't grown to its potential outside of Apple-land.
Embedded Swift is a moving target, but I am confident it delivers (it's evolving rapidly). Also, Wasm is a moving target to a degree.
And then there is just a ton to do, none of which a "great challenge", but just the grind of moving towards a "fully-featured UI framework"...
Just as an example: JSON data - Including a Swift serializer adds code size, but bridging to JS is a bit less comfortable. And for each similar feature we will need to find a good compromise. We need to be careful not to create a "parallel universe" of Swift, where everything works completely differently from "normal Swift" - but at the same time things like 'import Foundation' won't fly on the web.
And, of course, things like HMR or "module splitting" and other more dynamic features are much, much tougher to do with a compiled language and Wasm. So, trying to reach "DX-parity" with JS frameworks can be a very pricy endeavor.
I think Swift adoption in general is also a ... factor. I personally think it is way more ergonomic to write than most languages, especially for UI and app-level stuff, while bringing a lot to the table. But as - we all know - it is still hasn't grown to its potential outside of Apple-land.
Embedded Swift is a moving target, but I am confident it delivers (it's evolving rapidly). Also, Wasm is a moving target to a degree.
And then there is just a ton to do, none of which a "great challenge", but just the grind of moving towards a "fully-featured UI framework"...
- Strong Typing
- Great Performance
- Actor Model Concurrency [0]
- Modern Ergonomics
- Corporate Backing
- Performance
- Functional Style
- LLMs perform well with it [1]
- Usable across iOS, Android, Web, and Browsers [2][3]
The only thing its missing is adoption outside of the iOS space.
I'm not sure it will be able to make that leap, but the ingredients are there.
If it does I'd be happy to make it my primary language.
----------------
[0] https://www.hackingwithswift.com/quick-start/concurrency/wha...
[1] https://github.com/Tencent-Hunyuan/AutoCodeBenchmark/blob/ma...
[2] https://www.swift.org/blog/nightly-swift-sdk-for-android/
[3] https://vapor.codes/