1. A programming language, that hasn't yet shown "escape velocity" to go beyond D and other would-be-C++-successors in traction.
2. The only major application of that language... a pre-alpha browser engine, which may or may not eventually replace the engine in a browser that is seriously declining in market share with no reversal in sight.
3. A desktop email client, from which Mozilla has repeatedly made clear their intentions to divest and move on.
4. A JavaScript and HTML reference manual.
Mozilla is an organization with over $400 million in annual revenue. Where that money is going baffles me.
You may be interested in https://www.rust-lang.org/en-US/friends.html.
From FY2015, actual budget is $372 million. $227 million is applied toward investments - mutual funds, bonds, etc, presumably to ensure longevity and continuity. They paid $29 million in income taxes, $6 million in employee benefits. I can't really comprehend rest of the audit report in any practical terms I understand, but that leaves about $100 million to try to understand and rationalize (actually probably a lot less than that.)
At 1,000 employees, that's $100k per person on average, which doesn't sound so far-fetched (of course in reality it's a curve, but it suddenly doesn't look so alarming). Somewhat noteworthy, they donate about $300k/year and a full-time employee to Let's Encrypt. Which, well, I personally benefited from that, so kudos.
I think you meant this disparagingly, but such a reference is remarkable. Comprehensive disscussion of a massive standard, in a well-written, usable form is a huge accomplishment.
There are other promising applications. For example, it could be used for web technologies-based applications (e.g. hybrid mobile apps, Electron, ...).
This is astonishing. Anyone looked at their accounts?
Besides that, a few things to consider:
* Mozilla is currently doing financially well, no one ever claimed otherwise. They are putting money to the side and also diversifying their income strategies, in case their market share falls even lower and revenue from search engines drops out. * They are still by far the smallest of the big browser vendors. Google, Microsoft and Apple could all easily invest far more money than that, if they wanted to. * Mozilla is currently developing two browser engines in parallel, implementing a new extension model, making Firefox multi-process capable and just in general dealing with a lot of technical debt. No way to truly know what Google, Microsoft and Apple are up to, but I can hardly imagine them currently doing more than Mozilla in terms of innovation and development.
Anyway, $400 million a year, if you spend it all on developers (salaries, payroll taxes, benefits, desks, monitors, etc) gets you at most 2000 people in the US. And that's if you really stretch things, honestly.
That assumes you don't need a continuous integration infrastructure (which is actually a pretty large cost in practice). And that you don't need legal, payroll, marketing. Or any project management or management at all. And that you're not doing any documentation or anything like that.
In practice, Mozilla has a bit over 1000 employees and isn't spending all its revenue (so pays taxes on whatever it doesn't spend, and saves what's left).
The amount of funding they get is in direct correlation to how much market share they have in Firefox at the time they negotiate a search deal with one of the big search sites.
I love Rust, and advocate it among other memory safe systems programming languages, but right now it still has an uphill battle against Swift, C++17 and .NET Native, on the desktop and mobile OSes.
Adoption is growing slowly, even Microsoft has recently added a Rust library to VS Code, but it will take years to become a major systems language.
It seems Mozilla is very much aware of what will disappear when WebExtensions becomes the only extension API, and what will need to happen to replace it.
https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta...
https://addons.mozilla.org/en-US/firefox/addon/vertical-tabs...
Google may focus on specific types of exploits, but they let everyone bad just walk right in the front door.
Assuming you know better than installing adware or installing random chrome extensions, Chrome is the most secure browser out there.
Btw, regarding extensions, before Mozilla switched to WebExtensions, you could do nasty stuff like extension-reuse attacks.
You can hit a single accidental click on a malicious Google ad (yes, there are many), and end up with a voice telling you to click the "Install Extension" button to regain control of your browser, which alternates between a JavaScript alert popup message and the extension installation prompt to make it hard to get out of any other way (it's doable, if you're not a layperson). Approving it installs an extension which can inject ads into web pages and collect data on everything you visit and anything you type into Chrome.
Sure, it's removable, but most of the victims of this behavior don't even know what Chrome extensions are, much less how to remove them.
This is absolutely something Google has failed to address, and it's really not accurate to refer to Chrome as "the most secure browser" while this is so rampant and unhandled.
then you really ought to be using chrome
Servo is an "experimental" browser engine. While Chromium is cranking out features, servo is yet to reach version 1.0.
Thunderbird - was "discontinued" by Mozilla
MDN is a mess. The topics are all over the place and its hard to navigate. php.net docs is much more organized.
You can criticize Go but it has a more thriving ecosystem than Rust.
As much I'd like them to succeed, I dont think Mozilla is doing very good right now. They churn out technologically good products, but business wise, they dont know what they're doing. And without money, they wont be able to fight the big companies like Google, MS, FB.
This is just one of many examples!
This would be a more convincing point if any of memory safety, parallel styling, parallel layout, retained mode rendering as suggested by the GPU vendors, and so forth were on Chromium's roadmap.
Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.
> Servo is a nice goal and a technological feat but its a big business risk for Mozilla without clear return of value.
Doing nothing is an even bigger risk.
I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?
Disclaimer: I work on Chrome.
This is a case in which looking at the numbers without digging in more closely can lead to misleading conclusions. Yes, the Chrome Profiler reports that a lot of time is spent in JS (though ~25% of total CPU time on styling, etc. is not what I would call "paltry"). But what is that JS doing? It's usually not doing raw computation but rather doing custom layout, interacting with the DOM, etc. People do synchronous reflows (no matter how much you evangelize, people will still do it), which means that layout performance affects what looks like script time. And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).
The real problem with browsers is that so much is synchronous. We need to make everything as responsive as possible, and the way to do that is to aggressively multithread. Unfortunately, that's very hard to do in existing browser codebases. Hence Servo.
The solutions that the Chrome team keeps proposing—Custom Layout, Custom Paint, CSS Compositing, etc. are all targeted toward rendering (and they're essentially short-term band-aids at that). If rendering really weren't a problem, then we wouldn't be spending all this time on Google's Houdini proposals! If layout were fast, we wouldn't see people implementing layouts in JS, and therefore we wouldn't need Custom Layout. If painting were fast, then we could use SVG and CSS and not feel like Custom Paint is necessary. If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.
To be honest, I think that Houdini is largely misguided: there is a huge amount of performance left on the table that would obviate the need for Houdini if we simply chased it.
I do layout in JS because the existing layout capabilities don't cover my use cases. I create complicated visualisations in SVG, and SVG's layout capabilities are so pathetically anaemic that I have no choice but to take over and use a mixture of D3 and custom JS to arrange things.
Similarly, I don't do synchronous layouts because I'm a moron who doesn't understand performance, but because I need to measure the size of various data-bound elements and feed those dimensions back into my custom multi-pass layout algorithm.
AFAIK, Houdini is an actual attempt to solve both of these problems: It will let run my custom layout algorithm in a worklet, and give it access to the font metrics and element sizes it needs to run efficiently.
The Houdini people seem to be the only web platform people who actually "get it" with respect to these kind of problems. Everyone else seems to be either ignorant or dismissive that these problems even exist.
Of course, I agree with the rest of your points.
Chrome's profiler actually shows synchronous layouts and style recals forced from JS as layout/style so it's not misleading in that way. The traces I've looked at (admittedly, not something I do terribly often) showed those to be typically ~20% or less of the time spent while content is loading.
> And, due to ads, a lot of the performance cost is cross-domain iframes, which have no reason to run on the main thread (process isolation is too heavyweight to scale this far, which is why Chrome-style Site Isolation isn't a solution).
I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.
> If layout were fast, we wouldn't see people implementing layouts in JS
Are people re-implementing layout/paint because it's slow? Or because we didn't bake in the little detail they want into the platform through a multiyear standardisation process? I think it's naive to think developers will just stop writing JS if the browser gets x% faster.
> If the main thread weren't so bogged down all the time, then people wouldn't see the need to move a random subset of the Web platform to the compositor thread.
I disagree. Developers will always find something to fill it with. IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.
I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.
In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web. Lets all innovate independently and let the results speak for themselves :).
Yeah, it's too bad that Google's Chrome-first/Chrome-only approach to Web development these days is making that increasingly difficult to sustain.
If you can multithread iframes, then I think Amdahl's Law will start to kick in unless you improve style and layout performance. For instance, if I block the ads on washingtonpost.com, then style + layout is nearly as big as script.
But in any case, you have to look at how that affects the user experience. If done properly—i.e. everything remains responsive—the user won't notice slow script very much.
> I suppose the proof will be in the pudding, but I think process isolation could actually be a solution here. You don't have to have a separate process for every cross origin iframe. This is something desirable to do anyway for the security benefits so you might as well leverage it for performance as well. IMHO, this is the biggest problem with web perf and I don't see Servo as directly addressing it.
Servo definitely does address it, because it runs all cross-origin iframes in separate threads (and has from the beginning). Even same-origin iframes get separate style/layout threads, even though they share the same DOM thread. It can also do process isolation, as ipc-channel lets us abstract over the thread/process distinction.
I think multithreading is a more scalable solution for performance than process isolation, because with process isolation you need heuristics to avoid ballooning the number of processes out of control. You could have a throttled "ad process", but then you'd have to figure out what the ads are and hope you don't mess up, or else you might hurt iframes that matter. It's a lot simpler to just put separate origins in separate threads to begin with.
> Are people re-implementing layout/paint because it's slow?
Yes, because they've been told to use CSS transforms instead of real layout because those "run on the GPU".
> I think it's naive to think developers will just stop writing JS if the browser gets x% faster.
They won't, but we can certainly help things along a lot by making it easier to just use the platform. (I think we're in agreement here.)
> IMHO, the real goal - and the reason for the compositor thread - is to separate rendering from input and make it difficult for a page to tie the two together (or rather, easy to keep them separate). A user wont notice if the page takes an extra few hundred ms to render. She will notice if her scroll is delayed by 200ms.
I agree with the general principle, but I disagree with way it's implemented in existing browsers. The compositor thread is super limited; it's a thing that handles a weird subset of CSS that you have to be careful not to fall out of or else your performance drops. This is no way to treat Web developers! It's a historical accident, too, one that stems from the fact that Core Animation was developed independently of Mobile Safari for the iPhone 2G, Mobile Safari retrofitted a subset of CSS to that API, and then everyone copied Mobile Safari.
It makes more sense to have a dedicated thread for all style and layout and another thread for all painting, eliminating the paint/composite distinction. No matter what you do, the styling/layout runs off main thread, and the painting runs in yet another thread. That's Servo/WebRender's design. It's not easily compatible with existing engines, but that's why Servo exists :)
> I don't see Houdini as the main thrust here, there's lower hanging fruit. Practically speaking, non-blocking event handlers have had a bigger impact on user experience than anything I've seen in the last few years. I expect IntersectionObserver to have a big impact too. I think chasing the long tail of UX antipatterns, while not as sexy, is far more productive.
The problem with focusing just on adding new stuff to the platform is that, while Google's evangelism operation is impressive, it's hard to get existing Web developers to move to new stuff. It's the classic Itanium vs. x86 inertia problem. To take Washington Post as an example, they layout thrash like crazy when loading, despite it being known for years that that's a massive performance problem. By contrast, by making existing patterns faster, we improve the user experience for all Web sites, old and new.
To be clear, we should both introduce new APIs (IntersectionObserver is a very important one) and work on improving performance of the old. They're not mutually exclusive.
> In any case, I'd be happy to be proven wrong here - Servo is doing some really cool stuff and no one would be sad to see things get faster; I just don't see it as the silver bullet it's often promoted to be. I think this is a great example of how having multiple rendering engines is healthy for the web.
Oh, it's hardly a silver bullet. Those don't exist. By the same token, though, new APIs and things like AMP aren't a silver bullet either ;)
> I think this is a great example of how having multiple rendering engines is healthy for the web.
I agree, which is why I disagree with the "Chrome Won" defeatist attitude of the article.
True. But Mozilla is betting on servo which I see as a big question mark as well. Are you sure that people will download firefox over chrome when servo lands? How long before it will finally ship? 1, 2 years? Was there a market research before hand? Like I said its a big question mark. Cant blame me if I have doubts after Firefox OS.
> I don't understand why "you shouldn't even try to improve" is such a popular sentiment on HN, of all places. What possible benefit can complacency bring? Why advocate it?
I dont know and I dont have something to do with it. Personally, I think the popular opinion on HN is pro Rust and pro Servo.
> I'd be more than willing to hear your technical thoughts...
Wait, are you using the "if you cant talk technical GTFO" card on me? We are straying from my original comment.
To make this perfectly clear:
Im not against improvement. Im against Mozilla's poor business decisions. You can see that was my point in the original comment.
No im not downplaying all your hard work. But ive seen this happen before. Happened to me as well. "Oh this will be great when it ships" at the expense of the company. Im trying to give an alternative opinion here contrary to the constant positive reinforcement when Rust and Servo is posted on HN. Nothing personal.
Bits have already landed, and another major piece is being worked on right now. That's the whole idea of Quantum; no need to wait till Servo is done for Firefox users to start seeing benefit.
Are you sure that people will download Firefox over Chrome when Mozilla does nothing?
I think Go has already become unavoidable for those working in cloud like environments, thanks to Docker and Kubernetes.
Anyone working on those areas needs a working knowledge of Go, even he/she dislikes the language.
It's definitely put it firmly on my radar as something to pick up recently, and since I don't already know C or C++ it feels like a good starting point.
There are not a ton but there are more than zero.
I'm much less pessimistic.
Besides a cross platform and extensible browser we see also the following coming out of Mozilla:
* Rust, a modern low-level programming language with cutting edge "safety" build in at zero runt time cost, luring many system programmers.
* Servo, tomorrow browser, from scratch, in Rust.
* Thunderbird, x-platform desktop email client (interesting for those not trusting the cloud enough).
* MDN, everything MSDN and w3school wish they could be. :)
A lot with revolve around privacy and safety in the future, a space that Mozilla is very well positioned to florish in.
Chrome is a good product. But I prefer Firefox. And seeing what is becoming of Servo I will soon start using that. Form me Firefox has won, and is not at all losing. I dont need the "most popular" browser, I need the most secure one.
And when I see what programming languages Google came up with... (Seriously? Is Go the best money can buy?) Then I think Rust shows single handedly that Mozilla beats Google in that arena as well.