|
|
@pcwalton | |||||
|
IMO, modularity should be a goal of every browser engine. You should be able to share code between browsers, and between browsers and other types of apps, without taking the entire engine as a monolith.
|
||||||
|
||||||
|
|
Patrick Walton
@pcwalton
|
27. sij |
|
The trick, of course, is to do this without slowing down development. It's tough, but I think it's doable.
|
||
|
|
||
|
Bruce Mitchener
@ArmyOfBruce
|
27. sij |
|
WebAssembly could allow us to ship our own layout engines and such with the “right” lower level APIs. So many things could have been WebAssembly modules / plugins.
|
||
|
|
||
|
Anthony Ramine
@nokusu
|
27. sij |
|
The scare quotes are the most important part of that tweet.
|
||
|
|
||
|
Anthony Ramine
@nokusu
|
27. sij |
|
chrome: jUSt FORk It dUDE
|
||
|
|
||
|
Slava Pestov
@slava_pestov
|
27. sij |
|
OpenDoc!
|
||
|
|
||
|
Reilly Grant → @reillyeon@toot.cafe
@reillyeon
|
27. sij |
|
This would be a lot easier in something other than C++ where basic design decisions don't infect your entire application.
|
||
|
|
||
|
Thaddee Tyl
@espadrine
|
27. sij |
|
The LLVM of browser engines?
|
||
|
|
||
|
Moritz Mahringer
@mormahr
|
27. sij |
|
Would be interesting to have an easily pluggable css engine. (For example to make a HTML → PDF library). Weasyprint for example reimplements the whole css stack. Don’t know if one could use stylo for that. (Besides weasyprint being implemented in python).
|
||
|
|
||
|
Andrew Ɠɨḃșȏȵ
@goofballLogic
|
27. sij |
|
Oh yes should is here again
|
||
|
|
||
|
Paul Rumkin
@rumkin
|
27. sij |
|
I’m working on such browser. Now it has pluggable network layer which allows users to add custom networks support, like IPFS, from userland. The main issue there I see is the “hell of engines”. Still thinking about the solution, it could become a real trouble.
|
||
|
|
||