WEFT OS — Post 2 of 10
If you were paying attention between roughly 2012 and 2017, you probably carry a very specific kind of disappointment.
It’s the disappointment of watching several projects point at the same future — and then miss it in different ways.
Firefox OS.
Ubuntu Touch.
Sailfish OS.
Three names that still trigger arguments in the right corners of the internet.
Three projects that are easy to summarize badly:
- “No apps.”
- “Too slow.”
- “Too niche.”
Those summaries are not wrong.
They’re just not useful.
The useful question isn’t “why did they fail?”
The useful question is:
what did they get right about the shape of computing — and why did that rightness arrive before the world was willing to pay for it?
Because WEFT OS exists in the shadow of that era.
Not as nostalgia.
As inheritance.
🔗What that era actually felt like
If you weren’t there, it’s easy to imagine the early-2010s alternative OS wave as a clean engineering story.
It wasn’t.
It was a messy mixture of:
- prototypes that looked like the future
- devices that felt like compromises
- and communities that kept trying to translate “this is important” into something the market would fund
A lot of people first encountered these systems the same way:
- through a YouTube video
- through a conference demo
- through a screenshot of a homescreen that didn’t look like iOS
And the reaction was always the same:
- “this is either the future or a weird dead end.”
The reason those reactions coexisted is that the experience was inconsistent.
Sometimes the UI was fluid.
Then you opened an app.
Then you hit a stutter.
Then you felt the system hesitate at exactly the moment a phone should feel instantaneous.
And your brain tagged it as:
- not native
This is the cruelest thing about platform UX.
It doesn’t matter if you’re right about the direction.
If the experience breaks the illusion even occasionally, people stop trusting it.
🔗Why the question “were they right?” is still worth asking
It’s tempting to treat these systems as “failed products”.
But there’s a deeper reason to revisit them.
They were not only trying to ship devices.
They were trying to answer questions that mainstream platforms still avoid:
- Can the web be a first-class application substrate?
- Can apps be portable without being trapped inside one vendor ecosystem?
- Can convergence be real rather than a marketing slide?
- Can interaction models be reinvented without asking users to relearn everything every year?
Even today, those questions are not answered.
They’re just buried under platform gravity.
And that is why these projects keep mattering long after their market moment passes.
They force us to remember that platforms are not natural phenomena.
They are settlements.
They are agreements about:
- who gets to build
- who gets to distribute
- who gets to define the rules of software life
The old web-platform OS attempts mattered because they challenged those settlements directly.
Not always successfully.
Sometimes not even elegantly.
But they were asking a real question about whether application development could remain more open than the mobile market was becoming.
🔗The web as the OS: the most obvious idea that still feels radical
There’s a reason Firefox OS still feels like a ghost story.
It wasn’t just “a phone that ran web apps”.
It was a statement:
- the web is a universal application platform
- and the OS should treat it that way
The home screen was HTML.
The dialer was HTML.
Apps were “installed” URLs with offline packaging.
Even if you never used a Firefox OS device, you probably absorbed the idea indirectly.
Because the idea is obviously seductive:
- no vendor SDK gatekeeping
- no app store politics as the only distribution channel
- one UI language that ships everywhere
In a way, it’s the simplest possible platform vision:
if the web already runs on everything, why isn’t it the OS?
The reason that question doesn’t have an easy answer is that “runs” is not the same as “feels native”.
Firefox OS ran.
And then the frame budget would collapse.
And then touch would feel off by a few milliseconds.
And then the illusion would break.
People don’t forgive an OS for the worst stutter.
They judge it by the moment it feels like a website.
And once that happens, the stigma becomes sticky.
It stops being “this device is slow”.
It becomes:
- “web-based UIs are slow.”
Which is an overgeneralization, but it’s a predictable one.
🔗The technical failure that turned into a cultural stigma
One of the most damaging things that happened in that era is that a technical weakness became a cultural conclusion.
The weakness:
- web UIs had performance cliffs
The conclusion:
- “web UIs are inherently janky”
That conclusion got carried forward for a decade.
Even today, if you say “the shell is HTML/CSS”, a lot of people will hear:
- “so it will lag”
What they’re really remembering is not HTML.
They’re remembering:
- layout churn
- main-thread congestion
- GPU composition rules being ignored
You can build a smooth UI with HTML.
You can also build a catastrophic UI with HTML.
Firefox OS taught the world that the second is easy.
The open question is whether the first is possible at OS scale with enough discipline.
That’s one of the things WEFT is trying to test.
🔗Ecosystem gravity: the failure mode nobody likes to admit
The simplest technical explanation for why an OS succeeds is:
- it has good engineering
That’s not how OSs succeed.
They succeed because they become a platform.
And platforms succeed because they become gravity wells.
Once iOS and Android became the gravitational center of mobile apps, the hard part stopped being “write an OS.”
The hard part became:
- convince developers to care
That’s a brutally expensive task.
It requires:
- distribution
- a believable market
- tooling
- and time
Firefox OS, Ubuntu Touch, and Sailfish all fought this in different ways.
And they all hit the same reality:
- the app ecosystem was consolidating faster than alternative platforms could grow
This is the part that “no apps” hand-waves over.
The issue isn’t only number of apps.
It’s that:
- users want the apps they already use
- and developers want the platforms users already use
This loop is what kills most alternative OS efforts.
You can’t out-engineer a feedback loop.
You have to outlast it or change its economics.
WEFT is not naïve about this.
It does not assume “the ecosystem will come.”
It assumes the app story has to be built around portability and constraints.
🔗Ubuntu Touch: convergence as a worldview, not a feature
Ubuntu Touch is remembered for a very different reason.
Where Firefox OS was “the web everywhere”, Ubuntu Touch was:
- “one device, many contexts”
The convergence pitch wasn’t just marketing.
It was a legitimate interface design question:
- what happens when you plug your phone into a screen and it becomes a desktop?
It’s a simple scenario that exposes how brittle most software really is.
Because most apps are written with a hidden assumption:
- they live in one form factor forever
Ubuntu Touch tried to reject that.
It treated the UI as something that should be:
- adaptive
- semantic
- aware of input modality
That idea is still not “done”.
We have better responsive design tools now.
We have better hardware now.
But most platforms still treat convergence like a special mode, not a foundation.
WEFT is going to pick that fight later in this series.
The more interesting part of Ubuntu Touch isn’t whether it “won”.
It’s that it treated convergence as a first-order design problem.
It was willing to say:
- a phone UI and a desktop UI should not be two different products
That premise is still controversial.
But it’s also still unresolved.
🔗Sailfish OS: gestures as language
Sailfish OS is the project people reference when they want to talk about gestures without sounding like they’re describing a gimmick.
Sailfish treated gestures as a real interaction language.
Not “swipe to reveal an animation”, but:
- swipe as navigation
- swipe as system state
- swipe as application switching
It also treated UI as spatial.
The interface lived just off-screen until you pulled it into view.
If you used it for a while, you got a kind of muscle memory that icon grids don’t give you.
That matters because OS UI is not a website.
It’s a language you learn.
WEFT’s UI ambitions are much closer to that “language” worldview than to the “launcher page” worldview.
But the technology stack is different.
And that difference is the entire point.
🔗Why they were too early (and why that matters more than the obituary)
It’s tempting to tell a clean story:
- Firefox OS failed because it was slow.
- Ubuntu Touch failed because it had no apps.
- Sailfish survived because it found a niche.
Those are headlines.
The deeper truth is messier.
They were trying to build new platform gravity in a world that was already consolidating around two gravity wells.
They were asking developers to care.
They were asking carriers to care.
They were asking users to re-learn habits.
And at the same time:
- hardware performance was weaker
- GPU pipelines were less predictable
- sandboxing/capabilities were not baked into mainstream runtimes
- Wayland wasn’t the desktop default
- WebAssembly didn’t exist as a practical app runtime
That last point is the one I want to underline.
In 2013, “app logic” meant JavaScript.
You could optimize it.
You could write clever code.
But you couldn’t easily say:
- “this app runs as a module with zero ambient authority”
The web platform was powerful, but it was not designed as a capability-first OS substrate.
That changes how you build a system.
It changes how you build trust.
It changes how you contain failures.
It also changes how you talk about apps.
If your only runtime is JavaScript in a browsing context, you have a narrow set of tools for:
- isolating logic
- granting authority
- supervising failures
If your app logic is a sandboxed module with explicit handles, you have a different starting point.
🔗The emotional part (because it matters)
There’s also a human reason these projects still matter.
They were hopeful.
Not in a vague way.
In a very specific way:
- they suggested we could have computing without platform gatekeeping
- and that the web could be the public square of application distribution
For a lot of people, watching that hope get crushed felt like watching a door close.
And then we spent a decade inside the closed door.
Which is why, if you mention Firefox OS today, people don’t respond neutrally.
They respond like you brought up an alternate timeline.
WEFT is not going to pretend it can reopen that door by being clever.
But it is going to test whether some of the technical constraints that made that era impossible are now less impossible.
There’s a specific kind of optimism I’m trying to preserve from that era:
- the belief that UI and platforms can be less gatekept
But I’m trying to pair it with a different kind of honesty:
- the belief that architectures have to earn trust mechanically, not rhetorically
🔗What WEFT is taking from that era (and what it is refusing)
Here’s what WEFT is willing to inherit:
- the web as a first-class UI medium
- convergence as a foundational problem
- gestures as a real UI language
Here’s what it refuses to inherit:
- the idea that “web app” means “everything runs in one process”
- the idea that the UI runtime should hold system authority
- the idea that security is a permission prompt bolted on at the end
If WEFT works, it won’t be because the web suddenly became magical.
It will be because the architecture keeps the web honest.
And because the hard problems are named instead of hidden.
There is one more inheritance I want to call out, because it’s easy to miss.
That era taught people to conflate “web UI” with “lack of discipline.”
WEFT is trying to break that association.
Not by insisting the stigma is unfair.
By treating performance, authority, and failure as contracts.
🔗A note to readers who weren’t there
If you’re reading this and you’re too young to remember any of these projects:
- good
You get to approach this without baggage.
But you should understand what you’re inheriting anyway, because the current platform world you live in is shaped by the consolidation that followed.
When we talk about “alternative OS projects” today, we’re not just talking about code.
We’re talking about the price of challenging ecosystems.
So when WEFT says “the desktop is a document”, the correct response is not “cool” or “stupid”.
The correct response is:
- what promises does this system make?
- what does it cost to keep them?
That’s what the rest of this series is about.
And if you were there, and you’re reading this with the feeling of “I’ve heard this before”, that’s fair too.
All I’m asking is that you evaluate WEFT on the correct axis:
- does the architecture keep its promises?
Not:
- does the pitch sound familiar?
🔗What comes next
The next post is about Servo.
Why Servo.
Why not Chromium embedded.
Why not WebKit.
And what you implicitly sign up for when you choose a web engine as an OS foundation.