Servo’s new home
blog.servo.org
blog.servo.org
The former seems like it would be a huge amount of work, but if it's the latter I fear for the long term survival of the project because it's going to be hard to build a community around such a project IMO.
Or is there a possibility that Firefox will try to integrate Servo even if it's developed outside of Mozilla? Seems unlikely to me.
Rust will not bring that magic.
It’s not an automatic magic bullet, but in a world where humans are still writing the code, Rust’s feature set makes many performance optimizations much more practical.
(Provided that the C++ version is not strictly optimal WRT resource allocation; I think it's a rather safe bet.)
The memory usage part isn't really apart of rust or C, but rather that projects like chromium require significant hoops to jump through if you wanted to compile electron with only what you need.
I expect that servo will be tackling this issue, the browser works standalone and that's a hefty achievement in itself.
It's meant for embedded but that probably just means it's easy to build and uses low memory.
A high-performance, small-footprint platform that implements a subset of HTML5/CSS/JS to run applications, including the YouTube TV app.
To be clear I wasn't suggesting that Cobalt is a replacement for Electron. Electronic has a lot of its own APIs too.
Rather, I wonder if Cobalt could be better than Servo along some dimensions as an engine for something like Electron.
Previously it was doing research, with the possibility of landing in Firefox. Now that's highly unlikely.
This is exactly what I want their goals to be. Embedding Chromium in applications is cumbersome, bloat applications, etc...
In the long run, having more options of web renders to use will help with everything, including browsers. Maybe it won't all be pulled into Firefox, but (ignoring all the other problems with DRM/regulation/anticompetive behavior/etc) it'll at least make it a little easier for other people to build browsers, and it opens the door for us to have more lightweight alternatives to applications like Electron.
It's one thing for a mozilla team member to say "Hey, let's pull the servo css layout engine into firefox" It's a whole different thing for someone to say "Hey, let's pull the webkit css layout engine into firefox".
The servo stuff, while for experimentation, was ultimately geared towards the notion of landing parts of it into firefox. It was built for that. Under an opensource foundation maintainer model, there's a strong possibility that it moves from that as a goal.
It's more like Skia and can be used to develop GUI frameworks (which is exciting because Servo is Rust and Rust's GUI story is still in its early stages).
Chromium won because it introduced a sane API before Mozilla's Gecko. That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser. Just the engine and a debugger would've been fine.
The engine could be distributed as a lib and other frameworks could just bind it. Apps could be distributed without an 150MB behemoth just to have a chat client.
Making the engine also mobile compatible would mean Android and iOS could maybe have the same base. I also look forward to what this means for Linux phones. Custom browsers could be written for those that don't have to use WebKit or try to launch Chromium or Firefox on a mobile device.
Not only for mobile devices, but also displaying things in VR can be made significantly easier if you don't have to write all the UI yourself. Give it an opengl rectangular surface (or vulkan?) and you can then use web technologies to make UIs in VR.
All in all, I'm very for an engine. It would definitely allow a competitor with a good name to enter the market. Developer should be able to reach for something else than WebKit because nobody in their right mind is going to reach for Gecko.
Actually, Electron wraps an entire browser, except for its UI part.
Also, 150MB is not really that scary of a size in today's world. Also, a huge part of it is simply because of static linking - if they split it into dynamic libraries, the actual content of any individual Electron-based app would be reduced significantly. But people are mostly allergic to dynamic libraries, so we pay the cost in larger binaries. Also note that vim with all its dependencies is ~40 MB, without a GUI.
That's mostly just due to vim-runtime though, and the documentation in many different languages. The actual vim executable is around 3 MB.
That very much depends on where you live.
The bigger question is when will Mobile Safari retire its WebKit fork? What role will Servo play in that inevitable end point?
Are you asking for iOS and macOS Safari to converge, or for Apple to ship straight from the open-source HEAD?
WebKit was originally based on KHTML, but Apple still founded WebKit and controls its source code. Even if WebKit was just Apple's name for their internal fork of KHTML, I don't see any reason they'd retire it.
Blink was originally spun-out of WebKit too. Similarly, Google controls Blink, and the two have diverged significantly in the intervening years. I suspect patches for any of them won't apply cleanly to the other two.
Regardless of their origins; KHTML, WebKit, and Blink are now independent pieces of software.
It's still unclear to me why anyone should expect Apple to retire WebKit for iOS.
> Blink was originally spun-out of WebKit too
Founded, spun out of, forked... What's in the name?
I think one cannot "found" something that's largely based on a fork of something else.
Do 10 of those, and you'll probably have enough understanding to fix one off errors in the documentation.
Do 10 more of those, and you might start answering questions from other people re: how to help the servo project.
Answer 10 of those questions, and you might go, oh hell, I'm already answering questions, why don't I write a blog post introducing people to the servo project so you aren't repeating the same thing over and over again.
write 10 of those kinds of articles, and you'll be ready to be mentored by the great servo and rust community and start making larger code changes, algorithm changes, implementing a feature that you really wanted,
and so on.
You gotta start small!
Is any software embedding it now?
Does it not work for a useful subset of HTML/CSS?
EDIT: Oh, and the Rust performance book[2].
[0]: https://github.com/rust-lang/rust/pull/79135
[1]: https://cxx.rs
Please forgive the beginner's question: my understanding is that servo is "just" an engine, which needs to be wrapped into a browser to really become usable. I've just tried (not for the first time, btw) your tech demo, which I think illustrates this perfectly. The rendering was lightning fast, but it's not a full browser.
You state that your goals are "to provide a high-performance, safe rendering engine for embedding in other applications."
Given that browsers are notoriously big software projects, do you think it will be an obstacle that servo is no longer tightly integrated with any sizeable browser project?
Of course, I'm asking because I'm really afraid that the amazing effort that is servo might dwindle into irrelevance simply because there is no "killer app" for it, and embedding it into several small/niche products simply doesn't generate the same involvement as a web browser.
There are a lot of applications where you'd want to take advantage of a browser view or a renderer or a JS engine, but not the rest of the stack. There are native apps where you might want a well-sandboxed JS engine for extension support, or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface.
Splitting up those components would be useful in a lot of situations.
DOM is highly intertwined with JavaScript, so that wouldn't be possible.
I would love to be able to contribute improvements to the desktop environments I use, but I don’t have the time to learn languages that aren’t applicable to my daily work.
That made me chuckle. If you have a reading about that, I think I would enjoy.
https://www.linuxfoundation.org/blog/2020/05/building-a-succ... https://www.linuxfoundation.org/blog/2020/09/software-define...
Along with an older presentation I gave on the topic: https://docs.google.com/presentation/d/1Q2jKVpeGkbDVdcUhrzxC...
I mean, even if they need to cut costs, isn't Servo part of the team they should keep until the end?
[1] https://blog.mozilla.org/wp-content/uploads/2020/08/Message-...
To put it bluntly: Mozilla is no longer a browser company. It is a patsy for google to point to and say "See we're not a monopoly.". Secondary goals are increasing the supply of devs for big tech and lowering wages.
Except for the leadership.
You see this at companies when engineering teams get it into their heads that they need to rewrite in a new framework. There's a trade-off between that work and building new features for customers. The benefits might be worth it in the long term! They also might not be.
That seems to be the call Mozilla made. I don't know if it's the right one, but it seems to be what they did.
Yes, because all those years the Mozilla executive team has proved that they have a good grasp of where the cost/effort optimum lies... /s
I've seen it several times: Often after years of promises from "the new hot" team, with them cannibalizing resources and top talent but missing milestones and still having failed to deliver, the new beast is cancelled and the value of the "old" system is suddenly recognized.
There's the classic Spolsky essay about this: https://www.joelonsoftware.com/2000/04/06/things-you-should-...
What's better? Refactor the old thing as you go. Include the "legacy" team in the development team of the new thing. Even more so, make the "new" team work on the old thing as well. Rotate developers between the two, build a culture of respect.
Not saying that is what happened at Moz, but I've seen it play out so many times. And without a concrete commitment to be forced to deliver to actual customers projects like these can just go forever noodling around in perfection-land.
I wonder if this is the end of that model, or more an effort to get external people to contribute more to Servo.
People have been claiming Firefox components were written in Rust for ages, usually meaning Servo, but it seems now that those claims were just misleading.
In general, a lot of text handling, and parsing in general, is moving to Rust, although some code is moving far more slowly than others. Additionally, APIs that had been implemented in JS that are too slow (or memory-heavy) are being moved to a Rust implementation instead, such as the l10n implementation.
Yes, lots (and increasing). E.g.:
https://searchfox.org/mozilla-central/source/servo/component...
https://searchfox.org/mozilla-central/source/gfx/wr
https://searchfox.org/mozilla-central/source/third_party/rus...
By niche I mean the myriad of keyboard driven browsers. kiosks, QML, electron, etc.
All I can think is that they took a look at Servo and decided it was cool tech but was really nowhere near delivering things they needed for Firefox aside from Stylo which it had already delivered.
Besides, nothing's stopping them from porting it without funding the project.
They have done some exploratory work, but nothing that shows they would actually do it.
They are most likely to just double down on the ongoing C++ lifetimes support on LLVM than switch languages.
- Mozilla engineering finally gets the green light to beat Chrome through a from-scratch rendering stack
- This skunkworks initative popularizes the world's first viable C++ contender and interesting "mainstreamable" programming language
- Manglement suddenly lays off the teams responsible for both projects (Rust and Servo)
- Some awesome person from the trenches convinces said manglement to release governance of the rendering engine so it can be developed independently ((of said manglement))...
- ???
- Profit...?
This is real engineering and strategic problem solving. It's inspiring to see.
What is very annoying is that a Mozilla-branded web browser already took the "Phoenix" product name. :(
Unfortunately Mozilla seemed to go from "awesome" to really disappointing in a very short time window.
If you're going to be that biased, at least back it up. And by back it up, I mean at LEAST throwing in some statements of fact, if not URLs.
[1] - https://www.cnet.com/news/mozilla-cuts-70-staff-as-part-of-p...
The way to kill Mozilla is from the inside: to quash its soul.
In the open market, any organization that doesn't cares more about its survival than its mission will eventually be replaced by one that does. This is fundamental to the definition of "survival".
> If Mozilla falls, another will take its place.
The one that will take its place will be an organization that prioritizes survival, not its mission.
The only real downside is that they wouldn't have a seat on the WHATWG.
Yes, another chrome skin perhaps?
Sure, I’ll buy that.
> push policy objectives against free speech
Can people please stop this latent homophobia? Mozilla fired a person who donated money to a deplorable cause. You can try to hide behind free speech, but we all know what this is about.
He quit. And I don’t agree with it, but I wouldn’t exactly call his cause deplorable. People with those views can believe they’re being completely ethical. That was also in 2008, a different political climate, and nobody allowed him to learn from it or to restitute.
Of course, I agree that wasn’t their downfall—it was simply misdirected goals and funding.
The purpose of Proposition 8 was to remove the right to marry from gay couples - yes remove - because the courts had already granted them that right.
If I was a gay Mozilla employee and I learned that my CEO wanted to remove rights which the legal system had already granted me, I would be so incredibly demoralized and pissed.
Regardless of personal beliefs, it's a bad thing for a leader of a tech company to be doing if they want to retain talent.
I agree that Brendan's Prop 8 donation was bad. But he did it privately, and never (AFAIK) made anti-LGBT comments in public. People who had worked with him for many years were surprised to find he had these views. It was only found out because of political donation public disclosure laws.
Some Mozilla employees publicly criticized Brendan for the Prop 8 donation, but some defended him, because of the aforementioned privateness of it. A number of the defenses came from LGBT employees.
The pile-on at the time was intense. It lasted more than a week. It reached the front page of my local paper. Crazy stuff.
Brendan chose to stand down as CEO and also quit Mozilla. He wasn't fired, and Mozilla leadership asked him to stay.
All this nuance was lost. Lots of left-leaning people concluded that Mozilla had knowingly promoted a proudly anti-LGBT guy to CEO. Lots of right-leaning people concluded that Mozilla had fired their CEO for his political views. Both conclusions were greatly over-simplified. Almost everyone found a reason to hate Mozilla. Bad times!
This isn't a mystery. Mozilla accept donations. It isn't an ordinary for-profit corporation.
Yes, they separate Mozilla Corporation from Mozilla Foundation, but the point stands. If Mozilla are going to claim to make browsers, apps, code and tools that put people before profit, [0] they should expect backlash when they lay off engineers while continuing to overpay their leadership, despite continuing poor outcomes under their stewardship. [1]
This all contributes to create a very toxic subject that I generally tend to avoid, but I think that it's fair at this point to question Mozilla's execs results at this point. These past few years have been pretty brutal for Mozilla, and there's no clear path ahead from where I stand.
The only comment mentioning her gender was someone defending her, you're pulling hair here
I'd be especially interested in an Electron-but-for-Python, along the lines of PythonWebkit: https://www.gnu.org/software/pythonwebkit/
Though it should be said repurposing a desktop first framework for a mobile paradigm is much harder than the inverse.
Cheers for this. Definitely keeping tabs on the project.
The problem is the ecosystem is small. If your use case doesn't fit their widgets, you have to do a lot of workaround stuff.
Although this app stands out as a success in my mind: https://fluffychat.im/en/
Okay, so now I want Tauri-but-for-Python.
I'll keep an eye on the project.
Just write your application in Django and start the local browser. Use Web APIs to trigger interactions with native APIs from Python code.
After all, that approach was pioneered by Dave Winer around 2000 or so, and never really caught on. On the other hand, Electron has exploded as a platform.
Using daemons implies actually knowing the underlying platforms and writing proper cross browser applications.
There ought to be some desktop developers who see the advantages of your preferred solution, where are they, and where are their apps?
Thankfully Electron is just a tiny percentage of apps that with exception of VSCode and Slack I can abstain myself from ever touching, with plenty of native or proper Web alternatives that don't augment the hegemony of ChromeOS.
As for examples with daemons using Web GUIs, ever heard of CUPS and SharePoint?
I think you are getting into "No True Scotsman" territory here.
> ever heard of CUPS and SharePoint?
I haven't messed with either in quite a while, but are the use-cases for those UIs supposed to be from the same machine serving them (ie. a desktop app equivalent), rather than over the network?
Planning to do exactly that tonight.
I'm one of those who stopped donating to Mozilla once I realized none of the money donated could ever be used for developing the browser.
If anybody else thought like me tonight might be a good time to prove we were principled, not cheap.
Edit: one more thing. Hopefully at some time we can now recreate Firefox with a new name, a new engine and a new, safe but also complete extension API that allows us to recreate what we've lost over the last few years.
Edit2: done.
Though I do wonder how much influence Servo will have on preventing browser monoculture given that as a stand-alone thing it can’t be or isn’t involved in developing standards. Mozilla will still have to play that role. I hope they step up to the plate and stay focused on this most important thing.
I've been there myself for years.
I'm happy to now be in a position not even have to think to donate tonight.
Hopefully you too will get there soon too!
Edit: and thanks for your contributions to netty and graphql-java!
I donate to Blender from time to time and I like how they just put an IBAN on their donation page ( https://www.blender.org/foundation/donation-payment/ )
I copy paste the IBAN in my e-banking app, send, done.
Why here do I have to read pages and pages of privacy policy, create an account, give my email, etc.
I never donated to Mozilla for this precise reason. Now I'm seriously considering it.
Edit: Done
Setting aside concerns about leadership, because IMO it's time for most of the current leadership to retire and make space for more innovative folks, Mozilla needs two things to preserve Firefox and Gecko, money and relevance. The have had numerous misfires on diversifying revenue, and they have been challenged on how to do that for a long time, but MoCo (Mozilla Corporation) has been profitable for quite some time due to the business deals with Google. That funds Firefox and many other related projects.
The other thing that Mozilla needs is relevance, and over and above the presence of Firefox, MoFo (Mozilla Foundation) has played an activist role across many different initiatives, standards bodies, and lobbying. That requires money, and because of the legal manoeuvring that Mozilla has done in structuring MoFo and MoCo it requires that Mozilla Foundation be largely self-funding.
Donations help with that, and pay for relevance in a way that Firefox alone can't. Please rethink the hostility towards donating to Mozilla Foundation.
It's not easy because supporting open source contributors is hard, and Mozilla is trying to keep their staff focused on corporate and foundation priorities.
Even if users could directly donate money to develop Firefox, the implication is that any such donations should only be used for Firefox development, when in practice, shipping a modern browser in a way that is competitive requires an enormous amount of non-"Firefox" related work (safe browsing, sync, telemetry, marketing ,release engineering work, advocacy, documentation, etc, etc, etc). Earmarking donations for engineering work is kind of silly in the context of an OSS project designed to compete with some of the largest juggernauts in the industry.
My understanding:
I'm fairly sure they've said they are not allowed to direct money from the Foundation to Mozilla Corporation, and it kind of makes sense until you realize it is the coroporation that creates the outcome you want not the other way around.
Also - from my point of view it looks like the Foundation is overfunded the last few years while the guys who create Firefox are underfunded, but I'm not an expert so it might very well be more complicated.
I also don't want to say Mozillas management are useless: they somehow managed to land a huge deal earlier this year, but I will admit I sometimes find some of their decisions puzzling.
For-profit entities can, of course, lobby and sit on standards bodies just fine. We certainly see plenty of that behavior from the other vendors.
I'm not saying the Foundation is worthless or that people shouldn't donate to it, just that they should know what they're paying for and what they're not.
I'm not going to consider affirming bad leadership by giving them money. Mozilla Corp employees aren't locked into anything (unless they signed really shitty contracts). They can leave and rebuild.
Servo might finally provide the foundation for a browser that really is about privacy and not just a cash-cow for a bloated upper echelon.
Pocket was an unnecessary acquisition that wasted money for an opt-out solution to... I don't even know what problem. The money spent on acquiring it could've gone into more developers, technical writers, testers, etc. Clickz (or however it's written) was also an unnecessary fail investment.
Once Mozilla rethink;s its hostility to its user base maybe the user base will rethink its hostility towards Mozilla
Mozilla left us, we did not leave Mozilla
To be a viable computer system, one must honor a huge list of large, and often changing, standards ... A huge amount of work, but if you don't honor the standards, you're marginalized. ... At another level, instruction architectures, buses, etc. have the same influence. With so much externally imposed structure, there's little slop left for novelty. Even worse, commercial companies that "own" standards, such as Microsoft and Cisco, deliberately make standards hard to comply with, to frustrate competition.
Unlikely.
However -- after surveying the comments here, I am left with a poignant sense that this launchpad project has already contributed way beyond its share of heavy lifting to shape and to popularize the rust programming language. Servo no longer needs to succeed in order for rust to win.
Back before multi-core x86 CPUs or the C10K paper came out, a unique engineer decided to show the world[0] how an event-driven web server could perform way better than the threaded web servers of the day. Nobody really uses thttpd in serious production work anymore, but its influence and example can be traced through Zeus web server, lighttpd, litespeed, and on to haproxy and nginx today.
FWIW Mozilla gave up on producing an alternative browser engine years ago, much to the annoyance of its developers. The recently brought out one for Android aka GeckoView, but I doubt if any developers will have some interest in using it.
When Microsoft ports its new Chromium based WebView2 which is currently available on Windows to both desktop Linux and Android I doubt anyone will be interested in GeckoView any more. Mozilla's current role is to enable Google and Microsoft to point out to regulators that there are alternatives to their market dominance and gain some referral revenue in the process. The simple thing is no one is interested in an alternative browser engine from Mozilla because they gave up on that ages ago.
https://www.reddit.com/r/firefox/comments/ag0ug0/what_is_it_...
https://www.reddit.com/r/firefox/comments/9ugy1h/this_week_i...
https://www.reddit.com/r/firefox/comments/bld586/what_is_you...
https://www.reddit.com/r/programming/comments/akovnq/the_leg...
My ideal model would be having one piece of trusted javascript which works similar to web extensions which can control the window, trigger navigations, approve or deny permission requests by origins and can interact with the current web control. Any advanced integration with the host operating system would happen though the local webserver (which could be implemented in node.js if that's your thing, or in C#, Rust...). This would not require many changes to a browser runtime.
Be it lisp, WASM, plain old C... It's just functions to call, that change the DOM, CSS properties, load pages, perform computations, call APIs...
Of course, the thing you lose is the hardware and software abstraction layer provided by chromium's javascript APIs. Those could be exported to a select number of languages, it wouldn't be hard for a single dev to create a usable runtime in their language if they are provided with C bindings to the H/SAL...
Rust shine when it comes to building a safe and fast web engine. For the OS "glue" code, I would stick to whatever is best for each platform.
I would vote for HTML/CSS based browser (React / React Native?), though I know that a lot of operating system specific code needs to be written.
The best place if you want to keep tabs on this area is probably https://www.areweguiyet.com/
(through that's all there is to it, calling it "by Linux" would still be misguided I think as the foundation is named after Linux and not the other way around)
Tangentially, what’s the headless browser space with Firefox at the core looking like? When would it be able to provide something like Electron (possibly without being such a RAM hungry piece of software)?
Does anyone have any insight into what level of influence Linux Foundation's Platinum Corporate Members have over it's priorities and direction?
Beyond the obvious (Google), MS are invested in Blink and Tencent/QQ in Webkit. I guess there's scope for branching out in terms of engine use but... MS have already tried that quite a lot.
I'm not saying that it's necessary for all Foundation Corporate Members to be actively adopting Foundation projects, but more that some may have commercial interest in those projects not competing with their own.
The plan is to later have a Board responsible for financial decisions. Paid sponsorship to Servo (not just to LF) can grant a seat on the Board but not on the TSC.
Would it be possible to create a rendering path that just supports flexbox/grid and stuff that's not performance limiting ?
This wouldn't be great for existing websites but it would be amazing if you had a CSS "strict mode" for electron like apps and new content.
Stoked this project isn't dead and isn't tied to Mozilla, I like lsf much more.
You could also go for the more ambitious plan of creating a brand that can take over Mozilla as a "trusted browser maker", which seems feasible given the falling reputation of Mozilla and the technical security advantages of Servo.
before, a donation for Firefox or Servo was just a donation to the Mozilla Foundation, which probably went to Mozilla's unrelated monetization efforts rather than the thing you intended.
Original post: As an embedder, I just don't get the point. Servo is a nonstarter. The idea of Servo minus Rust is great, because most embedders don't use Rust. They use C, because C is easy to embed with, and the availability of FFIs across languages that interface with C is tremendous.
As someone who has used CEF, looked at Webkit ports, and has even written a compositor compliant with a subset of CSS 2.1, you just cannot sell Servo to me without a C interface.
My problem isn't, "I need an embeddable web browser written in Rust." My problem is I need any embeddable web software―at least a CSS 2.1 compliant compositor―as an alternative to CEF accessible through C, C++, or an FFI that talks to C, but almost no one makes one.
I don't even necessarily need anything beyond a CSS 2.1 compositor, because so much of "web development" is either CSS 2.1 or JavaScript, and I don't need the latter for my embedding purposes.
Reading code isn't reading documentation. The fact that someone on HN had to search for it and paste it here tells me enough about where they emphasize their time.
It's just that no one bothered to expose it.
EDIT: I'm wrong, but I do think the documentation isn't that great.
https://github.com/servo/servo/tree/master/ports/libsimplese...
Almost the entire quick start guide is about using Rust. So you know, if I want to embed it, how do I do it?
If I need a view offscreen rendered to a framebuffer, how do I get it? Can I blit? If so, how? How do I pass events to the browser abstraction?
Servo talks about none of these things and leaves it up to you, but 110% emphasizes everything possible about Rust.
I don't care about Rust, I care about embedding web technologies. So how do I do it? They don't explain.
The front page prioritizes these things, in this order:
* How to use Rust
* How to contribute to Servo
* Servo's blog
* How Servo is governed
* How to donate to Servo
* Contacting those involved with Servo
* Downloading Servo
Maybe they should spent more time catering to the people they claim to be providing the software for and less to the Rust crowd.
Anyway servo comes with libservo and libservosimple. Admittedly they don't seem to be well documented for people coming from C world.
Perhaps you might want to comment on raise an issue for Servo?
I haven't worked on it in quite a while.
If they don't have a getting started guide for people like me to actually embed and use the software it's a waste of my time and hypeware or vaporware depending on how you want to look at it.
18k stars and I know there aren't 18k embedders out there.
Embedding is a primary aim, but certainly requires a lot of wrapping at present to be as functional as more mature engines.
No doubt it would be nice to have an easily portable lib - maybe with a compatible interface to other engines - but its certainly not there yet.
I agree that the project could/should be a bit clearer on its current status.
I’m really not understanding your hate. Servo is a WIP. If you don’t have the time/skills to embed it in its current state, then don’t! But it’s still embeddable :)
It also produces an interesting coherence:
Google + MS -> Blink
Apple -> Webkit
Linux -> Servo
All the main OSs now have their own web rendering engine.
The 00s saw anti-trust against MS for this practice (ok, for the rigid way MS forced their engine onto their users)... but today the market has coalesced around the same core idea, cementing the notion that general purpose OSs need a web rendering engine.
Might this pave the way for a better cross-platform UI development? Rather than shipping Electron to every device for every app, apps might leverage the web renderer tied to the OS?
I'm just wondering out loud. I was actually hoping we'd collectively move back towards native apps with better cross-platform tools, rather than integrating web apps deeper into OSs (even tho' I'm a web developer by trade and stand to gain from this).
The "Linux" there is more of an indicator of its origins than its purpose.
I thought the biggest draw to Electron was that it was a single stable platform that worked and looked the same everywhere.
I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
> I feel like (based on that) any attempts to move to OS bundled web engines would completely miss the point of why Electron is popular.
If the web platform is modern enough (chrome, firefox and mayybe safari) then supporting these different platforms is not that difficult.
But certainly not anywhere close to the 0 extra effort required by an app developer to support other platforms with Electron as it currently is.
If you're targeting application developers, minimizing the system requirements (including size-on-disk) for an installed app that embeds Servo is going to matter.
I don't know how much it matters, though.
Lots of folks in this thread brought up Electron and Servo being a potential replacement for it, but the preview build is already larger than Electron today.
That's it. Firefox already has big chunks of Servo inside, those aren't going anywhere - without them firefox will be slow again.
Any idea?
This diagram [1] kvark posted the other day might help. (I think dotted-outline boxes indicate external components, but couldn't swear to it.)
The VR focus was because it was a good way to get servo out to end users early without needing to be fully web compat -- WebXR doesn't require complex layout. We didn't drop our focus on full web compat during this, but full web compat has always been a more long term goal given how complex the web platform is.
You have a massive effort ahead of you, and you won't get there by chasing distractions. You need to have a singular focus if you're going to accomplish this goal.
If they announced tomorrow they’d decided to focus all their efforts on using Rust to calculate digits of pi, that’s their perogative.
As a prolific creator with a strong sense of vision for your projects, I’d have expected this to be obvious.
Their webpage tells you what they really care about, and it isn't embedding.
I fail to see what benefits a more permissive license would bring.
For another, Mozilla has never really tried to "market" the license. It's hard to make something gain traction if you don't really try.
And then nobody really cares that much about licensing so if something is "good enough" and does what they want it to then they're going to stick to it. Especially if it means they get to avoid doing research about licenses.
And people that do really care about licenses tend to fall into camp permissive or camp copyleft with not a whole lot of in-between.
That makes it unusable for Rust, Go, and some C++ libraries.
Wheras with MPLv2 the contract is basically "if you make a change to any of the source code files derived from the original work, those changes have to remain under MPLv2". But linking that code from non-copyleft code is OK, and extending it with subclasses or traits is OK, as long as any modifications made to the original library itself are made available. And there is no limitations on linking proprietary libraries from MPLv2 code as there is with (L)GPL.
It's still going to be an uphill battle for Servo to really make an impact on the overall browser/web industry/ecosystem, but at least for now this is very positive news.
I see Servo as a great Electron alternative. And I think eventually it could become a browser, though I understand that at least as of a few months ago that wasn't the plan.