Famo.us open to everyone
famo.us
famo.us
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.
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.
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.
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.
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.
Yes, we support KitKat. We'll investigate the experience on your device.
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.
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?
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.
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?
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.
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.
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.
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.
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 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.
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 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.
Classic Vista moment.
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).
Watch the "3d layout engine" flip out thoroughly (tested only on chrome stable on darwin)
This doesn't seem to be designed with regular desktop usage in mind.
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 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.
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.
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.
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.
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.
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.
> 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
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.
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.
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)
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)
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.)
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.
It sounds like you've convinced yourselves of lots of things that just aren't true.
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.
Of course mobile web development is important, but I don't really see where Famo.us's market is. Full feature desktop web?
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.
That's not a great argument to convince me to adopt a brand new platform
- 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.
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.
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?
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
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.
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.
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.
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.
So please, tell me, how do I scroll down on the homepage? I've tried everything.
What device are you trying to view the site on?
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.
... 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.
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.
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.
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?
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.
Apple went from near bankruptcy to that $159 billion by sweating the details. (and, I suspect, a certain amount of luck)
Well, by mouse anyway
Even so, I'm not exactly inclined to throw my career behind what boils down to a JS animation library.
I'm back to using the browser like it should be (with a bit of angular on top)
"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?
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...
Btw, when would the forums will be open to public? We are in dire need of one.
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're interested in working with Famo.us and Clojurescript or know someone who does, you can contact me directly. Work email in profile.