Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
Programming The Internet Do We Really Need Another JavaScript Framework? 104

An anonymous reader writes Front-end developer Jaroen Janssen has a post about, "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 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. 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 will be able to change this."
This discussion has been archived. No new comments can be posted. Do We Really Need Another JavaScript Framework?

Comments Filter:
  • Not Ready Yet... (Score:4, Interesting)

    by jklappenbach ( 824031 ) on Friday July 04, 2014 @03:19PM (#47384971) Journal
    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.
  • by Anonymous Coward on Friday July 04, 2014 @03:23PM (#47384997)

    - 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.

  • We need something... (Score:5, Interesting)

    by shic ( 309152 ) on Friday July 04, 2014 @07:58PM (#47386095)

    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.

"Tell the truth and run." -- Yugoslav proverb