HN Theater @HNTheaterMonth

I just watched this GSS intro talk from last year: https://vimeo.com/91393694 It looks interesting, but obviously from this and the demo page it needs alot of work to be ready for the mass market.

One piece of advice for Dan if you are reading HN, you have a nice relaxed speaking style but please stop using the word "crazy" or "it gets pretty crazy" which for me at least parses as: "too complex to work with".

One of the devs of this project gave a talk about the motivation behind it, how it works, and other interesting details [1].

Of note, this project goes a fair bit deeper into advanced layout possibilities than the flexbox and grid modules included in the current CSS spec/drafts. Flexbox, for instance, prescribes a very particular pattern to the layouts that it affords. You must be rather methodical in how you break your layout into nested rows and columns. This focus on rows and columns causes quite a bit of visual shoehorning, or forces you to resort to hacks, at which point you've lost most of the benefit of using flexbox at all. Though for simple- to medium-complexity layouts where the visual arrangement is composed of nested rectangles following simple rules (as most of the web seems to be), flexbox is wonderful once you get the hang of it.

I'm very fond of constraint-based layout systems (and rule systems in general), having written a few of them myself. I feel that while this GSS project isn't a complete realization of the promise they offer, it is a nice step in that direction. I worry about the performance and complexity burdens this project seems to impose, though I say that only looking at the docs, the generated code, and the discussions that emerged the last time this was posted to HN. I will be using it for an in-house dev-facing tool in the near future, and about that I am quite excited.

[1]: https://vimeo.com/91393694

⬐ ender7

Performance would always be my key concern with something like a general-purpose constraint solver. I know that LP is a field in its own right, but I don't have a ton of experience there -- do you think there's a practical path to bringing the performance up to a necessary level (i.e. real-time, <10ms calculation times for complex pages)?

⬐ d4tocchini

Perf is surprisingly good, suitable for modern web apps. The bottleneck is DOM & CSS selector resolution, not the constraint solver - Cassowary is a beast!

We're working on a lib for pre-computing GSS layouts server-side, but it's significantly more hardcore than traditional pre-processing.

What we really need is browser vendors to offer deeper API hooks into layout lifecycle, painting, etc

⬐ skrebbel

Did you or someone else ever try combining it with React? Because of the virtual DOM, it'll probably mean that you won't need CSS selector resolution at all. Not sure here - I don't know how the solver gets its input (e.g. how you compute which elements impact which ones - do you read existing offsets and sizes from the browser DOM, or do you do something different?). But somehow I feel that the constraints story and React's render-only pipeline should somehow be able to work together really well.

⬐ d4tocchini

And here's a GSS screencast [1] that accompanied a tutorial in most recent issue of Net Magazine [2]

[1]: https://vimeo.com/99873002 [2]: http://www.creativebloq.com/net-magazine

⬐ notduncansmith

Thanks for the link. It did help cement some of the concepts presented on the website, but the presenter did a really poor job of selling some of it: "This... [points to screen] ... I don't know, it's crazy. [next slide]". How does that in any way convey the value of this thing?

Also, his answer to the question "How do we debug GSS styles?" was pretty worrisome: "Just add and remove constraints, and see what breaks it". That sounds to me like what a lot or people are doing with CSS right now, and the idea is horrifying. It's tough to imagine embracing a nondeterministic system where there's no telling what rules you've given it will be obeyed, and which will be ignored - at least in CSS, it's pretty clear when something will be overridden.

In this video the author says it works in IE11 and will be working in IE10 "within a couple of weeks" http://vimeo.com/91393694 .. which would mean it's working in 10 now .. also, if they manage to make the preprocessor stuff, then it will work in "all" browsers (that understand the generated css of course..)

Yes, the problem is that CSS's structural presentation is ultimately tied to the DOM. Funny you bring this up, as I commented earlier here:

"GSS was created b/c our company's main product, the Grid (still in stealth mode), is doing some radical things with design of newsfeeds, we need layout to be completely decoupled from the DOM. A fairly developed Float / Flexbox-based layout becomes as much of a CSS affair as an HTML one; changing layouts requires a whole new set of div wrappers. CSS was designed to separate presentation from content, and that ideal has unforeseen manifold benefit when actually realized."

Here's an example, http://gridstylesheets.org/demos/apple/ notice the button & panel layout as you change the screen size. Now, view-page-source & notice how every element is a direct child of <body>, no parent-child nesting... Here's a recording of talk I recently gave at FluentConf that delves deeper into this: https://vimeo.com/91393694