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.
If their performance claims bear out (which, we'll see) I could see this becoming a popular way to deliver apps and games to mobile devices without giving 30% of your income to Apple or whoever.
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?
From the rather vague text I can imagine they are doing matrix multiplication in JavaScript and assigning the end result to a CSS transform. Instead of doing multiple transforms in CSS which is slower. The end result is smoother HTML5 animations but I haven't yet figured out where they reinvented 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?
"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...
This may have something to do with "We use the CSS3 primitive -webkit-transform: matrix3d, which lets us compute the composite matrix and skip the browser's renderer. No plug-in, no download, no hack."
Yeah... "the vendor specific CSS3 primitive" and "no plugin, no download, massive hack". Would be a closer representation.
Sounds like they came up with a novel and impressive optimisation that everyone could benefit from, but decided to keep it to themselves and charge for it. So less "reinvent the web" than "go back to the way things were before the web" really.
Whether or not there's anything wrong with that is left up to the reader. :)
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.
Since the headline was "reinventing the web" (a pretty ambitious, even bombastic goal), it would be fair to expect the solution to be open-source and/or free. Of course had the headline been "improving the web" or "making a faster web" then our expectations might have been different.
The web is characterised by all code being visible by default, e.g. "View Source" in every browser. It's agnostic on whether you can charge for that source code, but in practical terms it's pretty tough to publish openly readable source and expect people to pay for it.
Many sites still use JavaScript that way, but some use it for major programs that do large jobs. For instance, Google Docs downloads into your machine a JavaScript program which measures half a megabyte, in a compacted form that we could call Obfuscript because it has no comments and hardly any whitespace, and the method names are one letter long. The source code of a program is the preferred form for modifying it; the compacted code is not source code, and the real source code of this program is not available to the user.
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.
"We were 14 times faster than compiled C in Chrome..." I feel this part needs clarification. As I understand it the "in Chrome" part is key, as they were bypassing the browser and interpreting javascript through compiled C (matrix3d).
The demo doesn't work on Firefox 27.0a1 on my MacBook Pro. Any effort to reinvent the web needs to keep compatibility in mind.
Tried it on my phone and the performance was good but still noticeably stuttering. Could be an interesting approach if they cut down the hyperbole and carry on improving.
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.
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.
I prettified the code myself too, but it's really unreadable. Have you extracted the parts into a nice library? Mind sharing your efforts?
Honestly, without going into the source code, I was like, this is matrix transformation, this is matrix transformation.. then I saw matrix3d and I was like yeaah!
I believe that no software can excel without a good mathematical foundation. What I see coming is that this approach will be extended by P2P Load-Balancing. Similar to what Bitcoin Hackers [1] were doing and still do [1].
Except that for nearly every -webkit property there's a non-vendor version as well. There's the occasional -moz in there so it doesn't seem that would be the problem.
It now redirects to famou.us/c/ in Firefox for me.
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'd recommend checking the Ajaxian article[1] that sums it up. You can find the source on Github [2]. You can play around with the River Trail interactive shell
[3] too.
Well it would if Javascript execution speed was the issue, but as the article highlights, they're using Javascript to replace slow browser rendering, and the argument is that JS is, in the case of matrix transformations, 80% the speed of native C, and using that to replace the renderer for animations in a browser is faster than the native render.
Vaporware. This stuff was announced years ago, we saw only one basic demo , they raised quite a lot of money though, yet there is no product today. What did they do with the money?
Mr Doobs did the same demo, even better since he used the framework he created ,three.js :
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.
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.
I think it's time browsers took a step back and gave more control to developers.
It's time for a major rethink of what a browser should be/do.
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.
Most of you're points I agree with but we tried Native it's not the answer.
With native you have to redo your work multiple times that is not efficient java had the right idea but their implementation is a nightmare.
We need something that would be as simple as using a browser but would act more like a java interpreter under the hood.
But I wouldn't want java or javascript as a language.
We need something that trows exceptions every time you attempt to do something the wrong way like Python because a log of beginners will try and if the language allows it there's going to be a lot of messed up code.
(BTW: It took me a while to figure out that if you close the dialog window, you can click the buttons at the bottom for more demo's.)
Unfortunately they are only using the webkit-prefixed properties, so their demo doesn't work in Firefox or IE. I'm guessing they wrote their demo a couple of years ago and never updated it.
There are some problems with CSS3 3d-transforms:
1) Text looks blurry, just look at the dialog window in the demo.
2) Some mobile devices (e.g. old iPads) have limited GPU memory. If you use too much (by setting 3d-transforms on large surfaces), the browser (or your app) will crash.
By the way, the answer to the question in the title is: No. And if they don't open source their code, they won't get a lot of traction.
"Obviously, this isn't exactly the reinvention of the Web, but Famo.us has pushed JavaScript in a novel direction -- and has poked a large hole in the argument that native apps alone deliver the goods. It will be fascinating to see the new types of applications that emerge."
I saw a video of the founder giving a talk, seems like they are hijacking css3 animations and doing matrix calcs better optimised than most css3 browser implementations
Cool stuff but I wouldn't call it re-inventing the web
Having never heard of this before, I actually read this half-way through and thought it was a highly satirical piece, so I went back here before realizing it's not.
The animations were pretty smooth anyway, but my cursor would skip frames over the content.
Looks like an easy to implement performance optimization for the browser. Feels like "This belongs in the browser source code, not in the application".
92 comments
[ 3.9 ms ] story [ 163 ms ] threadAt at least they admit its just hyperbole... right?
I had to look it up, so this might save some others the trouble.
Any time a commenter cries ad hominem, there will be a sub-thread arguing about the definition of ad hominem.
This was a particular bad reference since the title was very rhetorical and not meant to be taken literally.
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?
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...
Yeah... "the vendor specific CSS3 primitive" and "no plugin, no download, massive hack". Would be a closer representation.
Whether or not there's anything wrong with that is left up to the reader. :)
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.
Many sites still use JavaScript that way, but some use it for major programs that do large jobs. For instance, Google Docs downloads into your machine a JavaScript program which measures half a megabyte, in a compacted form that we could call Obfuscript because it has no comments and hardly any whitespace, and the method names are one letter long. The source code of a program is the preferred form for modifying it; the compacted code is not source code, and the real source code of this program is not available to the user.
So they're planning on releasing open source and charging for components on top.
Tried it on my phone and the performance was good but still noticeably stuttering. Could be an interesting approach if they cut down the hyperbole and carry on improving.
[0]https://twitter.com/onesleepynerd/statuses/34425107788713164...
The example shown on famo.us is identical to MrDoob's Three.js example that uses CSS3:
http://www.mrdoob.com/lab/javascript/threejs/css3d/periodict...
Edit: looks like it's the other way around -- according to MrDoob's G+ post from last year, he based his Three.js CSS3 example directly on the design created by famo.us: https://plus.google.com/113862800338869870683/posts/QcFk5HrW...
Honestly, without going into the source code, I was like, this is matrix transformation, this is matrix transformation.. then I saw matrix3d and I was like yeaah!
I believe that no software can excel without a good mathematical foundation. What I see coming is that this approach will be extended by P2P Load-Balancing. Similar to what Bitcoin Hackers [1] were doing and still do [1].
--
[1] http://community.websense.com/blogs/securitylabs/archive/201...
[2] http://bitcoin.stackexchange.com/questions/1364/how-can-i-st...
PS: Page 3 on the article answers the headline: No!
Metaphors are powerful.
> a javascript engine and framework that solves HTML5 performance
And doesn't work in Firefox. Aweso.me!
It now redirects to famou.us/c/ in Firefox for 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'd recommend checking the Ajaxian article[1] that sums it up. You can find the source on Github [2]. You can play around with the River Trail interactive shell [3] too.
--
[1] http://ajaxian.com/archives/intels-parallel-extensions-for-j...
[2] https://github.com/RiverTrail/RiverTrail
[3] https://github.com/RiverTrail/interactive
Of course, faster JS is never wrong.
Mr Doobs did the same demo, even better since he used the framework he created ,three.js :
- http://www.mrdoob.com/lab/javascript/threejs/css3d/periodict...
I think it's time browsers took a step back and gave more control to developers.
It's time for a major rethink of what a browser should be/do.
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.
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.
With native you have to redo your work multiple times that is not efficient java had the right idea but their implementation is a nightmare.
We need something that would be as simple as using a browser but would act more like a java interpreter under the hood.
But I wouldn't want java or javascript as a language.
We need something that trows exceptions every time you attempt to do something the wrong way like Python because a log of beginners will try and if the language allows it there's going to be a lot of messed up code.
http://famo.us/
(BTW: It took me a while to figure out that if you close the dialog window, you can click the buttons at the bottom for more demo's.)
Unfortunately they are only using the webkit-prefixed properties, so their demo doesn't work in Firefox or IE. I'm guessing they wrote their demo a couple of years ago and never updated it.
There are some problems with CSS3 3d-transforms: 1) Text looks blurry, just look at the dialog window in the demo. 2) Some mobile devices (e.g. old iPads) have limited GPU memory. If you use too much (by setting 3d-transforms on large surfaces), the browser (or your app) will crash.
By the way, the answer to the question in the title is: No. And if they don't open source their code, they won't get a lot of traction.
Cool stuff but I wouldn't call it re-inventing the web
These guys optimized some JS and you called it "reinvent the WWW". Ridiculous.
The animations were pretty smooth anyway, but my cursor would skip frames over the content.
- http://hakim.se/
- http://desandro.github.io/3dtransforms/
- http://glmatrix.net/
As for the article... the author confuses "rendering" with "layout":
- "the primary part we need to rewrite is the part of the renderer that creates and multiplies the matrices"
- "We use the CSS3 primitive -webkit-transform: matrix3d, which lets us compute the composite matrix and skip the browser's renderer"
Which leads to some absurd claims:
- "We were 14 times faster than compiled C in Chrome"
Before reality kicks back in:
- "rendering goes through DOM"
- "Obviously, this isn't exactly the reinvention of the Web"
And this is how you sell a DOM scenegraph engine to people with more money than common sense:
- "a W3C standard that must be supported by all browsers"
- "all text in Famo.us applications is searchable"
- "enable rapid application development"
- "smooth, high-functioning UI across all platforms"
- "one of several enabling technologies"
- "allow enterprise users to touch-interact with big data analytics"
- "spark a new breed of gamified enterprise apps"
...then went downhill:
"...and in JavaScript."