Relational databases may be ACID, but no, they do not "give us" ACID.
Take LMDB as an example. LMDB is a fast low-level KV storage engine. NoSQL here, but with full ACID semantics & usable as a backend for whichever DB flavor you so wish to implement. LumoSQL and the older sqlightning are sqlite implementations backed by LMDB.
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
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.
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.
Flexbox is a step forward, Grid Layout is awesome but is starting to look like CSS Vars, another spec lost in years of limbo
The myriad of incompatible CSS layout modes, present & coming, are evidence of the lack of a holistic & future-proof foundation. The Constraint CSS primitives can be used to implement Flexbox & Grid Layout in total, not true the other way around. And, such implementations would be fully compatible with each other. BTW, a Grid Layout implementation in GSS is well on its way.
The 2 fundamental layout features lacking in future CSS specs is 1) relative positioning & sizing & 2) true source order independence. Less this is addressed, layout will be tightly coupled with the DOM & good luck centering things
I'm all for improving what we have, and the new GSS system does look interesting and could possibly influence CSS. But I think you're reacting too strongly to CSS. AFAIK the normal, flex, and grid layout modes are compatible (in the sense that you can mix them in one page and have things like flex inside grid elements and vice versa). Being a lurker on some standardisation email lists some of the best engineers in the world are on there taking everything very seriously, including future-proofing since everyone is well aware anything they add now will basically have to be supported forever.
I'm not sure I understand your two complaints (isn't there already position: relative and percentage sizes?), but I think good engineering is always about making tradeoffs, and while I don't understand GSS enough to criticise it I feel it's unlikely to be a silver bullet that magically fixes everything in itself, and will likely have its own quirks and pitfalls as well.
LOL. Currently gss.js includes the generated PEG parsers with this madness. When the CLI tools come out, will include a build without the parsers, as it should be...
GSS was built not for standards, but for our flagship product, that's our priority right now. Our approach to organically influence standards is to make the APIs work in real world products, and if enough momentum builds to begin the necessary working drafts.
I'd like to see more polyfills of potential standards. Waiting years on end for things like CSS Vars or the Grid Layout Module is getting real old.
Instead of hating on JavaScript, the only turing complete tool we have in the browsers, we should be pushing for extensibility standards. API hooks into the internals of CSS selector resolution, layout calculations, etc so devs can add new features in a performant & predictable manner that may never trickle down from the ivory tower of standards.
GSS author here. What we're working on is a lot crazier than that! Using phantom.js we precompute layout for every possible screen size & generate pure CSS.
Precomputation - From small phones to large desktop, there are ~2million width & height combinations, even if solving a single screen size takes 10ms, were talking ~6hours. To get around this, using a sort of bisection method, we selectively solve for as few screen sizes as possible to test linearity of each variable's solved values. With Cassowary each variable is linear between breakpoints, making this possible.
Pure CSS Generation - Generate media queries & styles with calc() where calc is a linear function with respect to vw & vh units. A little JS we only be needed for browsers that don't support calc or viewport units.
Limitations - Precomputation will only work for deterministic / static layouts. For a highly volatile DOM, runtime will be needed, but that's probably OK given the fact that you're already using JS to mutate things in runtime.
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
Take LMDB as an example. LMDB is a fast low-level KV storage engine. NoSQL here, but with full ACID semantics & usable as a backend for whichever DB flavor you so wish to implement. LumoSQL and the older sqlightning are sqlite implementations backed by LMDB.