Live data from Hacker News

Servo’s new home

blog.servo.org

161–170 of 326 posts

Re: Servo’s new home

#161

We've been cagey about this over the months since the Servo team at Mozilla was disbanded, since there were various moving pieces that needed to fall into place. We're excited about the possibility for Servo to continue growing and evolving in its new home, though!

I don't imagine this is news to you, but just in case, the 'Contributing' link 404s.

Re: Servo’s new home

#162

On the face of it, this sounds great! I hope it leads to bold new things. 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 th…

The Linux Foundation is basically a catch-all foundation for smaller open source projects, this is not "Linux owns a browser engine". The "Linux" there is more of an indicator of its origins than its purpose.

Thanks for the clarification.

Re: Servo’s new home

#163

Edit: It's clear to me Servo is vaporware right now. The discussions in this thread and crawling servo.org make that abundantly clear. 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 tremendou…

Servo already has a C embedding API in https://github.com/servo/servo/tree/master/ports/libsimplese....

Re: Servo’s new home

#164
post #50

Earlier quoted context omitted.

Is it really so unlikely? Firefox integrates all kinds of components from elsewhere; why shouldn't it continue adopting parts of Servo where appropriate?

Seems just more unlikely. 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 ma…

The true difference is that Servo is more modular than WebKit.

Re: Servo’s new home

#166

We've been cagey about this over the months since the Servo team at Mozilla was disbanded, since there were various moving pieces that needed to fall into place. We're excited about the possibility for Servo to continue growing and evolving in its new home, though!

I looked for a list of projects currently embedding Servo, or planning to, but didn't find one.

Is any software embedding it now?

Re: Servo’s new home

#167
post #36

Earlier quoted context omitted.

What's the plan exactly? Will there be a Servo browser that integrates the servo rendering engine with some open source components (for instance from Firefox, WebKit or Chromium) that will let us use the engine stand-alone, or is it "just" going to be an engine for embedding in third-party programs? 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 th…

The latter would be better, imo. 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 e…

> That's why you see so many Electron apps. Seriously, we don't need to wrap a whole browser

Actually, Electron wraps an entire browser, except for its UI part.

Re: Servo’s new home

#168
post #4

Awesome news! The world needs another prominent browser engine that browser vendors would want to use, and detaching Servo from Mozilla makes it better positioned for that task IMHO. I'm also very happy that work on Webrender continues. I love what you're doing guys!

Should we start calling it Servo by Linux now?

Servo Rust Kernel™ ... coming soon to a hacked up Linux kernel near you.

Re: Servo’s new home

#169
post #100

Earlier quoted context omitted.

> 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. I never donated to Mozilla for this precise reason. Now I'm seriously considering it. Edit: Done

The irony is that from both of these comments it implies you have a concern about the future and the stability of Firefox as both an open source project, and it's role in preventing a browser monoculture. 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…

If Mozilla were serious about Firefox and privacy, they'd move it to the Foundation, allow direct donations, remove all the Googleware, Pocket and whatever else they unnecessarily shoved into Firefox + all the problems you stated.

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.

Re: Servo’s new home

#170

Earlier quoted context omitted.

Electron (WebKit) is much more than a rendering engine though. Sure, you could use Servo in a desktop app, but you’d have to also bundle all the other browser components (a JS engine, for example) individually. You’re basically building a browser at that point.

Well, to be honest though, a lot of the criticism of Electron stems from the fact that it's more than just a rendering engine. 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/Ru…

> or where you're writing all of your core logic in C/Rust but you want to use HTML/CSS for your interface

DOM is highly intertwined with JavaScript, so that wouldn't be possible.

Post reply on HN