Show HN: Stretch – A high-performance cross-platform layout engine in Rust
vislyhq.github.io
vislyhq.github.io
Erm, no. That’s testing Chrome compatibility (though it’s probably the only one easy enough to test).
Chrome is often rushing ahead to implement features that are either not standardized yet, or will not be standardized, or break exisiting standards and compatibility.
Chrome is, however, proprietary and driving further that way. IE6 showed that a single, dominant browser is not good for consumers or progress. Especially when it originates from one of the two leading surveillance tech firms.
[As an aside, I was disappointed to see MS admit defeat with Edge and jump into bed with G. Still seems a bit suspicious tbh].
You don't see people complaining that GHC is de facto the only Haskell compiler.
Sometimes. But motivation matters. The motivation behind ghc is clearly and unequivocally to advance the Haskell ecosystem. The motivation behind Chrome's dominance is another thing entirely.
There's (pretty much) only one Web that needs to serve us all.
Microsoft threw the towel for this very reason. It is quite hard to keep up when you have an implementation used by more than 70% of the market, because that makes it the de facto standard, regardless of what the standard really is.
We are going to see the same issues as with IE6: chrome does (and breaks) things before the standards are updated, and dictate huge chuncks of poorly-thought features on the web platform, that might become required for any kind of serious business (think flash, java, silverlight, widevine).
This really is the E part in EEE (the middle one...)
Given that all the relevant bits are in Chromium (sans Widevine, which is a whole subject on its own) this is not a strong argument.
We are probably past the point where a scrappy new open source browser could gain enough developer talent and user share to be relevant, though. Particularly since it can't be done without mixing in some proprietary code for DRM.
So there may be competition, and a significant chunk of open source code will be involved, but it won't satisfy the folks who want a pure open source browser.
For the rest, I work on Gecko (the rendering engine in Firefox). We get a fair number of bug reports about sites that work in Chrome but break in Firefox because Firefox is following the spec and Chrome is not.
Chrome is definitely closer to the standards than IE was, but that's at least in part because of all the changes standards have been making recently to match Chrome when Chrome makes it clear that they have no plans to implement what the standard says. When IE tried that sort of thing, people just wrote standards that didn't match implementation reality. That had its own drawbacks in terms of leading to standards so divorced from reality they were useless (see XHTML 2.0, for example)....
There were several things in the flexbox spec where Chrome refused to implement what everyone else was doing and the spec ended up getting changed, but I don't have links offhand, sorry. It would take me some hours of digging through bug reports and mailing lists to find them. In general, there have been a lot of things like this in the CSS world that I see peripherally, but I'm not as involved in that personally, so don't have them at the tips of my fingers.
A recent thing that came up is that the behavior of the `disabled` property on `HTMLLinkElement` in Chrome does not match the (very long-standing; literally decades) spec, and it looks like at this point we're going to need to change the spec to match Chrome because sites are writing code to the Chrome implementation, not to the spec, and it's causing compat problems for Firefox (which does implement the spec).
Now don't get me wrong: there are lots of cases in which Chrome _does_ fix longstanding spec-compliance issues. But that's not the only dynamic happening here.
As I put on https://www.reddit.com/r/rust/comments/9bapwt/thoughts_on_wh... this could enable the build of a different kind of cross-platform UI, where the logic (backend) is on rust and the UI render (front-end) in a native lang.
Long term goal of Stretch is to support multiple layout systems including Grid layout I just started with Flexbox because I know that so well :) Look forward to tackling grid layout soonish (contributions / help very welcome).
I hear you, but this is very different to "we're never going to implement this". I might look into contributing, but I've never implemented any layout engine, so I'm not sure how much help I would be!
If you’re not comfortable with constraint systems yet, just use UIStackView and voilà, it’s a flexbox.
I wish others would start their layout systems based on it (others like React Native, or native Android), then add simplified APIs like flexbox using it if needed/desired.
It is based on Cassowary constraint resolution algorithm just as Apple's AutoLayout.
Is it missing something compared to Apple's solution ?
No, the TeX book doesn't count. Looking at the source of Chrome or Firefox doesn't count. Stretch source doesn't count. W3C CSS specs definitely do not count :-p.
I know that there are some papers floating (pun not intended) but I wish somebody wrote a serious book about layout algorithms! Even splitting the words of a paragraph into an optimal shape is something that is surprisingly more complicated and rich topic than one would imagine [1].
Do you know of any resources/docs/papers/implementation-notes that you would recommend?
I thought a lot of people disliked Flexbox and preferred CSSGrid? I watched a talk a while back that made it seem like CSSGrid was better in many ways. Primarily being far more inline with peoples natural mental patterns (ie, what they expect). That talk basically had me thinking that the next frontend I write I'm not touching flex box and instead writing it in CSS Grids.
So am I mistaken? Why would people base a framework around Flexbox? Thoughts?
my email is in profile if you want to chat :)
All I wanted was a flexbox engine in Rust, and it's great to now have a pure Rust solution!