Famo.us: Do We Really Need Another JavaScript Framework?
An anonymous reader writes Front-end developer Jaroen Janssen has a post about Famo.us, "a custom built JavaScript 3D rendering and physics engine meant as a replacement for the standard layout engine of the browser." The engine effectively replaces a big chunk of HTML5 in order to render more efficiently by using technology based on WebGL. Janssen questions whether the world really needs another JavaScript framework: "Is it a bad thing that Famo.us replaces major parts of HTML5? To be honest, I'm not sure. As a Front-end developer I have to admit it makes me slightly uneasy to have to use a custom API instead of 'standard' HTML5. On the other hand, like almost everyone that makes web apps for a living, I have been terribly frustrated by some of HTML5 limitations, like slowness and browser incompatibilities. Either way, it might be a good thing to try a fundamentally different approach so I'm keeping an open mind for now.
Famo.us chases another holy grail, namely the 'write once, run anywhere' dream. Instead of having to write different code for different platforms, like iOS and Android, developers can write one application that works and looks as good on all platforms, in theory anyway. This of course saves a huge amount of time and resources. Unfortunately, this idea is not without its problems and has never really worked very well with earlier attempts like Java-applets, Flash and Silverlight. In the end native applications have so far always been faster and slicker and I'm pretty skeptical Famo.us will be able to change this."
Famo.us chases another holy grail, namely the 'write once, run anywhere' dream. Instead of having to write different code for different platforms, like iOS and Android, developers can write one application that works and looks as good on all platforms, in theory anyway. This of course saves a huge amount of time and resources. Unfortunately, this idea is not without its problems and has never really worked very well with earlier attempts like Java-applets, Flash and Silverlight. In the end native applications have so far always been faster and slicker and I'm pretty skeptical Famo.us will be able to change this."
The world is now ready for VRML.
Until 3D rendering is on par in terms of efficiency with 2D graphics, you'll see a rebellion against WebGL for general purpose websites. This is because mobile devices are drained of charge in minutes instead of hours when the silicon to handle 3D activates.
The web developers and users will quickly decide if people want this technology. The more options the better I say; the inferior ones will fade on their own.
Don't waste your vote! Vote for whoever you want, unless you live in a swing state it won't matter anyways
- inferior paradigm; ...
- Inferior performance;
- Inferior UI experience;
- Inferior security;
- Inferior privacy;
- Inferior development environment;
Honestly, it's just the mainframe game of the '60s, plus all the guys who realise they can make a lot of money by pretending that dumb terminals are an advance on autonomous desktops belonging to and being controlled by the user.
This is basically a waste of time. What they should be doing is working with the browser vendors and standards committees to improve HTML5, not making their own inferior and heavyweight solution to add to the slow-down of the Internet.
A lot of devs don't even realize how efficient and quick modern browsers are, because they're too busy complaining and trying to solve perceived problems using these kinds of crappy replacement stacks. What's the point in having a standard framework if everyone tries to write a "Flash" to replace it? It's inane.
Especially since a lot of effort has gone into making specs that are as efficient as possible and avoid a lot of problems you don't see immediately; several of these frameworks have serious performance issues that can't be rectified without the browsers themselves re-writing a lot of code. I utterly fail to see the need for this. Stop trying to replace standard technology with inferior solutions already.
If you want fast 2D or 3D graphics you DON'T code them in an interpreted script language welded onto a markup language pushed well beyond its sell by date running in a bloated client which in turns runs on the OS. If web devs want to climb out of the web playpen and do grown up programming then learn a grown up language such as Java or C++.
Over the last week, reading as an AC, I have been forced to the Beta site well over 50% of the time.
It looks like Dice are building up to having another go at forcing Beta on us.
One interesting piece of information: I have _never_ been forced to Beta while browsing from an Android tablet using the Android supplied browser.
In case you are reading this Dice, been forced to Beta at the rate I am is _really_ pissing me off. :-( :-(
When we were growing up our parents somehow made it clear that being famo.us was good. And I mistakenly thought that if I was famo.us then everyone would love me.
-- Ellen DeGeneres
The worst thing about being famo.us is the invasion of your privacy.
-- Justin Timberlake
Being famo.us is just like being in high school. But I'm not interested in being the cheerleader. I'm not interested in being Gwen Stefani. She's the cheerleader, and I'm out in the smoker shed.
-- Courtney Love
This has been tried and tried and tried and it's never worked. And yet, here we have Jaroen Janssen crying, "This time, for sure!"
Good, inexpensive web hosting
It's Jeroen Janssen, not Jaroen Janssen
Nope, not after AngularJs you don't. Not another framework needed. After huge loads of jquery before I ever knew what a client-side architecture was, and then knockout and backbone. I found my home with Angular. I know that will be developed and fine-grained further by both professionals AND the community.
And it already kicks ass. Pretty sweet...
Sure, having desktops "controlled by the user" has worked out just swell for the last 30 years or so. If you want to make sure a system stays at peak performance, doesn't get infected, and keeps up with bug fixes, put it "under the complete control" of someone who thinks a "buffer overflow attack" means someone pouring too much cleaning solution into a floor polisher.
I come from a background of systems-level software... server-side and thick client, predominantly. I've recently been looking at in-browser Javascript again - and recognise that it has come a long way in recent years. JQuery is nifty; Backbone useful; Angular is neat... but they lack a certain je-ne-sais-quoi.
In one sense, I love the flexibility of dynamic programming with Javascript - but, on larger projects, this benefit becomes a burden. What I'd really like is a Javascript-like language - that compiles to efficient Javascript - where I get to structure my application; enforce type constraints at compile-time; provide test-time assertions... etc... and allow me to implement my Javascript application as a collection of independently tested components. Client-side libraries are going in the right direction - but remain an evolutionary step away from where, I think, web-technology deserves to be.
Javascript has come a long way - but the journey isn't over yet... IMHO.
you've failed at life
I checked it out, out of morbid curiousity. The demo pages don't even display on Firefox 30 for Linux, which is a pretty common browser. Not display incorrectly, just nothing shows up at all when you click the different demo previews. pretty pathetic. Also I didn't see anything 3d in there at all.
JS frameworks are a dime a dozen, it's like everyone and their grandmother is making one in some form. What really is having is all these JS wrapper modules (frameworks) are allowing developers/programmers, do front-end and now back-end (mongoDB/NodeJS) all with-in JS. As a consultant, it's actually pretty awesome. Because I get tons of work stepping in and fixing things when the "companies dev team" can't figure it out as they all built X years and X products around JS frameworks.
Keep it up script kiddies, you're making me rich!
Sure, having has worked out just swell for the last 30 years or so.
"under the complete control" ? Of who, the mega corporations? The NSA?
"Belonging to and being controlled by the user" -- HA HA HA HA HA .
If you want to make sure a system stays at peak performance, doesn't get infected, and keeps up with bug fixes, put it "under the complete control" of someone who thinks a "buffer overflow attack" means "this backdoor was placed here for NATIONAL SECURITY"
HA HA HA "controlled by the user" -- where have you been the last 30 years? Please, share us the details of your homebrew machine, the "jeffb 8000".
From what I've seem Famo.us is more Famo.us for it's ability to market to hipster cool developers than to normal web developers. When they tire of using Famo.us and something else more hip, cool, "bro" comes along they'll go with that. I mean really, who calls their framework "famous", except for wannabe hipster, cool, "bro" programmers? It only came out this year - I give it another 6 months to hit the peak hype cycle, then it's all downhill from there "bro".
There's a class of application that will never make sense to be stand-alone, and for those apps, the cloud is probably the best paradigm. But the current state of HTM5/Javascript calls for a cloud with a ton of application logic running in the browser. I'd much rather see a single app running in the browser that isolates all the front-end specifics and makes it really easy to write fully server based apps that use the browser as a universal delivery system - and nothing else. Sure, you're not going to write video games that way. But I'm talking about apps that handle data input and output with a robust widget set that doesn't need to be programmed on the front end. A smart terminal that lets you generate, say, data to be displayed in a grid on the server and just send it to the terminal for display and manipulation.
I wrote something just like that a long time ago - though it doesn't run in a browser - so the smart terminal requires Windows or WINE to run. That no longer cuts it, but as a proof of concept it works really well (and is still in use). The data grid, for example takes grid layout instructions and a file in a 'CSV with flags' format that is produced on the server for display (and editing) in the terminal. Besides making the app easy to implement and debug, that level of abstraction has some nice side benefits. 'Printed' reports come for free, because the data and the instructions for laying it out in a grid are generated separately from the display logic, and it was easy to implement a printing module that takes that same info on the server side and uses it to generate a PDF or XLS file for download and native display/printing. I guess it's essentially splitting the MVC model so that only the View part (the part that has to run on the client) runs on the client.
I can't be the only one that's done something like this - but I'm curious why I don't see anyone trying to adapt that model as a browser-based application platform. Just because Javascript lets you write application code that runs in the browser, that doesn't mean it's a good idea - or that the end result is easy to write, debug and support. The browser's a really smart terminal, but maybe it would make sense to write a browser application that turns it into a somewhat dumber terminal - that only does terminal-like stuff.
Posted from my Android phone. Oh, I can change this? There, that's better...
Yes, the world needs it. Always. Not because we couldn't get along without it, but rather, thinking that you already know enough or have discovered everything worth knowing is how innovation and advancement die.
Try TypeScript.
http://en.wikipedia.org/wiki/Typescript