Did these guys just reinvent the Web?

It's been a while since I looked at transition (and 3d transition) support from css -- but this sounds really counter intuitive -- shouldn't the browsers be able to make these changes themselves, in c++/c/hand-tuned machine code at that?

http://www.w3.org/TR/css3-transforms/#transform-property

"A transformation is applied to the coordinate system an element renders in through the ‘transform’ property. This property contains a list of transform functions. The final transformation value for a coordinate system is obtained by converting each function in the list to its corresponding matrix like defined in Mathematical Description of Transform Functions, then multiplying the matrices."

On a side note: this looks like something that should work (transformation/transition) with javascript disabled -- we've (rather) recently gotten drop-down menus that don't require javascript -- seems like a bit of a step backwards to require javascript for (some uses) of basic transformations if that's being used as part of the essential ux for a page...

The first thing I did when I saw Famo.us last year was rip into the code. With a little persistence, you can pretty easily use the code without waiting for their release.

Since when did 'the web' involve giving away all the source code and not charging people for things? Did Google open source their search engine and let anybody advertise on their site for free while I wasn't looking?

I really don't understand this meme about the web being 'open'. Much of the native desktop software I use is open source. Practically none of the web services I use are open source. There is not much chance of a 'GNU project' for the web (i.e. reimplementing an open google and twitter and facebook and so on). Open source web services of significance are few and far between and when it comes to controlling our data usually the best we get is a proprietary API that may or may not get shut down or changed tomorrow.

The web gave us RSS which was good[1] but since then it has been pretty much a non stop stream of proprietary APIs and platform lock-in. Even things built on RSS tend to be proprietary APIs rather than open standards: take Google Reader for example. Before it shut down it should have been trivial to pull your subscriptions out of it and point your clients at a new replacement rss-syncing server (like you can do with an email client). But it wasn't because there was no damn standard for that, just proprietary APIs as various people wanted to lock you into their cloud service. The standards that have emerged have been, of course, ones that generally involve lock-in to proprietary platforms, like OAuth.

[1] interestingly many of the new generation of web developers seem to dislike RSS.

From the article: "Last month Famo.us announced that its core would be available for free under an as-yet-unspecified open source license when the company releases its software sometime next year."

So they're planning on releasing open source and charging for components on top.

Seems like just another case of Betteridge's Law of Headlines.

Check these for examples of performance:

http://www.framerjs.com/static/examples/GoogleNow/index.html

http://www.framerjs.com/static/examples/NewsFeed/index.html

http://www.framerjs.com/static/examples/Intro/index.html

nice - I have to use chrome though, no examples seem to work in Firefox. Is that expected?

EDIT: ahh, the http://famo.us/ example doesn't work in FF either, it redirects to a boring splash page. I didn't notice the redirect the first time!

Thanks for posting this here! Highly appreciated and relevant. I'll check this out, but why a Facebook Group?? Can't you just open an IRC Channel? I would definitely join and contribute back. I don't have a Facebook account and won't use it and I'm still very social. hmm, I guess many hackers don't have a FB account and hate using the Facebook Oauth Login on 3rd party sites.

If you were building specifically for mobile, how would it do?

Do iOS/Android handle CSS matrix well? Because if you could punt on FF/IE support, it seems like you could do some interesting mobile interaction stuff.

Same thought. Sent their link to a friend of mine, who said "hey, seems like i'm already registered to their beta...". That was one year ago, and he completely forgot about it.

But the article says it's based on "a W3C standard that must be supported by all browsers". How can this be?

Didnt seem to work in IE10 (Only other browser installed on this machine) either.

Ah, is that why http://famo.us just looks like a blurry pile of laundry to me?

But most importantly: didn't Intel release around this time last year JIT compilation of Javascript to run on their HID (GPU onboard CPU)? (wouldn't that make slow-execute javascript a non-issue?)

I'm inclined to agree with you here. While I love HTML, CSS and Javascript it's not the right tool for where the web appears to be heading, which is essentially a transport layer for data that services apps.

Mobile devices have turned the process of installing an app into something 'close enough' to the experience of browsing the web that I think a lot of consumers wouldn't notice if the twitter web site disappeared (except that would be big news, and they wouldn't be able to avoid all the complaining).

Conclusion... I don't know, but I think our current concept of a browser and the web might be reaching the end of it's usefulness. More data needed.

"Seems browsers are obsolete and are now just getting in the way. People are trying to use every loophole and new technology possible to bypass features implemented in browsers."

Warning: unpopular view ahead. It's a bit ranty, too.

That's because we're hell-bent on doing everything in browsers in the first place. Somewhere along the way, we collectively decided that write-once run-anywhere would become reality, damn the consequences. We just wouldn't call it that anymore - to do so would raise the spectre of desktop java which has essentially shit the bed. Instead, we'll call it "standards".

It's a most peculiar definition of "standards" though. These standards are a shifting target, receiving regular modification. Every major vendor can claim compliance regardless of whether they are actually compliant - after all, vendor prefixes. And many front-end developers extoll the virtue of these 'standards', apparently believing that the libraries and tooling that hide the inconsistencies from them are actually a solution instead of a band-aid.

We've been trying for "write-once-run-anywhere-but-don't-call-it-that" [WORABDCIT] for years. And we've made such progress - in another decade we may actually have consistent standard support across browsers. Of course, we haven't had this for the last decade so I'm not sure why we're perpetually hopeful that we will in the next.

And that's not even getting into performance. Because these 'standards' are built atop so many layers that applications built on them can very, very rarely provide performance like an application actually built for a native platform does. Leading to a whole discipline of computer science with a goal of performance that merely approaches native speed on a consistent basis.

Back when I first started in my career, I remember building native application UIs that were poorly coded, inefficient and bloated. Hell, I used MFC for love of K&R. Yet this crap still ran faster on a Pentium III than the majority of "web apps" run on the latest hardware.

A native application is nearly always going to be faster than javascript through a browser. For most applications being developed, it will provide excellent performance - even on ARM -- without any tuning, tweaking, shortcuts, or loopholes. It will give an experience consistent with the rest of the platform, so that users aren't having to learn a new UI paradigm with every hot new app.

You can even integrate technologies into a native app that still allow you to communicate with back-end components over http/https - go figure. A well-written native library is cross-platform (thanks to meaningful standards), so that only the UI bits would differ.

The cost is more time building. A loss of some flexibility. Levelling up some basic skills, perhaps raising the barrier of entry a bit. A step back from RAD practices that have become so rapid that it's become common for a new "app" to be deployed knowing it will break under stress and worry about fixing it later. Not saying that this didn't happen before - but I am saying it wasn't accepted as the norm to the degree it is now.

But nah. Native is yesterday. Why on earth would we want to take fullest advantage of modern hardware to provide a good user experience? Let's continue to reinvent the browser. We'll keep on with WORABDCIT because sooner or later, we're bound to come up with standards that are finalized and implemented consistently.

Really. We will.

Well, that’s just Betteridge’s Law of Headlines. Also, it’s an article on a website called ‘javaworld’.

Yes. Thats why I rarely click on such titles.

"Any headline which ends in a question mark can be answered by the word no."

I had to look it up, so this might save some others the trouble.

My instant thought too

What's the law for someone always mentioning Betteridge's law of headlines when a headline is posed as a question on Hacker News?

I would like to analyze the comment threads of all the submissions ending with question marks and see in how many Betteridge is referred to. I would guess it's close to 100%.

This was a particular bad reference since the title was very rhetorical and not meant to be taken literally.

Hmm, note that "Urasium" in the Apple demo has an atomic weight of 238.0289, while this one changes the weight to "Michael Arrington". I think the famo.us people may have been calling Michael Arrington an ass.

It seems that they will release their software as open source. I couldn't find what license famo.us will use.

so it doesn't work on firefox..

It seems the demo doesn't work on FireFox, but does on Chrome. Firefox just redirects to http://famo.us/c

Demo runs pretty slowly on my iPhone 4s, but really they need the same demo in raw CSS3 to compare speeds.

Does anyone really want that? Web is currently awful for mobile games: hard to interact with the content (see how scroll is handled in javascript) and low performance no matter how many tricks you do. Also, don't forget that you'll have to handle payments by yourself (and impulse shopping will not work if users will have to fill the credit card every time).

edit: I've opened that page in Firefox, it won't show the demo. I guess it won't show it on IE also, but I haven't tried. So who's their target? 25% of the users?

yes and that has been done already. I posted somewhere on this page links to it, in case you're interested.

Nope, it is a great idea on mobile, at least for iDevices and I imagine most Android devices. Especially with high dpi screens, leaving everything on the CPU is too slow.

I'm gonna go with 'no'; GPU's should be a lot faster (read: more specialized), and thus more power-efficient than general-purpose CPU's. In theory. Disregarding optimizations in general purpose CPU's in mobile.

Truth