12 ms·

Famo.us open to everyone

110 points by jp_sc 12y ago

pbobak 12y ago
I like this as a concept, but I wouldn't recommend to build websites with it. I wonder how user-accessible websites built with famo.us are — for example I can't just use my arrow keys to navigate up/down and tab'ing through elements does not move the scroll-bar accordingly, this could be an issue for some, older internet users.
- ewillis1 12y ago
  You can build that functionality if it's really a problem. Also surfaces within Famo.us afaik are just like normal sections on a webpage where your normal tabbing and arrow keys will work. But if you're building more traditional looking web apps in famo.us, I don't think you'll run into the issues you're talking about.
- thekaleb 12y ago
  There definitely are some accessibility issues especially for those with limited mobility where using the arrow keys is a necessity.
robbyking 12y ago
The Famo.us session (along with a couple others) at last year's HTML5 conference in SF is what made me decide to make the shift to full time iOS development. Every benchmark was presented in terms relative to native app development: "transitions are 95% as smooth as native apps;" "rendering times take only 3% longer than native apps." Of course mobile web development is important, but I don't really see where Famo.us's market is. Full feature desktop web?
gress 12y ago
Just scrolling the website is jerky on my iPad Air. That doesn't seem like good design.
- phpnode 12y ago
  it's jerky on my (haswell) desktop too. It seems that one of the things they've done to make it feel faster is to mess with the scroll wheel - it scrolls slightly more than the default which makes using the site feel sort of "fake".
  - owenjones 12y ago
    It seems like they heavily turned on scroll acceleration. If I scroll 1 "click" of my mousewheel the scroll bar only move a tiny almost imperceptible amount. If I scroll a lot the bar will fly off the top / bottom of the scrollable area and slowly come back. Feels like it needs a little work.
- nlh 12y ago
  I hate to be a negative voice but that's the first thing I noticed too. Using Chrome (desktop) and the site just feels all wrong (by re-implementing scrolling, I guess?) Scrolling seems like one of those things that shouldn't be touched by a 3rd-party library and should be handled by the browser/OS and only the browser/OS (in most cases -- I'm sure there are times when it's necessary, but this doesn't seem like one of them)
- lightblade 12y ago
  Jerky animation is not their only problem. The layout is incorrect with a lot of letters clipped off. The mobile menu breaks when you tap on it a little too fast.
richo 12y ago
Scroll from the top to the bottom (or vice versa) really hard. Watch the "3d layout engine" flip out thoroughly (tested only on chrome stable on darwin)
- mkoryak 12y ago
  I think it might be one of those "features" that someone thought would make the site look cool, but really just pissed off the users.
- squeaky-clean 12y ago
  Try grabbing the scroll bar with your mouse and pulling it down the page. Nope, apparently scrollbars aren't for that. This doesn't seem to be designed with regular desktop usage in mind.
  - brbcoding 12y ago
    With that bounce-back effect it doesn't seem like it was designed with usage in mind.
  - dagurp 12y ago
    I don't know why but it seems to be perfectly acceptable to break the scrollbar these days.
    - madeofpalk 12y ago
      I don't think it is. Famous is the first I've seen to complement reimplement (and fuck up) something as fundamental as scrolling.
      - dagurp 12y ago
        What about the countless sites that have infinite scrolling (Facebook for example)? It's not as bad as Famous but still breaks it in my opinion.
kapnobatairza 12y ago
I found it interesting that most of the demos provided work very poorly for "desktop web". I think frameworks like this exist in a no-mans land - A modern web framework is great because it allows you to easily deploy one responsive app to a variety of devices/screen sizes/user inputs. This comes at the expense of performance compared to a native mobile app. So if you are building a web framework that is built entirely with mobile in mind, then why choose the framework over native development? You are sacrificing platform agnosticism AND performance at the same time.
- ewillis1 12y ago
  How are you sacrificing platform agnosticism by using a web framework?
  - coreyja 12y ago
    Because using a web framework that only works on mobile is not truly platform agnostic. It may be platform agnostic in that it works on multiple different mobile platforms, but a mobile first web framework is not truly platform agnostic as it doesn't work for the desktop web.
    - ewillis1 12y ago
      So it's more agnostic for mobile development than the native mobile development you're clamoring for? Also it's really not a big step for them to polish the desktop experience. They just released 0.2.0, give it time and I really do think that it's going to be a great platform for both mobile and desktop.
      - kapnobatairza 12y ago
        It's more agnostic than true native development but less agnostic than a lot of other frameworks out there. And I agree that it is an early release and that they have room to improve on the desktop experience. I was just commentating on the current state of things. All other things aside I think it looks like a cool framework with lots of potential.
al_gore 12y ago
There's an absolutely massive custom scrollbar (why?!), but clicking in it doesn't do anything?
X4 12y ago
it was indeed hyped too much.
wdmeldon 12y ago
I find it interesting how much they seem to be focusing on the "career" aspect. I wonder if they are pivoting to an open source model with premium training. Even so, I'm not exactly inclined to throw my career behind what boils down to a JS animation library.
qhoc 12y ago
There are lots of negative comments. So I may as well complete the list: - Fundamentally you have to code UI within JS. It's like doing document.write('<div></div>'); without .html file - Physic lib is totally useless on mobile. It's slower than pure JS - Flex grid doesn't work well when you make browser size larger and then smaller. You can see the UI not being refreshed.
ing33k 12y ago
http://famo.us/demos http://famo.us/demos are quite good
general_failure 12y ago
Are these pages meant for desktop? I cannot even scroll http://famo.us/university/famous-101/slideshow/33/ http://famo.us/university/famous-101/slideshow/33/
- deleted 12y ago
  [deleted]
ballpoint 12y ago
That scrolloff bounce is absolutely horrible on Mac.
woah 12y ago
I got a look at this during the "Secret Beta". All in all, cool idea with using the 3d matrix transform, felt very unfinished though. I also felt that the coding style was very verbose with plenty of needless inheritance tricks, etc. They have a huge physics library and a bunch of other stuff that is not necessary for 99% of apps. There was one demo for a basic app, and like 100 demos of various bouncing balls and springs. I think that if they had focused on a minimal implementation of the basics necessary for apps, like menu dragging and maybe some light transforms, and really polished that, it could have been an awesome tool. Some stuff was indeed very smooth on my ancient Android phone. Too bad they disappeared down a huge rabbithole. The messianic proclamations from the CEO were pretty goofy too. EDIT: In their defense, many (but not all!) of these demos are much better on a phone. Don't judge it based on the desktop experience.
- malandrew 12y ago
  As an employee I have mixed feelings here. For a long time (I've been with the company for 2 years), I was the main person at the company arguing for the basics necessary for all apps like you suggest we should have done. However, looking at this from the inside my view has changed to where the approach we're taking probably makes the most sense long term even though it may not be immediately obvious. First, the goal posts have moved. With iOS7 and Jelly Bean, the expectations of people building apps have become an impossibly high bar for the traditional web. If we had built a simple app framework, then we'd be competing with native apps circa 2009. I think that hyperlinks alone would have helped us win the battle against native apps, but there would always be lots of use cases we wouldn't be able to touch. Second, focusing on trying to do everything you can do with iOS and Android provided us with much more challenging performance constraints. This extremely high bar has resulted in a design where performance is considered in everything we do. If we didn't squeeze out as much performance as possible, it would leave a much smaller margin for the developers using Famo.us. Looking at everyone who has built stuff with Famo.us, many people have been able to make demos and apps that compete easily with any mobile app built by very senior developers. Furthermore, there is one major yet unrealized optimization that all the browser makers are aware of that once implemented will completely eliminate 90% of the overhead. Basically, HTML, being XML, inherits XML's poor type system of only strings and children. When interfaces to the DOM were designed they adopted XML's weak type system for the getters and setters. This means that when Famo.us sets a CSS 3D Matrix transform, it needs to take an array of floats, stringify it and then set the style property on a DOM element. Once set, the browser then needs to take this string and parse it back into an array of floats. This marshaling of an array of floats to a string and back again is horrible for performance. This is why Famo.us is currently limited to moving 200-400 surfaces simultaneously on a desktop browser. When this bottleneck is eliminated, everything changes. Famo.us which is relatively fast compared to all techniques out there will become several orders of magnitude faster. What I don't get is all the hate out there. Yes, we've misstepped in places. Is what we've built thus far perfect? No, not yet. We're competing with operating systems that have years of head start on the web. If we want something that can compete with native, then we need to start building something that is as ambitious in scope with what already exists in native. What other option out there even comes close to giving us a path to combining an experience that is comparable to native (for the average web user, not us neckbeards), supports semantic web content (at the Surface level), has a faster development workflow for iterating on designs and supports the most important feature of the web: hyperlinks? Lastly, I think the importance of native scrolling and other native-like features are actually overblown. I've been on the web long enough to remember when people used to say that webmail would never compete with desktop mail and that Excel would never compete with something like Google Spreadsheets. Even ExtJS was born out of the need to have a javascript framework that aped the Microsoft Windows look and feel. What is so special about native scrolling that puts it on a pedestal where it cannot be disrupted? If we define "quality" as "fitness for use", does our scroller yet meet the definition of a quality scroller for the desktop? No, we've got a ways to go. However for mobile devices, I would argue that Famo.us is definitely already there. I encourage everyone to take the demos we have, boot them up on a local server on your machine and view them on your phone or tablet. Those are definitely fit for use now and give you access to a market that is already larger than any native platform and can be opened via a link (many greenfield opportunities not available in native land). There will come a time where native scroller is going to be shown to be the false god that it is. All you really need is to reach parity with respect to fitness for use and you're at a tipping point where that's no longer a hard and fast requirement. From there, things eventually shift far enough that it's no longer a consideration.
gkop 12y ago
On the demos page [0]: > The PHQ4 example shows off a great parallax effect. This isn't a parallax effect - there is no illusion of depth. Parallax is when "background images move by the camera slower than foreground images, creating an illusion of depth" [1] [0] http://famo.us/demos http://famo.us/demos [1] https://en.wikipedia.org/wiki/Parallax_scrolling https://en.wikipedia.org/wiki/Parallax_scrolling
pavlov 12y ago
Nothing seems to work right in touch IE11 on Windows 8.1, not even scrolling on the front page. Not a great showing for what's supposed to be a cross-platform mobile web framework.
- malandrew 12y ago
  FWIW, preserve-3D is not yet supported in IE11, even after the Windows 8.1 update. AFAIK there is no clear ETA on when preserve-3d support will land in Internet Explorer. My best guess would be in IE12. That being said, Famo.us currently works best on mobile devices, which nets you all of the iOS ecosystem and large portions of the Android ecosystem. Is it everyone? No. Is it a big market? Yes. Will it get bigger? Yes. (disclaimer: I work at famo.us)
  - jsnell 12y ago
    It might work "best" on mobile devices, but I'm afraid that "best" is still pretty awful. In Chrome on a Moto G the frontpage gets maybe 5fps when scrolling. And not even consistently, but with seemingly random intervals between refreshes. The effect is physically nauseating, a bit like bad VR. On the same phone with Firefox it's even worse. The touch response is just so badly off that I can't even come up with a mental model of what's happening. I'm sure you guys are proud of launching, and receiving criticism is never fun. But honestly there's no way this thing is usable at all on a midrange Android phone. If you as a company think otherwise, there must be some kind of collective self-delusion going on that you need to work out. (If instead you had to launch now for some reason, even if you knew that the system isn't really production quality yet on most platforms... Well, too bad. But maybe you could benefit from stating up front on the page the environments where you expect it to work well, before all the launch goodwill is squandered by people not viewing the page on exactly the right platform.)
    - malandrew 12y ago
      Thanks for the feedback. Out of curiosity, what version of Android are you running on the Moto G?
srinivsn 12y ago
I'm always disappointed with Famo.us's updates - so much hype, so much opportunity, always feels wasted. Building out a developer network is hard, and they were so good at getting buzz/interest- would love to see them translate it to something meaningful in a timely manner (like apps actually using and succeeding with the fwk), vs. sending more and more marketing updates.
victoro 12y ago
I'm surprised that so little consideration seems to have been given to the marketing of this framework. Your landing page should be optimized for the audience you are expecting to sell to. Running a general release aimed at developers on a Monday afternoon, they should have expected that most of their target audience would access their page from a desktop environment because they are likely programming. Having a page that seems to be optimized for mobile, albeit poorly considering the scrollbar didn't work on my iPhone any better than it did on my laptop, was a pretty egregious oversight, especially considering they constantly remind their audience that choosing reliable tools is important for their career.
tshadwell 12y ago
Is anyone else encountering large lagtime problems with scrolling? Also, the scroll-bar is non-functional. https://dl.dropboxusercontent.com/u/41231461/455436902/fff.webm https://dl.dropboxusercontent.com/u/41231461/455436902/fff.w...
- ansimionescu 12y ago
  I know, the irony is rather hilarious. https://www.youtube.com/watch?v=R4iyU2a0ivI https://www.youtube.com/watch?v=R4iyU2a0ivI
ecnahc515 12y ago
The scrollbar doesn't even let me drag it.
malandrew 12y ago
First famo.us employee here, want to give people some food for thought to consider as you gripe about things like zoom and and the scrollbar (rightfully so). Some of the more controversial points, especially those regarding accessibility and progressive enhancement, made below are my own. I think I'm the only person at the company that browses the web with JavaScript disabled, so I know how broken the original world wide web from when I first went online in 1994 is. I also remember using text-only browsers like lynx, and demonstrate it to co-workers on occasion. Lastly, I've been doing the web app development schtick for several years now and seen the good and the bad. With all that in mind, the push towards progressive enhancement starting in 2003 when AJAX was just starting to become popular has proven to be a false prophet. IMHO, no idea has done more to make the web less accessible while also holding it back in terms of interactivity. You simply cannot use the same abstraction for both documents and applications and expect decent results for either. What we should have done instead is allowed the two to diverge long ago and especially after 2007 when mobile computing took off and that change in screen size afforded us the opportunity to return to screens not all that dissimilar from those I remember using in '94. The first iPhone had a effective resolution of 320×480. You can effectively show as much on an iPhone as a 1994 computer monitor and have it be readable on both. In fact that's basis of the "Mobile First" design paradigm that frameworks like Zurb Foundation have pushed for. Designing content for a single-wide column that scrolls up and down, that you can jump backward and forward on via anchor hypertext references was a really smart abstraction for lots of content. The site http://www.motherfuckingwebsite.com/ http://www.motherfuckingwebsite.com/ illustrates this poignantly. The technology direction we should have taken should have made sure that search engines, the blind (or otherwise disabled or dexterally challenged) actually remained the first class citizens on the web instead of taking the back seat to print designers and interaction designers. It's easy to take the content designed for those constitutents and make it available via APIs that can then be consumed by people making rich web apps. We even had something like that, it's called RSS and it is glorious. RSS may have actually survived if it had not been for progressive enhancement which was crap but just good enough that people could get away with killing RSS off. Every technologist should make themselves familiar with the concept of path dependency (this Slate articles on the persistence of rockets as our primary way of putting objects in space is illustrative: http://www.slate.com/articles/technology/future_tense/2011/02/space_stasis.html http://www.slate.com/articles/technology/future_tense/2011/0... ). Had progressive enhancement not become the road taken, no one would have ever argued to kill off RSS in favor of a hack jobbed DOM implemented where maybe 1 in 100 developers actually understood how to actually implement accessibility. RSS and other means of programmatic content consumption would have become the prime way of being indexable by search engines. Everyone would have maintained content that way because it would have been in their self interest to do so. Not only that, progressive enhancement is just usable enough to not get sued under the ADA. Without progressive enhancement, businesses (read: at least every fortune 500 company and then some) would have poured gobs money to into making sure they have the digital equivalent of wheelchair ramps. Progressive enhancement gave everyone the opportunity to do the least amount of effort and still maintain a defensible position if challenged legally. The screen reading experience has been shit for like for ever and it's only gotten worse as designs have become more complex. Skipping over the level of abstraction that made content usable programmatically not only impoverished those that need it, but those who don't as well because we're deprived of richer, more flexible APIs. Having worked with webapps for a while, I think one of the most amazing improvements in the last 5 years has been the move towards displaying content on many more screens than just the desktop. This has forced us to go back to API solutions (usually REST, but sometimes RPC over websockets) that often ape what we originally tried to accomplish with RSS. This is the only sane way to provide content that needs to be displayed in different ways, from a Mobile First single long scroll page rendered by the server to a Famous/Ember/Angular/Backbone/React app that takes that server-rendered page and replaces it entirely with a rich interactive experience in the browser. We (at famo.us) don't yet have a solution for this future that treats everyone as a first class citizen, but we eventually plan to address this if the community doesn't tackle it first. We've been inspired by a few attempts at figuring out how to achieve this. Spike Brehm and crew over at AirBnB have been exploring this with Rendr, that works with Backbone.js, https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr , and August Lilleaas has worked on a solution for React, http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ . We feel like there is potential for a generalized solution that doesn't need to be necessarily tied to how one framework works. If you look deep at Famo.us, we don't throw out the DOM wholesale, instead we use the DOM where it matters. In Famo.us, there is a concept of a Surface (which is similar to Layers in CoreAnimation). The Surface is basically a container for HTML Document Fragments, usually fragments that are very strongly structured semantically. The entire scene graph above each Surface node basically helps you programmatically abstract away all the bullshit that many today handle awkwardly with levels and levels of DIV hell controlled by JavaScript. This is not only the abstraction that makes building things in Famo.us easy and fast, but also provides a boundary where content gets lumped into semantic chunks that oftentimes should be consumable for use in a long-scroll, semantically rich, Mobile First design where navigation is hyperlinked anchor based instead of spatial navigation. When browsers were first designed, they made a decision to have a 1 to 1 relationship between the window object and the document object. While reasonable at the time (remember: small screens, low bandwidth, high latency), this proved unscalable to larger screens, greater bandwidth and lower latency. Take Twitter for example. Twitter.com is basically an application for displaying a tiny document called a Tweet. There hundreds of tweet documents shown at a time. The code for tweets is semantically rich. The code for the twitter app? That's DIV hell. This is what Famo.us helps with. Like Flash and Silverlight before it, it helps apps be apps, but unlike its predecessors, it allows documents to be documents. Keeping these two separate keeps abstractions from leaking into each other in the code you write. So while some things may be broken, and the way its broken may inspire ire, it's important to understand that it's not where the puck is that matters, but where it is going. The scrollview we've made is still inferior to the native scroller in a few ways, such as missing keyboard bindings, but are temporary shortcomings that we and the community are going to address in time. Eventually the feature and quality gap will narrow and the Famo.us scrollview(s) will reach parity with native scrollers. Furthermore, some of the abstractions in the Famo.us scroller are remarkable for their programmatic flexibility. When most people think of a scroller, they only think of three scenarios: vertical scrolling, horizontal scrolling and a pannable tiled area (like Google Maps or Open Street Maps). This is actually a pretty limited view of what's possible to explore if you abstract a scroller to its essence. A scroller at is essential is a mathematical set with a curser and that all scrolling does (whether by mouse or keyboard) is move the cursor position in that set. When you think about it that way, many more things you've seen are scrollers. For example, the Apple Time machine view is a scroller in the Z-direction. CoverFlow is another scroller that is horizontal, but where the affine matrix transform applied to a surface is based on the distance of a surface from the cursor and inverts on each side of the cursor. One team of beta testers used the scroll view to display a DNA double helix. It was basically two position linked vertical-scrollers, where the positioner function didn't just set the position on the Y-axis, but also manipulated the affine matrix to create the helix shape. While probably not the best approach, even Google's new interactive Rubik's cube doodle could probably be implemented as a series of Famo.us scrollers. Each scroller would contain 12 surfaces (doubly linked in a ring), with pagination occurring at every three surfaces. The pagination function instead of translating the surfaces along only one axis instead rotates all the surfaces 90 degrees around an axis. All surfaces would belong to two scrollers "perpendicular" to one another at any given time, being lifted from one to the other and back depending on which one was in motion. And since all this is based on the same scroller, which will eventually reach parity with native scrollers, it means that they get all the same features. Home goes to the top of a vertical scroller, the left of a western horizontal scroller, the beginning of the double helix or the begging of time in z-axis time machine like scroller. End does the opposite. These examples just begin to scratch the surface of what's possible when you expose primitives that map to mathematical concepts like a set and current index to developers. Last, but not least, we're going to look at all the feedback on the scrollview and try to address all the issues you all have encountered.
rebelidealist 12y ago
Would there be any documentation of how to integrate this to Phonegap / Cordova?
- malandrew 12y ago
  Stock phonegap works fine for iOS, but there are limitations on Android. We've got an internal project that we'll be releasing in 1-2 months that allows you to package Famo.us apps for Android.
  - dygen 12y ago
    Could you please elaborate on these limitations? I've already tried packaging a simple app using cordova for android and it worked fine. Planing to use it for a real world app, so it would be helpful if you enlighten us about any pitfalls in this approach Btw, when would the forums will be open to public? We are in dire need of one.
    - malandrew 12y ago
      I'm not the right person to answer this question, but I'm not> What you can do is swing by #famous on irc.freenode.net or possibly even visit our offices to talk about this. Work email in profile.
      - malandrew 12y ago
        Sorry for the dangling sentence fragment. I got distracted yesterday and posted the comment in the middle of editing and forgot to proofread and edit that out.
kingnight 12y ago
Is the logo related in any way to the game(s) Marathon?
jbcurtin2 12y ago
Is there an ETA on official clojurescript support?
- malandrew 12y ago
  I'm a huge fan of the work being done by the clojurescript community and I'd love to see people from that community to adopt Famo.us, and we'd love to work with them. I personally find Swannodette's work with Om and Mori to be inspirational. If you're interested in working with Famo.us and Clojurescript or know someone who does, you can contact me directly. Work email in profile.
oori 12y ago
oh man, what a failed launch.. so much hype and then those uber-simple single-click demos.. wow.. I'm back to using the browser like it should be (with a bit of angular on top)
findjashua 12y ago
noob question - I saw this on HN sometime last week https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-... "This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C." Would famo.us have any utility once Apple moves to that version of WebKit?
- malandrew 12y ago
  Definitely. JavaScript performance really isn't the problem. DOM with getters and setters that only accept strings and children are the problem. That being said, once the browsers fix the getters and setters so you can set them without marshaling types into strings, Famo.us will be even faster and all performance issues will drop to almost nothing. When that does happen, assuming no new yet unannounced HTML5/ES6 features, there isn't anything in the browsers that will magically give you the capabilities Famo.us does. The browsers would have to create an alternate parallel scene graph based interface for content. It's possible that may eventually happen. But like almost all features of the web, it takes a few bold individuals and teams implementing those features first to show what's possible and how they may be accomplished. We're hoping we can influence where the web is going enough that some of the ideas eventually become standardized. It would be nice if in the future, we find a way to get the benefit of Tim Berners-Lee's vision for the web and also what Alan Kay thinks the web had the potential to have become [0] had we gone down different paths. [0] http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit...
kelvin0 12y ago
I have the famous song from the Beastie boys : 'Sabotage' playing in a loop in my mind as I watch this on my Desktop ...
jtth 12y ago
All your type is hideous on a retina screen.
marshallynch 12y ago
Famo.us is another over-hyped framework that would have been cool five years ago. I've met Steve several times at their absurdly pompous meetups in SF where he claims to be changing the world. Each time, I couldn't shake his dirty used-car salesman vibe. If you want to make a great product, try focusing on the problem you want to solve. You guys are honestly embarrassing yourselves - and your leadership isn't helping.
marshallynch 12y ago
Famo.us is another over-hyped framework that would have been cool five years ago. I've met Steve several times at their absurdly pompous meetups in SF where he claims to be changing the world. Each time, I couldn't shake his dirty used-car salesman vibe. If you want to make a great product, try focusing on the problem you want to solve. You guys are honestly embarrassing yourselves - and your leadership isn't helping.
handelaar 12y ago
Down arrow? Nope. Click and drag? Nope. PgDn? Nope. Nope. I tried, but while there's obviously more stuff to read below the viewport, I can't get to it. Oddly, this may increase the likelihood I will conclude I'm not missing anything.
Lidador 12y ago
Hey, where is the Facebook Paper demo? These news demos pale (to say the least) when comparing to the ones that made us interested on your company in the first place! What's going on here?
- jonperl 12y ago
  I am working on reproducing the stories scrollview from the paper demo. Lookout for github.com/jperl/famous-cards later this week.
skizm 12y ago
Scroll doesn't work (can't even hit spacebar or use the arrow keys), demos don't seem to work (I can't scroll to get to more than the first 2 anyway), and there is an unclickable scroll bar just taunting me. Maybe it is just linux+chrome that doesn't work well? Any one else get the same issues? Also I like how they eliminated the scrollbar everywhere (for aesthetic purposes?) and yet there is a big greyed out scroll bar in the university page (in the area where you type your code).
- MildlySerious 12y ago
  I usually scroll using the smooth scroll by pressing the middle mouse button. Doesn't work either.
sunsu 12y ago
95% of the negativity on this thread revolves around the obviously sub-par scrolling behavior. I think that if you look past the ScrollView problems there is a lot of great innovation in this framework. I'm looking forward to their continued work. I've been particularly impressed with the new support for Angular: http://famo.us/angular http://famo.us/angular As a side note, that page is a good example of famous being used with NORMAL scrolling.
- davedx 12y ago
  Hah, I went to the Angular page on my Nexus 4 and couldn't scroll down. Refreshed, managed to scroll down one page and got stuck.
- mercer 12y ago
  I'm trying to keep an open mind, and I feel really bad for the developers to get so much bad or even downright hostile feedback. But to me the terrible scrollbar, and the janky behavior on my Nexus 4 doesn't just frustrate me; it makes me seriously doubt the value of the whole project. If a group of people spend a very long time working on something, yet somehow can't figure out that releasing it with such basic, huge flaws is a bad idea, it signals to me that something is fundamentally wrong with the whole project. I think they should sit down and rethink what they're doing. That said, after my initial frustrations I decided to give the thing another look, and there's definitely some good stuff there. Maybe this could be really great some day.
- handelaar 12y ago
  I am literally unable to "look past the ScrollView problems" .
atoponce 12y ago
People, please, for the love of everything good and holy, stop developing tall websites. At first it was cool, but it get annoying really fast. I however have not read any of to comments, but I'm guessing there is probably some negative feedback on the horrid scrolling also. Stop trying to reinvent the wheel. Scrolling was solved decades ago.
rhubarbquid 12y ago
> Choosing a development platform is more than just a technical decision—it’s a career decision. That's not a great argument to convince me to adopt a brand new platform
null_ptr 12y ago
All these overbearing JavaScript frameworks solve problems nobody has. Web design is trivial, all you're doing is bloating it and making it less accessible by replacing native GUI elements (like scrollbars) with our own confusing, low-performance solutions. I see more and more bad habits from 15 years ago come back to hunt the web, how did it come to this?
Lennu 12y ago
Seems to crash on Firefox 24.1.0 ESR, also on IE 10 I can't click on anything.
stardrive 12y ago
Crazy to finally poke around the Famo.us University and then to read all these scalling comments. The scrolling did not work that well for me either, however having seen so many APIs for graphics in Java back in the RIA days until now, I think that Famo.us is doing something fantastic for HTML5. By the sound of the comments and also feeling the same pressure I'd say everyone is between a rock and a hard place, when it comes to getting their hands on a decent mobile framework (more than that Angular CRUD thing anyways). Yes, it is absurd that something like what Famo.us is doing at long last has not already been done. Now that they are doing it lets give them a chance to do it (if that leader of theirs could actually code instead of act like a kingshit it would also help). I'm also sure most of you could crawl back up your stack and shut up for a bit longer. I've had to wait a long time myself, to the point where I've just had to use a lot of engineering and progressively move toward an agnostic codebase that has become elegant as a matter of course. I would welcome Famo.us as an option for me, sure beats the incredible waste of going native. We need to support Famo.us with useful feedback not bitching.
dahdum 12y ago
The site is unviewable on a 4k monitor, giant red bar goes across the screen, scrolls to white, and nothing. Took a while to figure that out...
CmonDev 12y ago
What other programming languages do you plan to support?
- malandrew 12y ago
  Tell us more about what you have in mind.
  - CmonDev 12y ago
    Don't want to use JS or transpilers.
    - malandrew 12y ago
      I'm a bit confused. If you don't want to use either JavaScript or a transpiler (ClojureScript, TypeScript, CoffeeScript, etc.) that compiles to JS, how do you get what you've built into a form executable in the browser, our current runtime target? Are you talking about using LLVM in someway?

110 points by jp_sc 12y ago

I like this as a concept, but I wouldn't recommend to build websites with it. I wonder how user-accessible websites built with famo.us are — for example I can't just use my arrow keys to navigate up/down and tab'ing through elements does not move the scroll-bar accordingly, this could be an issue for some, older internet users.

ewillis1 12y ago
You can build that functionality if it's really a problem. Also surfaces within Famo.us afaik are just like normal sections on a webpage where your normal tabbing and arrow keys will work. But if you're building more traditional looking web apps in famo.us, I don't think you'll run into the issues you're talking about.
thekaleb 12y ago
There definitely are some accessibility issues especially for those with limited mobility where using the arrow keys is a necessity.

robbyking 12y ago

The Famo.us session (along with a couple others) at last year's HTML5 conference in SF is what made me decide to make the shift to full time iOS development. Every benchmark was presented in terms relative to native app development: "transitions are 95% as smooth as native apps;" "rendering times take only 3% longer than native apps." Of course mobile web development is important, but I don't really see where Famo.us's market is. Full feature desktop web?

gress 12y ago

Just scrolling the website is jerky on my iPad Air. That doesn't seem like good design.

phpnode 12y ago
it's jerky on my (haswell) desktop too. It seems that one of the things they've done to make it feel faster is to mess with the scroll wheel - it scrolls slightly more than the default which makes using the site feel sort of "fake".
- owenjones 12y ago
  It seems like they heavily turned on scroll acceleration. If I scroll 1 "click" of my mousewheel the scroll bar only move a tiny almost imperceptible amount. If I scroll a lot the bar will fly off the top / bottom of the scrollable area and slowly come back. Feels like it needs a little work.
nlh 12y ago
I hate to be a negative voice but that's the first thing I noticed too. Using Chrome (desktop) and the site just feels all wrong (by re-implementing scrolling, I guess?) Scrolling seems like one of those things that shouldn't be touched by a 3rd-party library and should be handled by the browser/OS and only the browser/OS (in most cases -- I'm sure there are times when it's necessary, but this doesn't seem like one of them)
lightblade 12y ago
Jerky animation is not their only problem. The layout is incorrect with a lot of letters clipped off. The mobile menu breaks when you tap on it a little too fast.

richo 12y ago

Scroll from the top to the bottom (or vice versa) really hard. Watch the "3d layout engine" flip out thoroughly (tested only on chrome stable on darwin)

mkoryak 12y ago
I think it might be one of those "features" that someone thought would make the site look cool, but really just pissed off the users.
squeaky-clean 12y ago
Try grabbing the scroll bar with your mouse and pulling it down the page. Nope, apparently scrollbars aren't for that. This doesn't seem to be designed with regular desktop usage in mind.
- brbcoding 12y ago
  With that bounce-back effect it doesn't seem like it was designed with usage in mind.
- dagurp 12y ago
  I don't know why but it seems to be perfectly acceptable to break the scrollbar these days.
  - madeofpalk 12y ago
    I don't think it is. Famous is the first I've seen to complement reimplement (and fuck up) something as fundamental as scrolling.
    - dagurp 12y ago
      What about the countless sites that have infinite scrolling (Facebook for example)? It's not as bad as Famous but still breaks it in my opinion.

kapnobatairza 12y ago

I found it interesting that most of the demos provided work very poorly for "desktop web". I think frameworks like this exist in a no-mans land - A modern web framework is great because it allows you to easily deploy one responsive app to a variety of devices/screen sizes/user inputs. This comes at the expense of performance compared to a native mobile app. So if you are building a web framework that is built entirely with mobile in mind, then why choose the framework over native development? You are sacrificing platform agnosticism AND performance at the same time.

ewillis1 12y ago
How are you sacrificing platform agnosticism by using a web framework?
- coreyja 12y ago
  Because using a web framework that only works on mobile is not truly platform agnostic. It may be platform agnostic in that it works on multiple different mobile platforms, but a mobile first web framework is not truly platform agnostic as it doesn't work for the desktop web.
  - ewillis1 12y ago
    So it's more agnostic for mobile development than the native mobile development you're clamoring for? Also it's really not a big step for them to polish the desktop experience. They just released 0.2.0, give it time and I really do think that it's going to be a great platform for both mobile and desktop.
    - kapnobatairza 12y ago
      It's more agnostic than true native development but less agnostic than a lot of other frameworks out there. And I agree that it is an early release and that they have room to improve on the desktop experience. I was just commentating on the current state of things. All other things aside I think it looks like a cool framework with lots of potential.

al_gore 12y ago

There's an absolutely massive custom scrollbar (why?!), but clicking in it doesn't do anything?

X4 12y ago

it was indeed hyped too much.

wdmeldon 12y ago

I find it interesting how much they seem to be focusing on the "career" aspect. I wonder if they are pivoting to an open source model with premium training. Even so, I'm not exactly inclined to throw my career behind what boils down to a JS animation library.

qhoc 12y ago

There are lots of negative comments. So I may as well complete the list: - Fundamentally you have to code UI within JS. It's like doing document.write('<div></div>'); without .html file - Physic lib is totally useless on mobile. It's slower than pure JS - Flex grid doesn't work well when you make browser size larger and then smaller. You can see the UI not being refreshed.

ing33k 12y ago

http://famo.us/demos http://famo.us/demos are quite good

general_failure 12y ago

Are these pages meant for desktop? I cannot even scroll http://famo.us/university/famous-101/slideshow/33/ http://famo.us/university/famous-101/slideshow/33/

deleted 12y ago
[deleted]

ballpoint 12y ago

That scrolloff bounce is absolutely horrible on Mac.

woah 12y ago

I got a look at this during the "Secret Beta". All in all, cool idea with using the 3d matrix transform, felt very unfinished though. I also felt that the coding style was very verbose with plenty of needless inheritance tricks, etc. They have a huge physics library and a bunch of other stuff that is not necessary for 99% of apps. There was one demo for a basic app, and like 100 demos of various bouncing balls and springs. I think that if they had focused on a minimal implementation of the basics necessary for apps, like menu dragging and maybe some light transforms, and really polished that, it could have been an awesome tool. Some stuff was indeed very smooth on my ancient Android phone. Too bad they disappeared down a huge rabbithole. The messianic proclamations from the CEO were pretty goofy too. EDIT: In their defense, many (but not all!) of these demos are much better on a phone. Don't judge it based on the desktop experience.

malandrew 12y ago
As an employee I have mixed feelings here. For a long time (I've been with the company for 2 years), I was the main person at the company arguing for the basics necessary for all apps like you suggest we should have done. However, looking at this from the inside my view has changed to where the approach we're taking probably makes the most sense long term even though it may not be immediately obvious. First, the goal posts have moved. With iOS7 and Jelly Bean, the expectations of people building apps have become an impossibly high bar for the traditional web. If we had built a simple app framework, then we'd be competing with native apps circa 2009. I think that hyperlinks alone would have helped us win the battle against native apps, but there would always be lots of use cases we wouldn't be able to touch. Second, focusing on trying to do everything you can do with iOS and Android provided us with much more challenging performance constraints. This extremely high bar has resulted in a design where performance is considered in everything we do. If we didn't squeeze out as much performance as possible, it would leave a much smaller margin for the developers using Famo.us. Looking at everyone who has built stuff with Famo.us, many people have been able to make demos and apps that compete easily with any mobile app built by very senior developers. Furthermore, there is one major yet unrealized optimization that all the browser makers are aware of that once implemented will completely eliminate 90% of the overhead. Basically, HTML, being XML, inherits XML's poor type system of only strings and children. When interfaces to the DOM were designed they adopted XML's weak type system for the getters and setters. This means that when Famo.us sets a CSS 3D Matrix transform, it needs to take an array of floats, stringify it and then set the style property on a DOM element. Once set, the browser then needs to take this string and parse it back into an array of floats. This marshaling of an array of floats to a string and back again is horrible for performance. This is why Famo.us is currently limited to moving 200-400 surfaces simultaneously on a desktop browser. When this bottleneck is eliminated, everything changes. Famo.us which is relatively fast compared to all techniques out there will become several orders of magnitude faster. What I don't get is all the hate out there. Yes, we've misstepped in places. Is what we've built thus far perfect? No, not yet. We're competing with operating systems that have years of head start on the web. If we want something that can compete with native, then we need to start building something that is as ambitious in scope with what already exists in native. What other option out there even comes close to giving us a path to combining an experience that is comparable to native (for the average web user, not us neckbeards), supports semantic web content (at the Surface level), has a faster development workflow for iterating on designs and supports the most important feature of the web: hyperlinks? Lastly, I think the importance of native scrolling and other native-like features are actually overblown. I've been on the web long enough to remember when people used to say that webmail would never compete with desktop mail and that Excel would never compete with something like Google Spreadsheets. Even ExtJS was born out of the need to have a javascript framework that aped the Microsoft Windows look and feel. What is so special about native scrolling that puts it on a pedestal where it cannot be disrupted? If we define "quality" as "fitness for use", does our scroller yet meet the definition of a quality scroller for the desktop? No, we've got a ways to go. However for mobile devices, I would argue that Famo.us is definitely already there. I encourage everyone to take the demos we have, boot them up on a local server on your machine and view them on your phone or tablet. Those are definitely fit for use now and give you access to a market that is already larger than any native platform and can be opened via a link (many greenfield opportunities not available in native land). There will come a time where native scroller is going to be shown to be the false god that it is. All you really need is to reach parity with respect to fitness for use and you're at a tipping point where that's no longer a hard and fast requirement. From there, things eventually shift far enough that it's no longer a consideration.

gkop 12y ago

On the demos page [0]: > The PHQ4 example shows off a great parallax effect. This isn't a parallax effect - there is no illusion of depth. Parallax is when "background images move by the camera slower than foreground images, creating an illusion of depth" [1] [0] http://famo.us/demos http://famo.us/demos [1] https://en.wikipedia.org/wiki/Parallax_scrolling https://en.wikipedia.org/wiki/Parallax_scrolling

pavlov 12y ago

Nothing seems to work right in touch IE11 on Windows 8.1, not even scrolling on the front page. Not a great showing for what's supposed to be a cross-platform mobile web framework.

malandrew 12y ago
FWIW, preserve-3D is not yet supported in IE11, even after the Windows 8.1 update. AFAIK there is no clear ETA on when preserve-3d support will land in Internet Explorer. My best guess would be in IE12. That being said, Famo.us currently works best on mobile devices, which nets you all of the iOS ecosystem and large portions of the Android ecosystem. Is it everyone? No. Is it a big market? Yes. Will it get bigger? Yes. (disclaimer: I work at famo.us)
- jsnell 12y ago
  It might work "best" on mobile devices, but I'm afraid that "best" is still pretty awful. In Chrome on a Moto G the frontpage gets maybe 5fps when scrolling. And not even consistently, but with seemingly random intervals between refreshes. The effect is physically nauseating, a bit like bad VR. On the same phone with Firefox it's even worse. The touch response is just so badly off that I can't even come up with a mental model of what's happening. I'm sure you guys are proud of launching, and receiving criticism is never fun. But honestly there's no way this thing is usable at all on a midrange Android phone. If you as a company think otherwise, there must be some kind of collective self-delusion going on that you need to work out. (If instead you had to launch now for some reason, even if you knew that the system isn't really production quality yet on most platforms... Well, too bad. But maybe you could benefit from stating up front on the page the environments where you expect it to work well, before all the launch goodwill is squandered by people not viewing the page on exactly the right platform.)
  - malandrew 12y ago
    Thanks for the feedback. Out of curiosity, what version of Android are you running on the Moto G?

srinivsn 12y ago

I'm always disappointed with Famo.us's updates - so much hype, so much opportunity, always feels wasted. Building out a developer network is hard, and they were so good at getting buzz/interest- would love to see them translate it to something meaningful in a timely manner (like apps actually using and succeeding with the fwk), vs. sending more and more marketing updates.

victoro 12y ago

I'm surprised that so little consideration seems to have been given to the marketing of this framework. Your landing page should be optimized for the audience you are expecting to sell to. Running a general release aimed at developers on a Monday afternoon, they should have expected that most of their target audience would access their page from a desktop environment because they are likely programming. Having a page that seems to be optimized for mobile, albeit poorly considering the scrollbar didn't work on my iPhone any better than it did on my laptop, was a pretty egregious oversight, especially considering they constantly remind their audience that choosing reliable tools is important for their career.

tshadwell 12y ago

Is anyone else encountering large lagtime problems with scrolling? Also, the scroll-bar is non-functional. https://dl.dropboxusercontent.com/u/41231461/455436902/fff.webm https://dl.dropboxusercontent.com/u/41231461/455436902/fff.w...

ansimionescu 12y ago
I know, the irony is rather hilarious. https://www.youtube.com/watch?v=R4iyU2a0ivI https://www.youtube.com/watch?v=R4iyU2a0ivI

ecnahc515 12y ago

The scrollbar doesn't even let me drag it.

malandrew 12y ago

First famo.us employee here, want to give people some food for thought to consider as you gripe about things like zoom and and the scrollbar (rightfully so). Some of the more controversial points, especially those regarding accessibility and progressive enhancement, made below are my own. I think I'm the only person at the company that browses the web with JavaScript disabled, so I know how broken the original world wide web from when I first went online in 1994 is. I also remember using text-only browsers like lynx, and demonstrate it to co-workers on occasion. Lastly, I've been doing the web app development schtick for several years now and seen the good and the bad. With all that in mind, the push towards progressive enhancement starting in 2003 when AJAX was just starting to become popular has proven to be a false prophet. IMHO, no idea has done more to make the web less accessible while also holding it back in terms of interactivity. You simply cannot use the same abstraction for both documents and applications and expect decent results for either. What we should have done instead is allowed the two to diverge long ago and especially after 2007 when mobile computing took off and that change in screen size afforded us the opportunity to return to screens not all that dissimilar from those I remember using in '94. The first iPhone had a effective resolution of 320×480. You can effectively show as much on an iPhone as a 1994 computer monitor and have it be readable on both. In fact that's basis of the "Mobile First" design paradigm that frameworks like Zurb Foundation have pushed for. Designing content for a single-wide column that scrolls up and down, that you can jump backward and forward on via anchor hypertext references was a really smart abstraction for lots of content. The site http://www.motherfuckingwebsite.com/ http://www.motherfuckingwebsite.com/ illustrates this poignantly. The technology direction we should have taken should have made sure that search engines, the blind (or otherwise disabled or dexterally challenged) actually remained the first class citizens on the web instead of taking the back seat to print designers and interaction designers. It's easy to take the content designed for those constitutents and make it available via APIs that can then be consumed by people making rich web apps. We even had something like that, it's called RSS and it is glorious. RSS may have actually survived if it had not been for progressive enhancement which was crap but just good enough that people could get away with killing RSS off. Every technologist should make themselves familiar with the concept of path dependency (this Slate articles on the persistence of rockets as our primary way of putting objects in space is illustrative: http://www.slate.com/articles/technology/future_tense/2011/02/space_stasis.html http://www.slate.com/articles/technology/future_tense/2011/0... ). Had progressive enhancement not become the road taken, no one would have ever argued to kill off RSS in favor of a hack jobbed DOM implemented where maybe 1 in 100 developers actually understood how to actually implement accessibility. RSS and other means of programmatic content consumption would have become the prime way of being indexable by search engines. Everyone would have maintained content that way because it would have been in their self interest to do so. Not only that, progressive enhancement is just usable enough to not get sued under the ADA. Without progressive enhancement, businesses (read: at least every fortune 500 company and then some) would have poured gobs money to into making sure they have the digital equivalent of wheelchair ramps. Progressive enhancement gave everyone the opportunity to do the least amount of effort and still maintain a defensible position if challenged legally. The screen reading experience has been shit for like for ever and it's only gotten worse as designs have become more complex. Skipping over the level of abstraction that made content usable programmatically not only impoverished those that need it, but those who don't as well because we're deprived of richer, more flexible APIs. Having worked with webapps for a while, I think one of the most amazing improvements in the last 5 years has been the move towards displaying content on many more screens than just the desktop. This has forced us to go back to API solutions (usually REST, but sometimes RPC over websockets) that often ape what we originally tried to accomplish with RSS. This is the only sane way to provide content that needs to be displayed in different ways, from a Mobile First single long scroll page rendered by the server to a Famous/Ember/Angular/Backbone/React app that takes that server-rendered page and replaces it entirely with a rich interactive experience in the browser. We (at famo.us) don't yet have a solution for this future that treats everyone as a first class citizen, but we eventually plan to address this if the community doesn't tackle it first. We've been inspired by a few attempts at figuring out how to achieve this. Spike Brehm and crew over at AirBnB have been exploring this with Rendr, that works with Backbone.js, https://github.com/rendrjs/rendr https://github.com/rendrjs/rendr , and August Lilleaas has worked on a solution for React, http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ http://augustl.com/blog/2014/jdk8_react_rendering_on_server/ . We feel like there is potential for a generalized solution that doesn't need to be necessarily tied to how one framework works. If you look deep at Famo.us, we don't throw out the DOM wholesale, instead we use the DOM where it matters. In Famo.us, there is a concept of a Surface (which is similar to Layers in CoreAnimation). The Surface is basically a container for HTML Document Fragments, usually fragments that are very strongly structured semantically. The entire scene graph above each Surface node basically helps you programmatically abstract away all the bullshit that many today handle awkwardly with levels and levels of DIV hell controlled by JavaScript. This is not only the abstraction that makes building things in Famo.us easy and fast, but also provides a boundary where content gets lumped into semantic chunks that oftentimes should be consumable for use in a long-scroll, semantically rich, Mobile First design where navigation is hyperlinked anchor based instead of spatial navigation. When browsers were first designed, they made a decision to have a 1 to 1 relationship between the window object and the document object. While reasonable at the time (remember: small screens, low bandwidth, high latency), this proved unscalable to larger screens, greater bandwidth and lower latency. Take Twitter for example. Twitter.com is basically an application for displaying a tiny document called a Tweet. There hundreds of tweet documents shown at a time. The code for tweets is semantically rich. The code for the twitter app? That's DIV hell. This is what Famo.us helps with. Like Flash and Silverlight before it, it helps apps be apps, but unlike its predecessors, it allows documents to be documents. Keeping these two separate keeps abstractions from leaking into each other in the code you write. So while some things may be broken, and the way its broken may inspire ire, it's important to understand that it's not where the puck is that matters, but where it is going. The scrollview we've made is still inferior to the native scroller in a few ways, such as missing keyboard bindings, but are temporary shortcomings that we and the community are going to address in time. Eventually the feature and quality gap will narrow and the Famo.us scrollview(s) will reach parity with native scrollers. Furthermore, some of the abstractions in the Famo.us scroller are remarkable for their programmatic flexibility. When most people think of a scroller, they only think of three scenarios: vertical scrolling, horizontal scrolling and a pannable tiled area (like Google Maps or Open Street Maps). This is actually a pretty limited view of what's possible to explore if you abstract a scroller to its essence. A scroller at is essential is a mathematical set with a curser and that all scrolling does (whether by mouse or keyboard) is move the cursor position in that set. When you think about it that way, many more things you've seen are scrollers. For example, the Apple Time machine view is a scroller in the Z-direction. CoverFlow is another scroller that is horizontal, but where the affine matrix transform applied to a surface is based on the distance of a surface from the cursor and inverts on each side of the cursor. One team of beta testers used the scroll view to display a DNA double helix. It was basically two position linked vertical-scrollers, where the positioner function didn't just set the position on the Y-axis, but also manipulated the affine matrix to create the helix shape. While probably not the best approach, even Google's new interactive Rubik's cube doodle could probably be implemented as a series of Famo.us scrollers. Each scroller would contain 12 surfaces (doubly linked in a ring), with pagination occurring at every three surfaces. The pagination function instead of translating the surfaces along only one axis instead rotates all the surfaces 90 degrees around an axis. All surfaces would belong to two scrollers "perpendicular" to one another at any given time, being lifted from one to the other and back depending on which one was in motion. And since all this is based on the same scroller, which will eventually reach parity with native scrollers, it means that they get all the same features. Home goes to the top of a vertical scroller, the left of a western horizontal scroller, the beginning of the double helix or the begging of time in z-axis time machine like scroller. End does the opposite. These examples just begin to scratch the surface of what's possible when you expose primitives that map to mathematical concepts like a set and current index to developers. Last, but not least, we're going to look at all the feedback on the scrollview and try to address all the issues you all have encountered.

rebelidealist 12y ago

Would there be any documentation of how to integrate this to Phonegap / Cordova?

malandrew 12y ago
Stock phonegap works fine for iOS, but there are limitations on Android. We've got an internal project that we'll be releasing in 1-2 months that allows you to package Famo.us apps for Android.
- dygen 12y ago
  Could you please elaborate on these limitations? I've already tried packaging a simple app using cordova for android and it worked fine. Planing to use it for a real world app, so it would be helpful if you enlighten us about any pitfalls in this approach Btw, when would the forums will be open to public? We are in dire need of one.
  - malandrew 12y ago
    I'm not the right person to answer this question, but I'm not> What you can do is swing by #famous on irc.freenode.net or possibly even visit our offices to talk about this. Work email in profile.
    - malandrew 12y ago
      Sorry for the dangling sentence fragment. I got distracted yesterday and posted the comment in the middle of editing and forgot to proofread and edit that out.

kingnight 12y ago

Is the logo related in any way to the game(s) Marathon?

jbcurtin2 12y ago

Is there an ETA on official clojurescript support?

malandrew 12y ago
I'm a huge fan of the work being done by the clojurescript community and I'd love to see people from that community to adopt Famo.us, and we'd love to work with them. I personally find Swannodette's work with Om and Mori to be inspirational. If you're interested in working with Famo.us and Clojurescript or know someone who does, you can contact me directly. Work email in profile.

oori 12y ago

oh man, what a failed launch.. so much hype and then those uber-simple single-click demos.. wow.. I'm back to using the browser like it should be (with a bit of angular on top)

findjashua 12y ago

noob question - I saw this on HN sometime last week https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/ https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-... "This will allow JavaScript programs to leverage sophisticated optimizations that were previously only available to native applications written in languages like C++ or Objective-C." Would famo.us have any utility once Apple moves to that version of WebKit?

malandrew 12y ago
Definitely. JavaScript performance really isn't the problem. DOM with getters and setters that only accept strings and children are the problem. That being said, once the browsers fix the getters and setters so you can set them without marshaling types into strings, Famo.us will be even faster and all performance issues will drop to almost nothing. When that does happen, assuming no new yet unannounced HTML5/ES6 features, there isn't anything in the browsers that will magically give you the capabilities Famo.us does. The browsers would have to create an alternate parallel scene graph based interface for content. It's possible that may eventually happen. But like almost all features of the web, it takes a few bold individuals and teams implementing those features first to show what's possible and how they may be accomplished. We're hoping we can influence where the web is going enough that some of the ideas eventually become standardized. It would be nice if in the future, we find a way to get the benefit of Tim Berners-Lee's vision for the web and also what Alan Kay thinks the web had the potential to have become [0] had we gone down different paths. [0] http://www.drdobbs.com/architecture-and-design/interview-with-alan-kay/240003442 http://www.drdobbs.com/architecture-and-design/interview-wit...

kelvin0 12y ago

I have the famous song from the Beastie boys : 'Sabotage' playing in a loop in my mind as I watch this on my Desktop ...

jtth 12y ago

All your type is hideous on a retina screen.

marshallynch 12y ago

Famo.us is another over-hyped framework that would have been cool five years ago. I've met Steve several times at their absurdly pompous meetups in SF where he claims to be changing the world. Each time, I couldn't shake his dirty used-car salesman vibe. If you want to make a great product, try focusing on the problem you want to solve. You guys are honestly embarrassing yourselves - and your leadership isn't helping.

marshallynch 12y ago

handelaar 12y ago

Down arrow? Nope. Click and drag? Nope. PgDn? Nope. Nope. I tried, but while there's obviously more stuff to read below the viewport, I can't get to it. Oddly, this may increase the likelihood I will conclude I'm not missing anything.

Lidador 12y ago

Hey, where is the Facebook Paper demo? These news demos pale (to say the least) when comparing to the ones that made us interested on your company in the first place! What's going on here?

jonperl 12y ago
I am working on reproducing the stories scrollview from the paper demo. Lookout for github.com/jperl/famous-cards later this week.

skizm 12y ago

Scroll doesn't work (can't even hit spacebar or use the arrow keys), demos don't seem to work (I can't scroll to get to more than the first 2 anyway), and there is an unclickable scroll bar just taunting me. Maybe it is just linux+chrome that doesn't work well? Any one else get the same issues? Also I like how they eliminated the scrollbar everywhere (for aesthetic purposes?) and yet there is a big greyed out scroll bar in the university page (in the area where you type your code).

MildlySerious 12y ago
I usually scroll using the smooth scroll by pressing the middle mouse button. Doesn't work either.

sunsu 12y ago

95% of the negativity on this thread revolves around the obviously sub-par scrolling behavior. I think that if you look past the ScrollView problems there is a lot of great innovation in this framework. I'm looking forward to their continued work. I've been particularly impressed with the new support for Angular: http://famo.us/angular http://famo.us/angular As a side note, that page is a good example of famous being used with NORMAL scrolling.

davedx 12y ago
Hah, I went to the Angular page on my Nexus 4 and couldn't scroll down. Refreshed, managed to scroll down one page and got stuck.
mercer 12y ago
I'm trying to keep an open mind, and I feel really bad for the developers to get so much bad or even downright hostile feedback. But to me the terrible scrollbar, and the janky behavior on my Nexus 4 doesn't just frustrate me; it makes me seriously doubt the value of the whole project. If a group of people spend a very long time working on something, yet somehow can't figure out that releasing it with such basic, huge flaws is a bad idea, it signals to me that something is fundamentally wrong with the whole project. I think they should sit down and rethink what they're doing. That said, after my initial frustrations I decided to give the thing another look, and there's definitely some good stuff there. Maybe this could be really great some day.
handelaar 12y ago
I am literally unable to "look past the ScrollView problems" .

atoponce 12y ago

People, please, for the love of everything good and holy, stop developing tall websites. At first it was cool, but it get annoying really fast. I however have not read any of to comments, but I'm guessing there is probably some negative feedback on the horrid scrolling also. Stop trying to reinvent the wheel. Scrolling was solved decades ago.

rhubarbquid 12y ago

> Choosing a development platform is more than just a technical decision—it’s a career decision. That's not a great argument to convince me to adopt a brand new platform

null_ptr 12y ago

All these overbearing JavaScript frameworks solve problems nobody has. Web design is trivial, all you're doing is bloating it and making it less accessible by replacing native GUI elements (like scrollbars) with our own confusing, low-performance solutions. I see more and more bad habits from 15 years ago come back to hunt the web, how did it come to this?

Lennu 12y ago

Seems to crash on Firefox 24.1.0 ESR, also on IE 10 I can't click on anything.

stardrive 12y ago

Crazy to finally poke around the Famo.us University and then to read all these scalling comments. The scrolling did not work that well for me either, however having seen so many APIs for graphics in Java back in the RIA days until now, I think that Famo.us is doing something fantastic for HTML5. By the sound of the comments and also feeling the same pressure I'd say everyone is between a rock and a hard place, when it comes to getting their hands on a decent mobile framework (more than that Angular CRUD thing anyways). Yes, it is absurd that something like what Famo.us is doing at long last has not already been done. Now that they are doing it lets give them a chance to do it (if that leader of theirs could actually code instead of act like a kingshit it would also help). I'm also sure most of you could crawl back up your stack and shut up for a bit longer. I've had to wait a long time myself, to the point where I've just had to use a lot of engineering and progressively move toward an agnostic codebase that has become elegant as a matter of course. I would welcome Famo.us as an option for me, sure beats the incredible waste of going native. We need to support Famo.us with useful feedback not bitching.

dahdum 12y ago

The site is unviewable on a 4k monitor, giant red bar goes across the screen, scrolls to white, and nothing. Took a while to figure that out...

CmonDev 12y ago

What other programming languages do you plan to support?

malandrew 12y ago
Tell us more about what you have in mind.
- CmonDev 12y ago
  Don't want to use JS or transpilers.
  - malandrew 12y ago
    I'm a bit confused. If you don't want to use either JavaScript or a transpiler (ClojureScript, TypeScript, CoffeeScript, etc.) that compiles to JS, how do you get what you've built into a form executable in the browser, our current runtime target? Are you talking about using LLVM in someway?