Introducing Famo.us-Angular
thomasstreet.com
thomasstreet.com
Here's an explanation of GPU compositor layers: http://www.chromium.org/developers/design-documents/gpu-acce...
Now, via Famo.us-Angular, you can tap into that performance with AngularJS, too.
Again...WTF does that even mean? So they only use CSS3 transforms that are GPU accelerated? So it's a CSS3 animation library? The vague documentation seems to imply a grander vision which is unclear.
The core of Famo.us is a rendering engine. Instead of using the DOM to represent its UI hierarchy or using the browser to render that hierarchical DOM to screen, it uses an internal scene graph representation and handles the rendering of the scene graph to screen through an abstracted output layer. The browser DOM is just one of its supported outputs; another is WebGL, and there's no reason there couldn't be other outputs, outside of the browser--I think this extensibility is part of the 'grander vision.' The scene graph is a very robust graphics model, so it would be a great choice for a model if someone were to reinvent HTML from scratch today. Again, 'grander vision,' maybe.
In the case of rendering to the browser, the way it works is by flattening and compositing its scene graph, creating a DOM node for each 'Surface' (which is a leaf node of the Famo.us scene graph) and handling the 3-space (or really, 2.5-space) positioning with CSS3 Matrix3D transforms, which are GPU accelerated. Since the DOM isn't needed for hierarchy (again, all of the calculations are handled by the engine) the Famo.us-outputted DOM is a simplified set of sibling nodes underneath a single parent (the Famo.us container,) and it continuously updates the Surfaces' DOM representations' Matrix3D properties (performantly, leveraging requestAnimationFrame) as the scene graph gets updated by the program running on the Famo.us engine.
So that's pretty much what Famo.us is. Does that help? A slightly less technical, if more practical explanation might be about how you can "write one JS app [and] deploy everywhere with awesome performance across devices and browsers."
How, I tried this using Angular and i cannot get it to work. Any sample available on github?
That being said, that is the state of famous today, but the long-term vision and plans are much more ambitious. At the end of the day, javascript has a single event loop, and any module/package you use that does not respect that single event loop as the commons can threaten the user experience of any app. What we're pushing for is not only a decent framework, but an entire ecosystem of libraries and tooling to make it easy to build high quality libraries that not only doesn't jeopardize the user experience, but actually makes it far easier for developers of all levels to make high quality (performance, affordances, etc) applications that delight the user.
[0] https://www.cocoacontrols.com/
disclaimer: I work at famous.
It's awesome. The API for working with 3D and animations/transitions is so much nicer than straight HTML+CSS. And I love having a render loop that's about 100x better tuned than I could come up with in the time available.
Adopting famous for mobile devices (phones and tablets) is a no brainer if you're trying to creating anything even remotely resembling a native iOS or Android app. The two reasons for this is that famous is basically the only thing currently really capable of building something comparable without requiring you to be a javascript performance expert, and because the browser situation is fairly homogenous in the mobile world (i.e. no significant portion of old browsers to cater to).
For desktop browsers, I would adopt famous now if you're trying to create a very app-y experience, but if most of what you're building is a traditional website, you should definitely take a progressive enhancement approach to incorporating famous.
disclaimer: I work at famous.
ala: http://worrydream.com/LadderOfAbstraction
I really wish there were more documentation on the progressive enhancement side of things though.
IMHO progressive enhancement is an anchor and those who have pushed for it for years are false prophets.
Instead I think we should focus on mapping routes to state (documents) so that an entirely different site (one resembling the original web) is shown instead.
I'm the first employee at the company and AFAIK also the only person at the company that browses with javascript disabled by default (ironic, isn't it?), and one of the things that most excites me about the API-ification of the web with thick web clients, is the possibility to create server side frameworks that a static representation (basically pure HTML and minimal CSS) with javascript for famous apps. If the user has javascript enabled, it would completely replace the content in body with a rich app. If not, they have the glory of a motherfucking website [0]. IMHO, progressive enhancement was a huge mistake and we instead should have been make two sites all along: (1) super duper interactive apps/sites for the newest and best browsers, and (2) stupidly simple sites/documents that would be browseable by old browsers, screen readers and hopefully even lynx[1].
Making a site serve two masters is more work and results in a poorer compromised experience for all. Apps and documents are built on fundamentally different abstractions and trying to find an abstraction that can accomplish both is a pipe-dream.
If you've never tried lynx, you should. It's a shame something like that is still not possible. Do a `brew install lynx` if on OS X, and when it's finished installing, type `lynx` at the prompt. Once there, type `g` to go to a specific URL and then type www.google.com and see what it's like to browse use google with lynx.
Developers should support disabled and disadvantaged users because it's a noble goal, but even if they don't do it for that reason, they should remember that Google, Bing and DuckDuckGo are some of the most active blind users on the web. Making a site work in lynx makes it work with screen readers and google.
For now, we don't have a good solution for this, but we're noodling on the problem and aware that it does matter.
This is absolutely exactly what I am talking about, and what I am dying to get back to. I find the idea of the content actually being the content, in a straight one paragraph/aside/article after another... with no floats or what not.... I find it completely fucking liberating.
I was absolutely blown away when i discovered that this is how you do responsive layouts in famo.us :
if (contextSize[0] < 480 || contextSize[1] < 480) {
dimensions = [2,8];
} else {
dimensions = [8,2];
};
I'm authoring lots and lots of content these days, and I just want to get on with writing the content, and then be able to add stuff like interactive figures, that only kick in when needed.
I also prefer links to lynx. I use it on my open pandora now and then, and whenever I am on a remote server.
What I can say is that what you're seeing are basically constraints and if you define lots of constraints, you can then use a constraints solver to help you automatically lay out your app on different devices based on rules you've defined. We're only beginning to explore these ideas at the moment, but we're definitely open to suggestions in the meantime.
If you're curious to know more about constraints and layout, check out the links below.
Regarding the notion of authoring content and then adding the whizz bang later, we're definitely interested in solving those problems, but it's going to take a while to get there. Ultimately, I think it's going to take an approach similar to what ember did, where you take a routes first approach. Once you have your routes, you then create the parts that determine what content/data needs to be show based on those routes. Once you're that far you, can then work on two layout strategies: one rendered by the server as static HTML and one that is rendered on the fly in clients with javascript enabled. My hope is that people are super lazy about the static HTML site, basically doing as little design as possible, leaving the final design looking more like the web before frames even existed; i.e. one long scrolling document with anchors jumping to the content you want, and reverse anchors taking you back to where you just were. I'm even curious if we could get back entirely to document oriented design as a fallback instead of some weird unusable frankenstein we get today when designers eager to make things rich and interactive also attempt make the same design support legacy browsers and the visually impaired.
[0] http://gridstylesheets.org/
[1] https://news.ycombinator.com/item?id=7353944
[2] https://developer.apple.com/library/ios/documentation/userex...
[3] https://harlanhaskins.com/2014/03/02/laying-out-ios-uis-in-c...