d4tocchini
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.
Cassowary is an incremental solver & is optimized for adjusting constraints in runtime.
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
[1]: https://vimeo.com/99873002 [2]: http://www.creativebloq.com/net-magazine
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'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.
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.
"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
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.
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!
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:
http://www.w3.org/TR/css-grid-1/#background
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 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:
https://github.com/slightlyoff/cassowary.js
Adam Solove had a good JSConf talk on Constraint Programming in the Browser that touches on Cassowary.js & perf benefits:
https://www.cs.washington.edu/research/constraints/web/ccss-...
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.