Forgot your password?
typodupeerror
Programming The Internet

Famo.us: Do We Really Need Another JavaScript Framework? 104

Posted by Soulskill
from the let's-create-a-javascript-framework-to-find-out dept.
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."
This discussion has been archived. No new comments can be posted.

Famo.us: Do We Really Need Another JavaScript Framework?

Comments Filter:
  • by iONiUM (530420) on Friday July 04, 2014 @05:31PM (#47385751) Homepage Journal

    but what is really scary is what a mess Javascript is in 2014 --- makes Perl look like BASIC. No need to obfuscate Javascript in 2014.

    I've been working in software development for about 15 years now, and I've worked professionally with all the majors (C++ a bit, Java, PHP, Perl, VBScript which was awful, C# extensively which I like a lot). For the last few years I've been tasked with writing a very large client-facing web application, where my team was mostly responsible for the front-end (JavaScript/HTML/CSS) that communicates with a large RESTful service provided by another team. This included writing an API in JavaScript with documentation.

    The first thing I did was set ground rules on how my team should program in JavaScript, the structure we would use, how we would use the functional language to maximize its abilities and have some class-like things (properties, inheritance, etc.) too. Now we have a full blown web-app with a JS front end with over 900 JavaScript files (when in debug) that are very nicely sorted and categorized, full class/inheritance structures, and many other things. We use Visual Studio 2012/2013 with a few custom JavaScript extensions, and along with Chrome's debugger, it is more than manageable. But we also don't need to target any old browsers. Nothing pre-HTML5.

    I'm not saying JavaScript is the best language in the world or anything like that, it definitely has its problems, and it certainly doesn't fit as a choice in many situation. But programming for it these days is not the nightmare it once was (assuming you don't need legacy browser support), and in many cases, it's actually rather refreshing after 13 years of strictly typed non-functional languages, because you can do some interesting things.

The use of anthropomorphic terminology when dealing with computing systems is a symptom of professional immaturity. -- Edsger Dijkstra

Working...