Famo.us open to everyone(famo.us)
famo.us
Famo.us open to everyone
http://famo.us/?new
143 comments
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?
> 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
That's not a great argument to convince me to adopt a brand new platform
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/ 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... ). 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 , and August Lilleaas has worked on a solution for React, 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.
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/ 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... ). 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 , and August Lilleaas has worked on a solution for React, 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.
TLDR. We're passionate about what we do and we're working on your issues even though our site as well as the entire web is a work in progress
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?
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?
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
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
No offence by I cannot read anything on your website because the native scroll doesn't work, nor does my keyboard ( I had to scroll using my mouse-wheel and it was not smooth). That is neither 1) nor 2), it's 101.
How can I trust your "Ready to start building a beautiful UI?", when the basic tenant of a UI in regards to a webpage is missing.
If you did this to any popular website it would be a mass exodus in no time flat.
How can I trust your "Ready to start building a beautiful UI?", when the basic tenant of a UI in regards to a webpage is missing.
If you did this to any popular website it would be a mass exodus in no time flat.
If you spent two years hyping vaporware and then do a major Apple-esque launch with all the fanfair while claiming to the next evolution of technology...
... you should at least attempt to make the scrollbar on your own website work correctly.
Seriously. You don't have to be Steve Jobs to realize that your scrollbar needs fixing. It's not just unpolished, it fundamentally doesn't work.
... you should at least attempt to make the scrollbar on your own website work correctly.
Seriously. You don't have to be Steve Jobs to realize that your scrollbar needs fixing. It's not just unpolished, it fundamentally doesn't work.
It took us some time, but it shipped, so by definition, it cannot be vaporware.
Yes, the scrollbar needs fixing. We're working on it. Remember that the framework is also open source, so we're open to receiving pull requests that help get these issues resolved sooner.
Wikipedia was once compared to Encyclopedia Britannica in terms of number of errors it contained. It had more errors, but shortly thereafter those errors were fixed. Many of the shortcomings of our scroller will be fixed very soon. Some fixes may take a bit longer, but anyone bitten by a particular bugs has the ability to fix the problem.
Linux also went through similar pains with obviously broken parts early on before it reached maturity.
I don't know about you, but I much prefer a world where open source projects exist, even if a little broken in the beginning. Whenever someone actively hates on an open-source project they are essentially littering in and poisoning the commons instead of helping cultivate and nurture that public space.
I think this is really the point I'm driving at that people need to consider. Building something of this magnitude and ambition takes time. It's open source and anyone, including everyone wielding criticism in this thread has the power to download the source code, try it out, find out where it shines and help polish it where it does not yet shine.
Give it a fair shot; discover its merits; help make it better for everyone.
Yes, the scrollbar needs fixing. We're working on it. Remember that the framework is also open source, so we're open to receiving pull requests that help get these issues resolved sooner.
Wikipedia was once compared to Encyclopedia Britannica in terms of number of errors it contained. It had more errors, but shortly thereafter those errors were fixed. Many of the shortcomings of our scroller will be fixed very soon. Some fixes may take a bit longer, but anyone bitten by a particular bugs has the ability to fix the problem.
Linux also went through similar pains with obviously broken parts early on before it reached maturity.
I don't know about you, but I much prefer a world where open source projects exist, even if a little broken in the beginning. Whenever someone actively hates on an open-source project they are essentially littering in and poisoning the commons instead of helping cultivate and nurture that public space.
I think this is really the point I'm driving at that people need to consider. Building something of this magnitude and ambition takes time. It's open source and anyone, including everyone wielding criticism in this thread has the power to download the source code, try it out, find out where it shines and help polish it where it does not yet shine.
Give it a fair shot; discover its merits; help make it better for everyone.
>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.
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.
>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?
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?
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.
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.
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?
When the goal is to get rich, every bit of work has a dollar figure.
I agree but add that it's not lean.
Being lean means having reduced functionality but the bits that you do launch should work well. In this case, the launched bits don't work well.
Don't sweat it, I recall Meteor went through the same thing way back when - cool core technology, no security or other practical considerations - and look at them now, $11.2M Series A from A16Z. You can never have too many JS frameworks doing cool new stuff pushing the limits on what's possible on the web, launch warts notwithstanding.
Thank you for your comment. It refreshing (not because it involves my company (although that helps), but because it sets the right tone for the community). Encouragement with constructive criticism combined results in greater good.
TBH I'm not sweating it at all. I understand the criticism. Some of it is fair commentary from thoughtful people, some is typical cynicism that blinds the otherwise intelligent. At the end of the day, the only difference between a bug report and a rant is the tone of voice used to communicate.
I'm mainly trying to provide counterpoint so that others who have yet to make up their own mind have the opportunity to do so. Many discussions can often get trapped moving in the direction in which they start. Get of on the right foot and things evolve excessively positive without constructive criticism. Get off on the wrong foot and things spiral out of control into doom and gloom. Regardless of which way it goes, doing a reality check lets the conversation focus on criticisms that actually have merit instead of the devolving into the mutual admiration society or a grand hate parade.
TBH I'm not sweating it at all. I understand the criticism. Some of it is fair commentary from thoughtful people, some is typical cynicism that blinds the otherwise intelligent. At the end of the day, the only difference between a bug report and a rant is the tone of voice used to communicate.
I'm mainly trying to provide counterpoint so that others who have yet to make up their own mind have the opportunity to do so. Many discussions can often get trapped moving in the direction in which they start. Get of on the right foot and things evolve excessively positive without constructive criticism. Get off on the wrong foot and things spiral out of control into doom and gloom. Regardless of which way it goes, doing a reality check lets the conversation focus on criticisms that actually have merit instead of the devolving into the mutual admiration society or a grand hate parade.
Agreed, let's keep it simple and polite.
So please, tell me, how do I scroll down on the homepage? I've tried everything.
So please, tell me, how do I scroll down on the homepage? I've tried everything.
Truth be told, we probably have to fix the scrollview as it has been used on the front page and implement some features like keyboard controls. In the meantime, you can download the starter pack, http://code.famo.us/famous-starter-kit/famous-starter-kit.zi... , or check out the github repo, https://github.com/famous/famous .
What device are you trying to view the site on?
What device are you trying to view the site on?
...or 3) Launch a product that is polished, but lacks some features.
Right here guys, right here. Lots of very real monetary lessons to be learned from the above
Our website is not the product. I promise you that if you take the time to explore actual product we're working on, you'll see that it's pretty polished, but lacks some features.
> Our website is not the product.
The problem is that it seems to be the only thing bigger than a one-click demo built with the product that is available, so it is -- whether you intend it to be or not -- the most powerful statement you have about what the utility of your product.
(It doesn't help that the broking scrolling makes it very hard to get to some of the rest of the content.)
If you think it represents the product poorly, I think you desperately need (1) to not rely on your product for your whole public-facing website (dogfooding is good, but part of that is having good judgement about fitness for purpose), and (2) build something that has a clear role that is more than a trivial demo that demonstrates the real utility of the product (something that's part of your public website, and a key and useful part and not just a demo, may be good, but it needs to be something that the product is ready to do acceptably.)
Or, if the problems really are fairly minor, then fix the problems that makes using it for your whole website and turn that into a plus.
> I promise you that if you take the time to explore actual product we're working on, you'll see that it's pretty polished, but lacks some features
Asking people to do more work to discover the value of your product is generally not a compelling way to get people on board with it. If the external visitors first impression isn't positive, its not their job to work harder to get to a positive impression.
The problem is that it seems to be the only thing bigger than a one-click demo built with the product that is available, so it is -- whether you intend it to be or not -- the most powerful statement you have about what the utility of your product.
(It doesn't help that the broking scrolling makes it very hard to get to some of the rest of the content.)
If you think it represents the product poorly, I think you desperately need (1) to not rely on your product for your whole public-facing website (dogfooding is good, but part of that is having good judgement about fitness for purpose), and (2) build something that has a clear role that is more than a trivial demo that demonstrates the real utility of the product (something that's part of your public website, and a key and useful part and not just a demo, may be good, but it needs to be something that the product is ready to do acceptably.)
Or, if the problems really are fairly minor, then fix the problems that makes using it for your whole website and turn that into a plus.
> I promise you that if you take the time to explore actual product we're working on, you'll see that it's pretty polished, but lacks some features
Asking people to do more work to discover the value of your product is generally not a compelling way to get people on board with it. If the external visitors first impression isn't positive, its not their job to work harder to get to a positive impression.
Your website is seen to reflect the quality & state of your product - by extension it _is_ your product.
I realize all the negative feedback must be demoralizing, but humans are silly beasts who have knee-jerk reactions to most things, and don't bother delving any further. Unfortunately, it's often best to cater to that.
I realize all the negative feedback must be demoralizing, but humans are silly beasts who have knee-jerk reactions to most things, and don't bother delving any further. Unfortunately, it's often best to cater to that.
The fact that you seriously say "our website is not the product" shows how utterly misguided you are in your marketing. I am not trying to be mean, this is simple and logical advice.
You make a platform for making websites. Your website is a huge turn-off that reminds everyone of every shitty over designed web brochure / 'experience' they've ever seen. And you think this is just a problem because people are picky.
Amazing.
You make a platform for making websites. Your website is a huge turn-off that reminds everyone of every shitty over designed web brochure / 'experience' they've ever seen. And you think this is just a problem because people are picky.
Amazing.
> I wish we were Apple and had $159 billion in cash reserves.
Apple went from near bankruptcy to that $159 billion by sweating the details. (and, I suspect, a certain amount of luck)
Apple went from near bankruptcy to that $159 billion by sweating the details. (and, I suspect, a certain amount of luck)
For such an ambitious project, bugs at this stage are totally reasonable. The problem is that they're front and center following months of hype and promotion.
And there's nothing wrong with building momentum either, Famo.us has really done a solid job generating the buzz. But if you are going to take that route, then yes, the details at launch-time are dang important.
I'm very intrigued by the premise and think the progress is tremendous. But I can't really blame folks for their initial reactions and that's kind of a shame.
And there's nothing wrong with building momentum either, Famo.us has really done a solid job generating the buzz. But if you are going to take that route, then yes, the details at launch-time are dang important.
I'm very intrigued by the premise and think the progress is tremendous. But I can't really blame folks for their initial reactions and that's kind of a shame.
What use cases is this good for? It seems to be fundamentally broken on both desktop and mobile for even basic functionality. There's something that solves only some very narrow provide problem better than existing solutions; that offers clear, if niche, value. But I don't see how this rises to that level.
I'm not sure 'make scrolling (a feature the browser does natively) work on desktop' = "perfect everything"... I can perfect scrolling by creating a blank html page.
Holy wall of text, batman! But seriously, why isn't any of this present on the website? If your big goal is to improve the web's usability and accessibilty, why doesn't that get more real estate than the "complex UIs for any screen" part of a small tagline?
[deleted]
> A scroller at is essential is a mathematical set with a curser and that all scrolling does (whether by mouse or keyboard)
Well, by mouse anyway
Well, by mouse anyway
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...
Seems to crash on Firefox 24.1.0 ESR, also on IE 10 I can't click on anything.
What other programming languages do you plan to support?
Tell us more about what you have in mind.
Don't want to use JS or transpilers.
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?
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?
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.
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.
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.
There definitely are some accessibility issues especially for those with limited mobility where using the arrow keys is a necessity.
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?
Of course mobile web development is important, but I don't really see where Famo.us's market is. Full feature desktop web?
Just scrolling the website is jerky on my iPad Air. That doesn't seem like good design.
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)
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)
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".
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.
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.
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.
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)
Watch the "3d layout engine" flip out thoroughly (tested only on chrome stable on darwin)
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.
This doesn't seem to be designed with regular desktop usage in mind.
I don't know why but it seems to be perfectly acceptable to break the scrollbar these days.
I don't think it is. Famous is the first I've seen to complement reimplement (and fuck up) something as fundamental as scrolling.
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.
Infinite scrolling doesnt break scrolling, it breaks backwards/forwards navigation.
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.
With that bounce-back effect it doesn't seem like it was designed with usage in mind.
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.
Apart from the slow pace at which the page scrolls back, the fact when it's doing so you cannot scroll up anymore (or down when you're at the bottom of the page) annoys me even more.
What Apple did, making scrolling behave like a sheet of paper confirmed using a rubber band, seems more natural than what this "3d layout engine" is doing. Giving it even more thought, it makes sense that even on a non-scrollable page scrolling (giving some form of input) should at least cause a confirmation that it recognised the action you preformed.
What Apple did, making scrolling behave like a sheet of paper confirmed using a rubber band, seems more natural than what this "3d layout engine" is doing. Giving it even more thought, it makes sense that even on a non-scrollable page scrolling (giving some form of input) should at least cause a confirmation that it recognised the action you preformed.
I also noticed that on my phone (Nexus 4) sometimes the scrolling just keeps going. I'm not sure that's how they meant it to behave, but even if it is, it's not great.
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.
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.
How are you sacrificing platform agnosticism by using a web framework?
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.
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.
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.
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.
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.
There's an absolutely massive custom scrollbar (why?!), but clicking in it doesn't do anything?
it was indeed hyped too much.
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.
Even so, I'm not exactly inclined to throw my career behind what boils down to a JS animation library.
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.
- 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.
http://famo.us/demos are quite good
Are these pages meant for desktop? I cannot even scroll http://famo.us/university/famous-101/slideshow/33/
[deleted]
That scrolloff bounce is absolutely horrible on Mac.
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.
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.
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.
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.
> 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.
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.
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.
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.
> 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.
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.
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.
Yes, we support KitKat. We'll investigate the experience on your device.
This link might be useful to your team: 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.
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.
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 , on your Android device to see how the demos perform?
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 , on your Android device to see how the demos perform?
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.
Post Hackathon: Great framework. Really interested to see where it goes.
Awesome. Thanks for the feedback. We're working hard on pushing things forward and will fix the initial problems we've had.
I'm running Jelly Bean on my Note 3. I tried Chrome, Firefox, and the stock Android browser. Scrolling is weird and choppy in each of them, and then it takes a very long time to slow down and stop.
Ordinary websites that don't do anything fancy but just let the browser handle the scrolling work beautifully in all three browsers, with smooth, natural feeling scrolling and easing.
Hmm... Just tried it in Chrome in Windows. I can't scroll at all! Tried a bunch of things but nothing would scroll. Dragging the scroll bar just turns text blue. Cursor keys and PgUp/PgDn don't do anything.
I even tried the middle TrackPoint button figuring that would fool it, but no, they disabled that too.
Ordinary websites that don't do anything fancy but just let the browser handle the scrolling work beautifully in all three browsers, with smooth, natural feeling scrolling and easing.
Hmm... Just tried it in Chrome in Windows. I can't scroll at all! Tried a bunch of things but nothing would scroll. Dragging the scroll bar just turns text blue. Cursor keys and PgUp/PgDn don't do anything.
I even tried the middle TrackPoint button figuring that would fool it, but no, they disabled that too.
Brand spanking new MotoX with Android 4.4 and Chrome. Homepage runs like a dog and scrolling is so erratic it's unusable.
Thinking that native scroll is not important puts you outside of the average. That's fine -great, even. It is where the innovators are. But you need to prove your point, and so far you have not. That's why an opinion like yours has detractors.
Fair enough. That's a very valid point.
With that in mind, what would you have to see to be convinced that native scrolling is not as important as many people claim it is? Also, what do you think it would take to convince many of those that hold native scroll in high regard that maybe it's not as deserving of the pedestal upon which it stands?
Dead serious here, besides meeting the definition of "fitness for use" by the common app user, it's as important to meet the definition of "fitness for use" by those that will be tasked with implementing an app that is built upon our framework and by extension uses our scrollview.
With that in mind, what would you have to see to be convinced that native scrolling is not as important as many people claim it is? Also, what do you think it would take to convince many of those that hold native scroll in high regard that maybe it's not as deserving of the pedestal upon which it stands?
Dead serious here, besides meeting the definition of "fitness for use" by the common app user, it's as important to meet the definition of "fitness for use" by those that will be tasked with implementing an app that is built upon our framework and by extension uses our scrollview.
> With that in mind, what would you have to see to be convinced that native scrolling is not as important as many people claim it is?
Something that actually is provides basic scrolling function effectively that replaces native scrolling -- as opposed to something that stutters badly on current, top-of-the-line mobile platforms, performs poorly (and, with many expected interaction methods, doesn't work at all) on desktop, etc.
If you are going to convince people to buy into your reinvention of the wheel, it better at least roll properly.
Native scrolling isn't actually important -- what is important is access to content that meets expectations either because it works as expected from past experiences or because there are clear affordances that make the transition easy. Native scrolling is an easy way to achieve that because users of a platform are almost certainly familiar with the platforms scrolling behavior, and every major platform has native scrolling that works acceptably in virtually all reasonable circumstances.
If I have scrolling content with no scrollbar, that's bad.
If I have a scrollbar I can't interact with as expected and nothing that clues me into how I should interact with it, that's bad.
If, on desktop, I can't scroll with the keyboard, that's bad.
If scrolling is erratic and jumpy on any platform, that's bad.
If content obviously extends past the viewport and there is no obvious way to scroll the viewport at all (as happens horizontally on mobile with the Famo.us website), that's bad.
Something that actually is provides basic scrolling function effectively that replaces native scrolling -- as opposed to something that stutters badly on current, top-of-the-line mobile platforms, performs poorly (and, with many expected interaction methods, doesn't work at all) on desktop, etc.
If you are going to convince people to buy into your reinvention of the wheel, it better at least roll properly.
Native scrolling isn't actually important -- what is important is access to content that meets expectations either because it works as expected from past experiences or because there are clear affordances that make the transition easy. Native scrolling is an easy way to achieve that because users of a platform are almost certainly familiar with the platforms scrolling behavior, and every major platform has native scrolling that works acceptably in virtually all reasonable circumstances.
If I have scrolling content with no scrollbar, that's bad.
If I have a scrollbar I can't interact with as expected and nothing that clues me into how I should interact with it, that's bad.
If, on desktop, I can't scroll with the keyboard, that's bad.
If scrolling is erratic and jumpy on any platform, that's bad.
If content obviously extends past the viewport and there is no obvious way to scroll the viewport at all (as happens horizontally on mobile with the Famo.us website), that's bad.
Thanks for this list. We'll work on this. Also, if you're open-source inclined, we would appreciate pull requests as well. :)
I'd suggest a scroller that works on most (for some reasonable definition of most) of the major (for some reasonable definition of major) platforms for the types of sites you're hoping will use it. A minimum list of platforms would be Firefox and Chrome on desktop and the latest stock mobile browsers on iOS and Android. A minimum website would be your own marketing and documentation portal.
It's all well and good to say "don't put native scrolling on a pedestal" but if the alternative simply isn't usable that pedestal sure seems justified.
It's all well and good to say "don't put native scrolling on a pedestal" but if the alternative simply isn't usable that pedestal sure seems justified.
What I don't get is all the hate out there.
Well you did hype it quite a bit. Just pretend the "hate" is HN hazing for your launch; it's a bit of trend around these parts.
I have a question: is the Lumosity iOS app built on Famo.us?
Well you did hype it quite a bit. Just pretend the "hate" is HN hazing for your launch; it's a bit of trend around these parts.
I have a question: is the Lumosity iOS app built on Famo.us?
Luminosity on iOS AFAIK is not based on Famo.us. Some of the transitions in Luminosity were built by one of the teams that participated in our private beta, so I reckon that's why you may have gotten that impression.
Between us and developers that participated in our private beta, many of the iOS transitions found on http://capptivate.co/ have been implemented and we're challenging Famo.us developers to try an build them all. IMHO, almost all if not all the iOS and Android apps showcased on Capptivate can be implemented with Famo.us. Those demos built so far were built by developers with a wide range of skills from junior to senior. Are all the demos perfect, nope. But do they all demonstrate that you can accomplish with the web pretty much anything you can accomplish in native without jumping through hoops and resorting to hideous hackery.
Between us and developers that participated in our private beta, many of the iOS transitions found on http://capptivate.co/ have been implemented and we're challenging Famo.us developers to try an build them all. IMHO, almost all if not all the iOS and Android apps showcased on Capptivate can be implemented with Famo.us. Those demos built so far were built by developers with a wide range of skills from junior to senior. Are all the demos perfect, nope. But do they all demonstrate that you can accomplish with the web pretty much anything you can accomplish in native without jumping through hoops and resorting to hideous hackery.
Thanks, I respect your work. Like I said, a lot of it is very smooth. I think a lot of the hate comes from the secret beta aspect of it. I thought it was pretty ridiculous, but I got a friend to send me the source when it came out so I could see.
I think people are going to naturally be dismissive when there's such hype and buildup and then the results are in any way disappointing. It also didn't help that you had "Open Source JS Framework" on your AngelList profile and then everything was closed source. A lot of people felt that you guys just didn't understand what open source is. If you had released it early, like Meteor, I think the launch would have been a lot smoother.
I think people are going to naturally be dismissive when there's such hype and buildup and then the results are in any way disappointing. It also didn't help that you had "Open Source JS Framework" on your AngelList profile and then everything was closed source. A lot of people felt that you guys just didn't understand what open source is. If you had released it early, like Meteor, I think the launch would have been a lot smoother.
Completely agree. I think meteor worked for quite some time secretly before they actually announced what they were doing. It's hard to say which was a better approach. Obviously on HN, a community in which I communicate a lot, it hasn't been received well, but in other circles that are far removed from the cognoscenti, it takes hype to break through to people far removed from our reality.
I have many friends from my home country (Brazil) far removed from San Francisco and the Bay Area that know about what I'm working on without me telling them. The fact that they know about what Famo.us is working and we don't have the luxury of having the visibility of a Google or Apple, is a testament that this approach may have value.
Many of us are entrepreneurs here. Having a great technical solution is half the battle. Awareness is the other half. I've been doing this for a long time, and I think there's gobs of merit in our solution despite the rough edges. I also know there's gobs of skepticism of our approach. If how we've communicated has been less than ideal, but succeeded in getting people to at least try to framework out that either would have dismissed it out of hand or sat on the sidelines waiting for others to test it first, then it might have been worth it.
What I do know is that despite some of our foibles, that when someone who is knowledgeable actually takes the time to sit down and build something, they come back a believer in the approach we're taking. A few months ago, I replied calmy to one of the first naysayers I encountered early on on reddit who was about to dismiss us. He gave it a shot and he's now become one of our biggest supporters.
Lastly, to you and everyone else, if the criticism you're giving us comes deep down from your values (and is not just a kneejerk reaction and bandwagon haterism), please tell us. It's a learning experience. We're a pretty motley crew here as Famo.us and not all of us come from an Open Source background, thus not all of us have the same experience upon which to draw when making decisions on how to handle an issue that might be controversial. Some open source ideas are controversial among people with a different business background, just as some good business decisions may be controversial among us that work on open source. Oftentimes the solution that produces the most good is somewhere in the middle. Furthermore, just because someone doesn't have the same experience as you or I, it doesn't make their decision necessarily invalid, since they may be operating based on experience which we lack and informs them to the contrary to the conclusions we'd come to. I know that I myself joined Famo.us with far less experience on how to generate attention for the important work I may be working on. I learned a ton about the value of that skill. Sometimes the difference between succeeding or failing with a good solution is generating publicity that increases willingness to experiement with your solution. Howard Aiken once said, "Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats.". The lesson I've learned is that if you've got a good idea and you're worried about ramming it down their throats, you're probably selling it wrong.
Thanks for your thoughtful, balanced comments.
I have many friends from my home country (Brazil) far removed from San Francisco and the Bay Area that know about what I'm working on without me telling them. The fact that they know about what Famo.us is working and we don't have the luxury of having the visibility of a Google or Apple, is a testament that this approach may have value.
Many of us are entrepreneurs here. Having a great technical solution is half the battle. Awareness is the other half. I've been doing this for a long time, and I think there's gobs of merit in our solution despite the rough edges. I also know there's gobs of skepticism of our approach. If how we've communicated has been less than ideal, but succeeded in getting people to at least try to framework out that either would have dismissed it out of hand or sat on the sidelines waiting for others to test it first, then it might have been worth it.
What I do know is that despite some of our foibles, that when someone who is knowledgeable actually takes the time to sit down and build something, they come back a believer in the approach we're taking. A few months ago, I replied calmy to one of the first naysayers I encountered early on on reddit who was about to dismiss us. He gave it a shot and he's now become one of our biggest supporters.
Lastly, to you and everyone else, if the criticism you're giving us comes deep down from your values (and is not just a kneejerk reaction and bandwagon haterism), please tell us. It's a learning experience. We're a pretty motley crew here as Famo.us and not all of us come from an Open Source background, thus not all of us have the same experience upon which to draw when making decisions on how to handle an issue that might be controversial. Some open source ideas are controversial among people with a different business background, just as some good business decisions may be controversial among us that work on open source. Oftentimes the solution that produces the most good is somewhere in the middle. Furthermore, just because someone doesn't have the same experience as you or I, it doesn't make their decision necessarily invalid, since they may be operating based on experience which we lack and informs them to the contrary to the conclusions we'd come to. I know that I myself joined Famo.us with far less experience on how to generate attention for the important work I may be working on. I learned a ton about the value of that skill. Sometimes the difference between succeeding or failing with a good solution is generating publicity that increases willingness to experiement with your solution. Howard Aiken once said, "Don't worry about people stealing an idea. If it's original, you will have to ram it down their throats.". The lesson I've learned is that if you've got a good idea and you're worried about ramming it down their throats, you're probably selling it wrong.
Thanks for your thoughtful, balanced comments.
The problem with native scrolling is that I can't effectively read the documentation on the website without it.
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.
Nearly every day I curse Google for breaking the native interactions with my browser (I mostly use Opera and they seem to only care about support for Chrome). For instance, today I was trying to type an equals sign and Google Docs only wanted to enter a plus, with or without the shift key. Please don't use them as your role model.
The thing about native toolkits is that they are battle-tested and you can trust them to work. Custom UI components are bound to have nasty little lurking bugs, so you should use them as icing on the cake. For things that are absolutely essential, like scrolling or entering data, please use components I can trust.
I've been around software long enough to remember when desktop application devs thought it was a good idea to develop their own basic UI components. Needless to say (or maybe not) they were often broken, usually in unexpected and irregular ways. I suppose it's only fitting that web devs would try, though to be honest I hoped that impulse had ended with the death of Flash.
Nearly every day I curse Google for breaking the native interactions with my browser (I mostly use Opera and they seem to only care about support for Chrome). For instance, today I was trying to type an equals sign and Google Docs only wanted to enter a plus, with or without the shift key. Please don't use them as your role model.
The thing about native toolkits is that they are battle-tested and you can trust them to work. Custom UI components are bound to have nasty little lurking bugs, so you should use them as icing on the cake. For things that are absolutely essential, like scrolling or entering data, please use components I can trust.
I've been around software long enough to remember when desktop application devs thought it was a good idea to develop their own basic UI components. Needless to say (or maybe not) they were often broken, usually in unexpected and irregular ways. I suppose it's only fitting that web devs would try, though to be honest I hoped that impulse had ended with the death of Flash.
We're not using Google Spreadsheets as the model. Famo.us is open-source, which means an Opera user like yourself has the opportunity to make sure that your browser is not neglected.
We only work better on Webkit over other browsers because Webkit has the most mature implementation of the W3C APIs upon which we rely. We do not not rely on special vendor-specific features that are only implemented in Chrome or Safari.
If something doesn't work properly in some browsers, like Internet Explorer thus far, then that is because that browser has yet to implement the features upon which we depend or has yet to implement it correctly. We'll work to account for variability between implementations, but at the end of the day that's how things get done.
Native toolkits are battle-tested because they have had the luxury of time. There is nothing inherent about the web that excludes it from the opportunity of also being battle tested.
Our plan is not to have custom one-off UI components, but to actually mature what we're building into something that rivals what is done in native land. What better way long term is there for the open-source world to hedge risk against closed platforms than to move those native features to the web and perfect them.
The only difference between the native components you keep on a pedestal and what we're building with the help of the community is time and polish.
Perform a mind experiment here: fast forward 1-2 years and just assume we are at parity with the native controls you prefer today. Given that what we're building is open and extensible to new unforeseen use cases, is that really a set-back or a leap forward in terms of what it enables us to explore as a community? The only thing standing between us and that future is time and effort.
We only work better on Webkit over other browsers because Webkit has the most mature implementation of the W3C APIs upon which we rely. We do not not rely on special vendor-specific features that are only implemented in Chrome or Safari.
If something doesn't work properly in some browsers, like Internet Explorer thus far, then that is because that browser has yet to implement the features upon which we depend or has yet to implement it correctly. We'll work to account for variability between implementations, but at the end of the day that's how things get done.
Native toolkits are battle-tested because they have had the luxury of time. There is nothing inherent about the web that excludes it from the opportunity of also being battle tested.
Our plan is not to have custom one-off UI components, but to actually mature what we're building into something that rivals what is done in native land. What better way long term is there for the open-source world to hedge risk against closed platforms than to move those native features to the web and perfect them.
"For things that are absolutely essential, like scrolling or
entering data, please use components I can trust."
"I suppose it's only fitting that web devs would try, though to
be honest I hoped that impulse had ended with the death of
Flash."
The only difference between the native components you keep on a pedestal and what we're building with the help of the community is time and polish.
Perform a mind experiment here: fast forward 1-2 years and just assume we are at parity with the native controls you prefer today. Given that what we're building is open and extensible to new unforeseen use cases, is that really a set-back or a leap forward in terms of what it enables us to explore as a community? The only thing standing between us and that future is time and effort.
> What I don't get is all the hate out there.
Classic Vista moment.
Classic Vista moment.
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 [1] https://en.wikipedia.org/wiki/Parallax_scrolling
> 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 [1] https://en.wikipedia.org/wiki/Parallax_scrolling
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.
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)
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)
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.)
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.)
Thanks for the feedback. Out of curiosity, what version of Android are you running on the Moto G?
4.4.2 (the normal Motorola version, which is very close to stock Android). Chrome 34.
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.
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.
[deleted]
I loaded the site on the iPhone 5S which is arguably one of the best performing smartphones on the market. Simply scrolling down the page is horribly jagged and jumpy.
It sounds like you've convinced yourselves of lots of things that just aren't true.
It sounds like you've convinced yourselves of lots of things that just aren't true.
>Famo.us currently works best on mobile devices
Since it barely works at all on desktop, this might still be completely true. I'm curious what mobile devices you actually tested this on though, based on the reactions of users here.
Since it barely works at all on desktop, this might still be completely true. I'm curious what mobile devices you actually tested this on though, based on the reactions of users here.
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.
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.
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...
I know, the irony is rather hilarious. https://www.youtube.com/watch?v=R4iyU2a0ivI
The scrollbar doesn't even let me drag it.
Would there be any documentation of how to integrate this to Phonegap / Cordova?
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.
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.
Btw, when would the forums will be open to public? We are in dire need of one.
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.
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.
Is the logo related in any way to the game(s) Marathon?
Is there an ETA on official clojurescript support?
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.
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.
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)
I'm back to using the browser like it should be (with a bit of angular on top)
noob question - I saw this on HN sometime last week 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?
"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?
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...
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...
I have the famous song from the Beastie boys : 'Sabotage' playing in a loop in my mind as I watch this on my Desktop ...
All your type is hideous on a retina screen.
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.
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.
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.
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?
I am working on reproducing the stories scrollview from the paper demo. Lookout for github.com/jperl/famous-cards later this week.
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).
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).
I usually scroll using the smooth scroll by pressing the middle mouse button. Doesn't work either.
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
As a side note, that page is a good example of famous being used with NORMAL scrolling.
I've been particularly impressed with the new support for Angular: http://famo.us/angular
As a side note, that page is a good example of famous being used with NORMAL scrolling.
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.
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.
I am literally unable to "look past the ScrollView problems" .
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.
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.
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.