Flex was working out a lot better for me some ten years ago, in Mozilla extensions, as it was. There's just too many rendering glitches and performance problems with flex nowadays, so I've moved on to scripted layout. I just felt that someone should say it.
Try writing idiomatic Flex rules based on the latest spec, and then running through PostCSS Autoprefixer. It smoothes out nearly all of the cross-browser glitches.
Well, I made some code that would emulate flexbox in IE for a specific HTML structure (it would parse classnames in the HTML and not the CSS, the code is still around on https://github.com/wiredearp/spiritual-mix/blob/master/dist/...) but it turned out to run about a hundred times faster than the associated CSS flex that other browsers would use; even in those browsers. The layout must aspire to a certain complexity before it happens, that's why you don't notice it at first (and why I posted the comment). I just checked back with the issue called "Catastrophic flexbox perf" over on https://code.google.com/p/chromium/issues/detail?id=331352 and it appears that it's now a lot better in Chrome, but you can try to Ctrl+F for "hosted demo" on that page and open the demo in Firefox (you should save your work first!). When the page eventually does appear, you'll see that it's really nothing special, and certainly not worth the wait.
There's one right now where a combination of flex and transform3d will cause things to simply disappear in Chrome and Safari but I haven't searched for any issues reported on that. The problem is progressively getting worse, so I'm almost sure you'll encounter it if you play around with those properties. I'm unfortunately not in a position to elaborate much further in this exact moment - but if this only happens to me, I really couldn't be happier!
We didn't like how attributes worked, so we changed it, but then people were using it and now we have to change it back. It's not a particularly good point. I would like to know more about the fundamental problem with existing specs. I've never had a problem with attributes that couldn't be fixed in browser implementation rather than specification, certainly not a "problem" that could only be solved with React or jQuery as suggested in comments. I thought that specs nowadays are modeled after "what works in todays browsers" rather than "what would be better", much like HTML5 is modeled after what works in IE6 (talking about "brave enough"). I also thought that this proposed simplification is already part of DOM4, or did I make that up? Should namespaced attributes simply become unsupported on an API level? That's a cost to pay, much like querySelector comes with the cost of 1) only being able to query the document structure downwards, not upwards, and 2) only being able to query the default namespace. The API may be less awkward, but it introduces problems that are actually problematic, so more arguments would come in handy for me to understand the point.
I wonder what will happen with the Polymer polyfills for WebComponents, a technology that Safari also hasn't declared intent to implement. And then I wonder what will happen with the polyfill for PointerEvents that already comes bundled with Polymer, which by the way works great in Safari. But most of all, I wonder what this all means for Polymer PointerGestures, which is exactly what we need around here: https://github.com/Polymer/PointerGestures. I'm starting to think that this may all go the way of all those technologies with an X in it's acronmym, which are largely forgotten today because of similar reasoning from Google's lobbyists. You have to assume that the future of these things is longer than the past. That's why you should never put politicians in charge of it.
Good info. With no specification to back it up, I might go back to my hand-rolled gestures-style library. I retired it because of imminent standardization, but at this point, it seems as likely to be standardized as everything else. I promise to take PolymerGestures for a spin, though, since I was happy with the coding going into those libs now deprecated. Thanks!
