Mozilla won the browser war. Firefox lost the browser fight. But there's many wars left to fight, and I hope Mozilla dives into a new one.

As technology shifts to a world where most people do not have a monitor on their home computer or a screen on their phone, what it means to be a browser will dramatically change. Certainly, we could post-it the current user experience into whatever we will have tomorrow, but if VR, AR, Speech, and AI and ample cheap private computing power don't excite people for the future of browsers and user agency, I don't know what will.

I know we've been working on tech such as Servo for a long time, but sometimes even just being "better" isn't enough, especially when there's a large legacy gap to close. You also need to get lucky with a point where consumers are making massive changes and open to new things.

I think that time is much sooner than the "always 5--10 years quoted", and you're going to see mind-blowing things on the web in general and supported by the browser and related services specifically. And I'm betting (at least with my current career) that Mozilla will lead the charge.

What's next isn't clear to me

Apple lost it by getting boxed into a market share corner by android. Google lost it by losing control over android. Android OEM's lost it by getting stuck in a cutthroat competition. Microsoft lost it by being microsoft. Users lost it by having no good choices left (either go with the golden cage iphone, or go with the privacy and security mess android).

Now OEM have to obey to Google because losing the Google apps and services licence (thus losing the Play store and the whole ecosystem) basically means they're dead as an Android manufacturer.

That works in China because Google is relatively weak there. It also works for Amazon, which has its own store for Fire products.

Apple was never likely to license iOS to other manufacturers, nor were they likely to have enough capacity to satisfy the whole market. I reckon they are where they always wanted to be: owning a very profitable and locked-in niche.

You mean the corner where they are the premium smartphone vendor, taking 90% share of global profits? That's a great corner to be boxed into :)

Because iOS users are a significant source of potential profit.

Apple doesn't need to maximize usage in order to control the ecosystem - they just need to maximize profit potential.

Secure messaging is also still a hot topic. Join forces with Signal or Wire or Matrix or XMPP. For example, Wire intends to open source their server code and enable federation [0].

Voice control requires some weight for an Open Source solution. Specifically, we could use something which does not rely on the internet. PocketSphinx is an ok foundation, but needs more work.

[0] https://medium.com/@wireapp/open-sourcing-wire-server-code-e...

However I would say that among those who do know, Lineage OS has a fairly good reputation for quality. You wouldn't be targeting mass adoption with this, you'd be targeting the influencers.

https://lineageos.org/about/

The Vivaldi browser has copied the original Firefox user interface and stole the best ideas from the Firefox extension makers so if you want the Chromium web rendering engine with the original Firefox user interface you are served by the Vivaldi browser. Hopefully they will become profitable and release their modification under a free software license.

But I am assuming that a browser offering a gigantic leap in UX through native-like rendering performance will entice web app developers to recommend that browser over others, because it's nigh impossible to build a consistently 60fps non trivial app with native-like interactions and transitions on the web today, while Servo and Webrender aim to make 60fps on the web the norm rather than the exception.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1347543 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1054016

Not that anyone cares, because MathJax...

The web is better without JavaScript.

Unless Firefox (and Servo) gets it GUI to not feel alien and clunky, it wont matter if it has a faster rendering engine. Rendering engines are plenty fast as it is anyway, it's CPU use and battery impact that matters to users. And when performance does matter, it's mostly Javascript performance, which Servo doesn't address.

It also wont matter for mobile, since Android will still keep Chrome browser, and iOS will still keep Mobile Safari -- they're both made by the platform's creators.

And as for Firefox on Android, I have plenty of hope for it. I'm seeing more and more people switch to alternative browsers for speed (the most common one is samsung's "browser" which everyone says is "super fast" but really only is a weird hack to make scrolling smooth which breaks a few standards).

Ios is another story, but at least on android if they make a damn good product, people will use it.

That's at odds with almost every single sentiment I've seen regarding native vs. Web apps. Take one look at any HN thread about the two.

> And when performance does matter, it's mostly Javascript performance, which Servo doesn't address.

If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)

Besides, a lot of what shows up as "JS performance" in a profiler is actually blocking on DOM operations. With off-main-thread layout, these operations can be done in the background, resulting in improved DOM performance.

If we're talking about e.g. Electron apps, the problem I see mentioned (and felt myself) is almost always the memory hogging, the GC-pauses, the battery impact and such -- not the rendering speed. Although, there is talk of getting to 60fps web apps etc.

For something like Atom, is the slow redrawing because "DOM is slow" or because "doing the calculations needed for a sizable file, with syntax highlighting regexes, compiler checks, freeing memory, etc takes lots of processing time"?

>If that were true, then there wouldn't be a performance differential between native and Web, since Objective-C and Dalvik are slower than modern JS engines. (Look at how method call dispatch works in Objective-C!)

That's not entirely true, as Objective-C dispatch was thoroughly optimized [1]. Besides, the performance differential is also in the time to process logic (and the network latency) which you don't address. And of course, aside from rendering (which often is just "show a few forms, buttons and lists" for most apps) a part of the heavy logic in Objective-C for lots of tasks is done in C or C++ frameworks at much faster speeds than modern JS engines.

[1] https://www.mikeash.com/pyblog/performance-comparisons-of-co...

I see the opposite. VS Code feels somewhat slow, mostly because of rendering—it doesn't hit 60 FPS.

You cite GC pauses. One of the best ways to mitigate GC pauses is to move the noticeable rendering logic off the main thread so that your app doesn't freeze during GCs, which is precisely what Servo is designed to do.

> For something like Atom, is the slow redrawing because "DOM is slow" or because "doing the calculations needed for a sizable file, with syntax highlighting regexes, compiler checks, freeing memory, etc takes lots of processing time"?

The performance differential is because of many things, but regex performance and freeing memory relative to native aren't among them. JS engines' regex engines are best in class and easily exceed the performance of popular C regex libraries; this is a side effect of SunSpider and V8 including regex benchmarks. Memory deallocation in popular JS engines is faster than in native, because sweeping takes place all at once and generational GC nursery evacuation is very fast.

> That's not entirely true, as Objective-C dispatch was thoroughly optimized [1].

Those numbers are precisely what I'm referring to. In most cases, JS method dispatch is more like a C++ method call or an IMP-cached message send than a slow hash table lookup. Often it's even better, because the inliner kicks in, while inlining is very difficult in Objective-C. Objective-C's "fast path" is the slowest path in JavaScript, one that's only hit for megamorphic call sites.

> Besides, the performance differential is also in the time to process logic (and the network latency) which you don't address.

Pure computation in most apps is not appreciably slower for the end user in JS than it is in Android or iOS. And if it is, there's always Web Assembly! We're doing lots of work to improve JS performance; it's just not all under the Servo umbrella.

> And of course, aside from rendering (which often is just "show a few forms, buttons and lists" for most apps) a part of the heavy logic in Objective-C for lots of tasks is done in C or C++ frameworks at much faster speeds than modern JS engines.

That same "heavy logic"—by which I assume you mean audio/image/video decoding, JSON/XML parsing, image filters, vector graphics work—is also done in native code in browsers. And it's those very same tasks that we're optimizing in Servo.

[1] http://benchmarksgame.alioth.debian.org/u64q/compare.php?lan...

You make it sound like these are two orthogonal aspects. When rendering is faster, CPU usage obviously goes down. As does battery impact, since the CPU can go back to a sleep state faster.

Only as much as its the rendering, and not the core logic that consumes the CPU.

Degenerative case: a page with a single text entry field, where you enter a number and it calculates e.g. the fibonnaci sequence up to that number or factor primes etc. There's hardly any rendering, but lots of CPU.

And it's proving to be fast, safe, and the future of browsers.

First of all, I think the idea behind Servo is awesome, and I follow it. But I've been testing it on Mac OS and Windows, and it is not a runnable browser, nor fast (as expected!). CPU is often fully pegged and it's very iffy if any UI elements or page loads work. Not to say they won't get there, but it's still very, very early and buggy.

We had a similar issue with Stylo (Servo style system in gecko) recently where there were bugs in the parallelism code making us slower than gecko. Fixed, now we're faster again. We only recently started tracking performance properly, and it was caught and fixed in a few weeks.

So it's not entirely unreasonable to suggest that Mozilla's next-gen engine efforts could be first-to-market, and that everyone else might have to play catch up.

As Servo would be a mobile app itself, I think no ;)