Slashdot Mirror
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.
You aren't right in a technical sense on this at all. It scary what Javascript and WebGL can do and the speed of it, 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. Also I'm not sure if technologies like NaCL and WebGL should be in the future --- I guess, but it will be coming.
...
But more to the question, what kind of web is this leading to
I used Adblock and Flashblock right now just to have a half-way decent experience on the internet to avoid a ghastly internet flash ads from downloading untold GBs of data/video/audio to annoy me without a way to mute it.
The internet is a train to nowhere and no one is driving it, big corporations will turn it into a minefield of advertising (which is FINE, by the way) but rip apart everything good (involuntary flash ads, bandwidth, speed, shitty cross-domain javascript, DRM, turn web standards into circuses) to get there.
Steve Jobs back 3 years did a rant again Flash, which at the time and still now embodies the villanous nature of plug-ins.
And with WebGL and video streaming and DRM in HTML5 --- your internet may get turned into a turdball --- just to waste everyone's bandwidth to show ads you will never click.
Priest: "Universe from nothing, no laws of physics, sped up time"+ huge discrepancies. Creationism? No. Big Bang Theory
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.
It means that there is yet another web site that I arrive at at see an empty page or maybe a few items scattered apparently at random. I surf with javascript switched off by default. Most sites should work without javascript, OK some fancy features might be missing but I should generally see the page. Those that do not: I might look to see what javascript to enable, but all too often they are trying to pull in javascript from 1/2 dozen sites - so I guess a couple and then give up and go elsewhere.
Javascript should be used to make a page look nicer, not to make it work at all. Insisting on javascript is like insisting on flash.
I accept that a few special pages really do need special effects that need javascript, but not many of them.
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.