Servo Driving Modularity To Support Different JavaScript Engines

[patrick1946]

I really hope web assembly will be used more widely. I really dislike this slow web apps. If that you could be compiled down to something more static it would be much faster.

[timofonic]

I really hope web assembly will be used more widely. I really dislike this slow web apps. If that you could be compiled down to something more static it would be much faster.

And remove Java dependencies, such as government certificates for electronic administration procedures, justice and eIDs...

[Vistaus]

I wonder if this could be used as a guide on how to port V8 to Firefox.
I'm not saying it should be done. But it is *interesting* how this small non-profit tries to compete with the biggest players, while all others gave up on their own development... I can totally see them switching to V8 or Blink or both for financial reasons...

A small non-profit with money coming in from the biggest tech companies on this planet???

[Quackdoc]

A small non-profit with money coming in from the biggest tech companies on this planet???

and good amounts of it too

[rmfx]

Extra modularity is often good to take.
As long as the final engine is ultra light, secure and efficient.

[Kver]

This is probably a stupid question, but why does a layout engine need to integrate with a JS engine in the first place? I know there's Ajax, but even that is just a collection of events.

Not a stupid question. Probably the best example is HTML5 components (custom elements), where custom tags are registered by Javascript. So if I wanted to make, say, a <my-cool-graph> tag, I'd need to register it with JS which builds a shadow-dom, which also affects the CSS rendering and even CSS pseudo-classes and state functions.

Several tags also have Javascript APIs (like the video tag) so that's a thing, too. Lots of sites also depend on JS to load contents, handle layout, provide shims, handle scroll events, etc... Real-world testing would be impractical, since the vast majority of sites wouldn't work without JS. You'd be limited to only a handful of extremely simple (and outdated) sites to test against.

[byteabit]

I think a restricted JavaScript / EcmaScript with less functionality and access, just with some basic functionality would be enough for most websites. That would help reduce the attack vectors, bloat at runtime and possibly other useful things. Or define official API Levels for JavaScript, where each level is more complex and has more features, bloat, privacy and security risks. In example with the most simple form of JavaScript API Level 1 would not allow the download anything or whatever else (I'm not a web developer).

[dragon321]

It's probably too late for Steam to replace the internal browser and UI engine of Steam from Chromium to Servo.

It's never too late to replace some component in your application with new one. It's always matter of time and required work (and obviously money for companies). Servo currently is not mature enough for it but maybe it will be in future.

[bug77]

Not a stupid question. Probably the best example is HTML5 components (custom elements), where custom tags are registered by Javascript. So if I wanted to make, say, a <my-cool-graph> tag, I'd need to register it with JS which builds a shadow-dom, which also affects the CSS rendering and even CSS pseudo-classes and state functions.

But that would only require supporting the small subset of JS that handles the registering (if that).

Several tags also have Javascript APIs (like the video tag) so that's a thing, too. Lots of sites also depend on JS to load contents, handle layout, provide shims, handle scroll events, etc... Real-world testing would be impractical, since the vast majority of sites wouldn't work without JS. You'd be limited to only a handful of extremely simple (and outdated) sites to test against.

JS can run wild and then tell the layout engine what to do. But that doesn't mean the layout engine needs to speak JS, they could be decoupled via some events. Yes, I get it, events would be async, they would need to be standardized, so the JS code can talk to various layout engines transparently. Oh well...

[Awesomeness]

It's probably too late for Steam to replace the internal browser and UI engine of Steam from Chromium to Servo.

Steam uses CEF. If Servo brings back CEF support (which was originally removed ages ago), you could even replace Chromium with Servo yourself.