
Famo.us open to everyone - jp_sc
http://famo.us/?new
======
woah
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
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.

~~~
dragonwriter
> No, we've got a ways to go. However for mobile devices, I would argue that
> Famo.us is definitely already there.

Looking at it on Chrome in Galaxy Note 3 with KitKat, no, you aren't "already
there". Scrolling is painfully erratic.

And if you really want to be "mobile first", which makes sense, it would
probably be a good idea to have content which (a) scaled to the width of the
device, or (b) failing to scale to device width, at least provided horizontal
scrolling. As it is, _even in landscape_ your "Famo.us University" content
extends beyond _both_ sides of the viewport.

> There will come a time where native scroller is going to be shown to be the
> false god that it is.

Sure, someone may one day build something that makes not using the native
scroller sensible. But Famo.us _hasn 't_, as yet, done that.

~~~
malandrew
FWIW, KitKat isn't on the list of versions we support. We target Ice Cream
Sandwich and above. Also, are you using the stock Android browser or did you
install Chrome?

The problem isn't with that device isn't Famo.us, and IIRC it's not the
hardware either, it's the implementation of the APIs we rely on in the
browser.

Many people replace their mobile phones every 1-3 years. Now that smartphones
are becoming feature phones and all these phones have the most recent versions
of Android, it's only a matter of time.

~~~
dragonwriter
> FWIW, KitKat isn't on the list of versions we support. We target Ice Cream
> Sandwich and above.

Since when is KitKat (4.4) not "above" Ice Cream Sandwich (4.0)?

> Also, are you using the stock Android browser or did you install Chrome?

Well, I said Chrome, but the problems (at least, the ones listed in my
previous post) are identical in the stock browser.

> Many people replace their mobile phones every 1-3 years.

Well, yeah, I just replaced my long-in-the-tooth iPhone 4 with a still-top-of-
the-line Galaxy Note 3 (though the GNote 4 will be out fairly soon.) That's
the phone we're talking about here.

> Now that smartphones are becoming feature phones and all these phones have
> the most recent versions of Android, it's only a matter of time.

But KitKat _is_ the most recent version of Android, and you just said you
don't support it.

~~~
malandrew
Oops .. total brain fart on my part. Did the alphabet wrong in my head. I
always felt more comfortable using numbers for versioning. Letters always
require a little bit of mental gymnastics since it's uncommon to think of them
as having ordinality in every day life.

Yes, we support KitKat. We'll investigate the experience on your device.

~~~
ChrisAntaki
This link might be useful to your team:
[http://en.wikipedia.org/wiki/Android_version_history](http://en.wikipedia.org/wiki/Android_version_history)

Looks like KitKat has been out for 6 months. Just a heads up, the best Android
devices are running KitKat, like the S4 & S5. I can confirm, the Famo.us
scrolling & animations have issues on the S4.

That being said, your framework is amazing on iOS, and feels like a native
app. I'm sure your team will have no problem with KitKat, if time is dedicated
to it.

~~~
malandrew
Oh we're familiar with it and we spend time trying to get Android working
well. It's been a more challenging platform because the performance of the
underlying APIs on Chrome has been more erratic.

FWIW, I made this versioning mistake because I'm one of the two people in the
company who is the least familiar with Android versioning because I work on
backend systems and tooling that we'll be releasing later this year. 90% of my
time is spent in the terminal.

Anyways, homepage clearly needs some a lot of love. In the meantime, do you
mind trying the following instructions in this comment,
[https://news.ycombinator.com/item?id=7771330](https://news.ycombinator.com/item?id=7771330)
, on your Android device to see how the demos perform?

~~~
ChrisAntaki
Hey Andrew, thanks for the clarification. I only had time to check out
Albumatic, Rise, and PHQ4, on the Samsung S4. Albumatic was a bit laggy, Rise
& PHQ4 were pretty great. Will have more feedback after the Hackathon.

~~~
ChrisAntaki
Post Hackathon: Great framework. Really interested to see where it goes.

~~~
malandrew
Awesome. Thanks for the feedback. We're working hard on pushing things forward
and will fix the initial problems we've had.

------
skizm
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
I usually scroll using the smooth scroll by pressing the middle mouse button.
Doesn't work either.

------
victoro
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.

------
richo
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)

~~~
squeaky-clean
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.

~~~
dagurp
I don't know why but it seems to be perfectly acceptable to break the
scrollbar these days.

~~~
madeofpalk
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
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.

~~~
madeofpalk
Infinite scrolling doesnt break scrolling, it breaks backwards/forwards
navigation.

~~~
dagurp
It does both (infinite scrolling is a horrible idea). If you try dragging the
scrollbar it will jump around every time more content is loaded and you lose
your position on the page.

------
kapnobatairza
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
How are you sacrificing platform agnosticism by using a web framework?

~~~
coreyja
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
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
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.

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

~~~
ansimionescu
I know, the irony is rather hilarious.
[https://www.youtube.com/watch?v=R4iyU2a0ivI](https://www.youtube.com/watch?v=R4iyU2a0ivI)

------
sunsu
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.

~~~
mercer
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
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.

------
gkop
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)

------
general_failure
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/)

------
stardrive
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.

------
marshallynch
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.

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

~~~
phpnode
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
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.

------
srinivsn
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.

------
null_ptr
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?

------
pavlov
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
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
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
Thanks for the feedback. Out of curiosity, what version of Android are you
running on the Moto G?

~~~
jsnell
4.4.2 (the normal Motorola version, which is very close to stock Android).
Chrome 34.

~~~
malandrew
Out of curiosity, how did the demos perform on that device?

We'll work on making the demos available at standalone URLs (instead of
iframed on our site). In the meantime, if you haven't tried them and want to,
you can:

1) download the starter pack

2) go to the demos folder

3) open a webserver in each folder that serves the app.html as the index (just
occurred to me that we should switch app.html with the iframed index.html for
this very reason).

4) then open each demo on your phone over the local network.

------
robbyking
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?

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

------
pbobak
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
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.

------
rhubarbquid
> 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

------
qhoc
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.

------
malandrew
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/0...](http://www.slate.com/articles/technology/future_tense/2011/02/space_stasis.html)
). 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.

~~~
joaren
I find myself agreeing with most of what you wrote, and yet, it doesn't
matter. You keep sabotaging yourselves.

Does no-one do QA? Do you not have a Steve Jobs-esque character who has taste
and an eye for detail and who can look at this stuff the way your users will?
Because such a person would've looked at this and Noped the fuck out of there,
cancelled whatever PR you had planned, and put everyone around a table saying
"we're not there and can we fix it?".

Your first hyped launch thing was a sign-up form with blurry fonts leading no
where. Now you've implemented a giant janky scrollbar with easing equations
calibrated for "instant turn off". The parallels to Flash really are quite
similar.

You should not imitate native behaviour unless you have someone going over it
with a fine toothed comb, and you shouldn't be making grand claims about the
future when you cock up the present.

If you believe your own claims, then why does your page work terribly on my
brand new laptop, never mind the 4 year old one it just replaced?

~~~
malandrew
What's the lesser of two evils?

1) Launch an imperfect product that works well for some use cases; or 2)
Perfect everything and be ridiculed as vaporware

I wish we were Apple and had $159 billion in cash reserves. We're not though
and have to operate within different constraints that don't afford us the same
luxuries. You can't really compare Apples to Famo.uses

~~~
icelancer
>1) Launch an imperfect product that works well for some use cases; or

I absolutely loathe this attitude that has taken over entrepreneurship. This
is not OK. I don't give a shit what the Lean Theory zealots say.

~~~
xiaoma
> _I absolutely loathe this attitude that has taken over entrepreneurship.
> This is not OK. I don 't give a shit what the Lean Theory zealots say._

They've worked insane hours for over a year to create a tool. It's an
imperfect tool, but one capable of doing amazing things. And they've given it
away for free. How are you not OK with this?

~~~
joaren
If you work insane hours for over a year, your company is broken. That is a
problem of time allocation and unrealistic expectations, and has no bearing on
the quality or usefulness of the work being done.

As for "capable of doing amazing things", this is stuff that Flash was able to
do better 10 years ago. If people hadn't forgotten where we came from, and
browser makers hadn't ridden the CSS train to performance hell, Famous
wouldn't even be necessary.

So far, all I've seen is a) huge, hyped up promises and b) janky demos that
feel like some interaction design student's wild experiments. You don't need
to be Apple to do this right, you just have to be able to be honest about the
output of your own work.

~~~
malandrew
I expect negative comments on occasion from everyone, but you've been
registered on HN for 16 days and every single comment you've made since you've
joined has been vitrolic haterade that adds nothing constructive to the
threads you participate or the community. Do you ever have anything positive
to say about anything? If you're so embittered, why participate here at all?

------
wdmeldon
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.

------
ballpoint
That scrolloff bounce is absolutely horrible on Mac.

------
oori
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)

------
ing33k
[http://famo.us/demos](http://famo.us/demos) are quite good

------
Lidador
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
I am working on reproducing the stories scrollview from the paper demo.
Lookout for github.com/jperl/famous-cards later this week.

------
findjashua
noob question - I saw this on HN sometime last week
[https://www.webkit.org/blog/3362/introducing-the-webkit-
ftl-...](https://www.webkit.org/blog/3362/introducing-the-webkit-ftl-jit/)

"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
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-
wit...](http://www.drdobbs.com/architecture-and-design/interview-with-alan-
kay/240003442)

------
dahdum
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...

------
atoponce
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.

------
jtth
All your type is hideous on a retina screen.

------
X4
it was indeed hyped too much.

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

~~~
malandrew
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
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
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
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.

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

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

------
ecnahc515
The scrollbar doesn't even let me drag it.

------
CmonDev
What other programming languages do you plan to support?

~~~
malandrew
Tell us more about what you have in mind.

~~~
CmonDev
Don't want to use JS or transpilers.

~~~
malandrew
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?

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

------
jbcurtin2
Is there an ETA on official clojurescript support?

~~~
malandrew
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.

