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
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
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
Author of GSS here. The brilliance lies with guys like Badros (Cassowary), Ken Ferry (Apple Auto Layout), Alex Russell (Cassowary.js), etc.
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.
Cassowary powered constraints allow for layouts not possible with a CSS unable to resolve cyclic dependencies in layout arithmetic. Of course, you could easily shoot yourself in the foot & define fragile, ambiguous and/or impossible layouts. But, w/ great power comes great... I always prefer expressive freedom over easy-to-comprehend limitations.
GSS is very new - much is needed like better debugging, implementing floats, etc.. Constraint-based layouts isn't a silver bullet, it takes practice & thinking more like a programmer. Fortunately, Apple Auto Layout demonstrates the viability of all this craziness.
that's with all the generated PEG grammars in the compiler. build w/o the compiler stuff, which should be handled node.js side anyway, will be approx jQuery's size.
Yes, yes, the site needs much more. Released only a couple weeks ago and probably needs a big fat "BETA" or something.
More language features, docs, demos, etc coming soon. Right now works down to IE11, and we will work our way further down, but once we get precompilation of a static GSS layout to raw CSS (difficult b/c must account for every possible screen size), it will be bullet proof on any crappy browser!
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:
W3C has been hashing out new grid-based specs for quite some time now, because as admitted in the Grid Layout Module working draft, "As websites evolved... floats, were not necessarily well suited for application layout."
Dozens & dozens of CSS grid systems have emerged, but without retooling the internals of the browser's layout engine and adding new CSS language features, such attempts retain the flaws of CSS float & will taint content semantics.
But, of course, the W3C's grid-based efforts is not without flaws, see:
The Cassowary Constraint Solver used in GSS is considered the most viable & perf-sensitive linear arithmetic constraint solver for real-time use-cases, hence Apple's adoption of Cassowary across iOS & OS X.
The GSS website is a good example, with about 400 atomic constraints on the homepage. Major bottleneck is reading / writing DOM, resolving element queries; not Cassowary's constraint resolution.
GSS uses the canonical JS port of Cassowary maintained by Alex Russell:
Yeah, common in the Constraint-based, or Logic, Programming paradigm. This particular spec was established in Greg Badros & Alan Borning's Constraint CSS (CCSS):
Likewise, I care not for, nor to learn, PHP, Ruby, Java, Python etc., but I can understand whatever I need to.
If you're a half-way decent js dev, it's hard to believe CoffeeScript could be a cognitive stumbling block for you. Inferring custom baked inheritance in js libraries surely is more difficult.
Of course CS isn't for everyone, but a hard stance that a CS lib can't be considered 'JavaScript' seems more of a political stonewalling than an intelligent conversation. But, I've come to expect such thorny defenses cultivated by a coterie of stern acolytes who have devoted themselves to a particular flavor of programming.
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.