6 ms·

I know Famo.us is pitched at app building, but how about websites? Would Famo.us-Angular be worth it for making a landing page with cool animations, or should I

by _zen 12y ago

I know Famo.us is pitched at app building, but how about websites? Would Famo.us-Angular be worth it for making a landing page with cool animations, or should I just stick with the simpler animate.css because it's good enough?

dgraunke 12y ago
Another Thomas Street dev here. I'm already using famous-angular on some client projects that are just that — animation-heavy desktop sites. 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.
- chalettu 12y ago
  Hi dgraunke. I am working on some projects and really anxious to try out famous-angular integration. Do yall have any alphas or betas of your angular integration js available yet? I'd be more than happy to be a tester for it.
  - dgraunke 12y ago
    Hey there. Shoot me an email at david (at) thomasstreet (dot) com.
- cfulnecky 12y ago
  Looking forward to May 19th, 2014 to put famous-angular through it's paces.
malandrew 12y ago
You can far beyond what is possible with animate.css and building a website is certainly a possibility. That being said, the current focus is getting everything rock solid across all mobile devices, so desktop support should be considered beta level for now. 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.
- AdrianRossouw 12y ago
  famous is going to make me pretend i'm brett victor soon. ala: http://worrydream.com/LadderOfAbstraction http://worrydream.com/LadderOfAbstraction I really wish there were more documentation on the progressive enhancement side of things though.
  - malandrew 12y ago
    We haven't yet decided how to handle the problem for which progressive enhancement is but one solution. 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. [0] http://www.motherfuckingwebsite.com/ http://www.motherfuckingwebsite.com/ [1] http://lynx.browser.org/ http://lynx.browser.org/ [2] http://dashes.com/anil/2012/12/the-web-we-lost.html http://dashes.com/anil/2012/12/the-web-we-lost.html

by _zen 12y ago

dgraunke 12y ago

Another Thomas Street dev here. I'm already using famous-angular on some client projects that are just that — animation-heavy desktop sites. 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.

chalettu 12y ago
Hi dgraunke. I am working on some projects and really anxious to try out famous-angular integration. Do yall have any alphas or betas of your angular integration js available yet? I'd be more than happy to be a tester for it.
- dgraunke 12y ago
  Hey there. Shoot me an email at david (at) thomasstreet (dot) com.
cfulnecky 12y ago
Looking forward to May 19th, 2014 to put famous-angular through it's paces.

malandrew 12y ago

You can far beyond what is possible with animate.css and building a website is certainly a possibility. That being said, the current focus is getting everything rock solid across all mobile devices, so desktop support should be considered beta level for now. 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.

AdrianRossouw 12y ago
famous is going to make me pretend i'm brett victor soon. ala: http://worrydream.com/LadderOfAbstraction http://worrydream.com/LadderOfAbstraction I really wish there were more documentation on the progressive enhancement side of things though.
- malandrew 12y ago
  We haven't yet decided how to handle the problem for which progressive enhancement is but one solution. 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. [0] http://www.motherfuckingwebsite.com/ http://www.motherfuckingwebsite.com/ [1] http://lynx.browser.org/ http://lynx.browser.org/ [2] http://dashes.com/anil/2012/12/the-web-we-lost.html http://dashes.com/anil/2012/12/the-web-we-lost.html