Home

News: JavaScript: Unscientifically tested to be more annoying and frustrating than Java

  1. The Dodgy Coder pushed out an article on Saturday asserting in the most interesting and unscientific manner that JavaScript is the most annoying and most frustrating of programming languages currently in existence.

    And how was this conclusion made? Basically, a comparison was made between how many people were using a given programming language, and how many inane questions about that language were posted to StackOverflow. So, if 17% of the programmers in the world use Java, then 17% of the questions on StackOverflow should be Java related. However, since only 7.6% of StackOverflow questions were Java related, Java is underrepresented, meaning that Java is well understood. Alternatively, JavaScript has a Tiobe representation score of 2.191%, while 6.4% of StackOverflow questions were related to the client-side monster. Clearly, people using JavaScript are running into problems.

    Why the problems with JavaScript?

    It's an interesting, if not highly unscientific, glimpse at what's happening in the programming world. And seriously, the conclusion can't be that JavaScript is hard, because it's not. The real problem is that JavaScript isn’t anybody's first language when it comes to programming.

    If you're a programmer, you're either a .NET programmer, or Java programmer, or you're a C++ person or perhaps even knee deep in Objective C. But nobody writes down on their resume that their primary competency is their ability to animate a web page using JavaScript. However, if you're doing any enterprise development these days, whether you're a Java Developer or a .NET developer, there comes a point where you've got to get your hands dirty with JavaScript. Okay, perhaps if you're completely immersed in Hibernate, JPA and SQL, you might be able to isolate yourself from browser-script, but otherwise you need to know it.

    The consequences of client side scripting

    And what is the consequence of this? It means that highly competent Java or C++ programmers find themselves humbly asking questions on the Internet that start out with a preamble such as: "I've done this a thousand times using Java, but how do you do it using JavaScript?"

    Like it or not, polishing off an enterprise application and providing the functionality and user experience that today’s application clients expect requires a knowledge of JavaScript. It's not only a fact, but it's also a sad reflection of the lack of progress that's been made in terms of both server-side technologies and client side standards, forcing developers to move away from their core competencies, and making them tinker around with a client side script that they never, ever, cared to be adept at in the first place.

    What's the alternative?

    Maybe the emergence of HTML5 based technologies, or the uptake of frameworks such as GWT or Vaadin, will reduce the need for enterprise developers with strong Java or C skills to post cries for help on StackOverflow, but in the meantime, learning the basics of JavaScript might not be such a bad investment of an enterprise developer's time.

    www.dodgycoder.net: StackOverflow's Programming Language Bias

    Now Go Learn some JavaScript:

    JavaScript: The Definitive Guide
    JavaScript: The Good Parts
    JavaScript, A Beginner's Guide
    Murach's JavaScript and DOM Scripting

    Threaded Messages (18)

  2. Rest of them were screwed by lock-in hungry browser vendors

  3. Apache Pivot[ Go to top ]

    The alternative to clientside Javascript would be bad old applets. But there are new applet-based technologies, too.

    Anybody tried Apache Pivot?

    http://pivot.apache.org/

  4. Alternative to JS[ Go to top ]

    No brainer as an alternative to JS.

    Flex/ActionScript.

  5. Alternative to JS[ Go to top ]

    Adobe reportedly will announce the end of Flash Player for mobile devices: http://www.engadget.com/2011/11/09/adobe-reportedly-will-announce-the-end-of-flash-player-for-mobil/

  6. Flex is dead[ Go to top ]

    Flex is dead, Adobe just announced its dropping mobile app support after the next version so expect a 5 year window before end-of-life.

  7. I'm not one for knee jerk reactions. If you read what Adobe is killing, you could see that the Flash plugin for Mobile browsers is what is being phased out. Flex/Adobe Air is still going strong and will continue to grow strong. I can see their point, since you can run Flex apps on Android using Adobe Air. No need to have a plugin in the browser.  On the other hand, Flex on iOS is still not supported. But. Who cares. My client base are Physicians. They don't like spending $700.00 on an IPad when a XOOM can be purchased for $450.00

    I will still champion Flex/ActionScript over that Monstronsity better known as JavaScript for building large complex enterprise front ends that have a cool factor, and, can easily integrate with a J2EE stack such as JMS and EJB.

  8. Flex is bad choice[ Go to top ]

    While JS is not ideal flex is outright bad choice for web development. It is proprietary, needs plugin, does not produce html. The web's lingua franca is html+css and we shouldn't fragment it. It is possible to consider either improving js or introduce new web wide scripting standard like Dart. If anybode doesn't want to bothered with browser scripting there are java web gui component frameworks that generate html.

  9. Who writes the checks !![ Go to top ]

    Those are your arguments against using Flex. Pretty thin arguments. After all. I'm not sure abot you. But.  I Design/Implement UX for end users. So. far. The scoreboard reads, users opinions on the Flex apps I have written 10, developers opinion 0. I don't write code for other developers to bless the implementation. I'm ONLY interested in providing the best possible UX for my clients.  And. Until something better comes along, I'll stick with Flex/ActionScript. Is there is a next best thing, fine, just don't tell me that the next best client technology is HTML5/JS. Because. Its NOT.  Besides, why not fragment. Free country, at least here in the US, and I think outside the box. So. Free thinking is what breeds creativity. The not fragment argument is a poor one. If every one thought like you. We would have one computer langauge for everything. One type of computer, one OS, on..and on.. Pretty dull, uninspired world. You get the picture.

  10. I personally find Javascript hard because of lack of strong typing and good library support. The same happens to me when using Objective C. For that reason, I preffer using GWT to writting pure Javascript. With GWT you can use really cool frameworks, such as GIN (type-safe IoC), take advantage of Java IDEs, using/building libraries (JARs), etc.

    Just my 2 cents

  11. Check STJS[ Go to top ]

    http://www.theserverside.com/news/thread.tss?thread_id=63199

  12. Or try ItsNat[ Go to top ]

    JavaScript is just one language to manage DOM and CSS in client, what if you can code the same kind of code in Java and executed in server (generating JS under the hood) using Java W3C DOM APIs?

    This is how ItsNat works, ItsNat simulates a Java W3C browser in server, the client browser is automatically in sync with the server.

     

  13. What does this do for me ??[ Go to top ]

    In my opinion. Client side technology should stay on the client. I have not seen anything better at giving the end user a compelling and inuittive UI as Flex/ActionScript. I remember some time ago using Echo to develop a web application. It was a nice interface. However. I realized I was using this technology to avoid having to code in JavaScript. Which most developers I know don't like coding in JavaScript.

    With ActionScript/Flex. You have a fully developed and mature OOPL. Complete with try/catch blocks, RPC, strong typing, event driven environment. The icing on the cake is, the way that the language is specifically designed to work on graphical objects. Try doing an easing-in transition of a given graphical object to a given location on your UI stage, while moving objects that are currently in that same space to another location with JavaScript. See how much code you have to write to get that done. Using Flex/ActionScript. Its a simple matter of creating a transition object and supplying it with parameters. Boom. Done. All of about 10 lines of code.

     

     

     

  14. Jerk[ Go to top ]

  15. Jerk[ Go to top ]

    I don't know if you got it... You can make much more with Java Script BECAUSE it's not type bound! You can make so much "shit" with it. Look at all the Frameworks using JS. Being open means, that you accept the fact, JS is "IN" and you need to use it. When you are so "open" for new aproaches, why do you denounce the idea of having client technology on serverside? Look here: http://en.wikipedia.org/wiki/Ajax_(programming) and here: http://en.wikipedia.org/wiki/List_of_Ajax_frameworks

     

    The last link should annul your statement.

     

  16. I'll wear that Jerk hat proudly[ Go to top ]

    Hey Max(whatever your name is.  using your expanded version of the english language, your arguments. Really suck.

     

    I'll wear the Jerk hat proudly. If it means I don't have to get on the Monstrosity, better known as JavaScript, band wagon.

     

    I've used that putred language in the past. It can't begin to approach the power of ActionScript 3.0. OOP, lots of high order Math. All things that hackers want to avoid. So. Go ahead Max Hacker, hack your JavaScript until your throat goes dry. Work your JavaScript data structures until your eyes water in front of the monitor. Me. I'm going to apply Calc, and Trig to solve the same problems in one line of ActionScript code, what will take you dozens of convoluted JavaScript code.

    And. Yes. Client side technology, belongs on the client. And. By the way. Server sider rendering to the client. Is nothing new. To reiterate. Server side rendering technology was created so that developers could avoid writing JavaScript code. Period.

     

    Who writes the checks :)

     

     

  17. Those are your arguments against using Flex. Pretty thin arguments. After all. I'm not sure abot you. But.  I Design/Implement UX for end users. So. far. The scoreboard reads, users opinions on the Flex apps I have written 10, developers opinion 0. I don't write code for other developers to bless the implementation. I'm ONLY interested in providing the best possible UX for my clients.  And. Until something better comes along, I'll stick with Flex/ActionScript. Besides, why not fragment. Free country, at least here in the US, and I think outside the box. So. Free thinking is what breeds creativity. The not fragment argument is a poor one. If every one thought like you. We have one computer langauge for everything. One type of computer, one OS, on..and on.. You get the picture.

  18. http://www.spoon.as/2011/adobe-announces-intention-to-donate-flex-sdk/ with angry reaction from users: http://forums.adobe.com/message/4021343

    Still unconvinced?

  19. The SDK has been open source for a while now. Only now. It will be maintained by one govening body. That's actually a good thing. I just love it when people make attempts at misdirection.