3 ms·

I don't know about the "completeness" part but the idea of making a brower-like rendering system without the burden of having to support old standards and data

I don't know about the "completeness" part but the idea of making a brower-like rendering system without the burden of having to support old standards and data formats _is_ appealing. I think this is what projects like QML [1], JavaFX [2], Avalonia [3] and more recently Flutter [4] have done (also... Flash! does anybody remember it anymore? One minute of silence please...). It is too bad none of these projects decouple well enough the layout and rendering part, they are really very coupled to their respective environments and all of them are super idiosyncratic and make cross-language development almost impossible or unpractical (except maybe Qt but it is not quite the same model as QML), as opposed to the openness of the web platform. I think maybe all of them use Skia on the back though? Some of these projects are similar to the browser in that they allow controlling the content using an scripting language (JavaScript for QML). What do you get when you mix a rasterizer plus a scripting system or VM plus a layout system plus some IO primitives? Macromedia Flash! Just kidding, you get a browser. Or either one :-). 1: http://doc.qt.io/qt-5/qmlapplications.html http://doc.qt.io/qt-5/qmlapplications.html 2: https://openjfx.io/ https://openjfx.io/ 3: http://avaloniaui.net/ http://avaloniaui.net/ 4: https://flutter.io/docs/resources/technical-overview https://flutter.io/docs/resources/technical-overview With regard to browser specific problems, I came across these articles from this "Meyerovich" guy talking about some opportunities to optimize and parallelize the layout process. Honestly a lot of this stuff flies over my head (formulating the layout problem with attribute grammars? I don't even know how to use attribute grammars for the "normal" things... :-p). I have the idea of maybe coming back to these papers some day with more time and patience and go over the references, etc: https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.pdf https://lmeyerov.github.io/projects/pbrowser/pubfiles/paper.... https://lmeyerov.github.io/projects/pbrowser/pubfiles/login.pdf https://lmeyerov.github.io/projects/pbrowser/pubfiles/login.... https://lmeyerov.github.io/projects/pbrowser/hotpar09/paper.pdf https://lmeyerov.github.io/projects/pbrowser/hotpar09/paper....

Yoric 8y ago
Another problem would be the delivery. Yes, writing something that behaves like a browser would be nice, but it took 10-15 years for browsers to be present on enough computers to make a clear difference, and there is currently no reason to assume that a new technology that is the-same-but-simpler would have nearly as much success. Of course, the solution would probably be to compile that code to something that works in actual browsers, which would be somewhat ironic :)
- emmanueloga_ 8y ago
  I would say, if you managed to cross compile your new browser into a statically linked binary executable weighting a few hundred kilobytes, it would become trivial to distribute and a very attractive “platform”.
  - naasking 8y ago
    You could probably easily render it in a regular browser using JS as well. Instant universal deployment.
- crimsonalucard 8y ago
  They can bake in dual rendering solutions into the browser and wait for the better solution to takeover. Very similar to what is happening with JS and web assembly.
mingodad 8y ago
There is also https://www.netsurf-browser.org/ https://www.netsurf-browser.org/ Small as a mouse, fast as a cheetah and available for free. NetSurf is a multi-platform web browser for RISC OS, UNIX-like platforms (including Linux), Mac OS X, and more.
- swiley 8y ago
  Have you ever tried building it? It’s small compared to Firefox but not “small as a mouse.” Lynx or (maybe) linemode might qualify for that.
  - mftrhu 8y ago
    It takes a while, but it's not too bad. Even my old Atom netbook managed the build in, if memory serves, under an hour - launched the build before lunch, was done afterwards - more than what I expected for sure, but even elinks takes its sweet time. And I believe that they might just be referring to NetSurf's memory footprint instead than its code size. It's much heavier than Dillo, but it's currently using only 118 MB with 10 open tabs.

Yoric 8y ago

Another problem would be the delivery. Yes, writing something that behaves like a browser would be nice, but it took 10-15 years for browsers to be present on enough computers to make a clear difference, and there is currently no reason to assume that a new technology that is the-same-but-simpler would have nearly as much success. Of course, the solution would probably be to compile that code to something that works in actual browsers, which would be somewhat ironic :)

emmanueloga_ 8y ago
I would say, if you managed to cross compile your new browser into a statically linked binary executable weighting a few hundred kilobytes, it would become trivial to distribute and a very attractive “platform”.
- naasking 8y ago
  You could probably easily render it in a regular browser using JS as well. Instant universal deployment.
crimsonalucard 8y ago
They can bake in dual rendering solutions into the browser and wait for the better solution to takeover. Very similar to what is happening with JS and web assembly.

mingodad 8y ago

There is also https://www.netsurf-browser.org/ https://www.netsurf-browser.org/ Small as a mouse, fast as a cheetah and available for free. NetSurf is a multi-platform web browser for RISC OS, UNIX-like platforms (including Linux), Mac OS X, and more.

swiley 8y ago
Have you ever tried building it? It’s small compared to Firefox but not “small as a mouse.” Lynx or (maybe) linemode might qualify for that.
- mftrhu 8y ago
  It takes a while, but it's not too bad. Even my old Atom netbook managed the build in, if memory serves, under an hour - launched the build before lunch, was done afterwards - more than what I expected for sure, but even elinks takes its sweet time. And I believe that they might just be referring to NetSurf's memory footprint instead than its code size. It's much heavier than Dillo, but it's currently using only 118 MB with 10 open tabs.