Rust and servo have noble visions but are irrelevant to the future of the web. UX is what drives browser market share and unless Mozilla refocuses on this, they will contjnue to lose maket share. TBH, it will take years if they start now to convince back all the people they lost.
So focusing on more concurrency in the web browser is extremely compelling in my view. I don't believe we're going to see widespread trimming of bloat from the web at large. It's something a few conscientious companies think about, but the majority just keep throwing frameworks and third-party scripts at their sites with abandon.
Web performance in 2017, even on high-capacity hardware, ranges from acceptable to bad. I'd prefer it ranged from superb to acceptable. If Servo moves us in that direction, I am a big fan.
Perhaps to your point: UX includes performance. And in that sense, UX may help Mozilla market share.
It's not necessarily a bad thing, but can all add up, and it's hard to measuer/add up the separate processes.
Come on. Do you really think I come into the office on weekends just for fun?
> Rust and servo have noble visions but are irrelevant to the future of the web. UX is what drives browser market share and unless Mozilla refocuses on this, they will contjnue to lose maket share.
Fortunately, Servo is experimenting with UX as well, via browser.html!
There is a difference between working hard and working smart. Working smart means to fix today's problems that all your users are complaining. People want to use Firefox everyday but cannot. The solution to today's Firefox performance problems is not Servo or Rust. It's basically engineers putting in time to fix it in the _current_ code base.
To be more constructive: Why don't you do a "Ask HN" about what stops them from using Firefox every day and you will have the answer. In fact, just reply to this comment and I will do this for you (It just seemed for me to do this as an "outsider").
On a personal anecode: I don't use firefox everyday for "fun" either despite having so many performance issues. I believe in Mozilla's original vision and it's sadly now like a "religion" for me - I use it despite the pain it causes me.
I brought up my own personal experience because I've also had people conflate where you work with what you do.
Given that Servo is now vendored inside of Firefox's tree, and Project Quantum more generally, this is not exactly an either-or these days.
Sometimes you DO have to step back, and rewrite, but at least you have a better idea what you need based on the prior version, even in a separate language.
If you're so convinced that the correct answer is to hack more on Gecko (as if hundreds of engineers haven't been doing exactly that for a decade), then it should be easy for you to explain to me, in detail, technically, why Gecko's architecture is suitable to achieve best in class performance in the long term.
> To be more constructive: Why don't you do a "Ask HN" about what stops them from using Firefox every day and you will have the answer.
Don't deflect. I want you to defend the choice of continuing to hack on Gecko's C++ codebase instead of using Rust. Preferably describe specific subsystems that you think Gecko is doing better than Servo is, and what the problems you think Servo's architecture has. This should be very easy for you to do, as you seem to think it's so obviously correct that the only conclusion is that none of us even care about making the browser better.
It may well be that Gecko just is that terrible and the only way to fix it is with Servo. If that's the case you guys really need to hurry up because you're loosing significant mindshare. Your organization's predecessor has also made this mistake before very publicly in the past with the Netscape rewrite.
Then show me those specific results.
I'll pose it to you, too. If it's so obvious, tell me what the problems with Gecko are, specifically, and how Servo cannot solve them.
> If that's the case you guys really need to hurry up because you're loosing significant mindshare.
This is the first time I've been called lazy by a random HN poster. I guess there's a first time for everything.
> Your organization's predecessor has also made this mistake before very publicly in the past with the Netscape rewrite.
Firefox was possible because of Gecko in the first place! Do you want to be using code descended from Netscape 4, which had no dynamic restyling at all?
Firefox is slow, I don't know why. I was hoping the engineers working on it would know - it's scary that they do not.
Do you realize why that does not make sense?
The difference is our customers see improvements over time not large periods of stagnation.
(unless you like tab nesting which i guess it cant do? personally just looking for the more readable left-side layout)
Yes.
> if they start now
We started last year with e10s, testpilot and dozens of other improvements.
Whereas Chrome can have over a dozen tabs open and it still operates well. Which is a shame because I was hoping to switch over back to Firefox.
The upcoming Quantum work will improve speed generally and specifically for multiple core setups. Electrolysis in the latest versions will also help prevent "bad tabs" from slowing the whole browser.