Comment by zghst | Hacker News Reader

Comment by zghst | Hacker News Reader

The page isn't showing up in IE10 for me and is sluggish performance wise on Webkit (OS X and Windows). You can see the layout stutter when recalculating whereas with natural properties, layout recalculation is smooth. In Chrome, the layout barely reaches 30fps.

Using CSS grids or flexbox would be more appropriate, and there is an outright lie on their section of flexbox. Flex items can be relatively sized according to their siblings using the flex property and aligned using the justify-content, align-items and align-content properties. In fact you do not need to change the HTML to reorder elements individually or as a column or row or reversed. Horizontally centering elements is now solved by flexbox (display: flex; on parent and margin: auto; on targeted element) and for legacy browsers, use display: table.

Trying to replace the browser's layout engine, instead of compliment existing technologies, is a terrible approach. It will always be slow and result in degraded performance. And shame on these guys building a so called 'layout' engine but not using requestAnimationFrame.

Anyone concerned about layout performance should visit these: http://jankfree.org/ http://wilsonpage.co.uk/preventing-layout-thrashing/

I agree about using Grids, in fact we're currently working on a Grid Layout Module polyfill, but with constraint-based sugar. Really excited for this one, relative constraints can get tedious, abstract grid-based primitives make high level layouts much more intuitive.

Concerning Flexbox, it is not a lie! Flexbox is still dependent on the source order / parent-child relationships within the DOM. With constraints, you get true source order independence, so you can layout any group of elements within any other regardless of DOM structure... When I get time, will push demos on how to simulate Flexbox and show examples not possible with Flexbox...

Amazingly, IE 11 just worked, yes need to tackle lower versions... Unfortunately, there is no other way to accomplish GSS's constraint-based CSS extensions without a runtime replacement for the browser's float-based layout. That being said, precompiling the computed results for a static page for all screen sizes, thus eliminating the need of 99% of the runtime, will make it viable for the jankiest of browsers, and resolved to ID selectors would be potentially faster than native language extensions!

We're still in very early days of the lib, specific issues and comments welcome on the repo:

https://github.com/the-gss/engine

> With constraints, you get true source order independence, so you can layout any group of elements within any other regardless of DOM structure...

That would be awesome. Does that means you can have a modal dialog box centered to the appropriate parent view and still allows user to dismiss it anywhere in the viewport?

yes, the HTML of the dialog can exist as direct child of body, or wherever, and then be aligned to any element...

Legacy IE support is coming, as well as precompilation to CSS. Those will fix your concerns.

But on modern browsers GSS can already solve and lay things out in 60fps.

Unfortunately on two machines that I'm using that i7 cores, 16GB of ram, they both seem to have performance problems with layout recalculation.

Also I believe that many problems that this is trying to solve is already alleviated in existing technologies that will work in modern browsers, including IE10+, and web documents do not necessarily need constraints.

I think contributing to Mozilla or Webkit, or proposing a specification to the W3C would be more advantageous for your cause.

W3C will be the way to go long-term, but first we want to have as much real-world experience with this thing as possible. And that is what the current JavaScript implementation enables for us and others. Specs should never be made in ivory towers!

As for performance, that sounds very dubious given that even my Nexus 7 does this thing at 60fps

Running into the same jank issue as well. Chrome 33, Macbook Pro i7 w/ 16gb RAM. While I'm not at 30fps (averaging in the 40s), there are definitely some frames being dropped.

Runs a bit smoother in Firefox.

could this be happening because of bad video drivers? gss uses css transforms to speed up rendering and a bad video driver can cause a browser to automatically switch down to software rendering of 3D transforms.

If GSS requires 3D acceleration to get good performance, I'd say that it needs some serious optimization somewhere.

Adding another slow layer is not really helping anything: by the time you have browser-C++-overhead + DOM overhead + JS interpretation/V8/SpiderMonkey overhead, adding another layer on top of this all is really not wanting to make me develop on this platform.

Reply on news.ycombinator.com