-
ORCSolver-CHI2020
Code released for our CHI2020 paper "ORCSolver: An Efficient Solver for Adaptive GUI Layout with OR-Constraints"
-
SurveyJS
Open-Source JSON Form Builder to Create Dynamic Forms Right in Your App. With SurveyJS form UI libraries, you can build and style forms in a fully-integrated drag & drop form builder, render them in your JS app, and store form submission data in any backend, inc. PHP, ASP.NET Core, and Node.js.
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
I don't know how you're quantifying "trying a bit harder", but from caniuse: https://caniuse.com/?compare=edge+102,firefox+101,chrome+102...
Safari and iOS mobile are the main outliers. Firefox is a little behind too, but few people use that anymore.
Chromium/Blink development is what actively drives the web forward, with everyone else playing catchup. Apple just doesn't care about that (or is perhaps purposely trying to slow it down) in favor of their own priorities and platforms.
Layout engines are difficult to write and adapt. Especially adapt as they're so complicated.
I read part of the ORC Solver paper and there is algorithms in that paper for writing a layout engine and there's code on GitHub.
https://github.com/YueJiang-nj/ORCSolver-CHI2020
I would like to adapt this approach but write the code myself but it is obviously a challenging area.
I am yet to write a branch and bound optimisation algorithm. But from my understanding you greedily try a number of rows or columns and try arrange objects preferred width and preferred height into the space available. ORCSolver uses intervals and eliminates attempts that are not viable. ORCSolver uses Z3 for the final step to actually get coordinates when the system has been constrained. I plan to use ORTools.
For simplicity I plan to break up text into letters and try place them all in a flowing horizontal then vertical layout. I can use GetTextExtents of WX widgets to predict size of a rendered letter. It shall be slow but then how else do you begin writing a layout engine? I would need to read TeX or the Art of Computer Programming.
Layout is expensive especially for grid based layouts with flowing. I wonder if website authors could prerender at different resolutions and provide start point sizes and coordinates for speed. Generally everybody reaches the same numbers on everyone's machines and we don't need to try a lot of aborted work to relayout.
I am the author of additive GUIs which is a declarative rendering approach for bootstrap layouts. https://GitHub.com/samsquire/additive-guis
Servo seemed to have pretty much got rendering working. I'm no expert but I feel like the hundreds of JS apis contribute a lot to the complexity. Just looking at the list here looks like it would take decades for a single person to complete https://developer.mozilla.org/en-US/docs/Web/API
You cannot escape the politics of browsers by going to WebAssembly, because that's where WebAssembly was born. To use features outside of the original WASM spec, you have to consult a table and perhaps use a polyfill, like with CSS or JS features. Browser implementer have a large influence on the direction of the VM. For example, around a year into the original spec's development, it switched from being based on an abstract syntax tree to being based on a stack (https://github.com/WebAssembly/design/issues/755). A big change like that, a year in! The s-expressions in the text format are an artifact of that period, since tools already relied on their existence for optimization.
Anyone who writes a compiler or engine for WebAssembly it is going to have to deal with the mess of web standards, unfortunately.